The maturity model approach to describing organizations and processes comes and goes out of fashion.  It is a repeating framework de jour.  In the game of agile jargon whack-a-mole, the agile maturity model is poking its head up again.

Agile Maturity Model

Ellen Gottesdeiner, author of Requirements by Collaboration, tweeted (@ellengott) a few hours ago with a link to an article proposing a set of maturity models.  She graciously passed on the opportunity to comment about the “agile maturity model” when pointing out her like of the collaboration maturity model.  The article proposed the following as an agile maturity model:

Agile Maturity Model (AMM)

0 – Dormant

1 – Speed: Focusing on being expeditious.

2 – Reactive: Focusing on acting relative to change from the perspective of the moment rather than a longer timeframe.

3 – Responsive: Focusing on acting relative to change from the perspective of the moment balanced with a longer timeframe.

I didn’t find it to be a particularly useful model.  Although descriptive, it won’t help your organization improve.

What Does Maturity Mean?

I wrote a series of articles a couple years ago that explored the CMMI and RMM – the capability maturity model and the requirements maturity model.  These are two different models that use maturity as a concept for articulating different levels, or grades (or enlightenment, or rigor), with respect to organizational behaviors.  At the time, there was both momentum and confusion around the notion of a requirements maturity model.  CMMI is a description of an organization’s rigor in “saying what it does, and doing what it says.”  RMM is an assessment of the level of critical thinking incorporated into the ways an organization is using requirements to develop products.

The problem is that people were incorrectly assuming that an organization “at level 4 CMMI” would approach requirements management at a comparably enlightened level.  The problem is that they are putting entirely unrelated concepts into similarly named classifications.  An organization could be at CMMI 1 and RMM 4 or RMM 2 and CMMI 3.  That series of articles explored what it would mean to be in any of the combinations of “maturity” for those two models.  Check out all the articles in the series if you want to put it all in perspective:

• Foundation Series: CMMI Levels Explained
• What CMMI Level Should We Use?
• CMMI Levels and RMM Introduction
• CMMI Levels and RMM Level 1 – Written Requirements
• CMMI Levels and RMM Level 2 – Organized Requirements
• CMMI Levels and RMM Level 3 – Structured Requirements
• CMMI Levels and RMM Level 4 – Traced Requirements
• CMMI Levels and RMM Level 5 – Integrated Requirements
• Don’t forget to take our One Minute Survey on CMMI and RMM.

Making a Maturity Model Useful

Why bother with a maturity model?  Not so you can “keep score” relative to others – rather, so that you can improve your own organization.  For a maturity model to be useful, you have to be able to do two things.

1. You must be able to determine where your organization is in the model.
2. You must be able to identify actions you can take to “improve” your organization relative to the model.

If you can’t measure maturity, and the model does not provide guidance about how to improve, it’s useless.  One challenge with maturity models is that they risk becoming contextually narrow in their application.  The more concrete a measurement or suggestion becomes, the less extensible it is likely to be.  Ideally, your model would be broadly applicable to many organizations.

With an agile manifesto that emphasizes people over process, it is ironic to consider applying a metric that measures your agile process.  So – goal #1 is immediately undermined.  Goal #2 – improving your organization, is, however, very valuable.

Improving An Agile Process

I’ve worked in several agile environments, both as a practicioner and as someone helping to transform organizations to become agile (or better at agile).  I’ve worked in enterprise software, helping large teams adopt agile processes; with a SaaS consumer product team, and in large IT departments with collections of teams adopting agile processes at varying paces.  I’ve played on both sides of the fence (delivery/QA & product management/ownership).

Going from zero to sixty on agile is a big task.  You can’t solve all of the organizational, practical, and interpersonal challenges at the same time.  Or at least you would be more effective tackling and resolving each issue in sequence.  In fact, you should solve the most important / largest problem first – then move on to the next, and so on.  You can call it agile agile adoption, or you can call it eating the elephant.

One powerful use of a maturity model is highlighting the next-biggest hurdle you have to overcome.  Unfortunately, most communication about maturity models is “look which hurdle we just overcame” – but the focus should be on “what’s next?”

When helping organizations be effective with agile processes, there are some clear “you have to overcome this first” challenges, that if unresolved, make other challenges irrelevant.

If you’re a software developer, I’m sure you’ve experienced the following scenario:

• A bug is reported.
• You fix the bug, and write some tests to prevent it from reoccuring.
• While testing, you discover another bug that was hidden by the first bug.

Fixing that second bug doesn’t do any good until you’ve fixed the first one.

If you’re a product manager or business analyst, think about it in terms of capability enhancements.  Is a faster search important if the current search algorithm is not returning the right results?  Get good results first, then make it faster.

You have to solve the biggest/closest/roadblockiest issue first.  Then move on to the next issue.  That’s how you should use a maturity model – as guidance about “what’s next?”

When assessing / improving your organization’s ability to be agile, you need to be addressing whatever is next.

What’s Next?

Let’s discard the “maturity model” notion and focus on “what’s next?” instead.  And that of course starts with “what’s first?”  Here’s how I’ve presented an agile hierarchy of needs to in the past:

1. Staffing the engineering team correctly.  People over process is the right emphasis.  If you can’t find people that are “good enough” you might as well go home.  Doesn’t matter how agile you are if you don’t have the horsepower.  You also need people who are excited to “do agile” – they like to communicate, they enjoy the project and team dynamics of an agile process.  You’re also better off with specializing generalists – ideally, every member of the team can do any work that is needed.  This is an efficiency play – you risk introducing bottlenecks when you have a specialist who is the “only one” who can do particular types of work – because you will not have a consistent mix of types of work from release to release.
2. Assuring Quality is in your team’s DNA.  Arguably, this is part of what’s first, but there are a lot of teams that get cood at cranking out code, before they get good at cranking out good code.  Continuous integration is the approach you must have.  Test-driven development, spec-driven development, and other testing-integration approaches are extremely important, but are really reflective of different flavors of agile and quality, not different degrees.
3. Reducing overhead in the release process.  There’s a cost associated with releasing a product.  Once you get good at releasing, and are releasing good product, your next focus is on finding the right release cadence.  There are three factors that essentially dictate your release frequency.  The size of atomic deliverables (user stories and use cases, non-functional requirements, etc) your team is creating, the overhead (time and cost) of releasing, and your customer’s capacity to consume the releases.  My anecdotal experience is that teams are usually constrained initially by the cost of releasing – dedicated hours to creating a build, code freezes, etc.  Automating the build process (to reduce both costs and errors introduced while building) is first.  Integrating automated build and automated test processes together is next.
4. Feeding the beast.  Once you have an engineering / delivery team that is operating efficiently, you run into the problem of making sure they have enough important work to do.  There’s pressure on product owners and  product managers to schedule something because it is easy to define, not because it is important.  It is also important that the team understand the context and importance of what they are doing.  So you have to focus on making sure your product management team has enough capacity to keep the engineering team busy on delivering really valuable stuff.  The “right” solution to this depends on how the problem manifests in your organization. Is your product manager spread too thin across multiple products?  Too junior?  Too bogged down in sales support or trade show attendance or or or?
5. Managing stakeholder expectations.  A big challenge in changing an organization to become agile is in resetting and managing the expectations of stakeholders.  Execs are used to having an annual budget exercise where they dedicate X dollars in the pursuit of Y objectives.  We’ll set aside the reality that they’ll only achieve 1/3 of the objectives, at 2X the cost, much later than originally forecasted.  We aren’t looking at the failings of waterfall, we’re looking at the risks of agile.  There’s a ton of stuff here, from doing damage control to reverse perceptions that “people who want to do agile just don’t want to be accountable” or addressing the “we can’t tell you what X dollars gets you” message.  Again – the particular solution is a function of how the problem manifests in your organization.  Once your team is delivering valuable stuff efficiently, you have to make sure your management team is happy and engaged and knows what to expect.
6. Continuously learning from your markets.  This is really what differentiates an agile organization from an organization with an agile development team.  Agile processes do enable you to develop code more efficiently.  If you aren’t taking advantage of the faster development, feedback loops, and ability to change that agile enables, you’re leaving money on the table.  And one of your competitors will pick it up.  There’s a whole community of MBAs that talk about business agility without once thinking about software development.  They’re talking about an organization’s capacity for rapid response to changing market conditions.  It’s what separates the winners from everybody else.  And agile development makes business agility possible.  As long as your team is able to identify and value industry trends, competitive threats, and market opportunities.  When you’re good at this, you have an agile organization.  And you win.

