Influence

I have recently been reading Influence - Science and Practice by Robert B. Cialdini. So far, it seems to be one of those universal business books that could be considered a must read for people in all industries. This topic should be of particular interest to Product Managers, many of whom are tasked with exerting widespread influence while possessing only narrow authority. This book provides insights that you can use to make both business and personal decisions.

In this book, Cialdini describes what he calls the “6 Weapons of Influence”. His weapons are actually 6 categories of triggers that have a tendency to start “fixed-action patterns” in humans. Cialdini attempts to alert us to the ways in which “compliance professionals” try to trigger automatic responses from their audiences. The six categories these devices fall into are:

Reciprocation - How a free gift makes us vulnerable to undue influence.
• The sense of future obligation within this rule makes possible the development of various kinds of continuing relationships, transactions, and exchanges that are beneficial to the society.
• By starting with an extreme request that is sure to be rejected, a requester can then profitably retreat to a smaller request (the one that was desired all along), which is likely to be accepted because it appears to be a concession.

Commitment and Consistency - Even a small commitment makes us act consistent with that commitment.
• In society, good personal consistency is highly valued and provides a beneficial approach to daily life.
• By being consistent with earlier decisions, one reduces the need to process all the relevant information in future similar situations; instead, one merely needs to recall the earlier decision to respond consistently with it.
• Within the realm of compliance, securing an initial commitment is key.

Social Proof - How we look to others when we are uncertain.
• When people are unsure, when the situation is ambiguous, they are more likely to attend to the actions of others and to accept those actions as correct.
• People are more inclined to follow the lead of others that are similar to them.
• The principle of social proof can be used to stimulate a person’s compliance with a request by informing the person that many other individuals are or have been complying with it.

Liking – People prefer to say yes to individuals they know and like.
• Recognizing this rule, compliance professionals commonly increase their effectiveness by emphasizing several factors that increase their overall attractiveness and likeability.
• Attractive people are more persuasive both in terms of getting what they request and in changing others’ attitudes.
• Increased familiarity through repeated contact with a person or thing normally facilitates liking.
• Upon recognizing that we like a requester inordinately well under the circumstances, we should step back from the social interaction, mentally separate the requester from his or her offer, and make any compliance decision based solely on the merits of the offer.

Authority - How we tend to obey perceived authority.
• The strength of this tendency to obey legitimate authorities comes from systematic socialization practices designed to instill in members of society the perception that such obedience constitutes correct conduct.
• When reacting to authority in an automatic fashion, there is a tendency to do so in response to the mere symbols of authority rather that to its substance.
• It is possible to defend ourselves against the detrimental effects of authority by asking two questions: Is this authority truly an expert? How truthful can we expect this expert to be?

Scarcity – People assign more value to opportunities when they are less available.
• When a message has been received, it is more effective if it is perceived as consisting of exclusive information.
• Scarce items are heightened in value when they are newly scarce and we are most attracted to scarce resources when we compete with others for them.
• In defense, we might try to be alert to a rush of arousal in situations involving scarcity. Once alerted, we can take steps to calm the arousal and assess the merits of the opportunity in terms of why we want it.

Part of Cialdini’s purpose is to alert readers to the ways in which unscrupulous people attempt to exploit these triggers for their own purposes.
There are of course also legitimate uses of these principles when attempting to persuade an audience. For example, many Product Managers would benefit from developing more extensive relationships amongst the developers in an effort to tap into Cialdini's "liking" category.

This is one of the best researched books I’ve read in a while and I think that everyone could benefit from reading it, both professionally and personally.

What Comes After Why?

As Product Managers, one of our roles seems to be to channel a 2 year old and ask “why, why, why”. Once we have gathered information, the team needs to make decisions. Sometimes we, the product managers, need to make recommendations and drive to decisions. How can we do this effectively?

I recently received some excellent training on making presentations, including information about a technique for beginning different types of discussions called framing. With framing, you use a pre-defined order to present information in a consistent and logical manner. Among the frames is a decision making frame, which is designed specifically for beginning a discussion in which you want to come to a decision. Conciseness, focus, and group alignment are a few key benefits of starting a conversation using this frame.

To begin a conversation using the decision making frame, you provide information in the following order:

