Why do products fail?  Trying to organize all of the reasons that your product might fail is a Herculean effort.  Understanding how your product did, will, or might fail will help you focus on what you need to do next.

An Exploration of Product Management

A personal goal for me is to become better at product management, so that I can help create better products.

As a product manager, the most important thing you should be doing is understanding the problems that your customers face.  If you treat “improving at product management” as the product, you should start with an exploration of the problem space.  I’m framing that problem space as products that fail.  I think it is also fair to also think about products that under-perform.  They “succeed” given the goals by which they are being measured, but they never realize their full potential.  I’ll keep the “not as good as it could be” notion in the back of my head, and talk to “failed” as the larger issue.

There are conversations, blogs, books, processes, and frameworks for “how to be a (good) product manager.”  I suspect looking at this from the outside-in (problem first, solution second) may yield some interesting insights.  Thanks to Leisa Reichelt for her article on why most UX is bad, which inspired me to have the conversation here, approaching the problem as a root cause analysis.

As an agile product manager, I’m going to approach this iteratively.  I hope that you will provide insights and corrections, helping to adapt this as we go.  Your contributions will make this better, faster.

Root Cause Analysis of Failed Products

Ishikawa diagrams were originally created to allow engineers to figure out why something broke – a visual tool for organizing root cause analyses.  I’ve been using this powerful decomposition tool for several years to solve problems and organize my thoughts.  It may provide the perfect framework for gaining understanding about why products fail.

Let’s dive right in.  Here’s my first crack at the very top level of an Ishikawa for product failure.

[larger version]

Looks pretty sparse (for now).  I will fill it in, as I drill down into each area.

If you’re like me, you’ve got some “reasons for failure” in your head right now – maybe from past experience, maybe from watching products in the market today.  Do any of those reasons not map into the categories above? Tell us about it in the comments (or tell me privately, if you must) – that’s the first vector for informing an improved version of this diagram.

Here are some prose descriptions of what I’m thinking about (for now) for each of those branches on the diagram – I expect them to fill out with smaller branches attached to each of the main branches.

Product Fails in the Market

• Business Case is Flawed – This is where we would capture things like a product strategy that is not profitable, for example, your model was dependent on exponential growth – so even though you had consistently growing market share, it wasn’t enough for the product to be considered “a success” by you.
• Picked the Wrong Market – Maybe this market is about to go away, like buggy whips or audio cassettes.  Maybe the competitors in this market are just too good.  Maybe entering this market is too divergent from your corporate strategy and dilutes focus and investment in your company’s other products.  Another example would be if your team does not have the skills and resources needed to win in a particular market.
• Takes Too Long to Enter Market – Whatever it is you’re doing to enter the market, it took you too long.  Competitors have “out-gunned” you, your customer’s needs have changed, etc.  This is to capture causes where even if everything else was good, you simply didn’t move quickly enough.  At first blush, I expect organizational problems (lack of alignment, bureaucracy, insufficient resources) will all land here.
• Doesn’t Solve the Right Problems – This is where most product managers focus most of their time – making sure we’re actually solving the right problems (the ones customers are willing to pay to solve).  Problems of design – where we intended to solve the right problem, but the proposed solution doesn’t cut it – would not be in this branch – they would be in the “not good enough” branch.
• Positioning & Sales Approach is Wrong – For the first iteration, this is my catch-all for marketing and sales.  All of the problems that are “your potential customers don’t think of your product as a solution to their problems (even though it is).”  Also the problems of “your potential customers decided not to purchase (when they should have)” and “your potential customers have never heard of your product.”  This is definitely an area where you can contribute more than I can to the framework.  How would you (product marketing managers, I’m looking at you) frame this?
• Product is Not Good Enough – Execution is key here.  Not solving problems completely (although that might move to the “right problems” branch) is an example.  Bad design is an example – both bad user-experience and bad architecture.  Poor execution also lands here – broken windows, sloppy implementations, poor quality.  For this branch to work, “product” is not just the product that your development team builds, but also your customer relationships, distribution, services, etc.

Open Questions in This Model

There are definitely some design decisions I made in the approach above that are worth questioning.  Here are some that come to mind for me – add your own in the comments.

• Designs that fail to solve the target problems – I put this in the the “not good enough” bucket, because I felt like there was value in grouping the “how” separate from the “why.”  Many times, an inadequate design is a design that works great for inadequate requirements – which means the problem is in the “why” column.  How would you organize “bad requirements execution” and “bad design execution” in this model?
• Pricing and Cost – together, they reflect profitability.  ”Not profitable” implies a business case problem.  Incorrect pricing implies a positioning problem or is a red herring that is masking a sales problem.  High cost is reflective of bad design decisions and/or execution problems (both of which are in the “not good enough”) bucket.  Perhaps if you can’t create the product at the cost you need to, for your business model to work, when selling at a given price in order to compete, you have picked the wrong market.  Where would you put pricing and cost issues?
• Team Capabilities and Support. Not having (enough of) the right skills on a team limits what solutions you can create.  Not having enough support to gain needed skills constrains the solution space as well.  When your team does not have what it takes, or have what they need, to create solutions that will succeed in a given market, where would you put this?  For now, it is in the “picked the wrong market” bucket, because trying to compete in that market is infeasible.  There’s probably a better way to frame this – how would you do it?

A Litmus Test

One experiment to validate this model is to look at the main causes of project failure and see if they map well into this space.  In the Chaos Report findings from the Standish Group, the following are the top ten responses from the companies they surveyed, along with my thoughts about how they map into this framework.

1. Lack of User Input – In my experience, this manifests both as not solving the right problems and as delivering a product that is not good enough.  The mechanisms are different flavors of “not listening.”
2. Incomplete Requirements & Specifications – Ends up causing delays, and possibly not solving the right problems, or having designs that are not good enough (because the requirements that drove the designs were not good enough).
3. Changing Requirements & Specifications – I put this squarely in the “your mindset is broken” bucket.  Requirements change, even if your requirements document does not.  Depending on how this plays out (for your team, for your process), you either slog on and deliver solutions to the wrong problems, or you take too long to deliver.
4. Lack of Executive Support – This can be a takes too long problem.  Or it could be that lack of support causes a product to be abandoned (even if it were succeeding), or constrains options for your team to the point that you aren’t able to succeed within the parameters.  This one definitely doesn’t fit the model.  Should we update the model, or treat this one as “out of scope?”
5. Technology Incompetence – insufficient skill results in not good enough and usually delivery takes too long.  If really bad, it results in “impossible (for this team) to deliver.”  For the really bad cases, does it land in picked the wrong market, because that market is infeasible?
6. Lack of Resources – Just a subset of lack of executive support.
7. Unrealistic Expectations – in the worst cases, it is a problem with the business model.
8. Unclear Objectives – lands in not solving the right problem.
9. Unrealistic Time Frames – same as unrealistic expectations.
10. New Technology – yes, change is hard.

Not surprisingly, the list from the Chaos report uses a project-centric language.  Other than the (very valid) “failure profile” that lack of executive support causes projects to fail, the model seems to hold up reasonably well.

Your turn – what would you add or change?

You start with a point of view about what makes a minimum viable product.  When your product launches, it is your customer’s point of view that matters.  You must understand which problems your customers care about solving, and what solutions are available to your customers today.  You need to understand your competition to make informed decisions about your product.  This is the latest in a series on comparing products – jump back to the beginning of the series to catch up, we’ll wait.

Overall Product Comparison Process

This is a relatively long series.  Each article will start with a recap of the overall process.

Getting useful information from comparing products requires you to:

1. Introduction & Overview (so that the step-numbers align with the article numbers)
2. Identify your customers.
3. Articulate the problems they care about solving.
4. Determine how important solving each problem is, relative to the other problems, for your customers.
5. Characterize how important it is for you to solve the problems of each group of customers.
6. Discover which (competitive) products your customers consider to be your competition. (This Article)
7. Assess how effectively each competitive product solves each important problem.
8. Assess how effectively each competitive product solves each important problem, for each important group of customers.

