Writing Verifiable Requirements should be a rule that does not need to be written.  Everyone reading this has seen or created requirements that can not be verified.  The primary reason for writing requirements is to communicate to the team what they need to accomplish.  If you can’t verify that what the team delivered is acceptable, neither can the team.  This may be the most obvious of the rules of writing requirements – but it is ignored every day.

Verifiable Requirements – Revisiting

In 2006, I first looked at how and why writing verifiable requirements is important - as part of the ongoing series on the rules of writing good requirements.  The focus of that article was on testability, as is this one.  When visiting verifiability again, however, I will add that not only must specifications be objectively measurable, but so must goals be written so that you can identify when a solution has met the objectives that justified its creation.

Directly Verifiable Requirements

Most of the requirements we come across can be directly verified.  The only problem with these requirements is that they lack specificity.  The following example is almost verifiable, and only needs a little help:

• The web site must make it easier for users who use site search to find the products they want to buy.

This requirement presents the challenge of resolving the ambiguity of the requirement. This lack of specificity prevents the requirement from being verifiable.  You have to identify how much easier the site search process must become for users.  Findability is a more is better characteristic in the Kano Analysis model for defining requirements.

You have to acknowledge that making it easier to find what you’re looking for is better for users than making it harder – there is an upward slope to the function.  However, there are also diminishing returns.

[larger image]

• A search that includes “the perfect item” is massively better than a search that does not include what you are looking for.
• A search that includes the perfect item on the first page of results is significantly better than one that returns the perfect item on the second page of results.
• A search that includes the perfect item as the first result is only marginally better than a search that returns that perfect item as the second or third result.

Improving findability as articulated above, from a user perspective, manifests in value to your company in two ways: immediate revenue impact and indirect revenue impact.

The immediate impact can be measured in terms of increases in commerce.  The indirect impact results from improving the user experience.  These improvements in experience result in increased word of mouth, as users altruistically encourage others to visit your website, and also result in an increase in satisfaction causing users to return to your site more frequently and make more purchases from you.

You can measure these impacts in terms of

• Conversion percentage (percentage of people who search and then purchase the products found in the results)
• Revenue attributed to users who search (an absolute measurement of purchases of products found via search)
• Site traffic levels (the number of people that visit your site over time)
• Visitor-recency statistics (the amount of time that elapses between return visits for returning visitors)

Conversion percentage, for users who search, normalized against users who do not search, is the most isolated (from other variables and noise) and fastest responding (as a delayed measurement of impact) measurement of the value of making it “easier” for users to search for the products they want to buy.

Your team will design different approaches to achieving these improvements.  You have to estimate both the cost and the potential benefit of each approach.  Balancing cost estimates with potential benefits will yield the ideal requirement – perhaps a 10% improvement.  [Note: I've collapsed at least another article's worth of balancing cost versus benefit, and multiple articles of "understanding and measuring site search" into one paragraph here, in hopes of staying on task with writing verifiable requirements.]

Rewriting the requirement as follows makes the requirement verifiable:

• Before: “The web site must make it easier for users who use site search to find the products they want to buy.”
• After: “Users who search on the site will be at least 10% more successful at finding the products they want to buy when using site search.”

Impossible to Verify Requirements

Often, stakeholders will present us with requirements that are impossible to verify (as requested).

• The home page needs to load fast.

At first blush, this looks just like the previous requirement (easier search is similar to faster page load).  You can use the same techniques to determine a measurable “requirement” like “the home page needs to load in under 1 second.”  However, that’s not a good requirement, because it is not an implicitly valuable requirement.  This statement provides no insight into why a fast-loading home page might be valuable to a particular user or why it would be valuable to the company.

To address this issue, you have to meet with the stakeholder(s) and understand the actual underlying requirements.  You will ask why, determine motivations and underlying problems, and apply active listening skills to discover the underlying requirement.

The problem is that the statement, “the home page needs to load fast” is a specification.  In Requirements Documents – One Man’s Trash…, I first used the following diagram to show how different people in the process of designing software view their piece of providing a solution.

A developer may receive a spec – “home page must load in under 5 seconds” and feel like the why component is perfectly well defined – it is a matter of context and perspective.  Another way to think about this is that the problem is with the problem statement.

A product manager, however, needs to do research that follows a path like the following:

Given that we are building an eCommerce website, we know that people have expectations around page load times (per Forrester / Akamai report (requires registration)).

[larger image]

Further, those expectations manifest as people abandoning slow-loading websites (from the same report).

[larger image].

We know from this market research that page-load times (for websites) represent another more is better Kano attribute, but one that has must be characteristics at the extremes.

[larger image]

While more speed is better, what the market research reveals is that for any given person, there is a minimum-speed threshold, at which speed is a must-be characteristic – too slow, and you lose customers (immediately).

A  combination of market research and elicitation will reveal that there is a true underlying goal of being fast enough to satisfy as many users as possible.  Combining this with practicalities of scaling your solution, and the associated costs; in the context of a particular solution design (an eCommerce website), you will arrive at a goal that allows you to rework your requirement so that it is verifiable.

Note: The requirement in this example is a subordinate requirement to a goal focused on maximizing conversion percentage (the percentage of customers who visit the site making purchases) – with a recognition that a major source of non-conversion is abandonment of the site, and that a large contributor to visitor abandonment is page load times.  An Ishikawa (or other model) will help you articulate this complexity and formulate requirements at a level of abstraction that is both valuable and actionable.

Rewriting the requirement as follows makes the requirement verifiable:

• Before: “The home page needs to load fast.”
• After: “No more than 10% of potential site visitors will abandon our site before viewing the page.”

Indirectly Verifiable Requirements

Some requirements are impossible to literally verify, and must be inferentially verified.

• The site must support 1 million visitors per day, with a peak of 10,000 simultaneous with page-load times under 5 seconds.

Models are Models, Not Reality.

Imagine trying to create a test by organizing a million visitors to hit your SaaS web solution on the same day, with at least 10,000 of them hitting the site simultaneously.  That is completely impractical.  That doesn’t however, invalidate the requirement or make it untestable.  The combination of modeling, hypothesis formulation, and extrapolation gives you a reasonable way to verify that your solution probably meets this requirement.

You’re already used to the concept that models are representations of reality – think about the maps you use – a map may have a scale like one inch equals one mile.  The map is a model of reality.  A map where one inch equals one inch would be impractical.

An effective approach to measuring this type of scalability requirement is to simulate users (with load testing and realistic user-behavior scripts) with automation.  That takes care of most of the coordination problem.  However, the cost of simulating a million users and 10,000 simultaneous users is high.  You can, more realistically, measure the site’s performance when 10, 100, and 1,000 simulated users simultaneously access a server.  You can extrapolate from those results to estimate how the system is likely to perform under 10,000 user loads.

Note: Extrapolation is dangerous (follow the Elvis link below)- you have to justify why extrapolation holds true, and identify when it does not, to minimize the risk of invalidating your hypothesis.  Make sure you have confidence in the engineering prowess of whoever is doing your extrapolation and modeling.

[see tip #5 of these ROI calculation tips for the Infinite Elvis anti-pattern]

While this requirement does not to be rewritten in order to be verifiable, it does need to be augmented:

• Original: “The site must support 1 million visitors per day, with a peak of 10,000 simultaneous with page-load times under 5 seconds.”
• Additional: “Testing of the site must show that 500 simultaneous users following <user script X> will yield no more than 1% page load times over 200 ms.”

Conclusion

Every requirement you write must be verifiable.  When you can’t verify something, and can’t rewrite it into a verifiable form, that should be a sign that either it is a vision statement or a red herring.  Vision statements guide how we approach creating products and engage markets – they are valuable, but they are not requirements.  Red herrings are well-meaning but ill-advised inputs into the process that need to be culled – they are neither valuable nor requirements.

Make sure all your requirements are verifiable.

Writing unambiguous requirements is about understanding what is written, and what is read.  Without a clear understanding of your market, you can’t write unambiguously.  Even when you understand your market, you risk writing something that is ambiguous to your readers.  Documenting requirements is about communication.  Don’t break this rule, or you’ve wasted all the energy you spent understanding your requirements.

Unambiguous Requirements – Revisiting

Fifty months and five days ago (another grin), I wrote about the importance of writing requirements so that they can be clearly understood.  Writing requirements so that there is one, unambiguous, interpretation of what you wrote.  This article is the seventh in a series on the rules of writing good requirements.  In that version of the article, I focused primarily on language ambiguity, and framed the discussion in terms of ambiguity to the writer and to the reader.

As part of improving that series, I am revisiting each of the articles now that I have fewer hairs and the remaining ones are more gray.  The same framework still applies, but will be expanded in scope, using the following modified definitions of the framework.

• Ambiguity for the Writer – not having a clear interpretation of the requirements.
• Ambiguity for the Reader – requirements that, as written, can be interpreted in more than one way.

It takes two to tango.  To lead, you have to know where you’re going.  To follow, you have to know where you’re being led.  The same is true with requirements – you have to know what you’re writing, and how your writing will be read.  Misinterpretation of requirements is the source of over 40% of all software defects.

Ambiguity for the Writer

When you don’t know why you’re developing a particular set of requirements, it is because you either don’t have sufficient understanding of your market, or of your corporate objectives.  While it is always a lack of knowledge, sometimes, that lack of understanding is insidiously hidden.  You, as the writer of requirements, are the reader of the market – and what you’re reading is likely to be ambiguous.

For Whom You Are Designing

The most overlooked element I’ve personally seen in product creation is failing to understand who the users and buyers of your product will be.  I wanted to type “forgetting to understand,” but I struggle to imagine someone who understands the value of defining user personas and buyer personas, who then forgets to define them when gaining an understanding of their market.

The reason that this is an ambiguity issue is that when you fail to define personas explicitly, you define them implicitly.  An implicit persona is an ambiguous persona.  Alan Cooper named this anti-pattern the elastic user, and the problem manifestation as failing to provide insight to guide design decisions.  When you have an ambiguous user, you lose what Frederick Brookes calls the clarity of design. This results in at best a mediocre product without a core idea or aesthetic.

Different users value the same solutions differently.  Users vary in competency, and therefore have varied personal goals as they learn how to better use your product over time.  When you don’t identify who the user is, you prioritize requirements without insight into what is important to the undefined, elastic, and ambiguous user.

The readers of your requirements are trusting that you will prioritize requirements correctly – but you can’t, because you lack an understanding of who the users will be.  You therefore lack an understanding of which problems are valuable, and which problems are more or less valuable than other problems.  This ambiguity makes it particularly difficult to write valuable requirements.

Precision in Language

The other aspect of writing unambiguously is in using language that has meaning.  Using words like “can” and “may,” is imprecise in requirements.  ”The system can respond in under three seconds.”  Does that mean that it must respond in under three seconds?  Does that mean it is acceptable if the system responds in twenty seconds?  This is an area of overlap with the rule of writing measurable, verifiable requirements, so I won’t go into more details here.

Another source of imprecision in language, not only for the reader, but also for the writer, is jargon.  You should never use jargon, as you have no way to know if your reader will actually interpret the jargon terms correctly – as readers often vary in the depth of their domain knowledge.  Jargon is also a high risk of ambiguity source, precisely because it is jargon.  Jargon is short-hand for communicating efficiently among domain experts.  Are you enough of a domain expert that you are confident that you absolutely, unambiguously understand the accepted meaning of the jargon term?

Hopefully, you’ve achieved a perfect understanding of your market.   Long-time readers will know that I’m joking.  Market analysis suffers from it’s own Heisenberg Uncertainty Principle – if you actually did manage a perfect understanding, the market will have changed – the best you can hope for is a statistical understanding of the behavior of your market.  You can document your interpretations, assumptions, and decisions – achieving clarity in your requirements – at least from your point of view.

Ambiguity for the Readers

As I mentioned earlier – using requirements is a dance – and it takes two, both the writer and the reader.  You need to write requirements so that they can only be interpreted in a single way, or you will stumble.

“You keep using that word.  I do not think it means what you think it means.” – Inigo Montoya (IMDB)

Shared Language

The word “shall” as in “the system shall…” can be misinterpreted when your readers don’t share the same native language as you – which is why you must always use “must.“

Some good research on vocabulary size data for comprehension of english can be found here. The average native english speaker knows 20,000 word families. With a vocabulary of 5,000 english words, only 98.5% of the words in a given text will be understood. 5,000 words is a lot for a speaker of a second language (3,000 words is considered aworking knowledge).

An analysis of the reading-level at which a document is written can be helpfull in identifying if the language is likely to be challenging for readers with limited vocabularies. The Gunning-Fog Index provides a measure of the education level at which a text is written.

Writing Unambiguous Requirements (2006)

Can’t write that section any better :).

Ambiguous Use of Language

I had the privilege to attend a presentation by professor Daniel M. Berry in 2007, on the ambiguous use of language in business rules and requirements.  In that presentation he referenced The Ambiguity Handbook that he authored (80 page pdf), which I just re-read last week.  There are many good examples of ambiguity in the use of English in business documents.

The following are some of the sources of ambiguity, for which I entirely credit professor Berry for pointing out to me.  I’ve only added some illustrative examples:

• Plurality Causes Ambiguity.  Consider “Emails must include sender addresses” and “emails must include recipient addresses.”  Must each email include one sender address and one recipient address?  Must each email include multiple sender addresses?  Solution – don’t use plural subjects.  ”Each email must include a sender address” and “each email must include recipient addresses.”
• Associative Ambiguity.  Professor Berry calls this the parenthesis problem.   What does “A and B or C” mean to you?  Does it mean “A, and either of B or C” or does it mean “either C, or both A and B” when you read it?  In math and programming, we learn very specific rules for how to interpret these types of structures.  We are also given parentheses, that we can use when we want to be specific and unambiguous.  The reader of your requirements is not a compiler, so don’t assume that she will interpret this the same way that you do.  Solution – use parentheses and explicit language to eliminate ambiguity that would arise from ignorance of the associative property.
• Anaphor Ambiguity.  For non-linguists: “don’t use pronouns.”  I love the example that wikipedia uses – “We gave the bananas to the monkeys because they were hungry.  We gave the bananas to the monkeys because they were ripe.
  
  We gave the bananas to the monkeys because they were here.”  The pronoun, “they,” has an ambiguous binding.  Should “they” be a reference to the bananas or the monkeys?  In each of the first two sentences, you could reasonably assume that the reader will properly bind “they” to the monkeys and bananas respectively.  In the third sentence, an assumption of how the reader will interpret “they” is not reasonable.  Reasonable assumptions are still ambiguous – and the context is less likely to be obvious – so don’t use pronouns and rely on readers to bind them to the appropriate nouns.  Solution – repeat the noun for every reference.