1. State the situation
2. Briefly list any complications
3. Identify the key item you are trying to address via a question
4. State your solution
5. Provide three key advantages of your solution

Your goal is to present all of this information in 90 seconds or less. Once you’ve presented the information, you’re ready to receive questions and further explore the solution.

Group alignment is achieved primarily in the first three steps. By stating the situation, listing the complications, and identifying the question you intend to answer, your audience has a clear understanding of the topic at hand. Immediately stating your solution and its key benefits sharpens the focus of the discussion. Having a well-thought out and logical presentation of the information supports conciseness.

I find this technique to be quite comfortable to use. In fact, I used it in the first two paragraphs of this post. Since we are not communicating verbally, I tried to anticipate a few questions about my solution and answer them in more detail in the remaining paragraphs. I hope you give it a try.

Are There Lazy Programmers?

I had been planning on one more post in my series on Karl Wiegers’ latest book, but an interesting post from Steve Johnson over at Pragmatic Marketing caught my eye. In Another Negative Development Rant Steve poses the following question:

Must the product manager have to specify everything in the requirements or should the developers know how to be good?

The basis of Steve’s post is a recent software upgrade that didn’t quite live up to his expectations. As a result of the hoops he was forced to jump through, Steve decides to unleash his frustrations on “lazy” programmers who “don’t really care.” He closes the piece by concluding:

Product Managers shouldn’t have to specify everything; developers should know enough about their target environment and customer to know how to be “good.”

As much as I feel that Pragmatic almost always has great things to say, I have to part ways with Steve on this post. I too share his frustration with far too many software products that are obviously distributed by companies that could care less about the user. A certain producer of both consumer electronics and entertainment content will not see another dime out of me due to one miserable software experience after another (when they aren’t actually installing viruses on your system they might as well be). When all is said and done, however, I find it impossible to go straight from a poor software experience to hitting an engineer in the face with a pie.

Let’s take Steve’s example as an excellent case study. His problems arose when he upgraded from one version of his GPS unit’s embedded software to another and his saved information was lost. Is this a clear-cut example of developer negligence? As much as the user-centric PdM/QA/UED person in me wants to scream out an emphatic yes, the software manager in me overrules them all with a probably not.

Imagine that reliable market research shows that only 1 person in 10,000 ever updates the software on a particular electronic device just to “stay current” like Steve does. Doesn’t seem like that much of a stretch when you think back to all of those VCRs incessantly blinking “12:00.” Of the use cases for doing an upgrade, 99.9% of them involve a system that has somehow become corrupted and where the reformat and installation of a new version is the last best hope of avoiding a $300 paperweight. Given this usage pattern, would it make sense to invest the time and energy to design/code/test the perfect upgrade solution that saves all of the user's previous data? Do the math.

• 1 in 10,000 voluntary upgrades
• 1 person year at $100K to design/code/test upgrade solution
• 1 million units sold
• All people impacted likely won’t repurchase their next widget from same company
• 5% net profit to manufacturer on $300 MSRP price

With those numbers, the potential bottom-line impact of not doing the upgrade is only $1500 versus the direct cost of $100K to do the upgrade. Even if you increase that potential impact 10x under the theory that 1 unhappy customer tells 10 friends, you are still looking at saving at least $85,000 by not building out the upgrade path. The right thing to do? Certainly arguable. Economically rational? Without a doubt.

Is this scenario the root cause of Steve’s frustration? I doubt it. Far more likely is the following scenario.

Product Manager – We need to spend some time thinking through the upgrade process for the update revisions to the firmware on last year’s model.
Business Sponsor – Upgrade process…I don’t think so. BigScaryCompetitor is releasing the MagnaWidget9003 this quarter and we can’t get left behind. I need every available engineer on our MegaDooDad2K6 release.

Development Manager – What about the upgrade process for this thing…how should that work?
Product Manager – Unfortunately, there just isn’t budget to do this thing right. As it is, the only reason why we get to do the patch release we all wanted is because of the bad write-up in Consumer Reports.

Development Manager – You’ll notice that there are no specs for an upgrade path. The powers at be, in all their typical wisdom, have decided it isn’t necessary.
Software Engineer – Do they do the business school lobotomy during matriculation or commencement?