With this information, you can create a point of view about how your product compares to the others.

No Competition

If you think your product has no competition, you’re wrong.

The photo above shows an El Camino, a combination of a car and a truck.  The front of the vehicle, the cabin interior, and the overall height / profile of the vehicle is that of a car; but the vehicle has a tailgate and a truck bed for hauling stuff.  A pretty novel idea at the time.  There were no other car-truck combination vehicles, but that doesn’t mean the El Camino had no competition.

You should not define competitive products as the products that exactly match the features of your product.  You should not define competitive products as those that solve (exactly) the same set of problems that your product solves.  Every interesting problem already has a solution – and therefore, you have competition.  It may be that there are not any particularly good solutions in the market.  It may be that the competitive products are not well known, and would not be likely to compete effectively.

It may be that the solution your customers choose is “deal with it.”  The “deal with it” solution, at first glance, from a B2C (business – to – consumer) perspective feels like “there is no competition,” but I believe that embracing that point of view puts you at risk of being myopic about your market.  In the B2B (business – to – business) area, “deal with it” is one version of the “in house solution” competitor – a very real scenario.  Stacking ridiculous amounts of stuff on top of your car is analogous to managing your accounts receivable in a spreadsheet.  You can do it, but it is a solution that is fraught with other risks.

Your customer generally has four options from which to choose when deciding if they should buy your product.

1. Buy your product.  Hooray.
2. Buy someone else’s product.
3. Build their own solution.  Your customer believes that rolling their own is a better alternative to purchasing a solution from someone else.
4. Deal with the problem.  The cost of the solution is believed to be higher than the cost of the problem.

How do you identify which products are compelling competitors?

Problem Abstraction

One thing you learn as a product manager, when eliciting requirements, is to keep asking “why?” (and more and more on asking “why?” – check out the comments on these articles).  The goal in elicitation is to find the actual underlying problem, and not just the obvious manifestation of the problem.  One technique you can use is to create an Ishikawa Diagram that helps you define the problem(s) your product is attempting to solve.

Your goal is to find the right level of abstraction at which to determine who your competition is.  If we consider Tim, the hi-tech prosumer who consumes niche content, we would see that the decomposition of his high level goals looks like the following:

[larger image]

There are several benefits to using this approach of describing the decomposition of Tim’s goals:

1. You get traceability of your requirements, allowing you to see why each goal matters, from Tim’s perspective.
2. The graphical layout forces you to be concise in how you describe Tim’s goals.
3. You have a framework for validating that you have defined the complete set of requirements needed to satisfy Tim.
4. Looking at “everything” in one view helps you assure that your requirements are consistent.
5. You know “when to stop” in decomposition when your requirements are atomic.
6. You have a framework for assuring that you focus on those goals that Tim is passionate about.
7. You have tractable goals that you can use to think outside of the box when identifying competitors.
8. You have a clear and visceral tool for communicating with your team, to inspire innovative designs and clever solutions.

Finding Competitors

Some of the competitive solutions will be very straightforward, and obvious based on your understanding of your product domain.  Others you will discover through research.

When we look at the Kindle Fire as a product, we know from Amazon’s positioning that Tim will be able to read books & magazines (in color), consume multimedia content, browse the internet, stream movies, and borrow books.  He’ll have access to “millions of books,” be able to “read anywhere,” and connect with people over email from the device.  The Barnes & Noble Nook Tablet is positioned directly as a competitor to the Kindle Fire (and can even be purchased through Amazon).

It is occasionally annoying to read reviews of the Kindle Fire that basically say “not an iPad killer,” where the reviewer compares the features of the Kindle Fire, a single purpose device with multiple capabilities, with the iPad, a multi-purpose device that can be used for (many) single purposes.  The iPad is a viable competitor for the Kindle Fire, but a comparison in the other direction does not make sense.  The products are asymmetric substitutes – they are only substitutes for each other in a particular context.  If you are Tim, trying to enjoy niche content, then the iPad is a viable competitive product.  If you are a 15 year old boy who wants to play a first person shooter when you’re being shuttled to soccer practice, the Kindle Fire is a non-starter.

Finding a needle in a haystack is easier than identifying competitive products.  You know there is only one needle – once you find it, you stop looking.

Identifying competitive products is more akin to finding out how many needles are in the haystack

You can do research on the internet – start with the positioning from already identified competitors, look for editorials, rumor articles, reviews, research papers, customer reviews, discussion forums.  Search social media streams – find conversations (and broadcasts) about the product and the domain.  This gives you either minimal or overwhelming information, depending on how many competitors are already positioning themselves as products in this market segment.

Interview people who share goals with your personas – they don’t have to match your personas (but they can) – you are trying to discover solutions that you don’t yet know about.  Find out how they address those goals.  Maybe they use a web browser on their desktop computer, cobbling together a cabal of single-purpose solutions.  If they already own a competitive product, find out what they did before they bought that product.  As an example, someone like our Tim persona, before buying a purpose-built product, did the following:

• Used The Sword and Laser podcast to discover new content and get recommendations.
• Used Facebook to get and share suggestions with his friends, and have conversations about his favorite works.
• Used wikipedia and artist individual websites to find other works by his favorite artists.
• Subscribed by email to artists that published serials, blogs, other recurring content.
• Purchased tangible copies of works from Amazon.com.
• Borrowed tangible copies of works from IRL (in-real-life) friends.
• Purchased ebooks in pdf, epub or other formats that could be read on his computer and phone.
• Used Dropbox (or drag-and-drop by USB) to synchronize content across devices.