Conclusion

Any agile “maturity model”, irony aside, needs to be structured to help organizations progress through the stages of enlightened operations – continuously providing insights into “what’s next?” for those teams to grow.

I know there are many readers here with years of agile experience – how would you improve the list above, to better provide a framework for “what’s next?”  When that framework is solid, we can do some wordsmithing and repackage it as a maturity model.  Until then, just focus on “what’s next” – that’s all a maturity model should be used for anyway.

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.

Creating a PERT estimate for a single task is both easy and straightforward. Creating an estimate for a set of tasks is still easy, but requires a little bit of math. Combining PERT estimates for tasks is easy, but not as obvious. Roll up your sleeves and dive in.

PERT Estimate Refresher

When estimating how long it will take you to complete a task, you shouldn’t estimate with a single value like “four hours.” “Four hours” does not provide enough information. Estimates reflect that there is uncertainty, and that single value does not give you any insights into how uncertain your estimate is. Your estimate could be “four hours plus or minus one hour” or it could be “at least four hours, maybe as much as sixteen hours.”

A PERT estimate, as we showed in our earlier PERT estimation article represents a distribution of likely effort for a particular task. To create a PERT estimate, you create three values -

1. The “best case” (shortest) amount of time it will take to complete the task.
2. The most likely amount of time it will take to complete the task.
3. The “worst case” (longest) amount of time it will take to complete the task.

A PERT estimate is presented in the form “Best Case / Most Likely Case / Worst Case.” If your estimate is “four plus or minus two hours” you would write 2/4/6 as a PERT estimate. Sharing “2/4/6″ as an estimate still doesn’t tell anyone else what you mean. A PERT estimate embodies some probability around completion time. You are precisely saying (for a 2/4/6 PERT estimate):

1. There is a less than 1% chance that this task will take less than 2 hours.
2. There is a 50% chance that this task will take less than 4 hours.
3. There is a greater than 99% chance that this task will take less than 6 hours.

This explicit statement of probabilities represents a distribution of likely outcomes. Statisticians would phrase it in a confusing (but mathematically important) way. They would say “if we sampled a large population of people (like you) doing this task, no more than 1% of them would complete the task in under 2 hours, no more than 1% of them would spend more than 6 hours on this task, and half of the people would complete the task in under 4 hours.” For the purpose of estimation, you can ignore the statistic-speak and just look at the “odds” of how long it will take you to complete the task once.

[larger image]

If you were to create a histogram of thousands of executions of the task, it would look like the diagram above.  This is the traditional bell curve shape we are used to associating with a normal distribution, but it actually represents a PERT estimate.  A PERT estimate is a distribution of possible outcomes, based on a beta distribution.  Another way to look at a PERT estimate is in terms of cumulative probability of a task being completed.  The same data in the graph above, when presented as a cumulative distribution function (CDF) looks like the following:

[larger image]

Here’s the rub – you don’t really know if the beta distribution is the right one.  Primarily because you can’t precisely know the actual probabilities.  So, you have to pick a distribution function to represent those probabilities.  There is debate about the right distribution function to use for estimation – check out this great article for hard core stats guys.  Here’s a cautionary warning from their conclusions:

Although bias stemming from misspecified activity time probability models is rarely mentioned in introductory discussions, we have seen several instances of this bias in simple examples. First, and perhaps most important is the uncertainty as regards the underlying activity time probability models. The literature offers no less than five procedures for translating the subjective estimates (a,m,b) into specific β-distributions. As shown, the methods lead to distinct β-distributions, and the PERT approximation need not satisfactorily estimate any of them.

Essentially, they are saying “you can’t really know the right shape for a distribution curve of possible outcomes – so don’t get carried away.”  And they then go on to suggest using a simpler model than the beta distribution for estimation.  Their suggestion is to use a triangular distribution (looks like a triangle, instead of a bell curve), because the math is easy.  With spreadsheets, we can still do “easy” math with a better distribution

The beta distribution for a symmetrical PERT estimate looks very much like a normal distribution.  You can see this by comparing the cumulative distribution function of the PERT and normal models for this 2/4/6 example.

[larger image]

Based on this similarity in distribution, and the inherent uncertainty in what the shape of the distribution really looks like, there are some benefits to treating the PERT estimate (2/4/6) as a normal distribution where the high and low values represent +/- 3 sigma bounding.  This approximation provides us some benefits when aggregating individual task estimates into combined project estimates.

Continued on the next page…

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.

Blue Ocean Strategy provides an interesting reactive analysis of companies and markets.  Personas are used to understand your customer’s needs.  Combining the two provides powerful proactive insights when positioning your product for market success.

Blue Ocean Strategy

The book, Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant, by Kim and Mauborgne, was written in 2005.  The book presents a very compelling way to visualize competition in your market by contrasting the emphasis (or effectiveness) of each company at solving particular problems.  The authors argue that red oceans are competitive markets where companies compete to solve the same problems for the same customers.  Their main idea is that by identifying (and solving) unaddressed problems, you can define a new market – a blue ocean with no relevant competitors.  The “red” in their metaphor implies blood in the water, caused by cut-throat competition.  Their position – by defining a new market boundaries with no competition, you eliminate the blood in the water and give yourself a calm, blue ocean in which to navigate your company.

This is a compelling idea, and has a lot of merit.  The Smarter Product Managers book club (started by Cindy Alvarez) reviewed this book last month, and one conclusion we reached during the discussion is that the examples in the book felt “reverse-engineered.”  I feel that the lack of prescriptive advice from the authors created a sense of “that’s fine, but how do I apply these ideas proactively?”   Some of the examples in the book, like Cirque de Solei and Southwest Airlines, felt very compelling (and are often cited), while others felt a bit more contrived.  Almost as if the authors were searching for data to support their arguments – a big no-no for product managers.

Creating a Blue Ocean Strategy Map

The book presents examples of “mapping” markets based upon the strength of the offerings from companies, along different dimensions.  The following example was created by me (and is used throughout this article), but follows the pattern of analysis described in the book.  This is an unresearched, hypothetical example analysis of the market for vaccuum cleaners – or more generically, floor cleaning products.

 [larger image]

The diagram above identifies seven dimensions by which you could characterize the offerings from each company.

• Breathe Easier / Anti-Allergen – sometimes, people vaccuum their rugs in order to reduce allergens (by sucking up dust), making it easier for them to breathe in their homes.  Vaccuum cleaners work by sucking up air through the carpet, collecting the dirt (that is sucked up along with the air), and filtering the exhaust air (that is expelled into the room).  Different vaccuum cleaners pay different levels of attention to removing allergens during this cleaning process, by (1) getting the allergens out of the carpet and (2) filtering the allergens out of the exhaust air.
• Remove Stains – one motivation to clean your floor is to remove stains.  This is not generally a focus of vaccuum cleaners, but products like the Green Machine do focus on removing stains, while also “picking up dirt.”
• Physically Easy to Use – after back surgery, one of the key pieces of advice my mother received from her doctor was “no vaccuuming.”  When you are young and healthy, you don’t expect vaccuuming to be something that is forbidden by your doctor.  Shoveling snow, climbing a mountain, running a marathon, yes – but vaccuuming?
• Reducing Hassle – Why don’t we vaccuum every day?  Because it can be a hassle to get out the vaccuum, set up the equipment, and actually use it.  When you reduce the hassle involved in vaccuuming, you are likely to vaccuum more often, thereby realizing more benefits from vaccuuming.
• Saving Time – Hassle is not the only barrier to vaccuuming.  If you could vaccuum your house in 5 minutes instead of 105 minutes, you would do it more often.  As a teenager, I used to jog behind the lawn mower, just to get the yard done so I could move on to other things.
• Reliability – While reliability is not a major factor when vaccuuming your house (once), it is a key component of making purchasing decisions – because you don’t vaccuum just once.  The more you vaccuum, the more you care about reliability.  This is also an indirect cost factor – a vaccuum cleaner that has to be frequently repaired or replaced will cost more per year than one that has the same purchase price and is more reliable.  This is also an indirect hassle factor – you may delay vaccuuming your home until you can make time to get a broken vaccuum cleaner repaired.
• Avoiding Cost – A direct focus on cost is primarily driven by purchase price.  Other factors (like reliability, and the cost of replacement bags or filters), but people place greater emphasis on purchase price when thinking about cost.  Consumer Reports and other “product review” companies will often “do the math” for you, taking into account all of the post-purchase costs to calculate total-cost-of-ownership.