I agree with Steve in that there is some set of inalienable “good things” that developers should be able to do without being told. I am guessing, however, that my list is probably going to be a whole heck of a lot shorter than his. Regardless, adhering to this list is not going to lead to great software. At the end of the day, I believe that the overwhelming majority of the responsibility for the software user experience rests with the entire organization. From the people who intimately know the market, to the people who write the requirements, and ultimately to the people who sign everyone’s paychecks, there are far more likely failure points in the chain before the engineer gets involved than after.

The Magic of 7-9

If you recall from psychology 101, most people can only hold 7-9 items in their short term memory. To learn more pieces of information, you need to transfer those items to your long term memory. There are two ways that you can do this, either by rote memorization or by creating a deeper understanding of the items. I am not really capable of memorizing thousands of requirements, so this human limitation has implications for working with requirements.

On a recent project we were given a set of around 500 pseudo-requirements. To this we added another 800, for a total of approximately 1300 pseudo-requirements. These pseudo requirements were statements of need made by business and technical users that were not well formed requirements and in many cases made no sense at all. We went through this list several times with the client to clean up the pseudo requirements and turn them into actual requirements by looking only at each requirement in isolation. However with such a large list it was impossible to retain the information to be able to make sense of the requirements as a whole.

As a first step we broke the requirements into 23 categories that made sense to the client. We worked with them to make the categories as orthogonal as possible and created strict definitions for what types of requirements would go into each category. We then began to categorize each requirement. After removing many duplicate and nonsensical requirements, we ended up with about 900 good requirements with about 40 requirements in each category. With the requirements broken up by category we had a much easier time understanding what we had and we began to work through the requirements not as individual requirements but as to how they related to each other. This made it possible to remove the duplicates and begin to find holes and commonality between requirements.

Even with 40 requirements it is difficult to find missing requirements, so in the next step, we worked to segment the requirements yet again. After looking at the low level requirements in each category, we developed around 5 high level requirements for each category that captured the essence of the category. We then mapped the low level requirements to the high level requirements with about 8 low level requirements for each high level requirement. Once we did this we were easily able to manage the requirements. In addition, this mapping enabled us to find additional high level requirements when we could not map a low level requirement to an existing high level requirement and enabled us to much more easily find missing low level requirements when a high level requirement did not have many requirements linked to it.

We ended up doing several other mappings, including to use cases, systems and entity-relationship diagrams (ERDs) but the mapping between 23 categories to 120 high level requirements to 900 low level requirements was the first critical step in creating the structure necessary to be able to comprehend a very large number of requirements. As a side note we actually created another set of 4 categories that we mapped our 23 high level categories to as well. I don’t think it is a coincidence that our natural tendency was to only have around 8 items in each category before being forced to decompose to the next level of detail.

The take home lesson here is that to properly review, understand and even remember a large number of requirements, you must decompose them into logical units. The human brain has a hard time working with more than 7-9 elements at a time and so the result is that you will need to categorize your requirements into natural groupings of 7-9 requirements and you will need to categorize your groupings similarly.

What Is the Right Level of Detail?

A couple of weeks ago I presented an overview of More About Software Requirements – Thorny Issues and Practical Advice by Karl Wiegers. Today, I am going to drill down a little bit further into one of the sections that I thought was particularly well done.

Part V of the book is titled On Writing Requirements and it presents a detailed tutorial on some of the tips and techniques that Karl has seen work successfully during his years of requirements work. The section includes 5 chapters:

• 12 - Bridging Documents
• 13 - How Much Detail Do You Need
• 14 - To Duplicate or Not To
• Duplicate
• 15 - Elements of Requirements Style
• 16 - The Fuzzy Line Between Requirements and Design

Karl starts Chapter 13 with a key question that I believe does a fantastic job of capturing the crux of the “how much detail” discussion:

Who do you want to have making requirements decisions and when?

In my opinion, too few organizations follow the advice that Karl presents for answering this question. His suggestion is that companies need to balance cost and risk as they seek to determine how much information needs to be included in the final requirements. Simply put, the amount of detail included in the requirements should be determined by calculating the risk that would be involved in allowing developers to fill in whatever gaps remain. Unfortunately, my experience has been that many organizations are not able to evaluate this equation quite so dispassionately. In many groups, there are long wars waged over the amount of detail that is “sufficient” with large amounts of energy expended on what essentially boils down to a turf war.

