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.

Pictures can convey messages much more powerfully than words.  In a recent discussion about writing whitepapers, I suggested combining the idea-creation advice from Made To Stick with the image-creation advice from Back of The Napkin.  Check out this article to see some concrete examples.

Made To Stick

Paul Young, product manager and author of Product Beautiful,  sent out a tweet the other day asking:

Anyone have any “best practices” for whitepaper development? E.g. most whitepapers I read are stilted, I want to make something compelling.

Tweet, on twitter

I suggested combining the ideas from Made to Stick and Back of the Napkin to create a compelling whitepaper.  Stephanie Tilton then replied with a link to a good article she wrote showing how to apply the ideas from Made to Stick to writing whitepapers.

The book, Made To Stick: Why Some Ideas Survive and Others Die, written by Chip Heath and Dan Heath, has some very powerful ideas for communicating ideas.  Stephanie sums them up nicely in her article:

• Simple
• Unexpected
• Concrete
• Credible
• Emotional
• Stories

Stephanie Tilton, How to Craft Whitepapers that Stick in People’s Minds

Check it out, she goes into more detail, with examples and insights about why they work.  What about the Back of the Napkin ideas?  That’s what this article covers.

Back of the Napkin

I remember feeling like I’d been hit in my frontal cortex with a frying pan at Product Camp Austin (Winter 2009), when I first saw a visualization created by Sunni Brown of Brightspot for one of the presentations.  I remembered hearing about Back of the Napkin: Solving Problems and Selling Ideas with Pictures, by Dan Roam, and immediately ordered it from Amazon.  This is actually the current book for the Smarter Product Managers book club.

Applying these visualization techniques is extremely compelling for sharing ideas.

There is a ton of science behind why (and how) visual presentation of ideas (pictures) works so well.  Dan Roam does a fantastic job of making this approachable and actionable – an excellent book.

Getting back to the conversation…

How to Put Pictures in your Whitepaper

The rest of this article is showing some example images, in Back of the Napkin style, that support the ideas from Made to Stick, as you would include them in a whitepaper.

Imagine you’re writing a whitepaper about requirements elicitation.  There are a lot of important topics you could cover, but to stay aligned with the simple message from Made to Stick, you will want to focus on one idea (for each whitepaper, as Stephanie explains in her article).

User representatives are often offered to business analysts as a “convenient” source of requirements – the actual users are too busy, too valuable, or too easily distracted/upset/encouraged by conversations about the future.  This idea is both bad and pervasive.  You want your whitepaper to convey emotionally why this is bad.  You need something concrete, and maybe you want to tell a story.  Consider this image:

This is poorly drawn (but that’s ok!), but it establishes the metaphor that inserting user representatives into the elicitation process is like playing the telephone game.  The message (user goals) gets lost between the users and the business analyst.  It also points out that the conversation between users and analysts is what makes good requirements elication, well, good (ref. the smiley faces in the drawing if you’re not sure).

Designing for “Everyone” is a Bad Idea

One challenge for product managers is determining which features to include in their product roadmap.  Industry analysts, and sometimes buyers, have been known to use checklists to pre-screen or select products.  That may be true, but using a checklist to prioritize your product development is a bad idea, because you end up creating a product that doesn’t thrill any particular users, and just makes analysts happy.