Incompleteness Ambiguity

Unwritten requirements are by definition ambiguous.  You must not assume that unstated requirements will be implemented.

A security exploit was recently discovered (and eliminated) in Facebook.  Previously, if you attempted to login to Facebook with an email address and a password that did not match the email address, Facebook would present you with a typical “failed login” screen and a link to reset your password.  However, in an effort to be friendly, Facebook would also include the first name and last name that were associated with that email account in the friendly warning message.

That is nice, except it is a privacy problem, and anyone who knew about this before could use the login page to discover the first and last name to associate with any email address.  ”Bad people” with email address lists could discover the name to associate with many of those email addresses – allowing more sophisticated phishing or social engineering attacks.

The requirement to not provide any personal information when a user fails a login attempt was almost certainly an unwritten requirement.

Conclusion

Precision in your writing will reduce ambiguity in your requirements.  Active listening will help you discover when ambiguity has slipped through your editing net.  You can never completely eliminate this problem, but you can improve.  You must.

vs.

What happens when billionaire media magnate, Rupert Murdoch, pits his idea against a Nobel-prize winning idea from the beautiful mind of economist and mathematician John Nash?

When you act on what you hope your market will do, instead of what you predict your market will do – you’re in trouble.

This is a story about understanding your market, and an example of using game theory – specifically, the Nash Equilibrium in “non-cooperative game theory” to predict market responses to your products.

Murdoch’s Idea

To sum up the particular idea I’m talking about – Mr. Murdoch has put the Times of London behind a pay-wall (you have to subscribe to access the content online), and removed the articles from Google’s search index.  He did this because he believes that people accessing the content for free are “stealing it” and that the only way to make money in the news business online is by forcing people to pay for content.  For more nuanced and deeper discussions of what Mr. Murdoch is doing, check out these articles from The Atlantic explaining what he’s attempting, the Editor & Times report of a 66% drop in traffic, Newser’s investigative journalism of what’s happening inside the company, or Business Insider’s take on the matter.

My opinion is that Mr. Murdoch expects his market will respond the way he wants them to – by subscribing to the online version of the Times of London – in stark contrast both to pundit predictions and what professor Nash’s Nash Equilibrium model of non-cooperative gaming predicts will happen.

As results have finally started surfacing, they appear to completely support what game-theory would predict and utterly refute what Mr. Murdoch would have hoped for.

Game Theory for Predicting Market Behavior

I was enthralled by Scott Steven’s lecture series, Games People Play: Game Theory in Life, Business, and Beyond – a DVD set of a series of lectures from The Teaching Company [link goes to Amazon].

Understanding your market involves not only knowing what problems your customers face, but also predicting how your competitors will behave.  Competitive analysis is not just capturing a snap-shot of their products and positioning today, but also forming predictions of how they will respond to the disruptions you will create in your market by innovating.  Markets are not static – you have to understand both how your customers’ needs will evolve and how your competitor’s offerings will change, in order to understand how your product will perform.

One of the “games” in game theory is called The Coordination Game, and it is the one that captures Mr. Murdoch’s conundrum.  The coordination piece of this game is in acknowledging that what you do (to pay-wall or not to pay-wall), and what your competitors do (pay-wall or not) are interdependent decisions, of which you only control your own decision.

You can’t (successfully) unilaterally decide what you are going to do, without taking into account what your competition is going to do.  And vice-versa.  That’s the part that makes it hard – there is a circular reference that has to be resolved.  I suspect that’s the source of elegance in the Nash Equilibrium – he realized that there are “stable” and instable combinations of the decisions – yours, and your competitors.

The Pay-wall Coordination Game

Mr. Murdoch and “everyone else” (his competition for consumers of news) are both faced with a choice – should they allow free access to the articles, or not.  Free access to articles can generate revenue by two mechanisms.

The first is one of the freemium business models – billing Peter to pay for Paul – charging money to advertisers for access to viewer’s attention.

The second mechanic is by leveraging word of mouth – people reading your free article, then encouraging others to read your other articles.  This approach can either be used to get a percentage of people as paying customers (with a “leaky pay-wall” model that allows some free views, but encourages paid-subscriptions), or to get additional traffic that increases revenue from advertising.  One way to maximize this approach is by making your product implicitly viral so that it promotes itself.

Alternately, Mr. Murdoch, or any of his competitors can create a pay-wall, where only paying subscribers will have access to the content.  Presumably, certainly historically, a subscription model with the same level of readership – if that could be achieved – would generate more revenue for the publisher than either freemium model.

The crux is that we have tons of market data to show that “the same level of readership” simply will not happen.

There are four possible scenarios that can happen in this market -

1. Both Mr. Murdoch and “everyone else” institute pay-walls, making all online content available only to paying subscribers.
2. Mr. Murdoch erects a pay-wall, but everyone else continues to allow free access to content.
3. Mr. Murdoch allows free access to content while everyone else erects pay-walls to prohibit access to content.
4. No one erects a pay-wall, and free access is allowed to all content.