A great example of this that I have witnessed is from a company where the founder was still CTO. He wanted nothing to do with formal requirements for the entire organization since the people on his team didn’t need them - they were the domain experts who best understood the users’ needs and how to solve them. Unfortunately, what he didn’t acknowledge was that the ability of the development staff to live up to this expectation decreased drastically once you moved beyond the CTO’s immediate orbit. What may have been true for the core team that had been around for years was anything but for some of the people that had subsequently joined during the growth phase.

As expected, Karl does not come out with an answer as to what level of detail is “just right.” Rather, he presents a spectrum of situations where the level of detail required will shift from “less” to “more.”

More Detail Needed

• Development will be outsourced
• Project team members are geographically dispersed
• Testing will be based on requirements
• Accurate estimates are needed
• Requirements traceability is needed

Less Detail Needed

• Customers are extensively involved
• Developers have considerable domain expertise
• Precedents are available
• A package solution will be used

Whether it was intentional or not, Karl seems to subtly point the reader towards the “more detail” end of the scale. For each of the bullet points above, he provides a few paragraphs of explanation. When describing the “more detail” situations, Karl is uniformly positive in what he has to say. The “less detail” descriptions, on the other hand, include many negatives. For example, the phrase “watch out” appears repeatedly when discussing the scenarios that call for less detail. I can understand Karl wanting to explicitly warn readers who might jump too quickly into the “less detail” end of the pool, but I think the section could have been made stronger if he had included similar “gotchas” when discussing the “more detail” situations.

All in all, I believe that Karl effectively used this section of the book to tackle a tricky question. Trying to find the right level of detail for a requirements document will almost always be a challenging judgment call for an organization. The odds of successfully navigating this decision in your company can be increased however if you make a conscious, rational examination of your unique situation and carefully evaluate the tradeoffs involved.

Why should we hire you?

This blog entry is going to be a bit of a departure from the norm. Tech people spend their time and effort creating a product or service. Sales people spend their time and effort defining the value of the product or service. I am in sales. Therefore, it is in that vein that I am posting this.

As much as we would love to have a prospective client look at us five minutes into our meeting as say, “You had me at hello.” (or maybe more appropriately, “You had me at requirements”) the more realistic expectation would be for them to ask, “Why should we hire Seilevel?”

That’s exactly what happened the other day. A very sharp, experienced gentleman turned to us early in our meeting and said, “What you do…eliciting and documenting the right requirements for software development, is something we do very well. And even if we didn’t we can outsource the development overseas for a fraction of the cost and they can send us a BA here to handle the requirements. Or we could hire one of the Top 25 Tech Consulting Companies and have them handle our requirements AND development. Why should we hire Seilevel?”

As confident as my co-worker and I are in Seilevel…as many times as we’ve seen our company wow our clients…we had no great answer. “We’re better!” or “Hire us and you’ll see!” wasn’t going to cut it with this guy.

Fortunately for us, he gave us enough time, and we were able to relate enough information such as client success stories, etc., that by the end of the meeting he actually had a list of reasons why his company would consider hiring Seilevel.

1. We’re local. Bringing in others from out of town adds to the cost…and eats up time.

2. We are process agnostic. We’re not going to force you to follow our process. The models we use are applicable to any process. In fact, he said because we’re process agnostic we would have a fresh perspective and we may see things that aren’t obvious to them because they’ve always done things the same old way. We wouldn’t come in with preconceived notions.

3. We have no “dog in the hunt”. We’re not here to push a product since we aren’t selling a requirements tool.

4. We specialize. Sure some may feel it would be more convenient if we were a “do it all” consulting company. But the fact is that if we were, we wouldn’t be as good at requirements. The bottom line is that software requirements are all we do.

Now while we are thrilled he saw value in out company, we are disappointed that we didn’t have a better, more compact answer for him when he asked. So that’s the point of this blog entry: It’s actually a challenge. To Seilevel’s employees, to Seilevel’s clientele and to anyone else that can answer the question, “Why should we hire Seilevel?’

After all…”You had me at hello” doesn’t really happen in business, unless it’s the movie business.