The problems that people are solving did not come into existence when the solutions were invented. The problems predate the solutions. [Note:if you have a Forrester subscription, check out Mary Gerush's Exploit the Requirements Lifecycle for a more detailed discussion].

The roll your own solution is a viable “competitor” for a B2C product.  In the B2B world, this is usually called best of breed. [Note: it is usually called this by one of the vendors of one of the pieces of the cobbled-together solution].  Using these amalgam-of-products solution strategies can make sense – and for some customers it will be the best solution.

We know that Christina and Time (two of our personas, defined earlier in the series) are different personas – they value different goals differently.  They will also use different approaches to create their own mix and match solutions to their problems.  Previously, I said that you didn’t have to interview people who represented your personas in order to identify competitors.  You do, however, need to figure out which product bundles represent the roll your own solution for each persona.  That is best done by interviewing representative customer prospects.

Our Example Competitors List

In this series, we are showing the mechanics of performing a product comparison, not sharing an actual analysis of the Kindle Fire.  As such, this is (again) where I get to manufacture illustrative data.  Here’s the list of competitive products that could have resulted from the research and analysis described above:

1. The Kindle Fire
2. The Nook Tablet
3. The Kindle Touch
4. The iPad 2
5. A laptop running windows, with a pdf reader, the free kindle app, and an HTML 5-compliant web browser.

The list above is not exhaustive.  Like most analysis activities, you can go on forever, but with diminishing returns.  Where you draw the line is a matter of risk mitigation.  Add as many competitors as you feel you need to accurately assess how well your product (or a future version of your product) will compete in the market.  There is a risk associated with both too much analysis and too little analysis.

Too much analysis slows you down and is expensive.  You will get a comprehensive view, and minimize the risk of missing something, but you run the risk of taking too long.  You also run the risk of never stopping – you can never find all of the needles in the haystack – and therefore you run the risk of never shipping or shipping too late.

Too little analysis saves money and time, but you run the risk of delivering the wrong product.  If you happen to identify all of the competitors that have (or will have) success in the market, you’ll be sufficiently informed (because your view will be a super-set of your customers’ views).  If you overlook a product that is driving the market, you run the risk of watching the world go by through rose colored glasses – you’ll watch people buy that other product, and not understand why they aren’t buying yours.

Here’s where agile provides a perspective that lets you escape the catch-22.  If you do “too much” you can never recover.  The money you spent is a sunk cost.  The time you lost is gone.

If you do too little, you can always do more later, when you realize you need to, as long as your team is capable of embracing change.

Summary

To create a competitive product, you need to know how your product stacks up against the competition – and that means you need to know who the competition is.  A product marketing manager may take this information to emphasize strengths and “turn weaknesses into strengths.”  A product manager can use the insights from this analysis to paint an informed picture of what the product needs to be (and why).

Recapping the overall flow of this series of articles on product comparison

Getting useful information from comparing products requires you to:

1. Introduction and Overview (so that the step-numbers align with the article numbers)
2. Identify your customers.
3. Articulate the problems your customers care about solving.
4. Determine how important solving each problem is, relative to the other problems, for your customers.
5. Characterize how important it is for you to solve the problems of each group of customers.
6. Discover which (competitive) products your customers consider to be your competition. (This article)
7. Assess how effectively each competitive product solves each important problem.
8. Assess how effectively each competitive product solves each important problem, for each important group of customers.

With this information, you can create a point of view about how your product compares to other products.

Attributions

Thanks Matthiew Yglesias for the El Camino photo.

A lot of teams that I’ve worked on and with get hung up when thinking about defining requirements for “migration projects” and “system upgrades.”  There’s some intangible barrier to being market focused when it comes to improving existing internal systems.  Every new product represents a solution to an existing problem.  Why do so many projects move forward with teams that are blind to the actual requirements?

New Products

Even “revolutionary” products like the iPod are just addressing existing market problems.  Part of what makes this statement true is looking at things from a market perspective – thinking about the valuable problems that people are willing to pay to solve.  Even if the iPod were the first mp3 player (it wasn’t), it would still only be an improvement.  The first mp3 player was not new, it provided an improved way to listen to your music on the go.  You could put your whole music library in your pocket.  Much better than a stack of cassettes melting in the glove box of your car, or a tape getting caught on your keys and unraveled when you pull it out of your backpack.

What’s important, and difficult (especially for people with technology backgrounds), is to think about it in terms of what people are trying to accomplish – not how they are trying to accomplish it.  In a business process view, it is the difference between process (why) and procedure (how).

There’s a continuum of migration projects, ranging from completely new to identical processes.  Neither extreme technically exists – think of it as a range from infinite change in the existing process to 1 / (infinite change) in the existing process.

Near the “completely new process” /infinite change end of the spectrum are processes that are completely new to you.  Remember, you’re solving a problem, perhaps in a very innovative way, that people are already solving some other way.  You’re just providing a better solution approach.

Near the identical process end of the spectrum are projects are “pin-compatible” platform migrations and near-sighted legacy system migrations.  Moving from an old gas-guzzling car to a new, more efficient model is a good example.  I mention “near sighted” because that old system was designed to meet an old set of market needs, so the new system will, by definition, not meet current market needs – it will only meet the old market needs.  Pragmatically, when considering organizational change, it may make sense to do your system upgrade in two stages: migrate the systems (“nearly identical process”) and deal with all the gotchas of migration first, then start re-engineering the processes and optimizing the procedures to address new market needs (major and minor process changes, respectively) second.

Set aside the possible, possibly rational rationale* to migrate the implementation first, and the functionality second.  Consider that a deployment and logistics detail and get back to the problem at hand.  Most of the times I’ve been involved in system migrations, they have been initiated as cost-savings platform projects.  Over the last few years, more often the migration project gets prioritized as a means to an end – “doing new thing X is prohibitively expensive on the old system.”  That opens the door to talking about goals.

* Couldn’t pass that one up.

Capturing Goals

On a recent project to migrate part of a company’s operations from one platform to another (system consolidation, after an acquisition), I created the following Ishikawa diagram to represent the goals for the migration project.

Even a “don’t change anything” project has real underlying goals.  Once you discover them, you open the door to having conversations about making things better.  Might be a “do it later” situation, but often, there is an opportunity to grab some of the low-hanging fruit during the system implementation.

The most important reason to capture the goals when “everyone already knows the goals” – aside from the fact that that is never true – is to make sure decisions are being made eyes-open.

Requirements live outside of the timeline of a particular project.  Once you’ve identified those requirements (aka market needs / company strategy), the next question is to determine which of those goals this project is intended to support or advance.  That question drives a lot of clarity into strategic thinking, and those answers drive a lot of clarity into project execution.

When you don’t share the context of the goals of the project, you are effectively blindfolding your team.  You prevent them from discovering opportunities to make things better.  You prevent them from making the right choice, when decisions are otherwise (without the context of goals) arbitrary.

For example, we talk about satisficing as a means to know when to ship – when it is “good enough.”  Without context, the opinion of “good enough” comes from someone on the team, without guidance.  In an agile environment, with self-directed teams, you’re making a trust-based decision to explicitly empower the team to make those decisions.  Don’t you want to give them some information, to help them make that decision?

Conclusion

This article really only explores part of the process of making real, large, projects happen in large environments.  That is a topic I’ll be talking about in a couple months.  You won’t get a sense of sated accomplishment from reading just this article – too much of the end-to-end, start-to-finish of real projects is unaddressed.

You will, however, know how to start the project.  Define the goals.  Someone will tell you the goal is to “Copy what the old system did.  We don’t have time to re-engineer.  Why are you bothering me?  Let me know if I need to find someone who can get the job done.”

Now you know how to respond.

**Attributions

Thanks foxtongue for the blindfolded typists photo

Ask someone what they want, and they’ll tell you they want a faster horse.  Provoke them, and they’ll tell you they have a ‘get there faster’ problem, an ‘equine waste disposal’ problem, and issues with total cost of ownership.

Thought Provoking

If your requirements elicitation session looks like the photo above, you’re doing it wrong.  However, just asking people what they want and confirming that you heard what they said is also not enough.  Active listening is important, but to capture great requirements, you also have to provoke thought about why someone is expressing a “requirement.”

Adrian Reed wrote a great article this week (hat tip to Kevin Brennan) on asking provoking questions that leverage lateral thinking techniques to get better insight into the true requirements.  Adrian presents eight questions, such as “Imagine if we fast-forward to 2 years after the implementation of this project, what will the organisation look like?”  Some of his questions remind me a lot of the ideas behind Enthiosys’ Innovation Games (and Luke Hohmann’s Innovation Games book).  The remember the future, and product box games immediately come to mind.

Unprovoked Thoughts

Most good subject matter experts I’ve met, when asked about the important problems to be solved, try and be really helpful and incorporate elements of solutions in their descriptions of problems.  They will say things like “the system must integrate with [other system] to do X.”  They may even ultimately be right, that this particular system integration is a constraint, and that “X” is the only acceptable (by policy) way to achieve “Y.”  But usually, neither constraint is a requirement – it is a solution approach.

Subject matter experts who are not as good at having and sharing insights about their domain often confuse problem manifestations with their underlying problems.  By analogy, it is requesting treatment for a runny nose, when the problem the you have is the flu.  You can dry up your nose and still feel horrible.

Provoking Questions Reveal Real Problems

Adrian’s questions are designed to help you understand that you’re treating the flu, and not a runny nose.  Requirements gathering is a lot like diagnosis of a medical malady.  You have to discover the real problems.  The problems that people are willing to pay to solve.  You have to uncover the latent problems that are “hidden” behind problem manifestations.

In a (rare for me) American football analogy – the problem manifestation is that your quarterback is completing 1 of 20 forward passes.  Replacing the quarterback and receivers will not solve the problem.  The problem is that your offensive line is not able to give the quarterback sufficient time to throw higher-probability-of-success passes.

Asking questions that force people to describe their objectives differently is a good way to bypass solution-design answers.  It also creates chinks in the armor of problem manifestations.  Completing more passes is not the future you’re looking for, winning more games is the goal.  When you’re treating your flu, your goal is not to be sick – but with a dry nose.  Your goal is to be well.  When you ask someone to remember the future, they will will describe being not sick, not being dry-nosed.  The product box will be a description of a winning team.

Check out Adrian’s list of questions, and ask yourself, how do you get to the root causes?  Ishikawa diagrams (also known as cause and effect or fishbone diagrams) provide a great visualization tool if you’re a spatial thinker or a whiteboard-talker.  In the example below, you can quickly see that spending too much on fuel is part of the real problem – that the cost of operation is too high.  You can likewise see that under-inflated tires are a source of poor fuel economy.  Check out the Ishikawa article for an explanation, or this article on providing context (with Ishikawa diagrams), and this article on buyer and user personas for more examples of problem decomposition.

If you’ve got any examples of problem-statement-turned-problem, chime in below…

Each requirement you write represents a single market need, that you either satisfy or fail to satisfy.  A well written requirement is independently deliverable and represents an incremental increase in the value of your software.  That is the definition of an atomic requirement.  Read on to see why atomic requirements are important.

Atomic Requirements – Revisiting

As part of the ongoing series, Writing Good Requirements – The Big Ten Rules, I wrote about the importance of atomic requirements first in 2006.  That article touched on only one aspect of atomic requirements – being able to ask “is it done?”

Writing atomic requirements is important from two perspectives – delivering value to your customers, and operating efficiently.  You get benefits both operationally, and in how you are delivering value when you write atomic requirements.

Atomic Requirements Accelerate Value Delivery

In a recent article, I proposed methods for splitting user stories when they are too large to be delivered within a single Scrum sprint.  That article looked at ways to break up complete user stories (an agile requirement artifact, similar to a use case) that were already atomic, making them even smaller.  Think of that article as Atomic Requirements 301 – sort of an advanced class on splitting the atom.  There are opportunities to subdivide molecular requirements – those made up of multiple atomic goals – the topic of this article, which would be Atomic Requirements 101.

If you’re using an agile development process like Scrum, consider a user story like the following:

• As an online shopper, I need to find and compare similar products, a few times a year, so that I can make an informed purchasing decision.

The key element, from an atomicity perspective, is find and compare.  These are actually discrete user goals, although it may not be immediately obvious.  Rewriting as follows, will highlight this:

• As an online shopper, I need to find products and compare similar products, a few times a year, so that I can make an informed purchase.

Rewritten like this, find products and compare similar products are clearly different activities supporting different user goals.  They should be split into separate, atomic user stories.

1. As an online shopper, I need to find products, a few times a year, so that I can purchase desired products.
2. As an online shopper, I need to compare similar products when shopping online, so that I can make an informed purchase.

These two user stories can be delivered separately.  If this example were for B2B (business-to-business) eCommerce, the example would be different – because the online shopper is (often) not the right persona.  A typical situation in B2B is that one person will do the research to determine what to buy, and another person will make the decision of from whom to buy it.

This rule applies for non-agile requirements development as well – consider the following “BRD-style” requirement example:

• The system must record all purchases and submit them to the fulfillment system for processing.

Recording purchases and submitting them for processing are two different activities.  While they likely support the same goal, they may also support different goals and could be implemented separately.  Recording purchases is important not only for fulfillment, but potentially also for analytics.  Pushing data to a fulfillment system can be done in either a manual or automated fashion – providing a distinct cost-reduction opportunity.  To write these as atomic requirements, they must be separated.

1. The system must record all purchases.
2. The system must submit all recorded purchases to the fulfillment system for processing.

This example shows only the bare bones – there is more involved in writing either requirement, particularly around defining the non-functional requirements and business rules (see also: why you benefit when you separate rules from requirements, and the difference between business rules and business requirements) that affect and constrain each requirement.  This is easier to see when the requirements are atomic. These two atomic requirements may be rewritten as follows:

1. The system must record all purchases on the same day that they are created, recording information per [BR117: Purchase Data Rules].
2. The system must submit all recorded purchases to the fulfillment system for processing per [BR231: Fulfillment System Data Interchange Specification].

These additional constraints are not non-atomic additional requirements, they are constraints that specify how the system must perform the atomic actions.

The previous examples allude to another key benefit of atomicity – clean traceability.  Each requirement (or user story) exists to support one or more goals.  Requirements traceability can get complex, when many goals are dependent upon multiple requirements to be realized and many requirements enable multiple goals.  This approach to representing goal-decomposition (or user story decomposition) is critical to assuring that you are writing valuable requirements.

The simple version of traceability can be visualized with this view of structured requirements, presenting (and slightly extending) some of Karl Wiegers’ work on requirements.  If you’re doing any work in requirements of any kind, you need to read Karl’s stuff – his Software Requirements is a must-have.

This diagram makes it seem pretty straightforward.  Where it gets messy is when the multi-goal-per-requirement and multi-requirement-per-goal dependencies (that always exist) turn it from a simple tree into a complex graph.  Non-atomic requirements make that graph messier (a hassle, but not a problem)as each “requirement that is really multiple requirements” ads extra dependency relationships to your traceability model.  This becomes a problem, however, when you need to change.

Every project has implementation tasks that take longer than originally expected.  Using a time-box approach to managing the content of each release gives you a straightforward framework for determining how much stuff will be delivered in each release.  When you have to slip something, you have to revisit prioritization.  With well-defined requirements, each valuable requirement that could be delivered provides value by enabling users (or systems as users) to achieve a goal.  When you have to delay the implementation of a requirement, you delay the goals that it supports.

As soon as you realize you are considering delaying part of a requirement, that is a red flag that your requirement is not atomic.

Atomic Requirements Simplify Operations

Atomic requirements allow you to make these on-the-fly prioritization decisions with much better insight into the resultant delay in value.  This allows you to better manage communication with your stakeholders – validating that you are delaying the realization of the right goals.

The same benefits apply when originally planning your software iterations and releases.  Conceptually, you can imagine “scheduling” everything for the first release, immediately discovering that most things need to slip to future releases.  That’s how most* software projects really play out.

*There are times when you intentionally delay particular capabilities, based on external factors – market positioning, customer-adoption cadences, sales-team capacity (to absorb change), etc.

Conclusion

Writing atomic requirements helps you

• Organize and describe why you are asking the team to build what they are building, and how stakeholders will benefit from what will be built.
• Understand the assignable value of each requirement by maximizing clarity in the dependency tree – each requirement is in place for specific reasons.
• Communicate the relevance of each requirement to the implementation team – informing cost-benefit discussions around the inevitable schedule-change discussions.
• Test the deliverables – atomic requirements get graded as pass-fail, not “X% working.”

Attributions:

• Thanks clix for both “atomic” photos!

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

Verifiable Requirements – Revisiting

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

Directly Verifiable Requirements

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

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

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

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

[larger image]

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

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

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

You can measure these impacts in terms of

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

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

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

Rewriting the requirement as follows makes the requirement verifiable:

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

Impossible to Verify Requirements

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

• The home page needs to load fast.

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

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

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

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

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

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

[larger image]

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

[larger image].

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

[larger image]

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

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

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

Rewriting the requirement as follows makes the requirement verifiable:

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

Indirectly Verifiable Requirements

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

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

Models are Models, Not Reality.

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

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

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

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

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

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

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

Conclusion

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

Make sure all your requirements are verifiable.

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

Attainable Requirements – Revisiting

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

Defining Attainable

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

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

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

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

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

Tractability

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

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

And zooming in…

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

[click for larger version]

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

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

[click for larger version]

Agile Product Management: Providing Context

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

Feasibility

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

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

plus  yields

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

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

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

Politics

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

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

Process

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

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

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

Conclusion

Attainable requirements are requirements that

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

Make sure you’re writing attainable requirements.

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

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

Concise Requirements – Revisiting

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

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

Concise Requirements Identify the Problems That Need to be Solved

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

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

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

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

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

Concise Requirements Explain Why Those Problems Are Worth Solving

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

[larger image]

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

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

Concise Requirements Define When Those Problems Are Solved

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

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

This gives you clarity in your objectives.

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

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

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

Conclusion

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

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

Writing valuable requirements is important.  It doesn’t matter how well your teams execute if they are off building the wrong products / capabilities / features.  The right products and capabilities are the ones that have relevant value.

• Valuable requirements solve problems in your market.
• Valuable requirements support your business strategy.
• Valuable requirements solve problems for your users.
• Valuable requirements meet your buyers’ criteria.
• Valuable requirements don’t over-solve the problems.

Valuable Requirements – Revisiting

A little over three years ago, I compiled the Big Ten Rules of Writing Good Requirements, which ended up with an even dozen “rules.”  The first rule was writing valuable requirements.  Three years is a long time.  Our environment has changed.  Many great insights have come into our neck of the software development woods from many inspired voices.  I’ve personally learned a lot.  My focus has changed from being more focused on product specification (back then) to being more engaged in business strategy (today).  Our audience here has grown ~ 10x since the original rules were published.  My dog has tripled in size.  Perhaps my writing has even improved.

Given that, it makes sense to revisit the topic now.

Valuable Requirements Solve Problems in your Market

I struggled a little about starting with “strategy” or starting with “the market.”  Pragmatic Marketing’s Framework (recently updated) starts with the market.  When I first watched the great video, where Jim Foxworthy introduces the updates to the grid, I was a little concerned about that.  Market first, strategy second.  Why not strategy first and market second?  I decided that I was happy with their presentation, since the framework is a tool for product managers.  Product managers usually have responsibility for a market, as a component of their company’s strategy – so the sequencing makes sense for a product manager audience.  Jim also puts it in perspective – their framework is focused on the company’s strategy for attacking a particular market.  I’ll stick with that here too.

To understand what problems are valuable for a particular market (or market segment) you have to approach it from your customer’s perspective.  What are the problems they are trying to solve?

Your customers might be distributors of retail products, who’s business it is to acquire, store, and redistribute small products.  They are in a business where their customers value accuracy, timeliness, and low cost of delivery.  Your customers may value solutions that allow them to more accurately redistribute products (they receive pallets full of items, and then redistribute them a case at a time).  They may value solutions that allow them to adapt to changes in orders with minimal turn-around time.  Or they may get the most value out of cost reductions.  Talk with your customers, listen to them talk about their problems.  When I was working for an enterprise software company years ago, our CEO stressed that he wanted to be solving the problems that keep our customer CEOs up at night.  Find out what those problems are.

The next challenge is in breaking those problems down into something actionable.  If your customers’ biggest problem is cost reduction, how do you solve it?  The first step is to understand where the costs are.  One way to visualize and decompose the problems your customers face is with an Ishikawa diagram (check this out to learn how to use an Ishikawa).

The following diagram shows a decomposition of “The cost of driving is too high” problem:

[larger image]

Now you’ve identified a set of problems that are valuable to your customers.  The Ishikawa can help you make sure you’re identifying problems, not the manifestations of problems.

You also have to understand what solutions are already available to your customers.  If you have a competitor that already offers a very good solution to one of the identified problems, your customers will find less value in a solution from you.

Valuable Requirements Support Your Business Strategy

With a set of problems in hand that are worth solving, you have to figure out which ones are aligned with your company’s strategy.

In the Ishikawa above, one of the problems that car owners face is excessively high payments (on their car loan).  Another problem is that the cost of maintenance is too high.  If your company provides financing products (loans and leases), trying to solve the cost of maintenance problem for your customers is probably out of alignment with your strategy.  Making the financing of a vehicle more affordable (while still profitable for your company) is probably a well-aligned problem.

Your company will also have a strategy for engaging the market – target market share levels, target market segments to penetrate, etc.  You may be trying to become a visionary company with your finger on the pulse of your market – or you may be trying to get mass adoption of your product by solving a very common problem, but solving it better than your competitors.  Your strategy for winning in this market may be to differentiate your offerings by solving different problems than your competitors, or defining a unique market.

Another way to think about alignment with your business strategy is to think about the owners of your company’s strategic goals – your internal stakeholders.  Most projects will fail (or be killed) without internal champions who believe in the ideas.

When you’re aligned with a part of your company strategy,  you’re aligned with whoever is the owner of that component of the strategy, and you’re providing value to that stakeholder.  Sometimes there are many components and stakeholders.  You can adapt some process-improvement prioritization techniques that Roger Burlton teaches to get an understanding of which goals are important to whom.

Valuable Requirements Solve Problems for Your Users

Products are used by people.  People use those products to accomplish goals.  They may be using your product for their employers, in which case they have “practical goals” (finish quickly) that represent how their company’s goals (lowered costs) are realized.  And those people usually interact with other people.  You can quickly build a visualization of who are the users (and indirect users).

[larger image]

You can think of this as an ecosystem of users of your product.  Develop personas and their goals to represent these users.  You can apply the same Ishikawa-based problem-decomposition technique when needed to make sure you’re uncovering the real problems (too many people abandon the sign-up process) and not the manifestations of those problems (users have to click too much).

When your users are not your customers, your users have personal and practical goals that represent their individual contributions to achieving your customer’s goals.  And your users achieve those goals by doing stuff.  You can represent that stuff with user stories or use cases.  The key element is to make sure that you’ve identified the valuable activities, the ones that are required to achieve goals.

[larger version]

The above diagram is used when assessing the completeness of requirements, which is an element of assuring valuable requirements.  If a goal has value, you have to identify the set of user stories required to achieve the goal.  Those user stories therefore have value.  User stories that don’t support a goal don’t have value.

Valuable Requirements Meet Your Buyer’s Criteria

The people who buy your products are sometimes not the people who use your products.  Even when the same person is both buyer and user, that person’s mental model for buying is different from their model for using a product.  If you can’t convince someone to buy your product, it doesn’t matter how great it would have been had they bought it.

Here are the opening soundbites from an earlier article on buyer personas.

• Buyer Persona: If you build what he thinks he wants, he’ll come.
• User Persona: If you build what he actually needs, he’ll come back.

And the closing summary points (it’s a long article):

• Buyer personas make purchases when products appear to address their internal view of what the problems are.
• User personas love products when those products solve the real problems.
• Don’t confuse buyers (who need to buy products to solve user problems) with users (who need to solve their own problems).
• When buyers and users are the same people, acknowledge the buyer-goals distinctly from the user-goals.

There are also several really great insights in the discussion thread – including great comments from Shaun Connolly, Edele Revella, and David Meerman Scott!

Valuable Requirements Don’t Over-Solve the Problems

More is better, right?  Not always.  Sometimes, “more” is a waste.  There are really two ways to think about how much is too much.

The ROI of Incremental Improvements

Because of the law of diminishing returns, the next “more” is always worth less than the previous “more.”  Think of it in terms of improving fuel-economy.  If you have a car that gets 10 mpg, and you drive 100 miles a day, you have to buy 10 gallons of gas a day.  If you improve the mpg by 10 mpg (to 20 mpg), you’ll save 5 gallons of gas per day.  Huge value.  If you improve the mpg by another 10 mpg (to 30 mpg), you’ll save an additional 1.3 gallons of gas per day.  Some value.  Another 10 mpg buys you 0.8 gallons per day.  Diminishing returns.

The cost of achieving “more” is also a factor.  The simplified diagram above shows a linear representation of cost as a black line.  The diminishing returns of value are represented as the red curve.  The optimal investment point is where the two curves are tangent (have the same slope) – marked with the blue circle.  Less investment leaves money on the table – additional investment is done at a loss.

Good Enough is Enough

You don’t need to super-solve the problem.  How much more would you pay for a car that got 10,000 mpg than one that got 1,000 mpg?  If you drove 100 miles a day, the difference between the two (from a value standpoint) is trivial.  Over the course of 100 days, you would save 9 gallons total with the car that had ten times the fuel efficiency.

Why haven’t microwave ovens been getting faster every year? Because the move from a 1-hr baked potato to a 5-minute baked potato is good enough.  You don’t need to get it under 4 minutes.

This is known as satisficing - stopping when something is good, not trying to make it “perfect.”  Additional “goodness” will not result in enough additional sales to justify the investment.

Conclusion

The tagline for Tyner Blain is Software Product Success.  On an elevator, I explain that you have to not only “build stuff right” but you have to “build the right stuff.”  And the right stuff is the valuable stuff.

Define valuable requirements to make sure you’re building the right stuff.

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.

Agile development methodologies succeed because they help development teams be as effective as possible.  Development teams do not, however, work in complete isolation.  The company they work for has a strategy.  The company manages a portfolio of products, and targets a particular product at specific market problems.  Within that context, an agile team can thrive.  What’s the best way to provide that context?

Agile Development in Context

Mike Cohn of Mountain Goat Software gave a presentation to the bayXP group in March 2007 on agile estimation and planning (video and pdf at link).  As part of setting the stage for his planning presentation, he describes the software development ecosystem as an onion.  So did I, coincidentally, in 2006.  The gist of both onions is that software development is implementation, in the context of design, driven by requirements, formed to address market opportunities.  Mike’s onion provides specific insights into the execution approach of an agile team, so let’s frame this conversation using his terms (but a new visual).

• A company has a strategy.  [Example: "Organize the world's information..."]
• A company has a portfolio of products that is intended to provide a mechanism by which the company can achieve its strategy.  [Example: Gmail, Chrome, Gears, Reader, Docs, etc.]
• Each product (or service) the company creates is an intentional part of the portfolio, targeted at specific markets or market segments, with an intention to solve specific problems.  [Example: Gears allows people to consume online content when offline.]
• A product is delivered through a series of releases. [Example: Chrome release 0.2.149.30.]
• The work that goes into a release, when practicing incremental development, may be decomposed into multiple iterations.  [Example: Chrome iteration 0.2.149.29, not released, but built and tested]
• In scrum, the completion of tasks within an iteration are managed daily.  [Example: Today, I will add the 'check for updates' to the 'About Chrome' popup.]

Many people talk about the agile process as if it encompassed the entire perspective shown above.  It doesn’t.  When you talk about the software development lifecycle from the strategy level down, you’re really talking about business strategy.  Agile development happens in the context of a business strategy, a product portfolio designed to achieve those strategic goals, and the product in that portfolio that is being developed.

Saeed Khan puts it pretty well in his first article about agile / scrum:

Keep in mind, Agile/Scrum is a DEVELOPMENT methodology. It is a great model for developers and engineers and other R&D team members to work and communicate more efficiently. There are very clear benefits to this model. It provides greater visibility into current work status, work remaining, can identify development hurdles earlier and can communicate them outward more easily.

I agree with Saeed.  In the diagram above, the layers that represent “what we do” have black text and borders (Strategy, Portfolio, and Product).  The layers that represent “how we do it” have white text and borders (Release, Iteration, Daily).  In Mike Cohn’s presentation on agile planning, he specifically calls out that agile planning happens in this (inner) scope.

Managing a product backlog (in scrum) is the place where things blur a little.  Determining what goes into the product backlog is “what we do”, prioritizing those product backlog items is “when do we do it”, and fitting them into individual releases (timeboxes and rolling-wave planning) is “how we do it.”  As agile teams stress, communication here is the key.

The true challenge that companies face is to provide agile development teams with the context needed to develop software.

Providing Context to Agile Teams

Product management is primarily a strategic activity, combining market insights () with company strategy to design a product portfolio, and to determine which problems a particular product should solve, for a particular market segment.  This leads to a focus on buyer personas and user personas.

Establishing and maintaining the connection between market insights and agile development teams will develop a distinctive competence for your company.  One key is to connect stakeholder goals with implementation activities.  This involves translation from the language of business to the language of developers.

An effective bridge across that communication divide has to be visceral and very straightforward.  Many agile team members rail against anything that looks like overhead, and the manifesto even codifies this disposition – “working software over comprehensive documentation.”

Our magic decoder ring must be simple, explicit, and light-weight.  Sounds like a job for the Ishikawa diagram.

Ishikawa Diagrams for Agile Product Management

The Ishikawa diagram, also known as a cause-and-effect diagram or as a fishbone diagram, can be used to describe and decompose market problems.  Consider the following near-real-world example:

You’re developing a product for sales reps.  The key to your product’s success is user adoption, and you believe the way to get that adoption is by helping sales reps to maximize their compensation.  Sales reps are generally managed via commission-based compensation models.  You establish “Maximize Sales Compensation” as a goal for your software (for these users, in this market segment).  You then acknowledge that there are a series of “smaller” problems that have to be solved before sales reps actually can maximize their compensation.  An Ishikawa diagram of your results would look like the following (consider only the main branches):

[click for larger version]

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

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

[click for larger version]

For the largest and most complex problems, this is still not enough.  You can take each major branch of the Ishikawa diagram and create a child Ishikawa diagram.  However, from an agile standpoint (as in “staying close to your market”), you don’t want to do all of that detailed analysis up front.  Once you’ve prioritized the main branches in your main Ishikawa diagram, you will want to go to the next level of detail only for the first branch.  You want to make sure that you are delivering “working software” – not “comprehensive documentation.”  Delay your detailed analysis to the last practical moment.

Assuming you chose “Improve Predictability of Sales” as the first market problem to address with your product.  And within that choice, you are going to tackle “Align Solutions to Customer Problems” first.  Your child Ishikawa diagram could look like the following:

[click for larger version]

At this point, you would start writing user stories (or defining use cases) around recording customer problems, searching for ‘comparable problems’, predicting the problems a customer might face (before your first sales call), etc.  Those user stories will then get mapped to releases and iterations, and their implementation will be managed through the daily standups.

Outbound Communication of Agile Delivery

This problem-decomposition approach was presented top-down, specifically around providing the needed context to an agile development team to guide their design and implementation activities, giving them the opportunity to intentionally solve valuable problems, in alignment with the company’s strategy.

This same approach can be leveraged in outbound communication of what the team will deliver (and when).  You can easily construct a product roadmap that is actually an “agile problem roadmap.” [Ed: can I trademark that?  Probably not, since Enthiosys already does it, but without the word problem.]  In the short term, talk about specific problems (“Align Solutions to Customer Problems”) that you are solving.  In the longer range plan, talk about the next level of problems (“Improve Predictability of Sales”).  The team is not committing to a widget or feature.  The team is committing to providing a solution to a particular problem in a given release.

When you commit to a particular feature, you inhibit your ability to change as you learn.  And that’s bad.  You need to be able (after each iteration) to say “This problem is still valuable, but our previous idea about how to solve it turned out to be a bad idea.”  If you communicate at the feature level, you’ve added overhead to your process – you now have to manage expectations and update your communications, EVERY time you change designs.

You introduce another problem – these Ishikawa diagrams are so easy to read, and you’re now managing your roadmap based on problems being solved in a given iteration/release – should you tell everyone?  Many product managers sidestep the “Do we make our roadmap public?” question because they don’t create an easy to consume roadmap.  With this approach, you do.  So you have to decide if it needs to be a secret.

Zero-Overhead Planning

Early in this article, I said “agile team members rail against anything that looks like overhead.”  Creating Ishikawa diagrams is zero-overhead.  Or nearly so.  99% of the work that is displayed through the Ishikawa is work that you have to do anyway, to have an intentional approach to product creation.  The only overhead that is introduced is in the creation of the Ishikawa diagram.  If your thoughts aren’t already organized this way, you’re in trouble.  It takes almost no time to create the diagram that reflects what you should already be thinking.

And that qualifies as low-overhead.  And high value.  That should win over any resistance from the team.

Conclusion

As a product manager, you have to synthesize market problems, and develop a product vision to solve those problems that is aligned with your strategy.  As someone who is “part of” or “working with” (whichever matches your situation) an agile development team, you need a way to provide context to your implementation team.  That context can easily be conveyed with an Ishikawa diagram, with almost no incremental effort.  Your team can easily consume the diagram, and it gives them the freedom to explore different solution designs.  It also enables you to communicate your plans with the rest of the company (and externally, if desired).

A lot of people stand up a variation of “If you build it, he will come” (from Field of Dreams) as a copy-writing hook for whatever they are about to tell you about creating products/services/whatever.  We’re no better.  We’re going to tell you that there is a big difference between the people who buy your product and the people who use your product.

If you build what he thinks he wants, he will come.

Actually, we need two catchy quotes.

If you build what he actually needs, he will come back.

For good measure, let’s plug my recent article in The Pragmatic Marketer, Maximize Your Word of Mouth Marketing: Turning Users Into Fans with a gratuitous quote.

If you build it right, he’ll bring his friends.

These quotes (the first two) highlight the differences between buyer personas and user personas.

Personas Are Not Personas

It can be incredibly confusing to anyone not already entrenched in product management or marketing, to hear someone talk about personas.  The buyer persona is a very different person than a user persona.  Understanding one influences how you sell a product, understanding the other is key to getting insights about how people will use your product.  There’s a bit of a catch-22 here – you have to sell the product (even free products have to be “sold”) before anyone ever uses the product.  And if you sell someone a product they hate, you’re worse off than if you never made the sale.

If you want to “test out” of the rest of this article, here’s the crux:

• A buyer wants a product that has capabilities that match his mental model of what is required to solve valuable problems.
• A user needs a product that solves her valuable problems.

Peony Problem

You are part of a booming florist business that has a problem.  Your profitability is too low on the flowers you sell.

One of your store managers, Eunice, looks at what you pay for flowers (very little), and what you sell them for (a lot).  She also determines that overhead (rent, salaries, etc) costs are reasonable.  However, Eunice notices that you throw away half of the flowers you buy.

[Note: Check out our article on defining problems to see how and why to create an Ishikawa diagram like this one.]

Your company policy is to throw away flowers after you’ve had them for 2 days, because they wilt as soon as your customers get them home if you don’t.

Amaranth Analysis

Eunice also reviews orders and purchases of flowers – there’s no regularity in ordering.  The average number of flowers purchased every day is about the same, but the individual amounts vary wildly.  If you ordered fewer flowers, you would save on waste, but you would lose out on some sales, and risk damaging relationships with loyal customers.  She decides that the solution isn’t to just order fewer flowers (you need that inventory on hand), but to make the inventory last longer, so that you can have the same amount on hand, but order fewer flowers.  Eunice gets approval from the owner of the florist to purchase a walk-in cooler for storing the inventory, and then asks Fiona, the head of operations, to make it happen.

Brenda runs operations.  She handles accounting, and ordering of supplies, payroll, all the things that keep the business running.  She doesn’t know flowers, but she knows the flower business.  Brenda now has a problem – she needs to purchase a walk-in cooler.

Eunice is your user.

Brenda is your buyer.

This is the important distinction.  Eunice has a problem that is solved by using your product.  Brenda has a problem that is solved by purchasing your product.

Helping The User

If you’re a product manager, you already know how to help Eunice the user.  You define a user persona and her problems and goals.  You prioritize those problems, build a product roadmap, and make sure your software process benefits from the user persona you’ve defined.  Of course, don’t overdo your persona development.

But what do you do with a buyer persona?  If you apply product management first principles, you recognize that the buyer has a problem (Brenda needs to buy a solution for Eunice’s problem).  So, create a solution for that problem.  Marketing experts might not think about it that way, but that’s what they do.  They understand the perceptions in the minds of buyers, and design marketing campaigns – and influence product development – to make sure there is both a product and a campaign that addresses the buyer persona’s problems.

Helping The Buyer

Shaun Connolly sums up his approach with two quotes from a recent article:

For both proprietary and commercial open source software, the Product Manager needs to focus on creating a product that people will actually buy! Plain and simple.

For any new product offering, one of the first places I focus is on understanding and documenting the Buyer Personas. After all, how the heck are you going to create real value for customers if you don’t know who’s buying? User personas, while not the same, are also useful to understand.

Product Managers: Chief *Holes or Value Creators?, Shaun Connolly

Shaun is definitely stressing the importance of one side of our catch-22, getting that initial sale.  Note that Shaun also links to a good article by Gopal Shenoy, Build Products That Customers Will Buy…

OK, so what is a buyer persona?  Adele Revella has an entire blog dedicated to buyer personas (and an article devoted to answering the question “what is a buyer persona?”

Don’t Confuse The Buyers With The Users

Adele has a great article lambasting some marketing work that Microsoft has done for their CRM product – apparently posting videos of their buyer personas, and treating them as if they are user personas.  Adele is being gracious, I think, in suggesting that the mistake was merely in sharing the buyer personas externally, when they should be for internal use only.  I suspect that this team has mixed the concepts, since the “buyer persona” Adele uses as an example is describing her problems as a user.

In any case, it is disheartening to see anyone have (and share!) such a disparaging and condescending idea of who their users and/or buyers are.

When Your Buyers ARE Your Users?

David Meerman Scott just posted an article, How well do you know your buyer personas?, where he shines the spotlight on Kadient, a SaaS (software as a service) company.  Kadient helps sales people manage their sales collateral (RFPs, white papers, proposals, etc).  David’s article is the latest in his theme of the importance of focusing on buyer personas.  He and Kadient share a couple buyer persona examples for us.  As it turns out, the personas they shared happen to be both buyers and users.  There are probably also buyer-only personas that they could have picked, but this choice is great.  It acknowledges for us that your buyer can also be your user.

Considering that Adele’s article just warned us not to mix them up, consider this as a corrolary to the maxim – Don’t confuse buyers and users, except when they are the same person.

One of Kadient’s combination buyer + user personas is Anya.  Check out David’s article for the full details.  One thing David shares with us is Anya’s goals.  Remember from our example with Eunice and Brenda – Eunice (the user) has goals to solve problems with her work, and Brenda has the goal of solving Eunice’s problem.  With Anya, she has both user-goals and buyer-goals.

David’s example captures both, but it might be tricky to tease them apart.  As a buyer, Anya is trying to match a mental model of what will work.  As a user, she has specific objectives.  Here’s the goal section from Kadient’s persona:

Anya needs to bring in the numbers every quarter, to remain secure in her position at the top of the sales performance chart. To do this, she knows that if she can spend less time doing administrative duties and looking for information and creating materials for her buyers, she can work more opportunities and maximize her face-time with customers. The service offerings she sells change frequently, and she knows she needs to be armed with the latest, most accurate messaging and content.

Breaking it down into two goals, half-buyer and half-user:

• Buyer Goal: “she knows that if she can spend less time doing administrative duties and looking for information and creating materials for her buyers”
• User Goal: “she can work more opportunities and maximize her face-time with customers”

And

• Buyer Goal: “she knows she needs to be armed with the latest, most accurate messaging and content”
• User Goal: “The service offerings she sells change frequently”

This is a buyer persona example, and the buyer goals are explicit – “She knows..” is a clear indicator of her mental model of what she believes she needs to solve her problems.  That is the key information for properly marketing to Anya.

The user goals are not crisply defined, but support a statement from Anya’s “bio” – “Anya wants to ensure she always remains at the top of the team.”  One way she could do that is by maximizing face time with customers and working more opportunities (as a means to close more sales).  Anya also acknowledges a nuanced goal – her service offerings change frequently – and those changes presumably can negatively impact her ability to sell.  It is ok, for a buyer persona, that the user goals need a little more inference.  But that’s ok – the team at Kadient will be using this persona primarily to sell their services to Anya, not to design them.

Ideally, your buyer’s mental model of the needed solution will align well with the user’s problems.  That isn’t guaranteed, even when the buyer and the user are the same person.

Summary

• Buyer personas make purchases when products appear to address their internal view of what the problems are.
• User personas love products when those products solve the real problems.
• Don’t confuse buyers (who need to buy products to solve user problems) with users (who need to solve their own problems).
• When buyers and users are the same people, acknowledge the buyer-goals distinctly from the user-goals.

Jun 14th was the first productcamp in Austin (and the second one anywhere).  It was a great event, and here’s the presentation that I did on how to define the strategic problems that drive our products.

Defining Problems

Here’s the presentation I gave at ProductCampAustin 1, posted on slideshare.  Just click on the forward/back arrows in the center of the bottom of the image, and it will cycle through the presentation – you don’t even have to leave Tyner Blain.

| View | Upload your own

Following Along

In keeping with the “don’t put a lot of words on your slides” tradition, the presentation is probably all but impossible to follow without some notes.  So here are some notes, organized by slide.  The presentation builds on concepts we’ve talked about here over the years, and in the notes below, I’ll link to some of those previous articles to provide more depth (instead of typing out everything I said).

• Slide 1.  There are two key elements to achieving software product success.  Build the right stuff, and build it right.  This presentation is about building the right stuff.
• Slide 2.  Specifically, when we start a project, it is to achieve some business objective.  The challenge is to find the right level of abstraction for that objective.  “Increase shareholder value” is too nebulous, and “Replace a legacy system” is too lacking in context.  Today we will apply a very powerful, but simple technique to help define the business objectives at the right level of detail to be actionable, while providing the right context to validate that we’re doing the right thing. My goal is for everyone to leave here with a new skill that they can immediately apply.
• Slide 3.  Everyone has a different perspective on a software project, and from those vantage points, perceives different elements of the project as the “why, what, and how” of the project.
• Slide 4.  Keeping in mind that people have different perspectives, let’s also look at a modified version of Karl Wiegers’ structured approach to requirements definition.
• Slide 5.  Introducing the Ishikawa diagram.
• Slide 6.  Set up the “deflated tires” problem from the article linked in (slide 5).
• Slide 7.  Showed the discovery process and representation of “real problems” closing out the theme from slides 5 and 6.
• Slide 8.  A real-world project I joined mid-stream for a client.  The project was a “collection of stuff” and no two people would give the same answer for “why are we doing it” and many people unashamedly admitted that they had no idea why.  No idea why!
• Slide 9.  Turns out, here’s what a view of the value for that program really looked like.  The team went from chaos to context.  Suddenly, scope discussions and prioritization decisions had a framework for validation.  There was also an organized way to begin completeness analysis.  Much easier to say “we’re getting this value” than to say “we’re doing these things – did we miss anything?”
• Slide 10.  I facilitated the folks in the room creating an Ishikawa from scratch.  We started with what we thought was the problem statement (provided by John Milburn from the back of the room) – “Traffic in Austin on Fridays is too bad.”  We ended with “John has work-life balance problems”, one of which comes from missing dinner with his wife, which can happen because of a combination of bad traffic and bad planning by John.  We also explored several solution-paths, including increasing the capacity of the roads and of the vehicles.  The ideas clicked for several people in the room.
• Slide 11.  Another real-world example, this one used in planning of a product roadmap for an 18-24 month view of the problems the team was signing up to solve.
• Slide 12.  Special thanks to the sponsors that made our inaugural ProductCampAustin a success!  My prediction for the next one (fall/winter 2008): 250 attendees.  So if you’re the sponsoring type, start planning on how you can help out.

Thanks again to everyone who attended, and special thanks to Tal Boyd of Seilevel, who video taped my whole presentation.  I just haven’t figured out how to split the 400+MB m4v file into something I can upload onto youtube.

The Cause and Effect diagram is also known as a fish bone diagram, because it resembles the skeleton of a fish. Using a cause and effect diagram can be the most effective way to define the problems that you intend to solve with your product. Get your stakeholders engaged in your program with this compelling visual!

Getting To The Root Of The Problem

In our recent article about writing good problem statements, we pointed out a common mistake people make with problem statements – they confuse the manifestation of a problem with a problem.

Problem manifestation [noun] – an example of a way in which a problem is exhibited, without appreciating the true nature of the problem. Ex: The problem manifestation is that the tires on my car are under-inflated. The problem is that my car is too expensive to maintain.

This distinction is relevant. The cost of operating the car is too high. That is the problem. It happens to be that one reason that the cost is too high is under-inflated tires. If you focus your energy on getting properly inflated tires, it will help (by improving fuel economy a little, and by reducing the frequency of tire replacement) with costs anecdotally. But you will not have solved the problem that costs are too high. Unless you get lucky. Costs can be high because the engine is inefficient or damaged, the aerodynamics of the car are bad, or any of a number of reasons. If you solve the problem by addressing a single manifestation of the problem, without understanding the whole problem, it is only because of luck.

Your Problem Statement is The Problem

In the comments on that article, The Demon points out that it is not always easy to identify the right level of abstraction for your problem. The cause and effect diagram makes it brilliantly simple not only to get to the root of the problem, but to communicate this cause-and-effect hierarchy of problem decomposition.

Cause And Effect Diagram Example

The cause and effect diagram is so visceral that the easiest way to communicate how it works is to show an example. Here’s what the cause and effect diagram would look like for the example problem above, where the cost of operating the car is too high.

[larger image]

The main problem is that the cost of operation is too high. This is the far-right, or fish-head part of the diagram (it is sometimes called a fish bone diagram).

The problem can be decomposed into three separate problems: spending too much on fuel, maintenance, and payments. Each of those problems can be further decomposed. Note that “under-inflated tires” appears twice – once as a cause of low miles per gallon (MPG) and once as an excess maintenance cost.

Alternately, you could recognize that spending too much on fuel could be due to lower fuel economy or excessively high prices. You could then choose to decompose the problem slightly differently:

[larger image]

Either approach results in crystal clarity that under-inflated tires is one root cause of low fuel economy, which is one cause of excessive spending on fuel, which is one cause of excessive operating costs. This visual approach helps significantly when trying to identify the right level of abstraction for expressing the problems in your problem statement.

Problem Abstraction Is A Side Benefit

The really cool part is that the help you get in finding the right level of abstraction for your problem is just icing on the cake. [Ed: No jokes about fish-bone cake. Ick!]

The real benefit comes in communicating and validating the problem decomposition with your stakeholders.

Someone questioned me once on the value of writing passionate requirements. Show one of these to your team, and you’ll get enthusiastic, passionate responses. You’ll get kudos from the business for demonstrating that you understand their needs. You’ll get praise from the implementation team for providing them with context.

Using Visio To Create A Cause And Effect Diagram

Creating a cause and effect diagram in Microsoft Visio is really easy, there’s a built in template, and it’s a good one. Create a new drawing and select the “Cause and Effect Diagram Shapes” template (under “Business Process”):

Visio will create a new drawing with a blank cause and effect diagram set up for you:

Fill in the boxes with the large problems. To get to the next level of detail (such as “Fuel Economy is Too low” in the last example), select the “Primary Cause” shape and drag it onto the diagram. Attach the arrowhead to one of the branches (the fish “ribs”) and start typing. For once, Visio’s default layout is where you want it.

To get a secondary cause shape (such as “Bad Aerodynamics” in the last example), select the “Secondary Cause” shape and drag it onto the diagram. Attach the arrowhead to the “primary cause” arrow you just created.

Conclusion

You already have a good justification for defining problems at the right level of abstraction. Now you know how to easily create a cause and effect diagram to find the right problem definition. As a bonus, communicating with stakeholders just got a lot easier – include this in your BRD.