The above diagram, with fictitous values for “Strength of Competitive Offering”, shows the competitive landscape for the vaccuum cleaner market.  One of the very powerful features of this visualization is that the Roomba faces “no competition” from the other companies in three of the seven categories – Ease of Use, Hassle, and Time.  A Blue Ocean Strategy analysis would say that the Roomba has created their own market, with an absense of competition.

This gets back to our insight that the examples felt “reverse engineered.”  The Roomba does have a dramatically different value-proposition, and focused on dimensions that are not addressed by their competition.  So why isn’t the Roomba in the book?  Because they still compete in the red ocean.  Unlike Southwest Airlines, they did not differentiate their offering in a relevant way.  And that’s the problem we found in trying to apply the principles from the book.  

It is not enough to be innovative and differentiated, which the Roomba certainly is, you have to be valuably differentiated.

So how do you differentiate valuably and proactively?  Identify the problems that your customers value, but don’t yet have solutions for.  How do you do that?  With personas.

Personas

Personas represent customers in your target markets.  Markets are not homogenous – different people in your markets value different things for different reasons.  You develop personas as archetypes to represent subsets of the customers in a given market who share common problems.  More concretely, personas share common valuations of shared problems.

To combine persona development with the market-mapping concept from Blue Ocean Strategy, create the same map, but for personas.  Instead of identifying the strength of each company/product along each dimension, identify how much each persona cares about each particular dimension.

 [larger image]

In the chart above, I’ve created 6 hypothetical personas who populate our market:

• Single Parent – the classic superman / superwoman who does everything, including keeping the house clean.
• Housekeeper – someone employed to keep someone else’s house clean.
• Office Cleaner – the person who vaccuums your office at 2am every night and picks up all the empty Diet Coke cans and Twinkee wrappers.
• Kid (Doing Chores) – most kids won’t ask for a vaccuum cleaner for their birthday, but when you child is responsible for vaccuuming, do you want a battle every week because they hate it?
• Homeowner – like the single parent, but maybe without kids, and definitely with fewer responsibilities (and more time).
• Retiree – like the homeowner, but with a lot more time, and a less robust physical condition.