[Update 2010.07.21: Why "everyone?"  See comment #2 below]

In scenario 1, assuming people don’t just stop reading online, everyone wins – everyone charges subscription prices, achieving the maximum amount of revenue.  So why didn’t this happen?  Because the decisions are interdependent, and because the market is starting out in scenario 4.

Mr. Murdoch has moved the market (from his perspective) into scenario 2, which is clearly bad for him, in hopes that everyone else will move as well, to reach scenario 1.  Once Mr. Murdoch put the Times of London into scenario 2, then everyone else’s best move is to stay there.  No one else will join him, because everyone else never will.  The market, once stabilized in scenario 4 (the starting point) can never move to scenario 1 – without collusion, which is conveniently illegal.

Someone will always be there to refuse to move to scenario 1.  ”Everyone else” is destined to allow free access, or exit the market.

Understanding Your Customers

It is possible that Mr. Murdoch looked at the Wall Street Journal, which has a pay-wall, and said “I want to do that too.”  And perhaps he discounted all of this game-theory “nonsense” because if it worked for them, it can work for him – the model is BS.

However, I believe the Journal’s market is different, and it works for them for different reasons.  The market for business news pays a premium for immediacy and quality of information – because getting the best information first is worth a lot of money to them.  There are “free” immediate sources of business news information, but the market indicates that it perceives that information to be of lower quality.  And there are free high-quality information sources, without the immediacy.

The reality, which you can only get from understanding your customer’s goals – is that the business-news market is stable in scenario 1. It could be destabilized, by someone offering free, timely, high quality information.  If that happened, as professor Nash showed, the market would either re-stabilize in scenario 1 (the company that changes says “oops” and reverts their policy), or the market would transition to a stable state in scenario 4 (everyone offers free content).

The more concentrated the market [see: measuring market concentration], the more likely a reversion to scenario 1.  The more competitive the market, the more likely that it will stabilize in scenario 3.

Non-business news on the internet?  Very competitive.  And stable in scenario 4, no matter what Mr. Murdoch might hope.  Sadly, there are profits to be made in scenario 4, but they aren’t as appealing as the double-rainbow of scenario 1 – however impossible it is to achieve.

Attributions

The two photos at the start of this article of Mr.s Murdoch and Nash are licensed through the Creative Commons Attribution Share-Alike 2.0 Generic and the Attribution Share-Alike 3.0 Unported licenses, respectively.

All other content in this article is licensed per the Creative Commons link at the bottom of this page.

As product managers, we talk about creating the right solutions with our products. Understanding the very real problems our customers face, understanding the very real opportunities our markets present, and manifesting that understanding in a product roadmap.

Other than being “not as good,” how expensive is it to build the wrong product?

The Cost of Poor Quality

There’s an analog to the market dynamics of making poor product decisions – executing with poor quality. Many research studies and articles have identified the market impacts of poor quality.  This has become so well accepted that people today cite it like a law of physics (one example here based on this 1988 IEEE research by Barry Boehm and Philip Papaccio) as the “1-10-100 rule.”  The primary conclusion of that research is that ten dollars spent on fixing bugs:

• Costs and saves $10 when you catch (and fix) the bug during implementation.
• Avoids $100 in costs when you catch the bug during QA and send the product back to development (then test again).
• Avoids $1,000 in costs versus waiting until your customers catch the bug in the field, causing the team to remedy the problems, rush out a patch release, and/or go to heroic lengths to manage a PR problem.

This is an opportunity in front of your product team – a 100x payback from investing in quality during the development process.  Of course, be pragmatic about it - if the cost of testing exceeds the cost of bugs, don’t test.

This is not a solved problem, by any stretch, but the solutions and methods to solve this problem are well understood now.  In fact, a 2001 article by Barry Boehm and Victor Basili shows that in some cases, the labor costs to resolve bugs can be as low as 5:1 – when considering a subset of smaller systems, when using more “agile” processes.  That lowered ratio does not take into account the lost market opportunities and the costs of cleaning up collateral damage to your product – just the immediately realizable (and measurable) costs of resolution.

One very real problem, when talking about “bugs” is in defining what a “bug” is. And the definition of a bug is a matter of perspective. A developer can reasonably assert that “if it meets the spec it is not a bug, it is working as designed.” What if the spec is wrong? The developer may not be guilty, but collectively, your team screwed up. There’s a “bug” in the requirements.

What Is A Requirements Bug?

Now things are getting interesting.

If you wrote a requirement that you interpret as “A” and your developers interpret as “B” – you definitely have a bug – the team won’t build the right product. For each $1 you could spend making sure you have bug-free requirements, you could:

• Make sure you have a shared understanding of the documented requirements through active listening before development begins ($1). Following the Rules of Writing Requirements will help prevent this miscommunication.
• Wait until the engineering team is ready to demo their progress ($10). They will have to build it again, because they built the wrong stuff.
• Wait until development is complete and QA is validating that the code meets the spec ($100). This gets tricky if you are thinking “A”, the developers are thinking “B”, and QA is thinking “C.”
• In classic throw-it-over-the-wall mode, wait until the product is launched, and it is the wrong product ($1000). Assuming “A” was the right problem to solve, the cost of entering the market with a solution to “B”, leaving “A” unaddressed, is impressively high.

This gets interesting because the above assumes that “A” was the right problem to solve. What if “G” was the right problem to solve, and “A” was the wrong market problem? Even if everything (else) is working perfectly – you document requirements for “A”, the engineering team creates a marvelous “A” and it launches without implementation errors – you still fail, and incur the 1,000x cost of a failed product launch.

There is an even larger opportunity in front of your product team – a 1,000x payback on discovering and choosing to solve the right problems for your customers and markets.

• Would Palm still be independent if the Pre had solved a compelling problem?
• Why did Intuit have to buy Mint.com – could they have embraced the same customers with Quicken?
• What is Garmin going to do now that “free” GPS mapping and turn-by-turn directions are becoming ubiquitous? If it is “more of the same,” how much are they wasting?

Wrapping Up

I’m not aware of any studies that show that “requirements bugs” fit the same 1/10/100/1000 cost explosion model that “implementation bugs” exhibit. Emotionally, it “feels about right” to me – it passes my “sniff test.”

There are times when days of research would have been required to avoid or redirect a few hours of implementation effort on projects I’ve worked on. And I’ve seen man-years invested solving problems that didn’t involve much more research.

My intuition from products and teams I’ve worked with is that it probably averages out somewhere around 10x.

What does your gut (or your data – if you have some, post a link below!) tell you?

Consistency in writing requirements is important on two levels – strategic and tactical.  Tactically, you need to write your requirements with grammatical consistency, so that potentially ambiguous statements will be interpreted similarly.  You also need to write requirements that are logically consistent, so that you avoid “impossible” requirements and gaps of unspecified meaning.   Strategically, your requirements need to reflect a focus on markets and problems that are consistent with your business objectives and the vision your company is manifesting

Consistent Requirements – Revisiting

Thirteen hundred ninety-six days ago (grin), I wrote about the importance of grammatical and logical consistency in writing requirements – an emphasis on the tactical aspects of consistency in writing requirements.  This article adds a brief discussion on the consistency of the requirements you write.  This article is the sixth update of a series of articles on the rules of writing requirements.

Grammatical Consistency

[source]

Writing requirements is not like other forms of writing in one key way – you don’t want to vary the terms and language you use in your requirements documents.  Remember the critiques you received when you studied writing in school for a moment.  Your teacher told you not to repeatedly use the same word, but to use synonyms for that word – walked, ambled, stepped, capered, etc.  Those synonyms allowed you to create imagery and helped your readers avoid boredom.  Your teacher encouraged you to use metaphors that created even stronger imagery – flew, slogged, muddled, danced, etc.  Those metaphors allowed you to infuse emotion into your narrative and helped your writing come to life for your readers.

As Yoda said, “Unlearn, you must!”

Requirements are not a narrative.  Your primary goal is not entertainment, it is enlightenment.  Don’t use varying terms to describe the same action or object – use the same terms over and over again.  Don’t vary the modifiers of terms except when you are explicitly varying the context and referenced items – and then make certain that you use the same modifiers consistently for the same context and references.  When dealing with anything that has some complexity, provide a figure or diagram (possibly in an appendix or glossary) that explains the explicit meanings of each term and term-modifier.

For example, if you are defining requirements for a classification system for authored works, be specific about the definitions of author, editor, publisher, and reviewer.  You may also need to define a term that is used collectively for all of them, like creators.

You must consistently use the same voice  - ideally the active voice.  And of course, you must not use ‘the system shall.’ [There's a great debate in the comments on that article - one thing to note - all of the people on both sides of the debate emphatically expressed their consistent use of one form or the other.]

Logical Consistency

[source]

Logical inconsistency most commonly comes from expressing the same requirement twice.  If you use the exact same words to express a requirement twice, you’re being redundant and repetitive (grin #2).  Most likely, the second expression of the same requirement is both unintended, and worded differently – running the risk that it will be interpreted differently, and therefore inconsistently.

You will also create logically inconsistent requirements when you express mutually exclusive requirements.  These can be directly incompatible, like writing “the system must infer the value…” and “the user must provide the value…”   Or they can be indirectly inconsistent like “the animal must bark” and “the animal must be a cat” – which is logically inconsistent because cats cannot bark (thereby making at least one of the requirements infeasible).

Strategic Consistency

One of the elements that defines valuable requirements is that they “support your business strategy.”  In the context of value, that means you have created a decomposition model for how you intend to realize value – manifesting a strategy or a component of a strategy.

A strategy, however is not always defined by a single measure.  Your strategy could include financial metrics and targets, as well as a stated mission regarding customer service levels, and a long-term investment that is hoped to eventually return long-term rewards.  Your requirements, while not only completely defining the mechanisms for achieving value, must also be consistent with the other elements of your strategy.

For example, you should not take advantage of uninformed costumers when you have a core value of integrity – regardless of how effective that may be at meeting financial goals.  The requirements that articulated the (subordinate) goal of grifting your customers (to maximize revenue) would be inconsistent with the goal of operating with integrity.

Conclusion

Consistent Requirements are requirements that

• Are not in conflict with any of your strategic objectives, vision, or corporate goals
• Avoid logical inconsistencies
• Utilize consistent structure, terms, and grammar

One of my colleagues got into a debate with one of his colleagues about the differences between goals and requirements.  His opponent fired the following salvo: “[That] is not a business requirement in any company of the world…”

What you call your requirements is less important than how you communicate them.

Labels

I’ve worked with a lot of companies that use different labels to describe their descriptions of the problems that need to be solved. This is not another article about requirements versus specification (specification = design constraint, btw).

If you’re not a long time reader who’s followed the debates and discussions on this topic in the past, check out these articles and comments, where we’ve had some great discussions on that topic – with particular thanks to Roger Cauvin for keeping the debate front and center.

• Requirements Versus Design: Which is Which and Why
• Requirements Docs – One Man’s Trash is…

The central theme is that the debate about “what versus why” centers around differences in people’s perspective on the problem.

This challenge is not really about that (but it makes for good background).  The complaint my colleague received was really a critique of the way that the why of a set of requests was communicated and labeled.

Actionable Goals

Companies have strategic goals (increase shareholder value, gain market share, etc) that serve to guide the investments and activities of the organization.  However, for the teams that are creating products, those goals are too vague to be actionable.  I guess this is where my set of labels comes in.  I don’t think the labeling of a goal as a goal (versus labeling it as a requirement) is abstractly important, however, when people value making a distinction, here’s how I do it.

A goal is something your business (or user) is trying to achieve.  It is too abstract to have a single valid solution approach.  Once your business stakeholder(s) decide on a strategy by which they will achieve that goal, the business will define requirements for the actionable project(s) that execute this strategy.  This is an ideation step that lives inside the “why” box from a business analyst’s perspective.  Here’s an example:

Warehouse Manager

You’re in the IT department of a large company.  You’ve been assigned to support the warehouse manager (or COO, or vice president of order fulfillment or whatever).  Your warehouse manager is responsible for procuring the products that your company sells, keeping inventory on hand, and delivering those products to customers when they have been purchased.

Your warehouse manager is measured (or promoted) based on her performance relative to the following:

• The time that a customer has to wait between placing an order and receiving the product.
• The cost impact of warehouse operations on the products.

Your warehouse manager focuses on these two metrics because of your company’s goals – provide good customer service, be profitable, and grow revenue.  Those abstract goals influence product pricing – it must be low enough to grow revenue in the target markets, and be high enough to be profitable.  Since market pressures drive pricing decisions, typically a profitability target will then create cost-reduction pressures (profitability also influences pricing decisions, selection of markets, positioning within that market, etc).  A customer service strategy can also include a “you get your product quickly” component – as it does in this example.

Your warehouse manager now comes to you and says “I have an initiative to lower costs.”

Is this a goal or is it a business requirement?

Ultimately, it doesn’t matter what you call it, but for you to actually do something you need to know more.  That’s why my approach is to call it a goal.  Your warehouse manager’s problem is to lower costs.  You need to decompose that problem to understand how you (and your team) can do something to help her achieve that goal.  The reason you have to do that is that you need a problem statement at the right level of abstraction.

In elicitation conversations with your warehouse manager, you learn that all of the costs of operating the warehouse are allocated to the different business units, who operate as profit centers.  The warehouse operates as a cost center.  The warehouse manager treats each business unit as a customer, and provides a service of “fulfilling product orders” in exchange for funds that cover the costs of operation.  The allocation of costs is done per product that appears in the warehouse.  Since allocation is per product, it could be something like $1.30 per product in “warehouse costs.”  There are multiple sources of those costs (that are then allocated per product), and there are multiple ways to approach reducing the cost per product.

Your warehouse manager develops a strategy (probably a “mini-strategy” from the company’s perspective) to lowering costs.  She rules out “sell more products” as an approach, because she can’t control that.  She also can not affect her fixed costs (rent, depreciation, labor).

Eventually you discover that there is another cost hidden in the provisioning model – products are purchased, they sit in the warehouse for a while, then they are sold and delivered, and eventually money is collected from customers to pay for the products.  Your company has to pay in advance for the products, and doesn’t get their money back until funds are collected from the customers.  That money is “tied up in inventory” when it could have been invested otherwise – so there is a cost associated with high inventory levels, that directly correlates with the amount of inventory in stock.  When a new version / revision of a product is introduced, your inventory may become obsolete (it is definitely devalued).  And since markets are moving targets, your prospects of selling a product change over time – a risk that you will not be able to sell all of your inventory.

At the end of the day, the amount of inventory you have on hand has a cost.  The more you have, the more it costs.  A rule of thumb I heard 20 years ago was that inventory costs could be as high as 1/3 of the cost of the product for each year you keep it around.  If that is true, that is something like 0.5% added cost for every week the product is in inventory.  Here’s something the warehouse manager can potentially control.

Currently, your warehouse manager has 8 weeks of inventory on hand (on average) for products, which allows her to ship quickly.  She realizes she is adding 4% to the cost of the product.  She decides that if she can cut those costs in half, she will be a heroine.

Her business requirement is to reduce inventory levels from 8 weeks (on average) to 4 weeks (on average).  She also has a constraint that no more than 1% of orders be delayed by more than a day (due to running out of inventory).

Now you have requirements that are unambiguous and measurable.

Conclusion

Don’t trap yourself in worrying about the labeling of goals / requirements, but if you have to work with someone who does find that really important, before you call it a requirement, make sure it is at the right level of abstraction.  And of course, make sure you follow the rules of writing requirements.

You give your requirements to the engineering team, and they look complete.  The team builds your product, you launch it and the market soundly rejects it.  Why?  Because your requirements weren’t complete – they didn’t actually solve the problem that needed to be solved.

Complete Requirements – Revisiting

Going back almost four years, I wrote Writing Complete Requirements, as part of the Big Rules of Writing Requirements series.  That article centered on two key ideas of requirements completeness.

• Data, not opinion, is the most important input into determining completeness.
• There is no absolute way to determine the completeness of your requirements in advance.

Completeness is best measured by market acceptance, so technically you can’t know if your requirements were complete until your customers buy (or fail to buy) your product.  This doesn’t mean you should give up on this rule of requirements – you can still focus on, and improve, the completeness of your requirements.

Objective and Heuristic Assessment

Given a market problem and the associated requirements (which you can argue are actually the same thing), you can review those requirements to determine if they objectively appear to be complete.  This assessment is based on what you objectively know about your market (needs, opportunity costs, competitive alternatives, etc).  You can also apply heuristic, or logical analysis to identify gaps in the language of your requirements.

Objective assessment is the application of market knowledge (data) to determine if the nature of the problem is being addressed completely by your requirements.  A bird-feeding maven would know that the requirements for your bird feeder would be incomplete if they didn’t address the problem of squirrels stealing food from the birds.

Heuristic analysis is the identifications of logical omissions in your requirements, without the need to apply market insights.  A logician would know that the requirements for your bird feeder were incomplete if they didn’t address the need to refill an empty feeder.

When you’re writing requirements, you need to do both.  Heuristic analysis of your requirements will identify where your requirements do not fully solve the problems you already know about – an eCommerce checkout process without the ability to receive payment, for example.  Objective assessment will help you identify the problems that you overlooked but need to solve – the need to allow customers to have different billing and shipping addresses when placing an order online, for example.

Complete Requirements for Incomplete Solutions

Don’t confuse having complete requirements (a good thing) with completely solving a problem (not always a good thing).  In agile development, the idea of satisficing is key to scoping individual iterations.  The idea, simply put, is to solve enough of the problem, and not delay delivery (and value) until you can build a solution to the entire problem.  Because of the law of diminishing returns, for many market problems, there is little or no incremental value in solving the entire problem.  Those resources can be better applied to solving additional problems.

Kano analysis provides a framework for identifying which market problems must be completely solved, and which ones have a more is better characteristic.  In practice, more is better problems exhibit the law of diminishing returns, and should not be “completely” solved.

[larger image, or view the entire Kano analysis presentation]

Conclusion

Complete Requirements are requirements that

• Identify all of the market problems that need to be solved and their nature (absolute vs. diminishing returns).
• Are logically complete in their coverage / articulation of those market needs.

To objectively improve the completeness of your requirements, apply market data in an assessment of your requirements.  To heuristically improve the completeness of your requirements, look for logical inconsistencies and gaps in reasoning or coverage.

Engagement – that’s what this whole product management blogging thing is about.  Check out what Tyner Blain readers found to be the most engaging articles in 2009.

Deep Dives

If you’re new to Tyner Blain, you may be surprised by the length of the articles here.  I joke that they are long because I don’t have time to edit.  Stewart Rogers jokes that they are long because I’m incapable of writing a short article.  If you’ve been here a while, you know what you’re in for.  If you’ve been here a long while, then you’re glad (like me) that I don’t write one per day any more.

Product Management is simultaneously a broad and deep discipline, requiring us to have a breadth of perspective combined with a depth of insight.  We then have to apply that in a market context, effectively navigating the political waters of our organizations.  Most of the articles here either try to skim the breadth of a range of related topics, or plumb the depths of a single topic.  Doing that in under a thousand words is pretty hard.  Most of the articles here also link to other articles, to try and provide even more depth and context, and encourage additional critical thinking.

One measure of the quality of the articles here is how often they stimulate readers to read further, or dive deeper into the topics.  While web analytics won’t allow us to measure how thought-provoking an article is, we can look to see how many people dive into the linked articles, versus how many people move on to something else.  We can measure the bounce rate of an article to see how often people leave a page without following any of the “tell me more” links.

Looking at ~170,000 page views at Tyner Blain in 2009, narrowed down to only those articles with at least 100 page views, here is the top-ten list of most engaging (or “least abandoned” if you’re a “cup is half empty” person) articles:

1. Use Case Series: Introduction: A collection of articles on the “traditional” forms of use cases – informal, formal, UML.
2. Agile Development of Use Cases: A dive into the dynamics and cadence of an agile process for developing use cases.
3. How Do You Manage Market Data?: A collection of articles exploring different market-immersion techniques in depth.
4. Scheduling Requirements Changes – Part 2: A focus on practical techniques for managing change with an agile development process.
5. Yesterday’s BPMN Post Was A Big Fat Lie: A mea culpa and clarification of interest to folks following the BPMN Series.
6. Everything I Needed To Know I Forgot in Kindergarten: Why asking why? is important.
7. Plan Your Next Sprint by ROI – Part 1: Prioritizing by Bang for the Buck, not just Bang.
8. Ten Common Mistakes of Going Agile: A collection of articles about common pitfalls encountered when adopting agile practices.
9. Perpetually Almost Finished Projects: Organizing a project with discrete deliverables and rolling-wave planning to avoid the “90% done, 90% remaining” problem.
10. How To Use Timeboxes for Scheduling Software Delivery: One of my personal favorites.  A rational approach to making trade-offs when your “perfect” plan has to change.

OK Stewart, that’s only 519 words.

Why does cross-selling, the process of selling something additional to someone who is already making a purchase, work?  This article explores some of the theory and rationale behind cross-selling – from qualification to motivation and profitability.

Cross-Selling is Big Business

You have an eCommerce site where people purchase products from you.  Adding cross-sale capabilities to your site can have a significant impact on your bottom line.

The e-tailing group’s 2009 report shows (by survey of eCommerce executives) that 55% of online retailers will include cross-sell and upsell capabilities in their sites in 2009 (already there or being added).  For retailers that measure the data, cross-sale promotions result in a range of conversions (additional sales) from under 1% to over 10% – with a plurality of responses in the 1% to 4% range.  That represents additional revenue the retailers would not get without using cross-selling.

According to the Get Elastic blog, Amazon reported that cross-selling accounted for 35% of their 2006 revenue.

Understanding why cross-selling works requires understanding customer’s purchasing processes work.

Customer Purchase Process

The following is a model for how customers make purchases.

• Customers start by thinking about their problem – what problem are they trying to solve (with a purchase)?
• Some people will try and understand the problem space, while others are happy to jump to solutions.
• Understanding the solution space (what are my options?) is next – and may be a shallow or deep analysis.
• Within the solution space, customers will select a product and decide to buy it (from you) or not.
• Customers who reject their first product choice may select another product or may abandon your store.

You can take a higher-level view of these customer activities and decisions, and categorize them into areas:

• Learning - Your customer is learning about her problem and possible solutions.
• Choosing - Your customer is comparing possible solutions, with the intent to purchase one of them.
• Buying - Your customer has selected a solution, and is trying to buy it.

Customer Qualification

In direct sales, one of the first steps a sales rep will take is to qualify a prospective customer – how likely is this prospect to make a purchase?  A similar model can be applied, when treating your website as a sales rep, to understand how likely it is that a visitor to your website will make a purchase.  There is a ton of additional qualification (assessing a prospect’s ability to pay, for example) that we won’t talk about in this article.  In this article, we’ll focus just on this simplified purchasing model:

• Customers who are learning are more likely to buy than visitors who are browsing (window shopping).
• Customers who are choosing are more likely to buy than customers who are learning.
• Customers who are buying are more likely to buy than customers who are choosing.

That last bullet seems silly – of course customers who are buying are more likely to buy – like 100% likely, right?

Wrong.

Prospective customers abandon the buying process all of the time.  SeeWhy reported ~70% abandonment rates during 2009’s post-Thanksgiving online shopping spree.  They also used the phrase “a relatively healthy 63%” to describe abandonment rates in August 2009.  SeeWhy is specifically measuring abandonment of the shopping cart (inside the “buying” area), but there is abandonment (often called leakage) throughout the process above.

The further a customer is into the purchase process, the more likely they are to actually make that purchase.

Clearing Hurdles

As a customer moves through the purchase process, they are clearing hurdles that would prevent them from making the purchase.  Each time they clear a hurdle, the pending “mental cost” of making the purchase gets smaller.

One of the hurdles is making a decision to purchase now, another is making the decision to purchase from you.

Offering cross-sale promotions to customers who have already (probably) decided to purchase from you, now, means that you’re offering the promotions to customers who are qualified.

Relevance

A defining element of a cross-sale is relevance.  You’ve got a customer who is purchasing a product, to solve her problem.  You want to increase the value of the transaction – both for your customer and for yourself.  To do that, you have to offer a relevant cross-sale item.  Selling french fries with a sandwich makes sense.  Selling car wax with a new car makes sense.

Selling car wax with a sandwich?  You probably won’t have a lot of success with that.

How do you determine relevance?  You can start out with an “expert opinion” – car wax is relevant to cars, for example.  Or you can do some data mining of past orders – “7% of people who bought cars also bought car wax.”  That lets you start out with a hypothesis (that car wax is a relevant cross-sell item for purchasers of cars).  If you’re data mining past orders, however, you may not know the direction of the cross-sell.  Cross-selling works because the two products are complementary goods – usually asymmetric complements.

Complementary goods are rarely symmetrical.  Peanut butter and jelly is a good example of symmetric complements – they have comparable price points, and both generally can be improved by purchase of the other.  In the mixer-cookbook example above, the cookbook is a great complement product for the mixer.

However, if your customer had selected the book initially, the encouragement to “add a stand mixer” would fall on deaf ears.

Foundation Series: Substitutes and Complements

You can measure behavior on your site to determine the nature of the complementary goods relationship.  For the orders that include two particular products (that are offered as cross-sale promotions for each other), in what percentage of orders with both products was each product selected first?  Alternately, what is the conversion % of product A when added to a transaction for product B, versus the conversion % for product B when added to a transaction for product A.

Measurement of Cross Selling

The obvious metric that most people think of when evaluating cross-sale promotion effectiveness is conversion rate.  Conversion rate identifies the percentage of people who, when buying the “original” product, choose to also buy the “promoted” product.  Making changes that raise your conversion rate increase your sales of the promoted product.  However, this conversion ratio is more a reflection of the relevance of the promoted product to the original product than it is a measure of profitability.

Your goal is to maximize profitability, while providing additional value to customers (who are better off or more satisfied with the original purchase when they also purchase the promoted item).

Introducing a cross-sale promotion can increase, decrease, or have no effect on the rate of purchase (conversion percentage) of the original product.  You need to measure the original-product conversion rate for customers who were shown the cross-selling promotion versus those that were not.

Second, you’ll want to know what the ideal products to promote are.  Typically, more than one cross-sale promotion is presented to a customer at a time.  For this example, assume 3 promotions are displayed.  Also assume that your data-mining exercise has identified 5 products that could be promoted as cross-selling items for this “original” product.  Which three of the five do you select?

You should select the three that you expect to be the most profitable.

“Most profitable” can be calculated as (profit per promoted item) x (conversion % – of the promoted item in the context of the original item).  When you don’t have conversion percentage data, you can either gather it (through testing) or predict it (through modeling).  There are many aproaches for predicting the degree of affinity, or implied relevance, of one product to another – but all of them are too detailed to cover in a blog article.  When you don’t have a model, you can test the possibilities to see which ones perform the best.

Some companies also report average order value (AOV), but that’s not necessarily an indicator of profitability.  It may be a component of profitability, but not necessarily.

Product Managing Cross-Selling

If you’re product managing your website, and exploring adding cross-selling capabilities, or enhancing current capabilities, here are some things to keep in mind:

• Your customers are in the middle of a buying process, and will be interested only in complementary products that would give them a better purchase – more value, even if it means more money.  This drives both the importance of relevance and value as criteria for selection of products to promote.
• There may not be any one person who is responsible for (rewarded for) the profitability of your cross-selling capabilities, as the complementary products being promoted may be “owned” by different parts of your organization.
• You will want to test the effectiveness of the approach you use for promoting particular products – which original products, promoted products, and unique combinations of the two are the most profitable?
• You will want to be able to test the effectiveness of changes in the presentation of promotions (images, page location, text, etc) on profitability (or on conversion percentage as an isolated variable.
• You may want to offer discounts that apply only in the context of the cross-sale promotion (e.g. “Buy these together and save!”) and measure the impact on profitability – do the added sales offset the reduced profit per sale?
• You may find that a given complementary product has a different degree of relevance (and therefore effectiveness) depending on the market segment to which you are promoting it.  As an example, a game controller may be more relevant to consumers buying a large computer monitor than small business owners buying the same monitor.

Conclusion

Cross-selling works when you promote a relevant product that is complementary to the original product.  It works because the prospective customer is already in the process of purchasing the original product, and is therefore already qualified.  You should only promote products where the additional sale increases value to your customer and increases value to you.

Ultimately, cross-sale is about profitability.

Do you know about substitute goods and complementary goods?  If you’re doing any eCommerce, and are thinking about cross-sell and upsell, you should understand the basics about substitutes and complements.

Substitutes

You’re considering purchasing a specific product (e.g. a blank compact disc from Memorex).  You could consider purchasing an alternate product (e.g. a blank compact disc from TDK), substituting the alternative for the original.  At a high level, that’s the definition of a substitute good.  Any product that could be substituted for another product, and still satisfy the needs that the original product was intended to address.

Complements

You’re purchasing one product (e.g. a slice of bread with peanut butter).  The value you get from the original product would be increased by the purchase of a complementary product (e.g. a slice of bread spread with jelly).  The basic definition of complementary goods is “products that are purchased together.”

Economic Models: Substitutes and Complements

The definitions for substitute products and complementary products come from the world of micro-economics.  Substitutes and complements are used to model the interdependent nature of the changes of prices on the supply and demand of “related” products.

You can imagine a junior economist who tried a pricing experiment to determine the price elasticity of demand of Jif brand peanut butter.  He predicted that by raising prices on the peanut butter, that the store would sell less peanut butter.  Sure enough, demand (at the higher price) was lower, and sales dropped.

However, he also discovered that sales of Skippy brand peanut butter went up, almost by exactly the amount that Jif sales dropped.  This is because Jif and Skippy peanut butter are substitute products (economists call them “goods”).

Later on, this economist tried another experiment.  He raised the prices on both Jif and Skippy at the same time.  This time, the store sold less peanut butter in total (there were no other brands), and the economist thought his experiment was concluded.

Another surprise for the economist – sales of jelly dropped too.  Sales of peanut butter and of jelly are tied together – when you sell more of one, you sell more of the other.  Economists, trying to be difficult, would say that when you raise the price of one, the demand for the other falls.  Technically true, but a little confusing.

Thus entered substitute and complementary products into the world of economics and pricing.

Substitutes and Upselling

You know that you’re upselling – trying to replace one product that is about to be selected with an alternative product – when your customer is considering substitute products.  Notice in the screenshot from amazon.com (above) that ~9% of the people who were otherwise going to buy the original product instead were convinced to buy a more expensive substitute product.

The goal in upselling is to create a win-win situation.  Your customer gets more value from the substitute product, and you get more profit from the sale of the substitute than you would have received from the original.  Everyone wins.

Complements and Cross-selling

The number one mistake I see when people talk about cross-selling is they call it “upselling [sic].”  Its enough to make me Cranky. The example above, also from amazon.com, shows an encouragement, when purchasing the first book (in the series), to also purchase the second and third books. What’s especially clever is that there is no discount – the total price is the same as the sum of the prices if purchased individually.

You can take advantage of the complementary product model to create product bundles, identifying products that should be sold together.

Although that may not be the best idea.

Often, you will see bundles created by combining products that do not go well together – products that are not complements.  This is a sneaky way for companies to sell products that otherwise would not sell as well.

The recording industry made money in the 1950s and 1960s selling singles.  The recording industry then made a lot more money selling albums that “bundled” 8 or 9 mediocre songs with one or two hits when compact discs hit the market.  Digital downloads have re-introduced the popular purchasing of singles, and revenues are declining – not because of piracy, but because a “take advantage of our customers” bundling practice is now broken.

Complementary goods should be used to create bundles that increase value for your customers.

A baking cookbook is a good complementary product for a customer purchasing a stand-mixer (a key appliance for baking).

Symmetric Substitutes and Asymmetric Complements in Context

Substitute products are symmetric – either product works effectively as a substitute for the other – in a specific context.

If you need a new computer to use at your desk, then a desktop computer and a laptop are symmetric substitutes.  Regardless of which one is your originally selected product, the other is a valid alternative.  If however, you are looking for a computer that you can use while travelling, the desktop is not a valid alternative for the laptop (nor would it be your first choice).

When you’re considering the travelling scenario, the products are not substitutes.  Economists will say that they are substitutes as long as they share common uses.  But economists are looking at aggregated behavior.  You have to make decisions in context – and when the context implies that products are not substitutes, they are not substitutes.

Complementary goods are rarely symmetrical.  Peanut butter and jelly is a good example of symmetric complements – they have comparable price points, and both generally can be improved by purchase of the other.  In the mixer-cookbook example above, the cookbook is a great complement product for the mixer.

However, if your customer had selected the book initially, the encouragement to “add a stand mixer” would fall on deaf ears.  Surprisingly, amazon.com still recommended adding a mixer to my book purchase.  Technically rated a “toss up” by GetElastic in their great cross-selling do’s and don’ts article, but I put it squarely in the don’t bucket (until measured and proven otherwise).

Summary

• Complementary Products – consider cross-selling an additional product.  Complements are usually asymmetrical.
• Substitute Products – an upsell is a suggestion to replace the original product with an alternative product.  Substitutes are symmetrical, but only in a context where both products address the relevant needs of your customer.

Unless you live in a world filled with unicorns and rainbows, writing realistic requirements is critical.  When you set unattainable goals, the best result you can hope for is a frustrated engineering team.  Write requirements that are attainable, and your team will surprise you with what they can achieve.

Attainable Requirements – Revisiting

A little over three years ago (ten unicorn years), I wrote Writing Attainable Requirements, as part of the Big Rules of Writing Requirements series.  In that article, we focused on the unique situations that every team faces – politics and people, and the shared challenge of implicit practicality.  Those factors are as important today as they were then.

Defining Attainable

Attainability, for requirements, is simply the answer to the question – can this be reasonably done?  Most, but not all, of the answer to that question comes from understanding if your team can build and test a solution to the problem you identify with your requirement.  Being able to create a solution requires that the problem you’re solving is tractable, and that the team creating the solution has the skills to solve it.

Being able articulate a problem and it’s solution is necessary, but insufficient – solving the problem requires that there be a feasible solution.

As the founders of the agile development movement explained in their pitch for “low overhead” process – people trump process.  I think it was Alistair Cockburn who added, “but politics trumps people.”

Finally, process is the often-overlooked element of determining attainability.  Realizing the benefits of a novel solution to an existing problem usually involves process changes – sometimes significant ones.

The next few sections go into more detail on each of these – tractability, feasibility, people, and process.

Tractability

Goldilocks ruled out the large bed because it was too large.  Eating the elephant, drinking from the fire-hose, boiling the ocean – these are all common phrases in the American vernacular, because so many people try to do too much (at one time).  There are many ways to decompose a large, intractable problem into smaller, addressable components.  Practicality requires that the problem you’re trying to solve is not too large.

If everything you do is small, however, you won’t ever accomplish anything big.  That’s where strategic product management shines.  As part of understanding your market, you identify large, valuable problems to be solved.  To solve those large problems, you have to break them up into smaller problems, and then address them individually.  You also have to make sure your team understands the big picture and the larger problem that ultimately needs to be solved.  A great way to share context while decomposing problems is with the use of Ishikawa diagrams.

And zooming in…

Maintaining context is a particularly critical component of working with agile teams, where each deliverable’s possible size is constrained further to what a team can accomplish in an iteration.

[click for larger version]

For some problems (and some teams!) this may be enough information to provide the context to develop a product backlog.  And your agile team will move forward into managing their own execution from the product backlog stage.  For larger or more complex problems (such as this example), you will need more detailed communication before diving into user stories / use cases.

The same Ishikawa diagram, with more detail, looks like the following:

[click for larger version]

Agile Product Management: Providing Context

This reduced granularity represents the smallest go-to-market atomic requirement.  Further decomposition results in smaller requirements, but they become too small, because they are no longer independently valuable.  I’m not talking about “the sum of the whole is greater than the sum of the parts” stuff here – I’m talking about “if you only get X, without Y and Z, it has no value” stuff.

Feasibility

Even after decomposing market problems into addressable chunks, you still have to make sure that there are feasible solutions.  One of the brighter software developers I worked with back in the day used to say “We’re writing software – it’s all ones and zeros – we can do anything.”  He also followed that up with “…but should we be doing that?”  The team I was working with at the time probably could do just about anything.  But not everything can be done with a given budget and a specific deadline.  Some things are simply infeasible.

Scrum teams measure velocity – a reflection of how much software they deliver in a given iteration, as a function of how much work they believe is involved in delivering.  This is a great “protected” measure of efficiency.  The team is protected from requests to do work that has little or no value – by measuring throughput in terms of effort, a team can get more efficient at doing more.  A requirement is infeasible, and therefore unattainable, when it exceeds what the team can accomplish given a fixed amount of capacity.  Project managers refer to this as the Iron Triangle – given scope, cost, and quality, pick any two as inputs and the third will be a variable output (absorbing the impact of uncertainty that arises during the development process).  I prefer to use timeboxes rather than that rusty old triangle, to emphasize my perspective that quality is inherent in delivery, and should not be a “variable output of uncertainty.”  Because quality is what usually bears the brunt of uncertainty.

plus  yields

When the solution to a defined problem is prohibitively expensive, it is not attainable.  The notion of cost should also be considered in the context of value.  Requirements with higher value can justify implementing solutions with higher costs.

Prohibitively expensive solutions make requirements unattainable.  Relatively expensive (relative to their value) solutions also reflect unattainable requirements.  You need to collaborate with your implementation team to understand the costs associated with any particular requirement to know if it is attainable.  This is one of the strongest arguments against throw-it-over-the-wall interactions between product managers and implementation teams.  Without that feedback about feasibility and cost of a solution, you can’t assure that the requirements you are proposing are attainable.

Regular readers of Tyner Blain will realize that this is just an alternate way of stressing the importance of considering ROI when defining requirements.

Politics

There are political realities that every organization faces.  It could be a benevolent dictator CEO, or an executive with an agenda or pet project.  It may simply be that there is value in the problems you’ve identified, but solving them is not aligned with your corporate strategy.  You may be focusing on dominating an existing market, where expansion into new markets is the company’s focus – or vice versa.  You may be focusing on top-line growth opportunities, while the company is fixated on cost-reduction in a time of economic contraction.

Each of these scenarios causes you to be fighting an uphill battle internally.  When that hill is too steep, you’re writing unattainable requirements.

Process

When deciding what to build, you also have to think about how you launch.  Launching, as Dave Daniels regularly points out on his Launch Clinic blog, is not just putting your product up on your website for sale.  You have to think organizationally about all of the other moving parts:

• Do your customers have the ability to absorb an update to your software?
• Can your customer service reps be trained in time to promote and support the new capabilities?
• Will your sales team be able to communicate a message that helps them close deals based on what you’ve just built?

Process is more than just the process of typing, compiling, and testing code.  Process includes everything needed to successfully go to market and sustain your product.  If you’re defining requirements that are too far ahead of your market they are not attainable.  If your requirements embody process changes that are too difficult or expensive for your customers or your organization to absorb, your requirements are not attainable.

Conclusion

Attainable requirements are requirements that

• Have a reasonable cost to implement,
• Are aligned with your company’s strategy and stakeholder’s agendas, and
• Result in solutions that can be consumed by your company and your customers.

Make sure you’re writing attainable requirements.

SEO, Search Engine Optimization, is an area that every online website needs to think about.  The idea is that the more traffic you can get to your website, the more products you’ll sell.  Just because you can lead a horse to water doesn’t mean you can make him drink.  What a great opportunity to product manage your website and ask why about SEO.

SEO

When you’re building a website, you have four primary channels by which you get traffic (visitors) to your site:

1. Direct Traffic – people who type in the URL (address) of a page on your website directly into their browser.
2. Referral Traffic – people who are sent to a URL on your website from another website (usually by clicking on a link).
3. Paid Search Traffic – people who click on an advertisement that you run (on other websites) to reach a URL on your site.
4. Organic Search Traffic – people who use a search engine (like Bing or Google) to try and find an answer to a question, who then click on a link to a URL on your website within the search engine results.

[Note that the graph above combines #3 and #4 into one channel of traffic, as the source of about 1/3 of the traffic for this website.]

Search Engine Optimization, or SEO, is collectively the set of activities you do to increase (“optimize”) the amount of traffic you get from organic search (#4 above).  SEO has at best a second-order effect on the other three channels from which you may get traffic – they are effectively unaffected by your SEO activities.

There are entire companies, in fact an entire industry, built to help companies increase the traffic they get from “organic” search.  It is called “organic” search based on the premise that search engine algorithms will determine (through their own proprietary algorithms) the “best” results for any given search.  Like nature, this can be influenced by you, but is out of your control – hence “organic.”  This is in contrast to paid search, where you are directly controlling when someone comes to your site (by clicking on an advertisement that you paid for).

Since SEO is such a large topic, even though this is a longer article, it only scratches the surface.  This article focuses on the decision making you would do (and the measurements needed to support those decisions).  It does not attempt to be a one-stop-shop for all of your SEO needs.

SEO Has ROI (or Does It?)

People who promote their SEO services will tell you – build it, and they will come.  What you do with the traffic once it arrives is up to you – SEO just gets people to show up.  Makes for a good movie, but it doesn’t always work that way.  This is where product management can help.

You want the right people to show up, not just anyone.  In keeping with the baseball analogy, applied to the web: your website is the stadium.  The games are free.  Your SEO efforts get people to show up at the stadium.  But you’re not selling tickets.  The only way you make money is if people buy hot dogs or pennants or peanuts.  You have products for sale at the stadium and you want people who will buy them to show up.  You don’t get any value from just filling the seats.

If the people who show up don’t buy anything, it’s as worthless as if no one ever came in the first place.

I’ve worked with a client in the past who had a project that successfully increased the number of visitors to one of their websites by over 30% for several months, resulting in almost no change in the amount of products they sold during that period.  An SEO-only person would say “hey, the people showed up, I did my job,” but a product manager is acutely aware that this was an exercise in futility.

Perhaps the people who showed up had no intention of buying anything.  That would be consistent with the data my client collected.  Perhaps something intrinsic to the website prevented the new visitors from purchasing (while allowing a consistent percentage of the previous visitors to continue making purchases).  To the best of my knowledge, the data needed to perform that root cause analysis was not available.

When you’re product managing your website, you are responsible not only for getting people to your website, but also for getting them to convert their presence into purchases.

Measuring SEO – Easy Versus Important

The challenge in any measurement activity is determining what to measure.  There always seem to be a bunch of things that are easy to measure, and a handful of things that are important to measure.  When you’re lucky, there’s some overlap.  The challenge is to resist the urge to measure stuff just because it is easy – you’re making work for yourself – both in taking the measurements and in reviewing the measurements.

To select the right measurements for your website, you first have to understand your goals.  Assume that your goal is to sell products, profitably.  This is the driver for your “bottom line measurements” – at the end of the day, how is your product (website) performing?  If you aren’t measuring revenue and profits, you won’t know if you’ve filled your stadium with “empty chairs” who don’t buy any peanuts.

You also have to understand the buying processes that users (website visitors) use to make purchases from you.  One way to characterize the buying process is to look at the process from the perspective of the user, who goes through the following stages of activity:

1. Identify a need to solve a problem (possibly by purchasing a product).
2. Discover possible solutions to the identified problem (possibly products that solve the problem).
3. Compare solutions (products) and decide which to implement (purchase).
4. Solve the problem (purchase and use the product).
5. Re-evaluate the solution (product).

Step 2, discover possible solutions, is where SEO can help.  One way people can discover solutions (and there are many others) is by using a search engine to discover solutions.  Those people may search for phrases that describe their problem (“webcam not working with Skype”) or ask questions as if the search engine could solve their problem directly (“how do I make my webcam work with Skype?”).  Some people will determine (or assume) that the problem is with their webcam, and that they need a new one.  Those people will search for the solution they’ve already envisioned (“best webcam”), or combine steps 2 and 3, and search for comparison data (“webcam reviews”) or pricing data (“webcam deals”).

In addition to the goal-measurements (step 4), you’ll also want to include search-effectiveness measurements (step 2).  Keep in mind that there are other factors at play in your website – not every visitor who searches has a propensity to buy, visitors who arrive may abandon your site because they don’t like your pricing, etc.

Measuring SEO Effectiveness

Keep in mind that you’re trying to sell products (profitably), and this particular effort is focused on improving organic search as a mechanism by which you attract customers to which to sell products (profitably).  Your measurements should focus on these two aspects.  Here are some things that are interesting to measure [note: the screenshots below are of Tyner Blain traffic - I won't share any client data - so these values are low compared to a successful eCommerce site - but they are illustrative.]:

Organic Search Engine Traffic

• How many visitors come to your site from search engines (and from which search engines?)?
• 
• What are the keywords / phrases that visitors used to find your website?
• 
• To which pages did the search engines direct the most traffic?
• 
• What search terms sent traffic to which pages?
• 
• SERP Ranking (Search Engine Results Page Ranking) – How high up is your result for one of your targeted keywords?  Is it on the front page?
• 

All of those measures, while easy to do (the screenshots above are from the free Google Analytics program), only tell you about how many people came to your stadium, they don’t give you any insight into peanut sales.  You can use these measurements to provide feedback as you make changes in your SEO implementation – to determine if each change increases or reduces traffic (or fills seats).

You also need to know about the peanuts.

The specific financial measurements you make will depend on your strategy for how you engage your market.  Are you a discounter, trying to maximize sales in the short term, with a transactional focus?  Are you focused on the long term, building relationships, and maximizing the lifetime value of customers (better to sell more, later, than less, now)?  Are you trying to gain market share, or maximize profits in a mature market?  The specific ways you measure will vary, but some common measurements are:

• Conversion Percentage – how many of the people who come to your site end up purchasing (during that visit)?
• Number of Purchases – how many orders were placed?
• Average Order Value (AOV) – how much is each order “worth” in both revenue and profit?
• Lifetime Customer Value - how much is each customer “worth” in both revenue and profit?

The way you get real insights from these measurements is by combining them.  Utilize the “SEO mechanics” measurements (above the peanuts) to slice or segment the financial measurements.  Ask questions like “How many orders were placed by people who came to the site and landed on the webcam page?” or “What is the conversion percentage for people who came to the site by searching for best webcam?” or “How much revenue do we get from each keyword that sends organic traffic to our site?”

SEO Goals – Getting Actionable

Combining the results of the two forms of measurement (mechanics vs. revenue) will identify for you where you are getting the most value, and where you have the most opportunity to increase value.  You’ll have to do analyses of “do I make one thing (page, keyword, etc) better, or do I try and make all things better?”

One technique that can help you reach those decisions is by noticing that most of the metrics you see follow power law (long tail) curves.  Roughly speaking, 80% of your traffic will come from 20% of your keywords.  80% of your sales may be to 20% of your customers.  20% of your pages may generate 80% of your visits (or 80% of your revenue).  You’ll have to “do the math” for each project to estimate the impact of those projects – and determine if your best bet is to improve a single page (a lot), or make a change to your site that improves all of the pages (a little).

You may find that your website is not sufficiently instrumented to make the measurements you need.  My suggestion is to instrument your website first, and then try and improve it second.  If you can’t measure it, it didn’t happen.

The current “state of the industry” for SEO has a hint of product management influence in it already – there’s some awareness that these sorts of aggregate statistics are limited in their ability to give you insight about your customers.  Where SEO seems to be pushing today is in being able to segment the above data views against personas or market segments.  This looks to me like an industry that is maturing beyond the elastic user problem that software development and user experience teams have been addressing for years.  This approach will allow you to target your website development initiatives with an eye on the uniqueness of customers in different market segments.

SEO Product Management Conclusion

Search engine optimization is important.  Focusing your efforts to improve your business, as it relates to search engines, is what is really important – and search engine optimization is how you get there.  Discover the factors that have a bottom line impact, and then execute to address them.  Don’t just assume that more traffic is better traffic.

Design-Free requirements are important for two reasons, and hard for two other reasons.

Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.”  Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.

Design-Free Requirements – Revisiting

It has been three years since I wrote Writing Design-Free Requirements as part of The Big Ten Rules of Writing Requirements.  In that time, agile development practices have moved from being an esoteric development methodology to being the topic on the tips of everyone’s tongues as executives and organizations try to either (1) get the benefits of the state of the art in software-development process or (2) do something shiny and fashionable.

The previous article centered on elements of designs within MRD, PRD, and SRS artifacts.  A regular alphabet soup of artifacts.  Honoring the values behind the agile manifesto encourages us to emphasize working software over comprehensive documentation.  In that light, we’ll take a “what is needed” approach to talking about how requirements, design, and implementation are all needed – rather than issue an edict about where that information should be captured.

Agile Development Inputs

When creating software, someone needs to know:

• What problems are being solved, and how important (valuable) they are to be solved.
• Who has the problems and who is using the software to (help) solve those problems.
• What constraints limit the space that defines the universe of possible viable solutions.
• What acceptance criteria define if the delivered solution will be acceptable.

Subject to those inputs, someone needs to make design decisions:

• User experience design - what interactions will a user of our solution love?
• Program design – how (in a nuts and bolts way) will our solution function?

When talking about agile and talking about design, we should take a look at how Kent Beck and Alan Cooper, as respective though leaders in each space, view this.

Cooper doesn’t talk much about creating the requirements to support the daily use scenarios – he proposes moving directly into design of the solution. This differs from the more traditional technique of writing functional requirements to support use cases. Cooper also breaks down design into two components – program design and interaction design. Program design is everything you don’t see. Interaction design is everything you do see.

[...]

Cooper argues that designing the interaction should happen before any code is written. He uses a construction analogy to drive home his perspective – you can’t pour the concrete before you build the forms. Kent Beck, founder of the XP programming philosophy disagrees with the premise. Beck believes that the cost of changing software is low, and the imagery Cooper uses is hyperbole. We touch on, and link to that debate in this post.

Interaction Design Process Overview

I don’t believe that Beck is arguing for “don’t do design” – I believe he is arguing for “don’t do big upfront design that would delay implementation.”  He’s championing the agile values that emphasize creating working software and responding to change.  I can imagine him saying “no one will buy a design, they want a solution.”  Cooper’s point is that create a solution without first understanding how someone will use it, you can’t create a great product.

Program design has many hidden impacts – cost of maintenance, cost to change, and the performance of the solution.  You can have a design (or architecture) that makes everything easier to do in the future – at the cost of delaying the delivery of anything.  Or you can have a design that minimizes the time to deliver the first thing, while increasing the cost to deliver any particular next thing.  Or you can design a solution that falls somewhere between those extremes.

If you say “we don’t do design” you’re lying.  Every solution includes design.  Your team’s design process may be “big and upfront” or it could be a couple sketches on a whiteboard, or some email exchanges.  You may create storyboards and wireframes.  Or design may be the thing that happens right before the programmer’s fingers strike the keys.  Design may be explicit or it may be implicit – but it never “doesn’t happen.”

In the movie Amadeus, Salieri is astounded that there are no rough drafts of Mozart’s compositions.  That’s because Mozart did the design in his head, not because he didn’t do design.  I’ve worked with programmers who’s “implicit designs” were great, but that is the exception, not the rule.

Who Owns Design?

Since design happens sometime before fingers strike the keyboard, the real question is – “who owns the design?”

• You have a product manager developing an understanding of market problems, and prioritizing the problems that should be solved with your product.
• You may have a product owner managing the backlog and clarifying those requirements (problems) for the development team.
• You may have an interface (or interaction) designer or team of designers who are broadly responsible for “how users interact with our products.”
• You may have an architect or lead engineer who is responsible for the “big picture design” of how your product works.
• You have developers and testers who are responsible for delivering your product. [Note: coding without testing is like typing code without compiling - maybe it works, but probably not.]

You may not have distinct individuals with each of these titles – every small team I’ve worked with has people wearing multiple hats.  This is especially true when you have an agile team full of specializing generalists – any given story (or task) may have a different architect and different implementer.  I’ve only worked with one company where the architects are NOT part of the development team.  If your team is set up that way, please comment below – I had never seen that before, and I’m not convinced that it is the best way to organize – what have your experiences been?

Generally, “program design” is clearly owned by the development team – and product managers (and product owners) know better than to specify program design in their requirements.  Neither the lead engineer nor the product manager believes that the product manager is a better programmer – so the product manager better not be specifying program design and mislabeling it as requirements.  Coincidentally, Steve Johnson, at Pragmatic Marketing has a post running right now with a bit of a quiz – is this a req(uirment) or a spec (design)?

Where the line is more blurred is around interface and/or interaction design.  Some development teams have interface designers as part of the team.  Some companies organize with interface design as a “shared service” within the company.  Either approach can be the “right one” – it depends on too many details to make a sweeping generalization.  When the designers are members of the development team, the solution (from a product management perspective) is the same – the “team” is responsible for all design.  When the designers are not part of the development team, the developers have to consume two sets of guidance – “solve this problem” from product management, and “the solution needs to look like / act like this” from the designers.

Collaboration between product management and user experience people is the ideal solution.  The “requirements” and “design” inputs to the development team are comprehensive and consistent.

Design-Free Requirements

There are benefits – especially when being agile and minimizing documentation – to delivering requirements and design at the same time.  Just don’t do it by embedding design constraints within the requirements.

• When people on your team misinterpret design as requirements, they are unnecessarily constrained.
• As a product manager – are you the best designer on your team?  If you’re busy designing, who’s product managing?

This is trickiest when writing use cases – sequencing a set of interactions is interaction design.  That is one benefit of writing a user story instead of a use case.  An approach that has worked well for me with multiple teams is to deliver user stories (requirements) combined with storyboards (interaction design) and wireframes (interface design).  When details are needed (usually when “changing” versus “creating” an interface), screenshots can replace wireframes.  When business processes are complicated, process flows can replace storyboards.

Just don’t embed the designs within the requirements.

You have an eCommerce site.  You sell products online.  Do you cross-sell additional products?  Do you upsell to better products?  This article explains the difference between cross-sell and upsell, and looks at some real-world data about the effectiveness of both.

Cross-Sell and Upsell – What Are They?

Cross-selling and upselling are marketing techniques that are applied during the sales process to increase the value of the transaction to both the buyer and the seller.  Technically, they only increase the value to the seller – but they should also be increasing the value to the buyer.

The key idea behind both cross-selling and upselling is that you are changing a transaction that is already in process.  You might think that marketing ends once buying begins.  Not so.  Marketing is about getting the right message (buy something from us) to the right person (someone who needs our products) at the right time (when they are ready to buy).

• What better time to market than when someone is in the process of buying already?
• Who better to market to than someone who is in the process of buying from us?

The trick then, is in sending the right marketing message.

Cross-selling and upselling only make sense in the context of an ongoing sales process.  For an eCommerce retailer (a company that sells a product online), that means that the customer (technically, the prospective customer, also known as a prospect) is in the process of making a purchase – either looking for the right product, evaluating a specific product, or having selected (but not yet purchased) a product.

• Cross-selling is defined as selling an additional product when the customer is purchasing the original product.
• Upselling is defined as selling a more expensive product instead of the product that the customer was originally purchasing.

As a retailer, you have to know when to attempt to cross-sell, and when to propose an upsell – and when to do both.  To decide when to try and modify (and risk losing) a sale, you have to look at the economic impact on your business of trying to change an ongoing sale.  Cross-selling does not help you make a sale that you wouldn’t already have made – although an upsell suggestion may help a customer discover a “better” product for their needs, and close a sale that would have been abandoned otherwise.

Note – to keep the language of this article easier to read, the word “product” is being used to represent (traditional) products and services – anything a business would sell.

Economics of Selling

To evaluate the economics of cross-selling, you have to first establish the economic measures of selling.  When you sell something you have the following:

• Price - the price the customer pays for the product being purchased.  This is also known as revenue.
• Cost - the cost to the merchant to acquire or create the product being purchased.  Also known as “COGS” – an acronym for cost of goods sold.
• Gross Profit – the price paid by the customer minus the cost of the product.
• Cost of Sale – the cost the merchant incurs to make the sale.  For an individual transaction, this is called “cost per quote” or “cost per order” or “cost per sale.”
• Net Profit – the gross profit minus the cost per sale.  This is also known as operating income.

As an online retailer, you will likely track all of the above.  Your Cost of Sale is potentially difficult to measure – you will probably have a mixture of variable costs and fixed costs that can be allocated to the cost of sales.

• If you pay $1,000 per month to host your eCommerce website (making sales possible) and you make 1,000 sales per month, you could allocate $1 per sale as a cost per sale.
• If you pay 2.5% of the price collected to a credit card processing service, and you sold a product for $100, you would incur a $2.50 cost per sale for that transaction.

A financial analysis of your business will involve aggregating all of the revenue and costs, and calculating the total operating income (all revenue minus all costs) for a period of time.  Since you sell different products (with different costs) at different prices, any given transaction will have a different net profit.  As part of managing your sales and pricing, you may also measure

• Average Revenue per Order - 100 orders for a total $1,500 in revenue would yield and average revenue per order of $15.  Calculated as Revenue / Number of Orders – in this example $1,500/100 = $15.
• Average Gross Profit per Order – 100 orders at $1,500 in revenue with $1,100 in COGS would yield an average gross profit of $4 per order.  Calculated as (Total Revenue – Total COGS)/Number of Orders – in this example ($1,500 – $1,100)/100 = $4.
• Gross Profit Margin (Percentage)- a product purchased for $100 for which the retailer paid $60 to acquire the product has a gross profit margin of 40%.  Calculated as (Revenue – COGS)/Revenue – in this example ($100 – $60)/$100 = 40%.

Economics of Cross-Selling

Cross-selling is when you convince a customer (who is in the process of buying something) to buy an additional product.  When you successfully cross-sell a product, you are increasing the revenue for the order.  This results in an increase in average revenue per order.  The sale of the additional product will also increase the average gross profit per order.  The cross-sell may increase the gross profit margin of the order, or it may not.  When the product originally being purchased is less profitable than the additional product being cross-sold, the margin is increased.  When the original product is more profitable than the additional product, the margin is decreased.

If your current operations strategy involves increasing your profit margins, you need to make sure your cross-sell activities only recommend additional products with higher margins than the products against which they are being cross-sold.  When your strategy is prioritizing growth over profitability, your cross-sell activities should focus on conversion – increasing the percentage of the time are you successfully cross-selling additional products.

Economics of UpSelling

Upselling is when you convince a customer (who is in the process of buying something) to buy something else – specifically, something more expensive.  This replacement of the original item with a new item is known in economics as product substitution.  Since the products are not identical (one is more expensive and presumably “better” than the other), the products are by definition imperfect substitutes.  A perfect substitute is one that would be identical to the product it replaced.

[Update: Check out Complementary and Substitute Products for more on product substitution.]

Successfully upselling a product results in an increase in revenue, and ideally an increase in profits.  It may also result in an increase in profit margin (but may not).  Consider a customer who intends to purchase a 200GB hard drive for $100 (at a cost of $45).  This purchase would yield $100 is revenue, and $55 dollars in profit at a 55% profit margin.  If you successfully upsold the customer to purchase a 500GB hard drive for $200 (at a cost of $100), the purchase would yield $200 in revenue, and $100 in profit at a 50% profit margin.

You have to understand if your strategy is prioritizing an increase in revenue, profits, or profit margins.  This will determine which upselling recommendations you want to make to customers.

Measuring Cross-Selling and Upselling

In addition to measuring your sales you want to specifically measure the impact that cross-selling and upselling has on your measurements.  Those measurements are described above.  You may be breaking those measurements down by product category, product price levels, market segments, or any other decomposition that helps guide future decisions.  You also want to measure the effectiveness of your cross-selling and upselling solutions.  You do that by measuring conversion – the percentage of customers that change their purchases in response to your cross-sell and upsell marketing.

Get Elastic, the eCommerce blog, shares some 2009 survey data provided by the e-tailing group on cross-sell and upsell conversion statistics.  Two-thirds of retailers that measure cross-sell and upsell conversion rates reported less than 5% conversion rates.  At the same time, Get Elastic reports that Amazon reported 35% of their 2006 revenue came from cross-sells.

If you’re adding cross-selling and upselling capabilities to your eCommerce website, you should set your initial expectations of effectiveness low, and your aspirations high.  You won’t start out with results like Amazon’s – no more than 98% of retailers that measure conversion see results far lower than Amazon’s.  In fact, most of them see results an order of magnitude smaller.

Perpetually intermediate (competent) users.  Users who briefly exist as novice users and never become experts. Most of your users are competent, and you should design for them.  Competent users have different needs and different expectations than novice or expert users.  How do you know your user’s competency levels, so you can design for them?

User Competency

User competency is a concept I first read about in Alan Cooper’s The Inmates Are Running The Asylum.  Cooper’s contention is that the level of expertise of your users follows a bell curve, or normal distribution.

When we’re designing software we need to keep in mind that most of our users will be competent – neither experts nor beginners. Alan Cooper’s studies tell us that user skill levels follow a bell curve. He talks about competent users as perpetual intermediates. Some users drop out of the bell curve when they stop using our software. The rare user becomes an expert. Most users only learn enough to get their real job done.
Competent Users and Software Requirements

Cooper contends that the combination of learning curves and natural user tendencies to stop learning or abandon a software application are the sources of this distribution of user competency.

Experience Curves

Experience curves represent the diminishing costs over time of manufacturing something repeatedly.  The process of manufacturing something gets more efficient as you get smarter about the process.  The process of using software is at least analogous to, if not a specific example of a manufacturing process.  If you’re using an email application, you are manufacturing email messages.  In a CRM system, you are manufacturing contacts, or contact reports, etc.

By treating any “using the software to do something” interactions as a process, you can measure the cost (how long it takes) of the user’s interactions.  Applying the math behind experience curves, you can predict the reduction in cost (to your users) over time, for any set of interactions.  Experience curves take into account that some processes are inherently more learnable than others.  This property of learnability is reflected as an efficiency coefficient – how efficiently someone can learn ways to reduce the cost (time) needed to perform the interactions.

This gives us an approach to quantitatively model user competency.  Having a definition allows us to model competence.  And measuring competence allows us to manage product design in the context of user competency - designing for competent users.

Defining Competence

The first step to measuring competency is to define the model.  I am proposing a definition in this article that I suspect will yield insights (to help us manage our products). I was unable to find any quantified definitions of competence, when researching it as part of a client engagement.  If you have, or know of a model, please share it in the discussion below this article.

• A competent user is someone who learns to perform a task in half the time it initially took them.
• An expert user is someone who can complete a task in 10% of the initial time.

This definition is guided by an expectation that Alan Cooper’s premise about perpetually intermediate users is true.  Being a novice user is a very transient state, and becoming an expert is very infrequent.  The goal of the definition is to be able to segment your users and make well-informed design decisions.

A Proposal, Not a Doctrine

This is a proposal that doubling performance reflects competence, and achieving a ten-times improvement represents expertise.  It may be that some different measure of performance improvement more accurately reflects competence and expertise.  We have to test it to know.

The experience curve is defined mathematically by Henderson’s Law.  It states that the time to complete a task is a function of the number of times you have previously done that task, adjusted by the “elasticity” of the cost of that task.  In other words, some tasks are easier to improve than others.  If you populate a table with the results of applying Henderson’s Law, you get the following:

[larger image]

• Each row in the table represents the Nth repetition of a task.
• Each column represents how easy that task is to learn – progressing from “hard to improve” on the left, to “easy to improve” on the right.
• Each cell in the table represents how long it would take to perform the Nth repetition of the task, as a function of how easy it is to improve your performance at the task.

The above definitions represent what experience curves predict mathematically, when the task initially takes 60 seconds.  The following definitions reflect the proposed user competency model:

• A user is a novice user until she has learned enough to cut the time-on-task in half.  These cells have a white background (and are in the upper left area of the table).
• A user is a competent user when the time needed to complete the task is between one half and one tenth of the initial time.  These cells are shown with a yellow background (and are in the central area of the table).
• A user is an expert user when she can complete the task in less than one tenth of the time required to initially complete the task.  Theses cells are shown with a red background (and are in the lower right area of the table).

In the absence of empirical data, I used my intuition to suggest that a representative experience curve for a typical task performed in software would be one with an “elasticity” of 50%.  For a task with those learning characteristics:

• A novice user would cut the needed time in half on the 4th repetition of the task, and would be considered to be a competent user.
• A competent user would further reduce the time needed to one tenth of the initial time on the 100th repetition of the task, and would be considered an expert user.
• The 50% elasticity column is surrounded by a black border, and the number of repetitions required to advance to competent or expert status is also highlighted with a black border.

Inferring Competence

Since different processes have different learning characteristics, you have to figure out how easy it is for your users to improve at your processes.  To do that, you have to study (or at least measure) your users’ interactions with your software.  In the 50% curve highlighted above, a user is capable of cutting their time-on-task in half by the fourth time they perform the task.

If data from your initial testing (or measurement) reveals this to be true, then you have selected the correct curve (the correct column in the table).  If it takes more or less time to reach this level of improvement, shift to the left or right to find the appropriate curve.  If software-interactions are reasonable analogs to manufacturing processes, then the experience curve projects an expected rate of improvement on task.

The following graph isolates the time-on-task data for a user who is learning to improve when repeating a task (process) that matches the 50% elasticity curve.

[larger image]

Note that the number of repetitions of the task (the X axis) is represented as a logarithmic scale.  The data points along the curve correspond to the cell values in the table above (for the 50% column).

Shades of Gray

One nice thing about this quantitative approach to inferring competency by measuring usage is that your measurements are per-process.  Users are not “purely novice” or “purely expert” – they can be experts at some processes, while remaining neophytes at other.  There is also awareness, for any particular process, of “how much competency” a user has.  This allows you to refine your assumptions of the steepness of the learning curve, and of the thresholds (doubled performance and ten-times performance improvements).

Improvement Over Time

Any particular learning curve can be considered relative to calendar time, to see how quickly a user will progress along the curve (as a function of frequency of use).  This can be useful for determining the ROI of improvement in a particular process.

The following graph shows how an 80% learning curve overlays a calendar for tasks that happen daily, weekly, and hourly.

[larger image]

The graph shows that for a weekly frequency, after 16 weeks, the task time has reduced from 300 seconds to 100 seconds. With a daily frequency, the task time is even lower – about 60 seconds. This graph shows nothing other than converting the academic learning curve graph into one that incorporates calendar time and frequency of occurrence.

Software Usability and Learning Curves

One approach to inferring user competency would be to measure how long a user has been using your software.  The variation in how frequently different users perform the same task will introduce an error into that inference.  You can avoid introducing that error into your modeling by counting the number of times a user has performed a task.

Applying the User Competency Model

The advice in previous articles, and from Cooper’s book, and from this great article on the  Coding Horror site, encourages us to focus on the competent users.

I’m working with a client who needs to prioritize a set of capabilities and establish design principles for a product.  We will incorporate this user competency model as part of our analysis.

Hopefully we’ll have an opportunity to collect data to validate and / or refine the model.  I’m proposing that we first gain some insight into the which users (novice, competent, expert) drive the most revenue and profit from use of the product – to establish the importance of each category of user.

For this product, I suspect that we will find many more novice users than a normal distribution would predict.  If that is true, the next question will be to understand if we are dealing with a normal behavioral dynamic, or if characteristics of the current product “force” novice users to abandon it before they achieve competence.

Either way, we will have a framework for prioritizing the goals of the novice, competent, and expert users.

How would you apply a model like this to improving your product?

Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done.  Great requirements exist to do three things:

1. Identify the problems that need to be solved.
2. Explain why those problems are worth solving.
3. Define when those problems are solved.

Concise Requirements – Revisiting

In the three years since we last looked at Writing Concise Requirements from the Big Ten Rules of Writing Requirements, the iPod evolved to give us a better experience.  Let’s see if we can do the same with the topic of brevity in requirements.  The size of our community here has grown ten-fold, and the people who were here back then have grown just as much.  It makes sense to look at this again.

Writing concise requirements is not just minimizing the number of words you use.  Writing concise requirements is presenting the most important information in the easiest format for your audience to consume.

Concise Requirements Identify the Problems That Need to be Solved

Ultimately, requirements are the problems that we choose to solve.  A concise requirements artifact (formal document, index card, photo of a whiteboard, whatever) is one that has the highest signal-to-noise ratio possible.  You’re maximizing the amount of communication, and minimizing the cost of communicating.

You want your requirements document to read like the lines, not the points.  If the line (the signal) is what you really want, and you communicate a big pile of points (the signal, hidden in the noise), you run the very real risk that your audience will misinterpret the signal.

User stories provide the best example of clarity that comes from conciseness.  The format you should use, based on Mike Cohn’s great book, User Stories Applied, is

As a [role], I want to [do something] [with some frequency] so that I can/will [achieve some goal]

The user story is not always the right communication format – it depends on what problems you’re solving, and who is on your team.  Sometimes, use cases work better than user stories.  Conciseness is important for use cases too.  Start with a good use case name.

Concise Requirements Explain Why Those Problems Are Worth Solving

Last week’s article on Valuable Requirements focused on why particular problems should be solved.  Your focus should be on value, and that article discussed five ways to assure that your requirements are valuable.  One of the techniques, the use of an Ishikawa diagram, provides a method for identifying the root causes of problems.

[larger image]

Imagine that you have a collection of user stories, representing problems to be solved for your users.  You need a way to demonstrate why this user story should be implemented and why that one shouldn’t.  You can often use the Ishikawa diagram in the same way.  A particular goal is achieved when a user is able to do something.  Perhaps several somethings are required.  The point is that you can use the Ishikawa to drive home the point – if this set of user stories are all implemented, then this goal will be achieved.

There are two reasons this is important – first, you’re providing context for your team.  They understand why they are doing something.  Second, you can make changes easily, because you can see the impact of those changes.  By understanding the cause-and-effect relationships between problems and their values (user stories and their goals), you can see the impact of changing one or the other.

Concise Requirements Define When Those Problems Are Solved

Clarity is the goal of conciseness.  It isn’t enough to say “work on this.”  It’s important to know why you’re working on it, but that still isn’t enough.  You have to know when you’re done.  When you’re defining problems to be solved (and therefore solutions), you must also define the measures by which the solution will be judged.

A measurement of success for “Cost of Operation is Too High” might be “reduce costs of operation by 10%.”  This gives you a testable criteria for knowing when that problem has been sufficiently solved.  Sticking with the Ishikawa, you can also map out the strategy for achieving that lofty goal.  You can say that the goal is to reduce fuel expenses by 20%, reduce cost of maintenance by 5%, and reduce payments by 15%.  This process continues – a 20% reduction in fuel spend requires that you operate with your tires within 5% of nominal pressure, and that you reduce the aerodynamic drag coefficient by 7% (or whatever).

This gives you clarity in your objectives.

User stories, when combined with user acceptance criteria, provide that last connection of testability that lets your team know when they are done.

There aren’t many things more frustrating to a development team than having them solve the wrong problems.  One of those things might be having their solution be rejected because it isn’t enough.  Writing acceptance criteria clearly and concisely lets the team know exactly when they can move on to the next problem.

Providing a crisp understanding of acceptance criteria also facilitates iterative development.  One challenge teams always face is making improvements that fit within the timebox of a given iteration.  Imagine a user story with 4 acceptance criteria, where the story is too big to complete in one sprint.  When talking with your development team, you may find that the story is too big because satisfying all of the acceptance criteria is too big.  This is where many teams miss an opportunity – by defining all of the acceptance criteria that are believed to be needed eventually and requiring that they all be implemented now.  One of those criteria is going to be more important than the others.  Implement the story such that is satisfies the most important criteria (timeboxing) now, and rewrite or enhance it to meet the additional criteria later.

Conclusion

Software Product Success depends not only on identifying the “right stuff” to build, but on making sure the team builds it and builds it right.

Concise requirements improve your ability to communicate with your team, thereby improving their ability to build the right stuff right.

User stories can make requirements management a lot easier.  They shift some of the communication from up-front documentation to ongoing dialog.  That’s the main reason they work so well for agile teams.  And agile teams focus on “what’s next?” instead of an ever-changing “what’s everything?”   The problem is, when those conversations are working well, it is easy to forget to make sure that what you’ve done is actually enough.  Add a small dose of traceability, and you can easily validate the completeness of your user stories.

Three Big User Story Problems

Over the last few years, Alistair Cockburn surveyed a range of teams and identified that they all were facing a similar set of problems.  Alistair proposed using use cases to solve those problems.  The following list of problems is Alistair’s:

1. Designers lack the context of the goal that the user is trying to achieve.
2. The team does not get a early indication of the scope of the project.
3. Alternate user-behaviors are not identified in advance of the commitment to deliver.

We agreed then (and still do) that well developed use cases can be used to address these issues.  Since then, however, we’ve done more analysis of how and when to create use cases and when to create user stories.  The primary drivers of the use case versus user story decision still apply, and should still sometimes point you to creating user stories.

Without the context of goals, and without a notion of completeness, your team just has a haphazhard stack of stories.  Not only will this reduce their motivation, but it will introduce frustration both for the implementation team and the stakeholders – no one will really know when the job is done.  Validating the completness of user stories will allow you to know (and regularly revisit) when you should be done.

When you are creating user stories, you need to be able to address the issues Cockburn identified.  You can do that with traceability, and a very small amount of additional documentation.

User Story Metadata

The cool thing about a well-written user story is that it already has metadata within it that makes tracing very easy.  A well-written user story, using a format based on the work of Mike Cohn (in User Stories Applied), would read:

As a [role], I want to [do something] [with some frequency] so that I can/will [achieve some goal].

If you were to build a UML Class Diagram to show the relationships that are implicit in a user story, you would get something that looks like the following:

[larger version]

• The [role] that starts a user story is the persona (lower right corner of the diagram).  For products with simple market strategies, identification of personas alone is sufficient.  Larger companies and larger products are often trying to address the needs of users in multiple markets or market segments.  Each persona you develop is in a single market segment.  You may organize your segments regionally or by vertical industry or any other strategy that helps you position your product.  You can manage your personas not only as members of market segments, but with a hierarchy of roles.
• The [do something] you identify is the meat of the user story (top center of the diagram) – what the persona is going to do.
• The [with some frequency] element tells your team how often a particular user story will happen.  This can be represented as an attribute of the user story.
• The [achieve some goal] component of the user story provides the context (center of diagram) for why a user will be performing an action.  The user will be performing the action either to achieve a user goal or a corporate goal.  If it is a corporate goal, it will have an internal stakeholder.  Ultimately, there should be an internal stakeholder who is not only the beneficiary of that goal, but also the person who “owns” the market segment in which the persona is defined.  Sometimes, there will be conflicts in goals, commonly between user and corporate goals.  These can also result in conflicting goals between internal stakeholders.

This is what makes things pretty exciting – all of that information is already there, and in your user story.  All you have to do now is leverage it.

Goals and User Stories

The following diagram shows how a use case exists to enable the achievement of a goal.

A user story can exist in the same way, just replacing the use case.  If you want to do a deeper dive into how interaction design and structured requirements work together, you can use the following model instead:

Note that the diagram above introduces a couple additional concepts.  The first additional concept is the practical goal – what the persona is attempting to do because it is the manifestation of a corporate goal.  ”Take an order quickly” is the practical goal that manifests the corporate goal of “Reduce time required to take orders.”  The second concept is that of a scenario.  A scenario is an amalgam of user stories (or use cases) that collectively allow the persona to achieve the practical goal.  We already represent this without introducing the scenario concept by acknowledging that a single goal is mapped to multiple user stories.

The common element in both approaches is a strong tie between goals and user stories.  Focusing on this aspect, you can visualize the relationship as follows:

[larger version]

Note that the acceptance criteria for each user story are called out (so that you can confirm that a user story is “done” and “done well”).  Each goal is achieved by enabling one or more user stories, such that the acceptance criteria are met.  This is the crux of it, so I’ll write it again, but in bold for the busy people who scan this article.

Each goal is achieved by enabling one or more user stories, such that the acceptance criteria are met.

Note also that multiple goals can be supported by the same user story.

Validating Completeness

The important question that many developers (agile or otherwise) can not answer about their project is “If we do [everything we've been asked to do] will we meet our goals?”  This is either a failure in communication of context, or a failure to validate completeness of the requirements.  You have to flip things around and ask “If only these user stories are implemented, will the goal(s) be achieved?”  This is the same process used to validate completeness of use cases – just applied to user stories [Ed: that completeness-validation article was written 3 years ago today.  That's 28 years ago in internet time].

Incremental Overhead

Each user story already identifies the goal(s) it is supporting.  The incremental overhead is to recognize that this is “a backwards view” of goal satisfaction and create a simple table that shows the “forward view.”

You are creating traceability from each goal to each of its supporting user stories – but you’re doing it with a simple table (or list, or tree, or whatever).  You don’t have to manage your requirements in some big messy repository.  If you’re using index cards, consider getting some brightly colored sticky-dots, number them for each goal, and stick them on the index cards to show the relationship.

Then ask the question, for each goal, “Will this goal be achieved if all of the traced user stories (and no other stories) are completed, such that the acceptance criteria are met?”

An added benefit of this simple document is that it markedly improves your engagement with internal stakeholders.  You’ve created another opportunity for them to influence the scope of delivery.  These stakeholders can identify user stories that don’t map to any goals (you can drop those stories), and by identifying incomplete support, you can collaborate to make sure the missing user stories are identified.

The task of updating stakeholders about progress and managing stakeholder expectations just got much easier – because you can report progress in the context of completed user stories (and therefore manifested goals).

Reviewing Cockburn’s Issues

Does this approach address Cockburn’s issues (listed at the start of this article)?

1. Lacking the context of goals.  This approach explicitly emphasizes that context.
2. No early indication of scope.  The combination of completeness analysis and acceptance criteria provides concrete insight about scope.  Note that scope can still change, but this approach is just as effective as documenting requirements with use cases.
3. Alternate behaviors not identified early.  Completeness analysis will highlight when the “happy path” (a.k.a. the normal course in a use case) is not sufficient to achieve the goal.  This is really just a variation of the second issue (not understanding scope), but along a variation dimension instead of a coverage dimension.

Conclusion

There is value in being able to document requirements with either user stories or use cases as circumstances dictate.  Cockburn identified issues that teams face when dealing with decoupled user stories.  His approach of leveraging use cases to solve the issues is perfectly valid.  The approach outlined above, tracing user stories, also addresses the issues.  As a product manager or business analyst, you need to be able to address the very real issues with either documentation approach.

When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal.  You need to be aware of both.  Having a positive user experience is important, and requires a user-centered understanding.  Achieving your corporate goals might be in conflict with some user goals.

User Goals

A user centered, or user-centric approach to developing software is one where you start by identifying the key persona in your target market.  For each of those personas, you identify their most important goals.  You then identify the user stories or use cases that represent the things these people do in order to achieve their goals.  These “things” are manifested as practical goals.  For these activities, you design user interfaces (process, layout, architecture, look and feel, etc) that create customer delight for those users, doing those things.  This is how your product exceeds the suck-threshold (good enough that it doesn’t suck to use your product).

Corporate Goals

There’s a reason your company is creating or improving a product.  It may be to gain market share, or improve profitability, or increase sales.  Whatever it is, there’s a corporate goal that your decisions should be supporting.  The (subset of) corporate goals that are relevant to your product could be communicated in a vision and scope document, that constrains the domain of problems to be solved, and provides nuanced insights into viable approaches to solving them (example vision and scope).

Corporate goals are achieved when customers do things with the products.  These “things” are manifested as practical goals.  For those activities, you document what should be accomplishable and why.

Alignment and Conflict of Goals

Notice that both the user goals and corporate goals manifest in terms of people doing things.  When the person (user) wants to do the same things that your company wants them to do, you’re in alignment.  When the user goals and corporate goals suggest different activities, you’re in conflict.

You can see visually that these worlds collide at the “practical goals” stage  in the following diagram, from an article on combining interaction design and structured requirements principles.

It may be great – when the user and corporate goals are in alignment, the practical goal and associated scenario (activity) are easily defined.  What about when the goals are in conflict?

Vending Machine Example

Last Thursday morning, as I interacted with a vending machine, the idea for this article was dispensed along with my Diet Mountain Dew.  Yes, I know that’s odd.  Move on.

It occured to me that the process of buying a cold, caffeinated beverage can be both aligned and unaligned from the perspective of user and corporate goals.  If you imagine writing a use case for purchasing a beverage from the vending machine, your most important scenario is the one where a person wants to purchase a beverage that is available in the machine.

• User Goal: Get refreshed and vitalized.
• Corporate Goal: Sell a beverage.

I want to buy a Diet Mountain Dew, as a means to realize my personal goal.  The owner of the vending machine wants to realize her corporate goal of selling me the beverage I want to buy.  We’re in alignment.  Our requirements definitions and design decisions will be pretty easy – everything that increases the likelihood of and improves the experience of purchasing that beverage is good.  I put my money in the machine and push the button.

Then it occurs to me – there’s a situation where my personal goals are clearly not aligned with the corporate goals of the vending machine owner.  When there is no Diet Mountain Dew available to be purchased.

Consider the following procedure I’m forced to endure:

1. I view the available beverages that this machine dispenses – Diet Mountain Dew is one of them.
2. I put my money in the machine.
3. I push the button for Diet Mountain Dew.
4. The tiny display on the machine presents a message in taunting, scrolling red LED lights: SOLD OUT.

At this point, I’m faced with a choice – select a less desireable beverage, or request my money back and try to satisfy my user goal in some other way.

Consider an alternate procedure:

1. I view the available beverages that this machine dispenses – Diet Mountain Dew is one of them.
2. I view the ‘current availability’ of Diet Mountain Dew and see that this machine is currently sold out of Diet Mountain Dew.

At this point, I’m faced with a choice – select a less desireable beverage, or request my money back and try to satisfy my user goal in some other way.

The differences in these two possible procedures indicate that there is a conflict between the corporate goal and the user goal.  With the first procedure, the “Sell a beverage” goal is given more importance, because it makes me more likely to purchase a beverage that I don’t particularly want.  My utility is potentially sacrificed, while the owner of the vending machine is just as satisfied.

By failing to tell me that I can’t get what I want, until I’m further invested in the process, I am more likely to purchase something else.  That purchase creates just as much value for the owner of the vending machine, but less value for me.

If the vending machine owner had allowed me to use the second procedure, it would demonstrate that the  owner believed the improved customer experience, while risking the loss of this sale, would encourage me to purchase more over time.  The owner would have been prioritizing the requirements and design that supported the user goal ahead of those supporting the corporate goal – in hopes that my user loyalty would result in better word of mouth (more business from other people) and more business from me over time.

Generalizing User and Corporate Goal Conflicts

In this vending machine example, the annoying procedure is probably the right one – I’m going to treat the “point of use vending of cold, caffeinated beverages” as a commodity product.  This market has a very low barrier to entry, and relatively small problem being solved.  I’m not going to tell my friends about how much I love the vending machines from Joey’s Vending and encourage them to go out of their way to find and use those machines.  Nor will I purchase more Diet Mountain Dew because the emotional cost of the occasional “sold out” scenario is trivially smaller with Joey’s machines.  I would, however, be more likely to buy a Diet Pepsi when I’ve already invested time in the process and put my money in the machine – especially when the alternative is to find a water fountain.  I’m emotionally invested at this point.

However, this experience did jump out at me as one that is worth explicit consideration when defining requirements and designing solutions.  It does come up regularly.

The new iPhone 3GS hardware allows tethering (using the phone as an internet-connection device for your laptop).  ATT (the exclusive carrier for iPhones in the USA) is indicating that they will charge customers an extra monthly fee for this capability, when they eventually allow it on their network.  The user already has a data plan, and the traffic that ATT would have to carry is just “data.”  The user just wants it to work.  ATT, however, may want more money, or may want to limit data traffic on its network – perhaps to improve the quality of service to all customers.  This could be ATT’s corporate goal of “provide better service quality” conflicting with the user’s “increase the flexibilty of how I use my data plan.”  The former would likely influence customer satisfaction (and abandonment) over time, while the latter would influence customer acquisition rates.  Another conflict in goals.

Think about how different goals can lead to conflicting solutions, requirements, and designs.  And tell me when you’re out of Diet Mountain Dew before I’m emotionally invested in the purchase.

For you product managers out there – here are a couple upcoming productcamp unconferences.  For you business analysts, here’s an excuse to do a little domain modeling and practice your UML class diagram skills.

Upcoming ProductCamps

There are at least four productcamp unconferences coming up in the near future.  I’ve been able to attend (and host sessions at) both of the productcamp Austin sessions, and they were great.  If you can make it to a session near you, you definitely should.  And if you go, you should help out – these are entirely free, and their quality directly relates to the amount of volunteer support that the attendees give.

1. ProductCampNYC – Jul 18th 2009 @ The Downtown Association, New York City, NY.  More info.
2. ProductCampAustin – Aug 2009 (exact day and venue TBD).  More info.
3. ProductCampToronto – (everything TBD).  More info.
4. ProductCampSeattle – Oct 10th 2009 @ Amdocs.  More info.

Check out the comments on this article too – as updates happen in different cities, I’m sure folks will post them here.

[Note: I updated the venue for the NYC product camp on 10 Jun 2009]

If you’re on twitter, you can search for #pcampnyc, #pca, for NYC and Austin productcamp info (respectively).  Or follow @ProductCampNYC.

Session Planning

One of the interesting things about productcamp is that it is a barcamp-style unconference.  That means it is free, and in theory, there is no centralized planning of sessions.  However, there’s a lot of planning that goes into having these unplanned sessions.

Roger Cauvin is one of the volunteers helping to organize the next productcamp Austin, with a focus on sessions.  He and I met over some seriously tasty Greek food at Tino’s Greek Cafe in Austin yesterday for lunch to begin planning for the sessions.  Our discussion focused around how the attendees will best benefit from the sessions, and what we can do to maximize that benefit.

One idea that came up was looking at addressing the frustration that people feel when there are two simultaneous sessions that they want to go see.  At previous productcamps, we used a very simple, on-the-fly scheduling approach:

1. We created index cards for each session and stuck them on the wall.
2. Each person had a few (3?) sticky notes, and stuck them under each session card.
3. The ones that got the most were lined up in the same room (to reduce conflicts in the popular sessions).
4. The rest of the sessions filled up the room/time slots without any particular optimization.
5. We did this sequencing in a couple minutes after everyone quickly “voted” with their post-it notes.

We learned, from “customer” feedback from the first two sessions that there is room to improve:

• People were still expressing frustration about “good session” conflicts.
• We also noticed a drop-off in attendance as people left before the end of the day – more attendees for earlier sessions.

So, if we’re going to improve session planning, one of the things we need to do is understand the details of sessions.  This is where domain modeling comes in.

We can create a UML class diagram that represents the domain of planning for (and attending) sessions.  This serves as an example of applying the business analysis techniques to gain insight into a problem domain before attempting to define a solution.

We know the following things about the domain:

• There are a limited number of rooms available for sessions.
• There are a limited number of time-slots available for sessions.
• Each session has a topic and presenter(s), and happens in a single room at a single time-slot.
• Each session has multiple attendees.
• Each attendee wants to attend multiple sessions.
• Each attendee has a prioritized list of sessions they expect will benefit them if attended.
• Each attendee can only attend one session per time-slot.
• Each attendee wants to maximize the benefit that they get from the productcamp.

[larger image]

The diagram above shows the relationships that will inform the design of any solutions.  For more on how to create UML class diagrams, check out our tutorial series on domain modeling.  One challenge of domain modeling is that there are often multiple ways to represent the same relationships.  With a goal of “understand the domain” – how would you model this differently?

When prices go up, demand goes down.  But how much does it go down?  Price elasticity of demand is the term economists use for the math that describes this behavior.

Cause and Effect

Prices go up and sales go down.  Prices go down, and sales go up.  There is definitely a correlation – and economists will argue that it is cause and effect.  I think they’re right – and here’s the rationale.

Imagine an apple, a group of people who are interested in buying that apple.  Each person would be willing to pay a different amount for that apple, because each person assigns a different value, or utility, to having that apple.   Even two identical twins who normally would value the apple the same might value it differently right now.  Imagine that one of our twins has not eaten in a couple days, and the other just finished a very large meal.  They would realize different amounts of utility right now from that same apple.  Or imagine a millionaire and a pauper, who value apples equally, but place less importance on a small amount of money.  Or imagine someone with a bushel of apples, and someone with none – to whom is “one more apple” worth more?

Because different people are willing to pay different amounts (for different reasons) to buy an apple, we have the effect of demand (a proxy for eventual sales) that varies with price.

At price X, half of this group of people would be willing to buy the apple.  Some people might see it as a great bargain, while others are only just barely willing to pay the price of X.  There are also some people who are almost willing, but the price is just a bit too high.  And finally, some people for whom a price of X is just unreasonable.

If you lower the price, all of the people who were previously willing to buy the apple are still willing.  The people who were almost willing before will now buy the apple.  If, on the other hand, you had raised the price, the people who were just barely willing to buy will instead not buy.

The graph above shows price on the vertical axis, and quantity on the horizontal.  When you lower the price from P0 to P1, the quantity that will be sold increases from Q0 to Q1.

Price Elasticity of Demand

When you’re talking about pricing impacts on demand, you’ll usually just say “price elasticity” but it is worth remembering the “of demand” part.  For example – there’s also Price Elasticity of Supply.  Think of the apple example above.  Imagine that the group of people are all selling apples, and there’s a single buyer.  Depending on the price the buyer sets, some people would be willing to sell, and others unwilling.  Change that market price, and the number of available apples for sale will change.  For now, we’ll focus on the impact of changing prices on demand.

The reason price elasticity is interesting is because it gives us some insight into how much the quantity will change when prices change.

Economists have a couple formulas for price elasticity (of demand), including e = % change in quantity / % change in price.

When the relative quantity changes by exactly the same amount as the relative price, you have e=-1, referred to as unitary elasticity.  If you reduce your price by 10%, you increase the quantity sold by 10%.

As a numerical example, you price bags of apples at $10 each, and are able to sell 20 bags of apples for $200.  With e=-1, unitary elasticity, if you lowered the price to $9, you would then sell 22 bags for $198.  If you had raised the price to $11 per bag, you would have sold 18 bags for $198.  If you dropped the price to $5 per bag, you would have sold 40 bags for $200.  Ignoring rounding errors, you would always have the same revenue.

The areas of the two rectangles formed by matching price and quantity are identical.  This leads to the conclusion that you will get the same revenue (assuming you can meet demand) regardless of the price you set for your product.  However, don’t worry about this too much – as far as I know, no real-world products have unitary elasticity.

Changes, More or Less

Elasticity is still useful for understanding the magnitude of change in demand that results from changes in price.  Does demand change by more than your change in price, or by less?

An inelastic demand curve has an elasticity value between 0 and -1.

The resultant relative changes in quantity from a given change in price are smaller than the change in prices.  You can see from the steepness of the cuve in the inelastic demand curve above that a large drop in price (from P0 to P1) results in a small increase in quantity sold (from Q0 to Q1).  However, the converse is also true – a relatively large increase in price will cause a proportionally smaller decrease in demand.

This tends to be the case with products that people “must have.”  In other words, people don’t have good alternatives (substitute goods, or doing without).  When the price of gas doubled, did you reduce the amount of gas you purchase by half, or by less than half?  On the whole, demand for gas dropped by less than 50% when the price doubled.  Another example is anti-biotics.

An elastic demand curve is one where the quantity is very sensitive to changes in price, and has elasticity values below -1.

Small changes in price result in large changes in quantity with an elastic demand curve.  This tends to happen when there are reasonable alternatives to purchasing the product.  For example, when mass-scale production of chicken started and poultry prices dropped in the US, demand increased faster than prices dropped.  This happened at the expense of beef and pork purchases.

Conclusion

Understanding price elasticity of demand is important to making decisions about pricing your products.  There are many factors that determine price elasticity.  The value of your product is a key driver, as it determines the utility curve on which a customer places your product – how much is “what your product does” worth to your potential customer.  Understanding the alternatives your customer has are important – are you selling a commodity product like typing paper, or a unique product like a Tesla?  The more “perfect substitutes” there are for your product, the more elastic your demand curve will be.  If the problem you’re solving can also be solved in other ways, you are again facing substitution.  A pencil is an “imperfect substitute” for a pen, for customers that care only about recording messages on paper.  These also tend to make your demand curve more elastic.

In Predictably Irrational, the authors identify several pricing concepts, like anchoring where people are psychologically influenced to believe one product is more valuable than another.  They look at some very interesting experiments that appear to highlight things that influence people’s perception of utility – making them willing to pay different prices.  An interesting extension of their ideas is that you can influence the price elasticity of demand for your product through positioning and marketing actions.