The quick mock-up of a Consumer Reports style checklist shows a comparison of your product against the competition’s product.  With six features (A through F), it appears that your product is better.  [Here's an article comparing elicitation techniques, with a real consumer-reports-style checklist and an explanation of how to read it.]  You have six “half-circles” which looks to be “better” than two “full circles.”  Therein lies the danger.

Any individual user cares about two or three of those features (capabilities), not all six of them.  Will that user prefer your product or the competition’s product?

That user is thrilled to use your competition’s product, because it does what that user cares about, really well.  Your product is half-baked. Happy analyst, missing user (for you).

Increasing Distribution Channels Decreases Sales

Another key idea from Made to Stick is the notion of presenting the unexpected.  The authors point out that you need to demonstrate an idea that is at odds with the reader’s concept of reality – breaking it – and then rebuild the reader’s sense of reality around your new idea.  That’s where the unexpected comes in.

Consider that you are selling a product into a crowded market, with many places that customers could buy your product.  You do your inital launch, selling through one sales channel.  Someone proposes adding other channels – hey, more is better, right?

How do you prevent this Benedict Arnold from killing your company with what looks to be a great idea?  How about getting people’s attention with this “violation of common sense”:

That will get people’s attention.  What the Heath brothers point out is that to establish credibility with this unexpected visual, you have to rebuild people’s perspective.  You could do that with the following:

Since each store (channel) has a best-sellers list, like the Billboard charts for music, you want to make sure you’re at the top of the list.  Most downloaded is a common metric for software available on shareware and freeware sites.  If people can get your product anywhere they happen to be, it will dillute your rankings at every store.  By targeting your marketing and making your product available at one store, you will get more traffic (at that store) than you otherwise would.  Then new potential customers will be more likely to discover your product because it is at the top of the list.

Climate Change

I touched on credibility in the last example.  As Stephanie points out in her article, the Made to Stick authors were talking more about data than visceral understanding.  The first thought that popped into my head was the effectiveness of Al Gore’s data in his An Inconvenient Truth book (and presentation and movie).  He demonstrates that there is a correlation (and implies that there is a causal effect) between the average temperatures on earth and carbon dioxide levels.

Pretty powerful message.

Conclusion

Pictures like the ones above, drawn as Dan Roam suggests in Back of the Napkin can make the ideas you present in your whitepaper really memorable.  Use the Heath brothers’ approach from Made to Stick in crafting your message, and fold it into your whitepaper as Stephanie suggests.

The result is a compelling and memorable white paper, just like Paul always wanted.

A lot of books and blogs and experts tell us to use “The System shall…” when writing requirements.  Read on to find out why that’s not a very good idea.

Ambiguity Is Bad

It is important that when you communicate requirements, you be unambiguous.  That communication may happen through conversation or documentation, or some of each.  

Conversations are most effective when you are face-to-face, and least effective when you’re talking to someone who is 8 to 12 hours out of sync with you.  This is because conversations become infrequent.  The time difference introduces a resistance into your product creation (requirements and design and implementation) process, because it decouples one of these areas from the other two.  You can co-locate requirements and design with a remote implementation team, or you can have your design and implementation teams both working in a different location than your requirements team.  

Remote teams introduce a latency in communication.  When the teams are working with no (or very few) overlapping hours, this latency becomes very large.  Each back-and-forth can take 24 hours instead of 15 minutes – that’s 1% as efficient!

The most effective ways that people have found to reduce the impact of this latency is through documentation – allowing artifacts to persist over time.  Well written documents can capture understanding, will anticipate questions with correct answers, and will be unambiguous.  The ambiguity part is key to improving team efficiency – every ambiguous statement introduces at best an extra back-and-forth (with possible delays), and at worst, an unpleasant surprise at the end of the project.

When dealing with distributed teams, ambiguity in your documents is a killer.  Your reader can’t pop his head over the cube wall and ask “What exactly did you mean by this?”

Language Barriers Can Hide Brambles

It is easy to acknowledge a language barrier when two people don’t share a common language.  What is insidiously dangerous is when two people share a common language, but not really.  There’s a clever joke – “England and America are two countries separated by a common language.”  And it is very true.  As a Texan, sometimes I feel that way about Americans from New England.  Down here, a bubbler is an oil well that needs to be capped.  Up there – it is a water fountain.

When you learn multiple languages, you translate (on the fly) into your original language.  The one exception I’ve heard is if you start dreaming in the “new” language, you aren’t translating anymore.  As our world gets smaller, and teams become more diverse, you become more likely to have someone on your team who is translating as part of communicating.

Translation is another source of ambiguity, both in conversation and in documentation.  In conversation, you can practice active listening or look for other cues that give you an indication that what you said isn’t what she heard.  In a document, either you are introducing ambiguity (causing another clarification cycle), or you are introducing an error in communication – imagine if the translation is “wrong.”

As dangerous and expensive as this can be in general, with a 1% efficient communication channel, it can kill your project.

Shall, Should and Must

In English, shall and must mean the same thing – something is mandatory.  Should means, roughly “it would be a good idea.”  In fact, should is such an ambiguous term, you should never use it in requirements.  I’ve worked with teams that used a MoSCoW rating system before – every requirement was identified as one of “must”, “should”, “could” (don’t not do it), or “would be nice.”  The problem with this approach is that the team is only accountable for the “must” requirements.  At least in practice.

Personally, I’ve always disliked the word “shall” when writing requirements.  First, not everyone considers “shall” to be a mandate – but generally people do.  Second, I’ve always found the word shall to be too similar to should - which is a terribly ambiguous word in a requirement.  Once I started working with global teams, often with “limited” sharing of a common language, I began to get that feeling that something isn’t right, that maybe shall would cause a problem.  Surely must is ok.

This, I realize, is an opinion.

Translating Shall and Must

Around 5 am this morning I had a couple hours to kill and a disturbing notion of what would be “interesting.”

So I used Google’s translation service to translate shall and must into every supported language and back again.  

When I was still programming, we often had to support import and export of data from our products.  A great way to test the importer and exporter was to import data into the product, then export it back out (or vice versa) and compare the (twice) translated version with the original.  If they were an exact match, both the importer and exporter worked.  If not, there was a bug somewhere.  We called this round-tripping.  As an aside – this is a great way to do test-driven development of import and export functionality.

This morning, I round-tripped the words shall and must from English, through 41 different languages, and then back into English again.  Here’s a table of the results (shall on the left, must on the right):

 [larger version]

Here are the facts about what happens when you translate shall from English into each of 41 other languages, and back to English again.

• In most languages (22/41) shall does not translate back into shall.
• Other round-trip results included: will, should, must, to be, point, has, going, and “I”

That confirmed my fears that shall was a dangerous word.  What about must?  I was not optimistic.  I was also undercaffienated.

Here are the facts about what happens when you translate must from English into each of 41 other languages, and back to English again.

• For 100% of languages (41/41) must translates back into must.

OK, that’s pretty irrefutable data.

Conclusion

I don’t really care if you like the alliteration of saying “The system shall share secrets on sign-in”.  

You need to use the word must when writing requirements to avoid ambiguity.

Growth is a make or break measurement for products and companies.  Investment is often determined by expected value, which is based (in part) on expectations of growth.  When you create a product, there are aspects of growth – how many people can use your product, and how many people do use your product.  When dealing with a freemium business model, there are two elements of use - paid use and free use.

Three Goals of Growth

You can think about growth in terms of three goals – increasing your servable market, increasing your market share, and increasing your paid market share.

• Servable Market – The number of customers that could potentially use your product.
• Market Share – The percentage of the market (or of the servable market) that does use your product.
• Paid Market Share – The percentage of the market (or the servable market, or your users) that use and pay for your product.

As a product manager, when you consider capabilities to add to your product, you need to understand which goal your capability is designed to address.  These are all inter-dependent metrics, so it can be challenging to stay focused on each.  For example, if you have a 1% conversion rate from free customers to paying customers with your freemium business model, you may assume that by increasing the number of free users, you will automatically increase the number of paying customers.  That might be true, it might not.  Ultimately, you want to increase the number of paying customers – so that is part of all of these decisions.  When making each decision about prioritizing the next capability to add to your product, make sure you understand the primary growth goal you are affecting.

To keep the language from being too contorted, in the rest of the article, I’ll talk about users and customers as people, and not try and differentiate companies and people.  Users are people (or companies) that use your product or service.  Customers are people (or companies) that pay to use your product or service.  Your product could be a physical product, a software product (or license), software provided as a service, or a service.  I’ll refer to it as a product.

Growing Your Servable Market

The pedantic definition of your servable market is all users who could use your product.  A better way to think about your servable market is all people who experience the problems you’re trying to solve, who have reasonable access to your product.  People who don’t have those problems are not part of your market.  People who have those problems, but can’t reasonably use your product are part of your un-servable market.

Imagine you build a product that only runs on Windows Vista.  Windows XP users are not part of your servable market – they could upgrade to Vista and use your product, but they haven’t yet.  There’s a barrier to entry that they have to overcome.  Perhaps you have a pizza shop that delivers within a 10 mile radius and allows customers to place an order for pick-up and drive to your store and pick up the pizza.  If your shop is in Mountain View, technically people could drive from downtown San Francisco to pick up a pizza – but there’s a barrier to entry (the time and expense of driving to Mountain View) that makes those downtown San Francisco people part of your un-servable market.  

The size of your servable market reflects the potential number of users you could serve.  Your focus on growing your business can include changes designed to increase the size of your servable market.  You can write (non-functional) requirements that express this goal.  One type of non-functional requirement is platform support - supporting different operating systmes; supporting netbooks (with less-powerful processors) as well as laptop computers; supporting devices with slower network connections; and supporting visually impaired users through your user interface.  Sometimes, the requirement to support a particular platform is represented as a constraint (e.g. you must provide support for linux users).

Many products are developed today as software as a service (SaaS) applications - and they are usually implemented as websites, where people can use the product through a web browser user interface.  The approach of ubiquity of web browsers and “always connected” devices leads to platform selection for web-based products being a less-constraining  factor in definition of your servable market.  You may still be constraining yourself based on the specific browsers (Internet Explorer, Safari, Opera, Chrome, Firefox, etc) that you support.  You can gain a lot of insight through an analysis of your traffic, or you can rely on general trends.

Your business model may only support customers in the United States of America (like the soon to be launched Google Voice).  Your user interface may be text only (and not support screen readers or other devices).  You may be building a Facebook application.  You may be selling headphones with controls for the new Apple iPod Shuffle (that has no integrated controls).

What’s important is that you identify the things you need to do (added capabilities, platform support, country availability) to increase the size of your servable market – and associate them with the theme (or context) of increasing the size of your servable market.

Growing Your Market Share

Your market share is the percentage of those people you could be serving who are your users.  You can also think of this as the size of your user base, but thinking of it as a proportion of possible users provides more insight (because it provides visibility into how many people aren’t in your user base too).  As part of developing a business model (or financial justification for investment in a new product), you will have developed a model with some assumptions about market share.  Venture Capitalists used to joke about pitches that projected capturing “1% of a trillion dollar market, and therefore a $10 billion business” without providing justification.

You have to develop a plan for how and why you will achieve a particular market share.  One approach is to develop a viral marketing message, for products that “sell themseleves.”  Another approach is to develop a product that is inherently viral.  You can, of course, apply multiple tactics.  

The point here is to identify those product capabilities or features that will encourage users who can use your product to use your product.  Adding support for a platform does not encourage users to use your product – it just makes it possible.  Adding a solution to a valuable problem encourages people to start using your product.  Your product may be one that is designed to inspire love, or one that is designed to reduce annoyances.  An effective (and right-minded, in my opinion) approach is to identify personas within your servable market, and focus on their problems.  As a product manager, you choose which of those problems to address – and your team invents a solution approach.  You then validate that this approach is an effective one for the particular problems of the target persona.  

You may also want to define market segments to subdivide your servable market, so that you can develop unique strategies for presenting your solutions to potential users.  For example, you may find yourself with a surplus of cheap black pearls.  You can create two market segments – people who buy cheap jewelry and people who buy very expensive jewelry.  For the first group, you may position your product as cost-effective elegance.  For the big-spenders, you may position your product as something rare, unique, and not like those “everyday” pearls their friends all wear.  [I am pretty sure this is a reference to an anecdote from Predictably Irrational, but I'm not sure.]

What’s important is that you identify the things you choose to do (develop solutions to specific problems) in order to increase your market share – getting viable potential users to become active, actual users – and associate them with the theme (or context) of increasing your market share.

Growing Your Paid Market Share

People normally talk about this as conversion - conversion of free users into paying customers.  We’ll do the same.  I wanted consistent section headings. so I came up with “Paid Market Share” as a title.

Conversion is a key element to a freemium business model – one that offers two or more versions of a product.  One version is free to use and the other is a premium version that users pay to use (thus becoming customers).  Your conversion rate is the percentage of your users who are paying customers.  As we mentioned in the previous section on growing market share, you will have developed a business model for how much market share you would get and when and why.  If your business model is (or involves) a freemium product offering, your plan will also include projections around the number of paying customers you will have over time.

This is where focus becomes valuable.  As you identify problems to be solved (as part of developing a market-share growth strategy), you need to also decide which problems should only be solved (or should be solved better) for premium customers.  For example, the free version of MediaMonky (audio software) solves the problem of being able to listen to your audio files on your computer.  The catch is that when you add new music, you have to click a button that updates your “library” (so that MediaMonkey will play the new music).  The premium ($20US) version will automatically detect those new files.

You may also decide that a product is free for some users (companies with fewer than 10 users), and charge a fee to larger companies (10 or more users).  I don’t consider this to be a freemium model  In a freemium model, any user can choose either version of the product.  A related model is one where one set of users pay while another set doesn’t.  The distinction is probably best made by thinking about market segments.  If all (potential) users in one market segment only consider the premium version, and all (potential) users in another market segment would get no additional benefit from the premium version, then you would approach your growth strategy differently.  You wouldn’t be focused on converting customers, you would be focused on attracting paying customers – which is the same approach you use for growing market share.  In this case, you’re trying to grow the “pay for our product” market segment.

When you do have a freemium model – one where any given user can choose to pay or not – your focus is on identifying problems to solve for premium customers.  Not only do you have the normal “is there value in solving this problem?” question, you also have a positioning question.  Will you alienate the users of your free product (or inhibit market share growth) by offering a capability only to paying customers?  Another interesting strategy is to introduce new capabilities to premium customers first, and then have them “trickle down” to the free version as new capabilities are introduced for premium customers.

This strategy seems to be a powerful way to leverage market insights to continuously make your product more valuable than your competition’s products.  This could be a great way to “set the pace” for your market – forcing your competition to be reactive.  Slower competitors will lose not only to your premium product, but to your free version, which will out-value their paid products.  You get to define the rate at which your market changes.

What’s important is that you identify the things you choose to do (develop solutions to specific problems, and position them appropriately) in order to increase your rate of conversion – getting current free-product users to become premium-product (paying) customers.

One Way to Bring it all Together

I’ve done work with a client who has a distributed leadership team, so whenever I wanted to write on a whiteboard or stick stuff to the walls, I had to do it electronically.  We created a “strategy” Google-spreadsheet.  We have three columns one each for – grow the servable market, grow our market share, and grow our paid market share.  We added items into the appropriate columns, and developed relative priorities within each column.  The client strategy at any point in time, clearly drove the balance of emphasis for a given release across those columns.  Some releases, for example, were entirely around growing the servable market.

Conclusion

It isn’t enough to just consider the value of a particular capability, you have to put it in the context of an overall growth strategy.  Even if you’re solving problems from all three columns (servable market, market share, and paid market share growth), your top down strategy should drive how much effort you dedicate into each column, for any given release.

Ever scratch your head and wonder why you can use your favorite application for free?  How can a business actually make money (and stay in business) when they offer their product for free?  This article looks at the freemium business model, to see when it makes sense for a company to offer it.  The freemium model is one where the company offers two (or more) versions of a product.  The basic version is free to use.  You have to pay for the premium version.  The goal of this article is to answer the product management question, “Should you create a freemium business model?”

Economics of a Freemium Business Model

One way to look at the freemium business model is to look at it per user.  A user will either use the free (basic) version, or for-a-fee (premium) version.  

By definition, a freemium model is where one user is faced with a choice – do I use it for free, or do I use it for a fee?  

We will look at how to encourage users to move from the free version to the for-a-fee version later.  For now, we’ll just look at the impact of that choice.

Billing Peter to Pay for Paul (Freemium)

Every free user gets benefits, for free.  Every for-a-fee user pays for the benefits of the product.  The customers who pay for your product also cover the costs you incur when providing the service for free to other customers.

As a company, you have to look at your aggregate user base to analyze the economics.  Some percentage of your users pay for a product (premium), and another percentage do not (free).  What makes this interesting is asking the question – “What percentage of your users will pay when a free version is available?”  Basecamp, from 37signals just celebrated its 5th anniversary, and serves as a good illustrative example.  Note that 37signals expressly does not share this information, so we have to speculate.

• In a 2006 interview with Ryan Carson for ThinkVitamin; Jason Fried, owner of 37signals, indicated that it was “more than 0.87%” – we’ll call that 1%.
• In a 2009 interview with Brad Spirrison for MidWestBusiness.com; Fried indicated that 90% of revenue comes from subscriptions to web applications.  Spirrison points out that 37signals earns $40,000 monthly from their job board – so we’ll estimate $360,000 per month from subscriptions.  We can sanity-check our 1% estimate.  Fees for 37signals products range from $24 to $149 per month.  If the average paying user pays $36 per month, then there would be 10,000 paying customers – 1% of a million.  We could tweak the numbers (the average might be lower, there may be more than a million users, etc).  But this data is consistent with a 1% conversion rate.
• Jed Christiansen did an analysis about a year ago where he estimated ~ $5,000,000 per year, with numbers very consistent with the Spirrison interview.  Jed built his estimates up from the usage stats that 37signals reported (links at Jed’s article), and some assumptions for converting from usage to number-of-users.  His estimates would put conversion somewhere around 0.5% to 1%.  He provides a spreadsheet of the model too, if you want to tinker with it.

This feels reasonable – 100 free users for every paying user.  Even if that number is wrong, the rest of this article holds true, but it sometimes helps to have a number to think about.

The Left Hand Doesn’t Know What the Right Hand is Paying (Not Freemium)

This is the situation where a user gets a product or service for free, and a different user gets a different product or service for free.   Technically, this is not a freemium model – the same user does not choose between the two options.  User A chooses between free-product-A and not using anything.  User B chooses between for-a-fee-product-B and not purchasing anything.  User A has no interest in product B and vice-versa.  A company may offer a free product or service using this business model, and it may make sense – but it is not freemium, because the same user is not choosing between the two different products.  A company may also use a freemium business model, but augment it with this business model.  The following examples are examples of this model, listed here to avoid miscommunication:

• A company can offer a product for free to (primary) users, then charge advertisers (secondary users) to display ads to the primary users.
• A conference may offer the opportunity to speak/present (for free) to lecturers, then charge attendees to listen to the lectures.
• A government may offer waivers on corporate or property taxes to a company to build a new facility, then levee payroll taxes against the employees for the priveledge of working there.
• A shopping mall may host free events (like christmas pageants) to the general public, then charge the retailers for rental space in the mall.

In each of these scenarios, the users who get the free product or service are not choosing it relative to the paid product or service.  Different users are targeted for each.  The first model (advertizing supported products) is easy for everyone to identify, but all of the examples share a commonality.

Freemium Product Costs and Prices

Isolating the freemium business model from other revenue-generating opportunities, you can see that finding a profitable model can be tough – you have to control costs and set prices correctly.  Assuming our data from above is representative (and I don’t know if it is), if 1% of customers are paying customers, then each paying customer has to cover the costs of 100 customers to have the possibility of being profitable.

Quick Cost-Model Refresher

From a management accounting standpoint, for a given product, there are two types of costs.  

• Fixed Costs – these costs are the same for the company, no matter how many users there are – additional (incremental) users add no incremental costs.
• Variable Costs – these costs are the same per user – incremental users add incremental costs.
• Total Costs – the sum of fixed and variable costs.

There are also two important ways to look at profitability – overall, and per product sale.

• Total Profit – The sum of all product sales minus the total costs to make and sell the product (including overhead).
• Contribution Margin – The difference between product (or service) revenue and the variable costs to make and sell the product.

When the total revenue from product sales exceeds the total costs to make and sell that product, the product is profitable.  From a decision-making standpoint, the contribution margin needs to be positive. The number of products that need to be sold for the company to be profitable is the fixed costs divided by the contribution margin.  Here’s an example (using a software as a service pricing model):

• Your business has $10,000 per month in fixed costs.  
• Your product has a variable cost of $0.10 per month per user.
• 1% of your subscribers pay for their subscription, 99% subscribe to the free version.
• You price your product at $20 per month per user (per unit subscribed).

That looks like a hell of profitable product – some people will pay $20 for something that costs you a dime.  But looks are deceiving.  You have to cover the costs of the free subscribers, and you have to cover the fixed costs of making and selling your product.

 [click for larger image]

You have to get to 100,000 subscribers (1,000 paying customers) just to break even.  This takes much longer than you would expect when selling dimes for $20!  Even a 25% per month growth rate can’t help you early on.

 [click for larger image]

The exponential growth does start to compound, but it delays break-even.

The reason this happens is that you have to pay for 100 free-account subscribers with the revenue from each paying customer.  The contribution margin is the key here, and three things have to be true or you shouldn’t have a freemium business model.

1. You have to have a contribution margin that is positive, when taking into account the ratio of free users to for-a-fee users.
2. You have to have a sufficiently large user base (number of users – more precisely, paying customers) to cover your fixed costs.
3. You have to lower your costs (if (1) is not positive or high enough) and grow your user base (if (2) is not large enough) fast enough to get profitable before you run out of funding.

Growing Your Customer Base

There are a two ways to grow your customer base – traditional marketing to grow your customer base, or word of mouth marketing to grow your customer base.  If you’re relying on word of mouth marketing, there are two different dynamics that drive word of mouth [thanks to Jonathan Berkowitz of Thinktiv.com for this insight!] – altruistic and selfish.  

Altruistic – This product helps me, it will help you too.  You should use it.

Selfish – It helps me if you start using this product.  You should use it.

Discussion of the two different word-of-mouth patterns will have to wait for the next article.  I’ll update this one with a link to that one when it is written.

[Update: Viral Product Management is now posted!  Thanks all for the great attention to this one so far.]

Just because your requirement is not a user story does not mean you have to throw it out when planning your next sprint.  See one way (that is working) for managing non-functional requirements with an agile team.

Product Backlog Stories

Every article* I can remember reading that explains how to manage a product backlog talks about user stories.  Those articles are necessary, but not sufficient .  You’ll create better products by developing them from the outside-in, with a user-centric point of view.

*One loophole – scheduling refactoring (or the payback of technical debt).  A lot of articles talk about the need to do this, and refactoring is pretty much the opposite of a user story, since by definition, refactoring improves the software without introducing new capabilities.  The best idea I’ve come across for incorporating refactoring as part of a sprint is to write a user story, with the system as the user, and the lead architect / developer as the primary stakeholder.  This actually works really well, but it works by treating the work as a user story.

Atomicity

What is really important, when scheduling sprints (or releases, if you are not doing scrum) is that you are scheduling solutions to atomic, measureable, valuable problems.  Atomicity is the reason for breaking epics (really big stories) up into smaller stories.  It is also important that you communicate them unambiguously.  That might mean writing user stories or writing use cases instead of user stories, when things are complicated.

The problem is, not every atomic requirement can be represented with a user story.  Some things that must be, are not stories.

Non-Functional Requirements

Non-functional requirements always seem to be under-emphasized when writing requirements.  The Twitter fail whale has become famous, because twitter could not scale to meet the demands of a rapidly growing user base.  Maybe the Twitter team planned for scalability, but demand simply outstripped it.  Or maybe they failed to plan for it.  Either way, they failed to meet the non-functional requirements of supporting the growth that they did have.  (Un)Luckily, this type of problem self-corrects.  Scaling failures drive away users, reducing the need to scale, until balance is achieved.

Product managers and business analysts tend to neglect non-functional requirements.  Unfortunately, this is especially true when managing with a focus on users and their goals.  Not because goals don’t drive non-functional requirements – they do.  I believe this has happened because historically, non-functional requirements were treated as an after-thought.  In reality, they are explicitly driven by goals.  I proposed an equal rights amendment to the structured requirements domain model almost three years ago.  In short, it explicitly calls out the relationship between goals and non-functional requirements.

Agile Non-Functional Requirements

Getting non-functional requirements into your sprint planning is actually not that hard.  You only have to make two tiny adjustments to get from the waterfall world to the agile world.

The first adjusment is that you have to treat non-functional requirements incrementally.  Non-functional requirements often affect all of the other requirements – so they seem massive and unweildy.  You have to decompose them.  Consider the platform-compatibility requirements for a web application.  You may have to support IE6,7,8; Safari on Windows, Safari on OS X, and Firefox on Windows XP and Vista.  That could be incredibly daunting.  So break it down.  Your first group of users (key persona) are primarily Firefox/XP users.  So the first platform you support is that one.  The next big platform for your persona group is Safari on OS X.  Add support for that next without breaking the previous support for FF/XP.  With each release, you add a platform (or two, or none).  You are conspicuoulsy addressing the needs of your target users.  The key is that once support is added for a platform, all future development is required to “not break it.”

Each non-functional requirement is cumulative.  This is the second adjustment.  All development, once a non-functional requirement is in place, must continue to honor it.  You wouldn’t break a previously released capability (functional requirement), so don’t break a non-functional requirement.  You have to determine, in each sprint, if additional functionality is more important than additional platform support.  And add in the platforms as they become the most important “next things to do.”  In waterfall projects, I’ve seen many teams break and re-break platform support throughout the development process, with the knowledge that it only has to work “at the end.”  Include platform-specific support in your continuous integration tests.

You have a launch event coming up in six weeks.  You have an established user base.  You’re also developing a key new set of capabilities for your product that you believe will be a big hit and drive significant growth for your product.  You have a small group of people in a private beta, providing you with feedback about the new development.  If you believe the launch will cause your customer base to double very quickly (maybe over a month), how do you plan for that?  This is a serious scalability non-functional requirement.

Break the non-functional requirement up into cumulative requirements.  Assuming your plan is to add 10,000 users “at once” – have your implementation team brainstorm what that could/would mean for the system.  [Also, make sure you coordinate with your community manager and marketing folks, both to validate the anticipated growth, and to device any contingency strategies in advance.]  After talking with your development team, perhaps you learn that “at once” is a nuanced proposition.  Literally at once is very bad.  Spread out over a few days, not so bad.  OK – you can deal with this too.

Imagine you already have the following non-functional requirements in place:

• The system must be available 24/7, with no more than one hour of down time per day, and no more than one outage per day.
• The system must respond in under 2 seconds for >95% of uses [ in key user story].
• The system must respond in under 20 seconds for 100% of uses [in same key user story].

Based on what we’ve said above, these non-functional requirements must not be broken.  They essentially define the acceptance criteria for our scalability requirements.

Consider the following as the non-functional requirements that must be deployed by the time of launch (six weeks, or three releases from now):

• The system must support 10,000 additional users added in the month following SXSW.
• The system must support 500 new users signing up and initiating [troublesome user story] within the same hour.

Your dev team does not really know exactly what needs to be done – they just know that the current solution won’t scale – it barely meets the existing non-functional requirements.  They propose a couple redesigns that may get the job done.  But they point out the need to actually test that the designs work.  Schedule the following for the first release:

• The system must support 100 additional private beta users.
• The additional users will all have [troublesome user story] initiated within the same hour.

The second one is really a pragmatic solution – artificially creating a spike in demand, to test out the scalability of the new code.  From that data, we can determine what we need to do to hit 10,000 additional users, and to support 500 concurrent [troublesome user story] instances.  By managing expectations of the new users (that you’re queuing them up to test scalability), you can get the data you need.  And you have a couple more iterations to improve if needed.

As a benefit, you get to completely avoid the fail whale.  The other half of this is making sure you can constrain the rate of new-user sign-ups.  Work with your community manager and marketer to make sure you position this effectively.  You are creating scarcity, which may increase demand.  A crashed server won’t.  If your team can’t support 10,000 in time for the launch, plan on 2,500.

Conclusion

You can plan and schedule more than just user stories.  And your product will be better for it.  Give those non-functional requirements a chance.