[Note - the above examples are really stereotypes and not personas (there is no research to back them up - they are entirely fictional) - don't fall into the trap of thinking persona development is this easy.]

OK, now we have an understanding of how much importance each persona places on each dimension.  It looks like a mess, for this example, when you try and absorb the big picture.  If you focus on a single persona, you get great clarity about what that type of customer cares about.  Look at each curve individually, then look at them all together.  If you’re thinking ahead, you’ll suspect that the Roomba is perfect for the kid doing chores.  But wait, we’ll come back to that.

One insight we can gain from this messy view of the market is that you can’t create a product that is “perfect” for all of these personas.  You have to target a specific persona, and tailor your product for that persona.

Mapping Personas to Products

Now we have two views of the market, along 7 dimensions.  We have assessments of the relative strength of each competitor’s offering, and we have estimates of the relative importance to each persona – for each dimension.  What we need to do is combine the two.

All of this analysis runs the risk of introducing a notion of false precision - we have a lot of data, therefore it must be accurate.  So our inclination may be to try and do some mathematically refined, scientific analysis.  I suspect that would be wasted effort, providing no additional insights, and risking leaps to the wrong conclusions.  I propose a simpler approach.

The analysis we really care about – which product offering is best aligned with the needs of each persona?  A simple mathematical equivalent of “which curves match the best” is an easy analysis.  By comparing the values from each competitor curve with those of each persona curve, we can create a series of “how good a fit is it?” values.

 [larger image]

Imagine a persona saying “how well does each company’s product align with my goals?”  This “simple math mashup” takes into account both “they succeed at what I care about” and “they haven’t invested in something I don’t care about (at the expense of something I do care about).”

You can see that the Roomba clearly wins with kids doing chores.  The rest of offerings stand out less, but do provide insight.  Now you can easily drive strategic decisions – “we want to be the vaccuum of choice for housekeepers” now drives some obvious emphasis on ease of use and a reduced emphasis on reducing costs.

Improving The Model

My two main problems with the blue ocean strategy were lack of relevance (who cares about dimension X) and magnitude (which dimension is most important?).  The model above addresses only relevance – a focus on target personas.  We can overlay some “relative importance of each persona” data, or just manually focus our efforts on each persona in series.  

The other magnitude challenge is in understanding not just which problems are important in absolute terms (kids care a lot about saving time, but not cost), but in relative terms (kids would trade an hour of time for a modicum of ease-of-use).  Essentially, defining the utility-curves for each persona.  For any but the largest, most saturated markets, I would hesitate to do the utility curve analysis in detail – it feels too heavyweight and un-agile.

Conclusion

The Blue Ocean Strategy book provides us with a visceral tool for visualizing relative offerings from competitors in a given market.  Combine it with the same visualization approach for personas that participate in that market, and you gain insights into which problems to solve next to achieve product success.

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.

Is your market competitive, or concentrated?  What’s the difference, and how can you be objective about it and not just subjective?  The United States government uses a measure called HHI – the Herfindal-Hirschman Index – as an objective measure of how competitive a market is.  They use this measure to determine if a company is operating monopolistically, or to determine if a merger needs to be explored from an anti-trust perspective.  The ask the question: would the merger create an anti-competitive market?

You can use this metric to get insight into how competitive your market is, and to gain a better appreciation for trends in your market.  Read on to review the competitive landscapes and trends for email, search engines, browsers, and internet service providers.

Email Client Competition

It is hard to compete in the market for email clients (the applications people use to read their email).  Usually people will describe this market as “very competitive” – meaning that there are some products that dominate the market.  What people really mean is that it is “very hard to compete” in the email client market.  Take a look at this market data from fingerprint.

 [larger image]

The graph shows the percentage of emails that are read in each email client by consumers (blue, on the left) and business users (red, on the right).  Yahoo! Mail, Outlook, and Hotmail clearly dominate this space.  Almost three million emails were analyzed  to produce this market-share data.  The emails were opened by people, and fingerprint determined which email clients people used to read the emails.  It would definitely be hard to compete in this market with the introduction of a new email client – but is this market competitive?

Definition of Competitive and HHI

The United States government classifies markets based on degrees of competitiveness – competitive, moderately concentrated, and concentrated.  They use an objective measurement, the HHI (Herfindal – Hirschman Index, sometimes called the Herfindal Index), to determine the proper classification of each market.

Calculating HHI

To calculate the HHI for a market, you take the market share captured by each company and square it.  Then you add up those values to determine an HHI value.  

A pure monopoly market is one where a single company has 100% market share.  The HHI calculation for that market would be 100*100 = 10,000.  That is the highest possible HHI value, reflecting the complete absence of competition.

A market with 100 competitors, each holding 1% of the market would have an HHI = the sum of 1*1 for each of the 100 competitors = 100.  That is an incredibly low HHI value, reflecting an almost purely competitive market.  [At this point, you are probably wondering, "How do I find out the market share of the 99th largest company?" - don't worry, you won't need to.  We'll cover that later.]

The US government has declared that markets be classified based on the following ranges of HHI values:

• HHI below 1000 – a competitive market.  There are no dominant competitors in this market.
• HHI between 1000 and 1800 – a moderately concentrated market
• HHI above 1800 – a concentrated market.  There are one or more dominant competitors in this market.  Higher HHI values translate into fewer, more dominant competitors.

Anecdotally, the HHI values for the consumer and business email client data (shown in the graph above) are 2254 and 2650, respectively.  While Yahoo! Mail, Outlook, and Hotmail collectively dominate both markets, Outlook and Hotmail dominate even more (relative to Yahoo! Mail) in the business email client market.  The HHI shows this distinction with a 400 point (20%) difference between the two markets.

The US government uses this data to establish context – is a company operating in a concentrated market – one that promotes collusion, or is the company operating in a competitive (as in “free market”) market?  The government also uses HHI values as a litmus test for determining if a proposed merger might be anti-competitive.  If combining the market share of two companies results in an increase in the HHI calculation for a market of more than 100 points, then the move will raise anti-trust concernts.  I am not an anti-trust lawyer, but my interpretation is that if a merger does not raise the HHI value by more than 100 points, that would be evidence that could be used to argue that the merger is not anti-competitive.  

You can get useful insights about a particular market from the HHI value, that may guide your strategy for growing your market share, and apply them as part of your prioritization strategy.  Since it is an index that ranges from 0 (for an infinite number of competitors with effective zero market share) to 10,000 (for a pure monopoly), a difference of a few points between two HHI values does not yield a lot of insight.  A difference of hundreds or thousands of points does yield insight.

Avoiding Analysis Paralysis

One challenge you face is knowing when to stop gathering market share data, in order to calculate the HHI for a market.  I gathered a couple hundred data points in a dozen different market analyses, and determined that there is a reasonable stopping point, where additional leg work does not yield additional insight.  I’ve combined those findings in the following chart:

 [larger image]

As you record market share data, each new competitor adds to the total market share already analyzed.  That value is captured on the vertical axis of the chart above.  The horizontal axis shows how much the HHI value for any particular market will increase by gathering one more data point.  When adding the data for one more competitor has little or no impact on the resulting HHI calculation, you can stop gathering data.

There are two distinct curves present above – the lower one represents a competitive market (HHI = 223), and the upper one represents multiple concentrated markets (HHI values ranging from 2254 to 6753).

 [larger image]

By the time you’ve addressed more than 50% of the market share, additional analysis increases the calculated HHI value by less than 0.1% (per additional competitor).  In one market I analysed, the top 20 competitors combined had just under 50% market share.  Including the next 50 competitors in the analysis increased the HHI by 2% (from 219 to 223).  You can’t gain any insight from that difference in value.  A good rule of thumb is to only look at the top 10 competitors, or however many it takes to capture 50% market share.

 [larger image]

In a concentrated market, once 90% of the market share has been calculated, the incremental increase to the HHI value by adding additional competitors is also negligible.

Looking at Trends

One powerful way to apply HHI measures for a market is to look at the trends of the market – is it growing less competitive or more competitive?  Specifically, are dominant competitors gaining market share, or losing market share?  Having this insight can tell you who’s products are succeeding, so you can focus your analysis effort.  The following diagram shows how competitiveness has been trending for the last five years in the web browser and search engine markets.

 [larger image]

The lines represent the HHI values (downward sloping blue line is for web browsers, upward sloping red line is for search engines) that indicate the competitiveness (or concentration) of the two markets over the years 2005 – 2009.  The inset on the left shows market share data for web browsers from 2005-2009.  The inset on the right shows market share data for search engines from 2005-2009.

The HHI values for both markets indicate that they are both very concentrated – with a small number of companies controlling each market.  From reviewing the HHI values, you can see that the web browser market is gradually becoming more competitive and the search engine market is becoming less competitive.  Both markets are dominated by a handful of companies.

A Competitive Market – Internet Service Providers

The internet service provider (ISP) market, unlike the others we’ve looked at, is very competitive.  The HHI value for the ISP market is 223.  A pie chart of the major competitors shows that there is no clear dominance by any one provider.

 [larger image]

As a column chart (to be consistent with the other charts here), the same ISP Mar 2009 market share data looks like the following:

 [larger image]

There is not a set of clearly dominating ISPs – this is a competitive market – based on just looking at share data.

Danger

However, there’s a big danger in just looking at the numbers.  Internet service providers, while competitive in aggregate, generally have dominant market share for any one physical region of the country.  Rogers does not offer internet services in Texas, and Comcast does not offer them in my neighborhood.  So, from an end-customer’s perspective, this competitive data is almost meaningless.  It still serves as an example of a very competitive market, in contrast with the email client, web browser, and search engine markets we also reviewed.

Conclusion

Understanding the problems that plague the customers in your market is critical to being a successful product manager.  Understanding your competition (and their solutions to the problems) in your market is also very important.  The HHI value provides a metric for measuring competitiveness in particular markets.  Your approach to competing in a particular market will be different, depending on the nature of the competition in (and competitiveness of) your market.

Note that this is a primarily red ocean analysis – a blue ocean analysis is a focus on finding ways to redefine your market so that competition is irrelevant.  You can read about the differences in Blue Ocean Strategy, which is this month’s Smarter Product Managers book club book, created by Cindy Alvarez on the Booksprouts site (you may need to create a free account to view the page).  Analysis of the existing market is still required in order to define a new market – you just apply your insights in different ways.

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.

No cell for Dell.  According to Kaufman Bros. analyst Shaw Wu, carriers rejected prototypes from Dell because the “lack of differentiation.”  As product managers, we know the importance of keeping up with the Joneses, but we also know the importance of including differentiated value in our product offerings.

Old Rumors

The rumors that Dell would offer a cell phone (re) started when Ron Garriques, former EVP and president of Motorola’s mobile devices division joined Dell about two years ago.  There are many more articles and speculations from that time period (just search for them).

New Rumors

In January, Silicon Alley Insider reported a lack of denial from Dell CEO, Michael Dell in January.  A reader of the Insider, claiming to be “close to Dell” suggested a September 2009 product availabiliy, and calling it a “MePhone.”  They particularly called out 09/09/2009 as the date.  Tyner Blain (the company) was started on 05/05/2005, so maybe that’s a good idea :).

Barrons just reported Wu’s comments that carriers essentially rejected the Dell cell phone prototypes because they were no different than current and pending product offerings from competitors.

Dell recently filed a revamped retention plan for Garriques to stay through March 2010, according to the Austin Business Journal’s reporting a couple weeks ago of recent SEC filings.

Product Management

The entire Dell phone thing may be a farce (I don’t think it is), but it doesn’t matter.  The product management perspective on this situation (real or otherwise) is still interesting.

Should Dell enter the Cell Phone Market?

There are two sides to this question – the cell phone (and more particularly, the smart phone) market is hyper-competitive.  In Dell’s strong markets (corporate, channel), there’s the Blackberry devices from RIM.  In Dell’s stated focus markets (consumer, retail), there’s the iPhone and the Palm Pre (which is not a product yet, but has generated a lot of buzz).  Competition in either of these markets will be tough, as they are both pretty saturated, and both are under pressure with current economic conditions in the US.  Companies can easily cut back on subsidies for cell phones, and consumers can easily delay purchase of a replacement phone.  Customers in either market would need a compelling reason to purchase from Dell.

On the other hand, computer and smart phone technologies are rapidly converging.  Phones get more powerful, and people are shifting “traditional computing tasks” to their phones because of the convenience of having a phone where having a laptop is impractical.  Computers are getting smaller every day, and new usage patterns are developing.  You could argue that a computer manufacturer should be on top of this movement, and to be best positioned to have insights into what a “hyper convenient computer” should do, they should get into the smart phone market.

Kano Analysis

When you apply Kano analysis to the potential feature set for a phone, everything you might add to the phone falls into one of three buckets: must be, more is better, and surprise and delight.

Kano analysis recap

Kano provides three relevant classifications of requirements (the fourth category is redundant). All requirements can be placed in one of these categories.

1. Surprise and delight. Capabilities that differentiate a product from it’s competition (e.g. the nav-wheel on an iPod).
2. More is better. Dimensions along a continuum with a clear direction of increasing utility (e.g. battery life or song capacity).
3. Must be. Functional barriers to entry – without these capabilities, customers will not use the product (e.g. UL approval).

Prioritizing Software Requirements – Kano Take Two

What Wu points out is that while Dell may have identified all of the must be requirements, just doing the minimum to be considered as a product is not sufficient to be accepted by your customers.  With the competitive landscape of the cell phone industry, these capabilities are necessary, but not sufficient.  The cell phone market is not a pure B2C (business to consumer) market, because the carriers (the providers of cell phone connectivity services) play such an integral role in the ecosystem, they have to be considered as customers too.  This is because the consumers are willing to accept long-term, very expensive contracts with service providers.  Those contracts allow service providers to subsidize the price of the physical phones (to the tune of $100 to $300 per device), in exchange for a contract that is worth over $1000 to the service provider.  For a phone manufacturer to penetrate the market in a meaningful way, they have to get these subsidies (from the service providers) in order to be remotely competitive on price with other phone providers.

Wu’s assertion is not that Dell failed to satisfy the requirements of the service providers, but rather that the service providers determined that Dell’s offering to consumers was insufficiently differentiated from other phones.

Differentiation

In addition to incorporating the must be capabilities into their phone, Dell also needed to have enough more is better features – like battery life, reception, screen size, (lower) weight to be perceived differently by consumers.  Dell also could have taken a surprise and delight approach, and introduced new capabilities that essentially make the competition irrelevant, by carving out a new market space.  Dell could have also focused on design elements – the same feature set, but in a more desireable device.

For fun, we can imagine some capabilities that Dell might have introduced that would have made their cell phone distinctive, allowing them to reach agreements with service providers to offer subsidies that would make their phone competitive in the market.

• Double the battery life, double the dB gain (strength) of the signal, cut the weight in half – all “obvious” more is better features – so they are probably also currently impractical, or Dell would have done it.  Note that these would have had to be achieved with protected intellectual property, or all of the other phone makers would also be doing it (or doing it very soon after Dell did).
• Create a social networking ecosystem around the phone – a surprise and delight approach to making the phone not just a phone, but a social networking device or entertainment device.  There are many solutions that solve parts of this problem (facebook connect, instant messaging, twitter applications) by connecting the phone to a customer’s social network.  No one is really providing a “social networking platform that is also a phone” today.  While I don’t know what this magic combination of features would be, I do know that it would be possible.  With android, the open-source operating system from Google, Dell software engineers have the ability to develop this, and encourage the open-source software community to contribute.  Flock is an open source browser that did this by building on the core software of the Firefox brower.  This could be developed either for consumers or business users who can use the product for managing their networks and contacts.  Imagine out of the box integration with Salesforce.com, and what sales rep wouldn’t want this?
• Create an entertainment ecosystem in which the phone plays a key role – the iPhone and iTunes work together to create this, in a walled-garden of interoperability.  Dell could develop a multi-vendor (of media), open-source, device-agnostic media solution for “everyone else” and extend the android operating system to work in this environment as well.  An alternate proprietary system probably wouldn’t work, it would just be “more of the same.”  Many large media companies are trying to figure out the right models for digital distribution of content.  Tivo lets you “time shift” and watch a show whenever you want.  Imagine integration with your smart phone, that also let you “location shift” and watch it wherever you are, whenever you want.
• Change the way networking works for your phone – develop a mesh network with your phone (every phone connects to every other phone in range to share networking resources).  This will create problems with today’s battery-life, and todays service-provider business models.  But imagine if hulu.com allowed you to download tv shows and movies to your phone (with advertisements embedded in the video), and then you could share those shows with peer-to-peer technologies like bittorrent.  More people would watch more video (and therefore more attention would be dedicated to advertising), and people would want the phones that could do this.
• Figure out a way to improve on location-based advertising, figure out how to solve more customer problems with the phone (phone + operating system + applications).

Conclusion

We don’t have any of the details about specifically where the Dell phone (if it exists) fell short.  But assuming that it did, we can have fun speculating about things that Dell could do that would make their product distinctive.  More importantly, we can learn from how Dell has apparently stumbled and apply it to our own products.  Are we just doing more of the same?

Another key idea – Wu said “…versus current and coming products…”  It is not enough to just do more than “yesterday’s competition” – you have to be ahead of tomorrow’s competition too.  This dynamic is generally true, but magnified in the cell phone market, where the service providers know what tomorrow will bring.

We spend a lot of time (rightly) on the capabilities of our products – identifying valuable problems and compelling solutions.  This focus is ideal for addressing the needs of our users.  But what if people abandon our products before trying them?  First impressions matter – both for buyers and users.

SXSW BizSpark Accelerator

Microsoft sponsored the BizSpark Accelerator at SXSW this year, where several startups competed by giving a 2 minute presentation of their products / companies.  The panel of judges emceed by Guy Kawasaki and Brad King.  The contestents were the top 20 from 200 submissions.

First Impressions

I was lucky to attend part of the event, focusing on the eight finalists in the Innovative Web Technologies area.  I recorded the presentations, but the camera shakes so badly in my hand that watching them is like trying to listen to a lecture while riding a rollercoaster.

Two minutes is barely enough time to make a first impression.  Each presenter had 15 minutes of Q&A with the panel, where they could get into more details and provide feedback to the entrepreneurs.  First impressions, however, are made by the very first thing you say.  Here’s the first sentance from each of the presenting finalists:

• klout.net – Hi everyone, I’m Joe.  At klout, we measure influence across the social web.
• OtherInbox - Thanks everybody, my name is Josh Baer, and I’m here to tell you about OtherInbox, which helps you save your real inbox for real people.
• Piryx - The idea is that you want to wake up, create an account, run for public office, and change the world. [Note - I lost the first sentance when recording, but this is the first substantive sentance]
• Ribbit.com – My name is David Lee, I am the director of strategy and business development for Ribbit Corporation. Ribbit is a cloud service for enabling communications innovation, bringing together the internet, voice, and data.
• Ringlight - I’m here to talk to you about my company, Ringlight.  My name is Brandon Wiley, I’ve been working in peer-to-peer for a decade, from the first peer-to-peer application, freenet, to the most popular peer-to-peer application in the world, bittorrent.
• Thrive - My name is Avi Karnani from Thrive.  I’m going to show you a new feature we’re about to launch called behavioral budgeting.
• YouData - Let’s talk about internet advertising.  [something garbled as the speaker had trouble speaking clearly into the microphone]
• Zoomorama - Hello, my name is Franklin, and I’m president of Zoomorama.  Zoomorama comes from panorama, the wide open space, and indeed zooming is not just about details, it is mostly about space. [Note that in parallel with the speaker, the display was showing some compelling image zooming technologies]

Every one of these presenters made a first impression.  klout, OtherInbox, and Zoomorama (and maybe Piryx) tell you what their products do in the opening sentance.  Ringlight and YouData both set the tone by identifying an existing space.  Thrive lets us know that whatever it is, we haven’t heard of it before, and Ribbit shared a lot of jargon words.

Elevator Pitch

When I was in presales, I learned how to craft an elevator pitch.  What I had not heard of before this year’s conference was the one-floor/two-floor pitch. 

An elevator pitch is a presentation of what your product (or company) does, that is short enough to be delivered while conveniently riding on an elevator with the really important person you want to hear your pitch.  It is a powerful image, used to remind us that people will usually give us a brief opportunity to get their attention.  To get more time, we have to earn additional attention.

The one-floor elevator pitch is a variation of the elevator pitch, but imagine your audience gets off the elevator after one floor.  You really only have time to get out a sentance or two – just like the above quotes.  

Which of the eight presenters, after giving the quotes above, would get invited to follow their listener down the hall, and which would have to stay on the elevator?

I saw the full presentations, and one of the presenters is a client, so I won’t share an opinion.  Would love to hear yours.

As a product manager, what would you have wanted the presenter to say for the one-floor elevator pitch?

My friend Rich Mironov, chief marketing officer at Enthiosys, recently published The Art of Product Management, and was kind enough to send me a free copy.  The essays he shares in the book make great conversation starters for product managers.  Tyner Blain is giving away a free copy to someone who participates in the product management conversations.  Read on to see how you can win.

Conversation

Rich really has a great conversational style in his writing, it reads well and flows easily. Rich knows his audience well, and provides keen insights into different elements of product management.  Often, he uses analogies – like running a grocery store versus running a restaurant, to put SaaS versus licensing of software into perspective.  Even with essays so well aligned with the interests of product managers, it can be challenging to create a conversation through writing a book.  Rich can’t get real time feedback while writing his book, like he can from the readers of his blog.

Cindy Alvarez started the smarter product managers book club on booksprouts, and we’re on our second book – The Art of Product Management.  We meet tomorrow night (Wed, 11 Mar 2009) – details in the book-club area, sign up and join for free.  This will help get more conversation going around Rich’s book.  

Also, if you’re on Twitter [I'm @sehlhorst if you want to follow my tweets], you can search for “#pmbc” and find tweets that are related (usually) to the current book.  You can also search twitter for “#prodmgmt” to see tweets from/about product management.  If you aren’t on Twitter, you can still follow those links and watch the conversations, and find people to follow.

One of the most rewarding things about writing the Tyner Blain blog is the conversations it starts for me.

Contest

This contest is meant to serve two goals.  First, to give away a copy of Rich’s book, balancing out the free copy he so graciously sent to me.  Thanks again, Rich!  Second, to trigger even more conversations on Tyner Blain.  Since Rich’s book is written for product managers, the contest is structured to inspire conversations about product management.

The Rules of the Contest

There are three ways to “enter” the contest to win a free copy of The Art of Product Management.

1. Add a non-trivial comment to this article, about one or more of the essays in The Art of Product Management.  You can either start a conversation or join an existing one.  ”Non-trivial” is solely up to my judgement.  If you’re contributing to the conversation, then I’m happy.  ”Me too” won’t cut it.
2. Add a non-trivial comment to any of the 200 Tyner Blain articles in the “product management” category.  You can either join a conversation or start a new one related to the article.  Feel free, of course to be critical of any of those articles – just make sure you’re conversational, and I’m happy.  ”You stink, Scott” isn’t good enough.
3. Write a blog post on your own blog and either use a trackback or link it to this article or one of the product management articles on Tyner Blain.  The same conversational rules apply.

You’ll get 1 point for each comment or blog post you make as you participate in the conversations.  You can write multiple comments / posts, you’ll get credit for all of them.  Your comment needs to include the email address you want me to contact you at when you win, or I need to be able to find a way to contact you if your blog post is the winner.  You can select to be notified by email whenever a new comment is added to any article you’ve commented on – just check the box before submitting your comment.  I’ve found that to be a fantastic way to participate in conversations!

The contest starts immediately after the first comment I post to this article, and ends either when we get to 100 qualifying comments/posts, or one month from today (April 10th, 2009).  I will randomly select a winner from all of the entries, and contact you after the contest is over. [Note: Comments by Scott Sehlhorst are not counted in this contest.]

But I Already Own The Art of Product Management!

OK, if you already own a copy, you can accept the cash equivalent (the current Amazon price on April 10th, 2009), and choose to buy something else, or get another copy of the book and give it to someone (or run your own contest).  Your choice.

Thanks

Thanks to Rich for writing this really enjoyable book for product managers, and thanks to everyone who contributes to the product management conversations here and on the other great product management blogs that I read.

Our previous article looked at the economics of a Freemium business model.  One element that is key to making a strategy that involves “free” work financially is growing your user base.  One way to get that growth is through a word-of-mouth marketing campaign.  This article looks at different elements that characterize or affect the successfulness of a viral product – from a product management perspective.

Word of Mouth

We wrote about the dynamics of how to maximize your word of mouth a couple years ago.  Essentially, you create a product and a situation where people want to tell other people about your product.  Ideally, your customers (free or otherwise) will like your product so much that they want other people to use it – not just know about it.  Word of mouth is a double-edged sword however, so you have to be careful about the propagation of bad word of mouth too.

Word of Mouth Marketing

People in marketing, PR, and corporate communications talk a lot about viral marketing.  Viral marketing is when you create a message that is implicitly viral, causing exposure for your product.  This is different than viral product management, which is when you create a product that is self-promoting with similar dynamics to a viral marketing campaign.  A great example of a viral message is the Mentos / Diet Coke videos.

But this phenomenon was viral because of the message, not because of the product.  This article focuses on product management – the things we do to make a product self-propagate, not the explicit marketing we do to get awareness.  You can think of the product management as implicit marketing – a feature or capability may have a direct impact on your word-of-mouth.

Word of Mouth Product Management

As a product manager, when you need or want a viral vector by which you grow your customer base, you can either rely on word-of-mouth marketing (see above) or focus on making product management decisions that encourage the same communication dynamics (see below).  At a high level, you simply need to create a product that your customers want other people to start using, but they have to want it “enough.”

iPhone Market Data

Pragmatic Marketing likes to remind us that our opinions, while interesting, are irrelevant.  Greg Yardley of Pinch Media shared a really interesting analysis on ad-supported versus for-a-fee iPhone apps that came out a couple weeks ago.

This presentation is an analysis of the economics of publishing an iPhone application as a for-a-fee product, or as an advertiser-supported product.  [Hat tip to Andrew Chen.]  What is most relevant to viral product management is the graph on slide 26.

[click for larger version]

What the graph shows is that the top 10% of ad-supported applications break away from the other 90% in terms of usage.  The reason (in that presentation) for looking at the data was for measuring the CPM (cost per thousand impressions) based revenue for applications, in comparison with the charge-for-the-application model.  At the end of the day, the free version makes sense, but only for the top 5% of applications, according to Pinch Media.  For the rest of the field, a for-a-fee application will probably generate more revenue.

What is glaring in that data is that the applications in the top 10% (the discrete red line at the top of the graph) are not the same as the other applications.  Something is different that causes users to want to use those applications a lot more.  As a product manager, I believe that those applications have crossed the suck threshold.  In other words – they are a pleasure to use.  What Pinch Media’s data also does not show is how viral the applications are.  In other words – do the top 10% (in repeat usage per user) applications also have the fastest growth (in user count), and if so, is it by word of mouth.  

My premise is that the applications that are most pleasurable to use are the ones that can achieve viral growth.  These are the applications that you want to tell other people about.

Pleasurable Products

As a user-centered product manager, you are spending some of your time on customer delight features and capabilities.  These are the things that wow a customer, and cause them to want to tell others about your product – simply because it is cool and useful.  You’re also spending time on the more is better features and usability concerns that make a product a pleasure to use.  You keep making it better, because there is clear ROI to increasing your user base, and improving usability makes it more likely that people will tell other people about your software.  Eventually, your product will be good enough that people will start telling everyone, and your growth will start to climb.

One of the dangers of this incremental product growth strategies is that you catch a case of featuritis.  Very rarely will you hear people clamoring to remove features from your product.  You’re more likely to hear a steady stream of “one more thing” requests.  Too many features can make it hard for people to learn how to use your product.  There’s a threshold of user tolerance for features.  Too few or too many features, and your product will be unpleasent to use.  Above that limit, the product is a pleasure to use.  Kathy Sierra coined the term suck threshold, to mark this delineation.

The following diagrams are from an earlier article on featuritis, and build on some great ideas from Kathy Sierra.  These focus on the holistic “how good is your product, from a user perspective” question, and take a Kano-analysis approach to looking at ways to improve your product.

You can improve the curve for any particular product by improving the user’s experience with “more is better” features.  You can either improve usability or performance (or both) and change the shape of the curve above.

Given the above dynamics, and Malcolm Gladwell’s concept of a Tipping Point, where things discontinuously change, there will also be some threshold by which your product is so pleasurable to use, that people will feel compelled to share it.

Since 90% of the applications didn’t appear to tip in Pinch Media’s analysis, I’ll show the default tipping point as being out of reach – at least until you do something about it.

Two Modes of Viral Product Propagation

There are two primary human-nature mechanisms by which a product will propagate virally – altruishm and selfishness.

• Altruism – You should use this product because I love it and you will too.
• Selfishness – You should use this product because If you use it too, it will be better for me.

If your product falls below the suck threshold, I don’t believe you can sustain any form of viral growth.  Sharing a product recommendation builds on trust, so sharing something that people won’t like will erode that trust.  I believe this is a self-correcting behavior, and what little sharing may occur will be short lived.  A product that gets shared because of altruism needs to not only be better than good, it has to be so good that you’ll go out of your way to tell people about it – with no expected benefit for yourself.  [Note: other than the self-reinforcing positive feeling you get from being altruistic.]

Leveraging Altruism as Viral Mechanism

Altruism is an interesting viral dynamic.  If you make your product so good that people feel compelled to tell their friends about it (or blog or tweet about it), you’ve got a great product.  Product management decisions to achieve this are easy in that you only have to make the product fantastic for your users.  At the same time, your product management decisions are difficult, because you have to make your product good enough to cross the tipping point.  The iPhone, Synergy, Sherwin Williams paint (when the first local store opened in Austin, the owner was stunned by how much demand was out there), Tweetdeck (a Twitter client), and GMail are all examples of this.  Additional users / customers don’t make the experience any better for the current users, but people still rave about it to their friends and associates.

Leveraging Selfishness as Viral Mechanism

The are two ways to leverage people’s inherent selfishness when developing products.  The first (and harder) is to define capabilities or features for the product where the customer’s experience is better when more people use the product.  Twitter (and Facebook and other social media applications) take advantage of this.  If you’re using Twitter as a broadcast medium, then the more people who are out there to listen to you, the more value Twitter has to you.  So you encourage people to use it.  On the reverse side, if you’re looking to Twitter as a source of good information, the more people who are out there sharing information, the more valueable this channel is to you.

The second, and easier way to reward customers for encouraging other people to use your product is to explicitly reward them.  Affiliate programs, finder’s fees, account credits, or other compensation can be given to existing customers, in exchange for signing up new customers.  A software as a service variant of this would be a program that rewarded you with credits to your account for every customer you refer, for as long as both of your accounts are active.  People can get your product for free if they encourage enough other people to sign up.

Both of these selfishness-model variants, to be sustainable, need to be leveraged to promote a product that is actually good.

The altruism model won’t work if your product is not better than good, but actually exceeds a tipping point.

Conclusion

You can create viral messages or videos that spread awareness of your product tangentially, or you can create programs that encourage people to promote your product, or you can create products that promote themselves.  As product managers, if your business model relies on viral growth, you can either take ownership and create viral products, or cross your fingers and hope for viral promotions.

*Attribution [CC 2.5 attribution: bullhorn photo - seesix]

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.]

Jump forward in time to the day of your next big product launch (first release, new features, new market segment, etc).  And your site/application crashes due to the “unexpected” demand.  All you can do now is look for a bucket of water to put out the fire.  What could you have done to prevent this disaster?  Jump back to today and start doing it!

Backwards Planning

Depending on how you look at things, this is a backwards planning exercise, or a variation of the  remember the future innovation game, or risk management, or proactive product management.  You can avoid a disaster by imagining what might happen, then hypothetically figuring out why it (would have) happened.  That leads to planning how you could prevent it.  And now you’ve left the dream world of a Gedanken experiment and returned to the real world of product management.

Problem Triage

The way to approach this is straightforward.  Imagine some failure scenarios and the importance of preventing them:

1. Imagine a failure scenario.
2. “Predict” the likelihood of the failure.
3. “Estimate the impact of the failure.
4. Repeat for each scenario

You can prioritize your failure scenarios by multiplying the likelihood of each with the impact of each, and sorting them from largest to smallest.  Then determine which ones you’re willing to address, and which ones you’re willing to risk.  You may not be able to predict the likelihood of some failures (at least until you do a root cause analysis).  Take each of these and put them directly above the scenario with the next highest impact.  The rationalle is that these are so bad, that you really want to find out how likely they are to happen.  Once you predict likelihood (see below) you can reprioritize.

Root Cause Analysis

For the failure scenarios you choose to address, the next step is to do a root cause analysis that identifies why it might have happened.  The best tool for capturing this analysis is an Ishikawa diagram.  Consider that one problem you might face is your website crashing.

[click for larger version]

Essentially, you can crash your site by having too many users, too many concurrent users, or too many concurrent sign-ups.  Developing a cause-and-effect diagram (another name for an Ishikawa diagram) is usually an iterative and exploratory process.  You probably won’t create the simple version above first.  You may ask your implementation team “What can cause the website to crash?”  For each of their answers, you identify when that situation can happen.  Or you start top down.  Most likely, a mix of the two.  Your completed root cause analysis may look like the following:

[click for larger version]

At this point, your team can probably predict many (maybe all) of the root causes of a website crash.  The predictions may be conditional – “we can handle 10 concurrent users, but 20 probably kill us, and 100 definitely would.”  Developers are notoriously good at answering questions with conditional statements that reveal the nuances of their thinking.

Remember that you’re looking back from the future.  At product launch, what are you hoping for / reasonably expecting?  For this example, assume it is 10,000 total users, with 100 concurrent users (normally) and 500 concurrent signups.  You determine these numbers by working with your PR, marketing, or mar-com people (or wearing those hats, when it is all you).  Your plan is to do a big launch with a demo and a promo code for signup.  You know your audience will have internet connections, and will have twitter running at the time of your presentation.  You expect/dream of an immediate burst of signups, followed by tweets and word of mouth, and eventually blog articles causing additional growth over the next couple of weeks.

Use this data to feed back into the developer’s conditional responses.  If you’re like me, you will have found “absolute certainty of failure” from something.  And you may have even identified the thresholds for each element.  For example, database loading can handle 75 concurrent users, but with the current implementation, you only have enough database connections available to support 25 concurrent users.

Jumping back to the present, you now have some very discrete, and very important things to do before your launch.  If you need to, revisit the prioritized list of failure scenarios.  By looking at the next level of detail, have you found that the order of importance (to fix) has changed?  What about the “must fix” versus “willing to risk” line?  Has it moved?

Fold the “must fix” items into your backlog, and prioritize them relative to the other capabilities on your roadmap.  As a side note – make sure you’ve built in some testing to make sure you actually prevent the problems.  This might even be a great opportunity to implement “performance regression tests” – it is not enough to prevent bugs, you have to prevent slowdowns.

Rethinking the Problem

Without going into details on how the team will solve each problem, make sure that together you keep the Ishikawa diagrams in mind, and see how any proposed solutions might “reappear” on the diagram.  For example, rewriting your database connections to use asynchronous processes and a set of pooled connections may prevent a crash, but it may really hurt performance.  You may not have time to find an elegant solution.  So stop and rethink the problem.

At this point, you’ve said

1. Given a marketing plan / launch strategy, we would crash the website.
2. We can make changes between now and the launch that will double the number of concurrent users we can support (or whatever), but that is not enough to support the launch strategy.
3. Solution: Change the launch strategy.

Maybe you can’t support a wide-open promo-code based signup.  You should modify your launch so that it can only create as much demand as your product (including pending improvements) can support.  Maybe you limit it to the first 1,000 new users (probably more code to write to enforce the limit).  Maybe you launch with per-user invitations, where you can control the speed of propagation of invites (start with 100, when those have been sent, make another 100 available, etc).

Entire Team Problem

This is a problem that is solved collaboratively, by the entire team.  It is not just a “go write the code” problem.  What your product can support at a launch should drive how you choose to launch, just as how you choose to launch should drive what you want your product to support.  

You may have to delay a key capability in order to scale.  Does your marketing team know this?  Slightly less bad than crashing would be announcing a feature that is disabled.  Still need to announce the feature?  Pre-announce it: “Coming in a month…”

This stuff is important for every company and product, but it is especially critical for start-ups.  As a start-up, you have limited opportunities to grow, and a limited safety-net to catch you when you fail to capitalize on those opportunities.  So make sure everyone (not just the development team) is aligned to make the best use of each opportunity.

Conclusion

You have an opportunity to prevent problems.  All you have to do is imagine that they have happened in the future, figure out why they would have happened, then do what it takes (in software, or organizationally) to prevent them.

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.

User Stories are one of the key agile artifacts for helping implementation teams deliver the most important capabilities first.  They differ from use cases in some important ways, but share more commonalities than you might think.

User Stories Applied

Mike Cohn wrote User Stories Applied: For Agile Software Development.  It is the book for understanding how to write, estimate, and use user stories.  If you’re thinking about trying out “agile” for the first time – and you haven’t read his book, you need to.  He provides great detail and anecdotes about how to write, manage, and utilize user stories.

What are user stories?

A user story is a user-centric description of the goals that one or more people will achieve by using your product.  User stories are applicable whenever there is a person, interacting with an interface to a product, to achieve a goal.  They aren’t just for software – even though the tone of this article may imply it (since I live in a software mindset most of the time).

A user story is written in the format

• As a [person in a role] I want to [perform some activity] so that [some goal is achieved].

That’s it.  No more.  Perfectly atomic, very concise and unambiguous.  Where did this elegant idea come from?

User-centered design (UCD) is an approach to product design that can almost be considered a philosophy.  In college, I used to say that industrial designers designed things from the outside in, and engineers designed things from the inside out.  The ideal products are the ones that marry form (outside) and function (inside) in an elegant solution that blurs the lines of distinction.  The first designers of engineered products were the engineers, and the first designers of software were the programmers – they were the only ones who knew what could be accomplished.  Anyone who has used an application with a user interface designed by a database expert can remember what that was like.  Eventually, someone successfully adopted the mindset of designing a product based on what someone could use it to do instead of looking at what it could do and figuring out how to use it.  That under-emphasizes the importance of UCD, but you get the idea.

Out of UCD come different things that really drive how we create products today.  Kessler and Sweitzer focus on understanding these user goals in Outside-In Software Development.  Stakeholder goals drive (arguably, are) requirements.  But it is difficult to develop actionable implementation plans directly from goals.  You need something to bridge that gap.

A user story, in an agile process, bridges that gap.  In Wiegers’ world of structured requirements, that gap is spanned with use cases.

Conceptually, a user story crosses the same chasm as a use case.  A user story defines what people need to accomplish (e.g. faster call processing), in order to achieve the goals of the company (e.g. lower call-center costs), given a solution approach (write software versus outsource to lower-cost call center employees).

Now we find ourselves in a confusing situation – there are user stories, use case scenarios, and at least three different kinds of use cases – formal and informal use cases, and use case briefs.  How are they different, and how are they the same?

Usage Descriptors

Use cases, use case scenarios, and user stories all document descriptions of how a product will be used.  They vary, along a continuum, in terms of the amount of overhead required to create each.

• Formal use cases require the most effort.  They have a lot of pomp and circumstance going on, but they describe all the permutations of how some person does some activity (or its variations).
• Informal use cases are pretty much the same – just less formal.  The challenge is to provide the right level of detail, without the guide-rails of the formal use case to remind you.
• Use case briefs have almost no overhead, but have the same “how much is enough” challenges of informal use cases, only more so.  Think of it as a single-paragraph description of a formal use case.
• User stories have the least overhead, and provide the least context.

Use case scenarios are a slightly different breed.  Like a user story, a use case scenario describes one path through a multi-path use case.  But you can’t (or at least I’ve never seen anyone) create a use case scenario without first creating the formal use cases.  This artifact basically combines the weakness of a formal use case (high overhead) with that of a user story (limited context).  It can be very handy for developing test cases if your testing team is not well versed in writing test cases.  We’ll leave use case scenarios out of the rest of the discussion.

The cost of high overhead in documentation comes with a benefit – increased detail.

Because a user story captures a single path through a use case, while having less overhead, it also captures less detail.  This is ok, because an agile process stresses communication over comprehensive documentation.   You start to run into inefficiencies when the amount of conversation (especially when repeated) is burdensome.  The amount of conversation required is a function of the amount of domain expertise, or context, that the implementation team already has.

Should I write User Stories or Use Cases?

It depends on your audience.  The formal and informal use cases, in addition to having more overhead, also provide more context, and allow you to describe more complex usage patterns of your product.  Some uses are so complicated that you have to use a use case to describe them.  Others are so simple that anything other than a story is wasted effort.  The interpretation of complicated and simple, though, is not purely an assessment of what the users want to do – it varies with the level of domain expertise of your implementation team.

Some teams simply aren’t equipped to consume user stories or use case briefs.  You have to write your requirements for the readers, so you need to know when people are struggling to implement solutions based upon stories or briefs, and give them more structure and formality.  You have to adapt to the realities of your current situation, and the experience of your team.

You could replace the words “Reader Domain Expertise” with “Writer Trust of the Team” if you wanted, and the graph would look about the same.  This is another concept that is critical to a team working effectively – trust equates to delegation.

If you can trust your team to come up with a solution that matches the story, delegate that “next level of detail” to them.  If you can’t trust them, then don’t.  But you should.  One of the benefits of agile is that your team will quickly give you a solution, and then you can give them feedback.  If they don’t create a solution that meets your interpretation of your user’s needs, then give them feedback, and they will change it.  The agile process actually relies on this dynamic to allow less-verbose artifacts to still be effective.  Someone on the team will sketch out what the solution will look like, and get your feedback, before implementing.  The more this collaboration happens, the more effective a light-weight document will be.

Conclusion

Don’t just rely on platitudes about stories and use cases.  Think about the nature of the different artifacts.  Think about their strengths and weaknesses.  Consider how you interact with your team.  Should you trust your team?  Do you trust your team?  Determine what they need, and give it to them.

Pragmatic Marketing’s 2008 Product Management and Marketing Survey Results – Part 2

This article continues our analysis of Pragmatic Marketing’s survey data – this time looking at the data for signs of gender inequality.

Previous 2008 Survey Results

Our first look at the data starts with a focus on the distribution of salary data broadly across roles, and taking a deep look at product manager compensation data.

The view we finished that article with was the distribution of reported total compensation for product managers.

[click for larger version]

Salary Distribution by Product Manager Sex

When splitting the data from the above chart into compensation for women and men, we see the following:

[click for larger version]

The graph shows two things – more men responded than women, and the men that responded to the survey reported higher total compensation than the women.  We should not (yet) jump to the conclusion that men statistically tend to earn more than women in product management roles.  It may be true, but we have to acknowledge that other factors might influence the data.

Product Manager Compensation and Age

One trend that “feels true” is that older people earn more than younger people.  As long as people enter the workforce at roughly the same time, and as long as raises are larger than increases in starting salary, this will hold true.  The following chart shows the reported ages of the product managers that responded to the survey

[click for larger version]

This distribution shows that there is a wide range of ages among the population of product managers that reported total compensation data for 2008.  Perhaps there a higher percentage of the older respondents are male (and with higher salaries that correlate to their ages), explaining the disparity from the first graph.

The next diagram shows product manager compensation versus age.  The diagram also shows the sex of each respondent – red “O” symbols for women, and blue “X” symbols for men.  We’ve also applied linear regressions to the data – showing the overall trends in compensation versus age.  The blue trend lines are for male respondents, the red trend lines are for female respondents.

[click for larger version]

The trend lines that are drawn show the linear regression as well as the +/- 95% lines.  You can see validation that total compensation does tend to climb with the age of the product managers.  The trend lines show that compensation for female product managers is lower than that of male product managers, as a function of the product manager’s age.

Since the trends are so visibly different, we can conclude that even if more older males responded to the survey, it does not really matter – the trend lines show a disparity across the reported age range.

Product Manager Compensation and Experience

While a trend of “the older you are, the more you make” feels accurate (and the data also suggests it), a trend of “the more experience you have, the more you make” also seems logical. When all other things are equal, a more experienced product manager is likely to be more effective than a less experienced product manager.  What does the data show?

An older product manager is also likely to have more experience.  The following diagram shows age versus experience as reported by product managers in Pragmatic Marketing’s 2008 survey.

[click for larger version]

The blue X symbols represent male responses, and the red O symbols depict female responses.  There appear to be more responses from experienced product managers than inexperienced product managers – both for men and women.  The following diagram shows the frequency of responses by reported experience.

[click for larger version]

There are definitely more responses from more experienced product managers.  And there are disproportionately more male responses among the more experienced product managers.  If compensation correlates strongly to experience, that could explain the distribution variance within the overall population.

Product Manager Compensation Versus Experience

The previous two graphs give us insight into the ages and experience levels of both male and female responses.  The following diagram shows the reported total product manager compensation by years of experience.

[click for larger version]

There is a visible trend that shows average compensation increasing with years of experience.  The grey “+” symbols represent each response (total compensation) at each experience level.  There are also green, red, and blue lines showing connecting the average total compensation at each experience level (for everyone, women, and men, respectively).

The disparity seems to be the most pronounced in the 11-15 years of experience range.  Zooming in on that data, we see the following:

[click for larger version]

There is a clear difference in the compensation levels for male and female product managers having 11-15 years of experience.  At other experience levels, the disparity is reduced or reversed.  There is also a significant disparity for respondents that reported zero years of experience, albiet with far fewer respondents.

Conclusion

I don’t believe that we can extrapolate from this data to reach crisp conclusions, but we can definitely acknowledge a disparity in the compensation levels reported by respondents to the 2008 survey.  Generalization is dangerous, when looking at sampled data – especially when the respondents self-select for participation.  Sometimes, that’s the best information we have, however – and it seems reasonable to form suspicions from the data.  I suspect that the data does indicate inequality in the compensation of men and women in the product management role.  The data does also indicate that product manager compensation increases correlate both with product manager age and experience.

Netlife Research brings us the 2009 Bad Usability calendar.  Get it while it’s hot.

Download it from the 2009 bad usability calendar page on their website.  Or check out our article from last year for the 2007-2008 bad usability calendars.  They really do have some great points to make.  Two in particular got my attention this year – any guesses which months?

Last year, over 100K copies were downloaded.  Act now and be on the bleeding edge of the first 2% to download for 2009.