If you understand the important market problems, you can make a good product.  If you understand how important each problem is, for each group of customers, you can make a great product.  If you’re new to this series, go back and start at the first article, we’ll wait for you right here.

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. (This article)
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.
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.

Important Problems

In the previous article on defining market problems, we identified 6 personas / contexts by which we would compare the kindle fire with other products.

1. Tina - A hi-tech prosumer who is using the device to get smarter about the latest trends in her industry
2. Tim - A hi-tech prosumer who is using the device to enjoy niche fiction content, particularly comics, e-zines and self-published works
3. Kenny - A typical kindle user who is using the device for his work in the finance space, studying proposals and business plans, etc
4. Karla - A typical kindle user and voracious reader who is using the device to eliminate the large pile of books on her nightstand
5. Chris - A basic consumer who would is studying business in college
6. Christina - A basic consumer who is in a book club, and who is always reading the latest best seller

The reason it was important to identify contexts is that the important aspect of personas is to identify groups of users with homogeneous perspectives on the relative value of solutions to particular problems – and the three personas previously identified would place different values on the solutions, depending on the context in which they were using the device.

Revisiting the Market Problems

We also identified a set of problems that these personas would want to solve.

1. Read Anywhere – Be able to read content in multiple physical environments / on multiple devices, and not lose my place in the book.
2. Annotate – Be able to annotate / highlight what I’m reading for future review.
3. Talk About It – Be able to have conversations with other people who are reading what I’m reading.
4. Find More to Read – Make it easier for me to find other content that I would like to read.
5. Subscribe – Be able to subscribe to magazines / newspapers / blogs / serial publications.
6. More From My Network - Be able to read what people I trust are reading.

This process is iterative, and in reviewing the 6 problems above, a valid question is – are problems (4) and (6) different versions of the same problem?  When writing requirements, it is important to specify the problems and not the design.  This is a tricky one, as it blurs the line between requirements and design.  Reasonable people can make either of the following interpretations:

• The market requirement is to “find more to read” by any means necessary – it could be through receiving recommendations from the user’s network, or it could be based on some not-specified “black box” heuristic and scoring algorithm.  These two requirements are duplicates.
• Yes, ultimately the user is trying to find more to read, but this is actually too abstract – consider the goal of “enjoy using the device,” which is also the ultimate goal, and too abstract to be useful in guiding the product creation.  Asking people you trust for recommendations is a well established practice for finding reading material, and people make the distinction that it is inherently different from, and provides unique value relative to other approaches (like finding similar products, or “people who bought this also bought this other thing“).

Based on research I’ve done for previous clients (primarily on findability and recommendations in an eCommerce context), my personal perspective is that these problems are distinct, and should be treated differently.  This is one of those Art of Product Management situations, where different product managers can, will, and should reach different conclusions.  For this analysis, the problems will be treated distinctly, and the data that I invent will reflect that I believe these problems would manifest with different importance for different personas in different contexts.

In contrast to the above analysis, problem (1) conflates the two notions of “multiple devices” and “multiple environments.”  People familiar with eInk technologies and Amazon’s Whispersync technology may see these as independent solutions to reading in direct sunlight, and moving from device to device respectively.

I’ve combined these two ideas, primarily because of the influence of this presentation about multi-screen strategies from Precious , a design and strategy consultancy.

[image from Precious article]

My interpretation is that the notion of device shifting is something that is intentional – use the right device for the right environment – and not arbitrary.  Based on that, and the technologies that enable reading in different physical environments – like direct sunlight or a dimly lit room – should be evaluated as part of implementing a device-shifting strategy, and not independently.

Combining these two (in this example) is an opinion-based decision, just as keeping problems (4) & (6) distinct is an opinion based decision.  If the data you gather in identifying problems leads you to combine or separate those problems, do so.

Gathering the Data

In the previous article on identifying market problems, I indicated that you are using a mix of qualitative and quantitative data-collection techniques to identify the problems.  It is during those activities that you also quantify the relative importance of solving these problems.

Innovation Games are a particularly engaging way to gather this type of information [disclosure: while I haven't formally done work for the company, I have worked with and know and respect the founder Luke Hohmann , and likely will work with him again in the future].  I’m including them here because they have worked for me.  A couple examples:

• 20/20 Vision – get customers to put solutions to the problems into relative order (for them).  Effectively, a card-sorting exercise.
• Speedboat – the relative priority insight you get from this game comes when people put anchors at different depths, indicating the severity of a particular problem.
• Whole Product – this brainstorming game can also be used to identify what people perceive to be Must Be (table-stakes) capabilities of your product.

Surveys can also be used to gather data when you need to get feedback from larger numbers of people, or are operating in an environment that is less collaborative.  A simple approach – ask the question “How important is it to you to solve problem X?”  Read up on Likert scales to understand the dangers of asking this type of question, and determine if you need to bring in someone who is an expert at survey design to minimize the impact of bad survey design in your results.

Quantifying the Results

Using the word, quantifying, may not be wholly accurate here – it implies something scientific, when really you are synthesizing the data you have received, in order to eventually determine the relative importance of solving (or improving your solution of) specific market problems.  A made-up word like numberifying might be better.  If quantifying, used in this context, causes your head to explode, please comment below – I suspect this might be a hot-button for folks, but I’m not really sure if it is.

[larger image]

The above table shows hypothetical data representing the “quantified” relative importance of having a solution for each problem, to each persona / context.

For example, Kenny wants to use a device to review and annotate proposals and business plans – internal company documents.  He can do this on any of a number of devices, but the ability to do it “anywhere,” as long as he can annotate, is what really matters to him.  He’s not at all interested in capabilities to find more to read, discuss what he’s reviewing, or subscribe to new content.

For Christina, however, the act of reading is more social than private.  She is not worried about making notes in what she reads or subscribing to new content – she’s reading books and talking about them with her friends.

Gaining Insights

We’re not to the point in the series where we can actually compare competing products effectively yet, but you can already start to get insights.  Imagine you are designing a product for Christina.  Your business case is about going after the “Oprah book club” audience, and Christina is your target user.  You already know which problems are important to her, and more importantly, which problems are not important to her.  You can completely eliminate the subscription and annotation capabilities from your product and create something that Christina would love.

This step alone allows you to avoid the elastic user problem.

Usually, you aren’t able to design a product for just one user.  You can’t be all things to all people.  This is part of the analysis you have to do to determine what to build first – identifying the relative importance of problems to each persona.  The next step is to figure out the relative importance of each persona.  Combining the two allows you to understand the overall relative importance of each problem.

Summary

Creating a great product for your customers means not only knowing who your customers are, but also knowing which problems they want to solve, and among those problems, which ones it is most important to solve or solve first.  When comparing your product to competitive products, the best measure is one that compares the products based on the most important problems for each group of customers.

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. (This article)
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.
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.

Your boss wants a commitment.  You want to offer a prediction.  Agile, you say, only allows you to estimate and predict – not to commit.  ”Horse-hockey!” your boss exclaims, “I want one throat to choke, and it will be yours if you don’t make a commitment and meet it.”  There’s a way to keep yourself off the corporate gallows – estimate, predict, and commit – using agile principles.

This is an article about agile product management and release planning.

Change and Uncertainty

In the dark ages before your team became agile, you would make estimates and commitments.  You never exactly met your commitments, and no one really noticed.  That was how the game was played.  You made a commitment, everyone knew it would be wrong, but they expected it anyway.  Maybe your boss handicapped your commitment, removing scope, lowering expectations, padding the schedule.  Heck, that’s been the recipe for success since they planned the pyramids.

It makes sense.

1. Your early estimates are wrong. When you add them up, the total will be wrong.  If you do PERT estimation, the law of large numbers will help you in aggregate.  But you’ll still be wrong.
2. The outside demands on, and availability of, your people will change. Unplanned sick time, attrition, levels of commitment over time, lots of “people stuff” is really unknown.
3. The needs of your customers will change. Markets evolve over time.  You get smarter, your competitors get better, your customer’s expectations change.

Agile processes are designed to help you deliver what your customer actually needs, not what was originally asked for. Contrast the two worlds.

In the old world, you would commit to delivering a couple pyramids. After spending double your budget, with double the project duration, you would have delivered one pyramid. When you deliver it, you find out that sphinxes are all the rage. Oops.

Your team changed to agile, so that you could deliver the sphinx. But your Pharaoh still wants a commitment to deliver a couple pyramids (the smart ones will be expecting to get just one).  You can stay true to agile, and still mollify your boss’ need to have a commitment, if you take advantage of the first-principles of why agile estimation works.

Estimation

A commitment is a factual prediction of the future.  ”This will take two weeks.”  Nobody is prescient.

A factual prediction has to be nuanced.  ”I expect* this will take no more than two weeks.”

*in reality, this is shorthand for a mathematical prediction, such as “I expect, with 95% confidence, that this will take no more than two weeks.”

Few non-scientist, non-engineers, non-mathematicians understand that 95% confidence has a precise meaning.  People usually interpret it to mean “a 5% chance that it will take more than two weeks.”  What it really means is that if this exact same task were performed twenty thousand times (in a hypothetical world, of course), then nineteen thousand of those times, it would be completed in under two weeks – do you feel lucky?

To make a statement like this, you actually have to create a PERT estimate – identifying the best-case, worst-case, and most-likely case for how long a task will take.

Unfortunately, we’re rarely asked to make a commitment about a single task – but rather a large collection of tasks – well-defined, ill-defined, and undefined.

You can combine PERT estimates for the individual tasks, resulting in an overall estimate of the collection of tasks.

The beauty of this approach is that the central limit theorem, and the law of large numbers, work to help you estimate a collection of tasks – you can actually provide better estimates of a group of tasks than a single task.  This obviously helps with the well-defined tasks that you know about at the start of the project.  This even helps with the ill-defined tasks.  Rationalists will argue that the key, then, is to do more up-front research to discover the undefined tasks – and then we’re set.  As Frederick Brooks (Mythical Man-Month) points out in The Design of Design, this debate has been going on since Descartes and Locke.  It is not a new idea.

Big Up-Front Design and Requirements (BUFD & BUFR) hasn’t worked particularly well, so far.

Don’t throw out the baby with the bath-water, however.  The math of estimation is still important and useful.  Even if empiricism is not the silver bullet.

Prediction

Estimation is a form of prediction.  Even agile teams do it.  In Scrum, you estimate a collection of user stories – in story points that represent complexity, and you predict how many points the team can complete in this sprint.  Note the time factor.  If you’re working a two-week sprint, there is very little risk of changes in staffing during a two-week period.  There’s also very little risk that your market will change significantly in two weeks – and if it does, what are the odds that you will notice and materially change your requirements in two weeks?

Visually, let’s take that PERT estimate and turn it sideways – so we can introduce the dimension of time.  Imagine you estimated all of the tasks (well-defined, ill-defined, and a guess about the undefined), as if they were all to happen in the first sprint.  Ignore inter-task dependencies, and pretend you had unlimited resources and the ability to perform all tasks in parallel.

The graph above shows the aggregate estimate – the circle is your best prediction, with error bars representing your confidence interval in the estimate.  If you were using PERT estimates, these could represent that 5% and 95% confidence lines.  Subjectively pick something based on your team’s experience in the domain and your confidence in your guesses (about the undefined tasks).

We need a segue into the “best of waterfall” approach to estimating projects, to steal and invert a good idea.

The Cone of Uncertainty

The folks at Construx have published a nice explanation of the cone of uncertainty – an adaptation of an idea from Steven McConnell’s Software Estimation: Demystifying The Black Art (2006).  That article uses his imagery with permission – so please go look at it there.  The idea is that as the project becomes better defined (e.g. during the project), the amount of uncertainty is reduced.

The findings show that initial estimates are off by 400% (either low by a factor of 4 or high by a factor of 4)!  Even after “nailing down” requirements, estimates are still off by 30% to 50%!

As bad as that sounds, it is actually worse.  This is a prediction for the original project (delivering pyramids).  Not only are your estimates wrong – but they are bad estimates for delivering the wrong product.

But – the core idea is sound – the further into the future you have to execute, the greater the mistakes in your estimate.

Taking that concept, and applying it to our diagram, we get the following:

The further into the future you are trying to predict, the less accuracy you have in your prediction.  This reduction in accuracy is reflected as a widening of the confidence bands for your estimate.

• A couple sprints’ worth of work is not much different than one sprint – so your estimation range is not much changed.
• An entire release of sprints (say 6 to 10 sprints) has much more opportunity for the unknown to rear its head.

Now, your prediction is (probably) unusably vague and imprecise.  ”This set of tasks will take X plus or minus a factor of two.”

That’s the reality.

Note: This has always been the reality.  People have historically reduced this “risk to timing” by hiding the “risk of change” aspects – and waterfall processes encourage you to deliver the wrong thing, as close to on-time as possible.

That’s not what we want to do, however.

We still want to deliver the (not-yet-defined) right product, as efficiently as possible.  That’s the goal of agile.  (For folks who haven’t been here at Tyner Blain for long – “right” includes both value and quality).

Refinement

Because we’re agile, and we’re willing to “get smarter” about our product over time, we have an opportunity to improve.  Because of the nature of compounding estimates and the cone of uncertainty, our uncertainty gets smaller over time.

Let’s remove our artificial simplification that we could do everything “right now” and look at what we think we know right now, about the end of the release.

Our ability to predict the amount of effort (for today’s definition of the product) at the end of the release is not very good.

Our ability to predict (today’s definition of the product) one sprint into the future is much better.

After completing the first sprint, we are a little bit smarter – the ill-defined tasks are better defined.  Maybe some of the undefined tasks are now ill-defined.  The same cone of uncertainty is now a little bit smaller – we are a little bit smarter, and the time horizon of the release date is a little bit closer.

The trend continues – each sprint gets us closer to the release date, and with each sprint (assuming we get feedback from our customers, and continue to study our markets) we get a little bit smarter.  We also get better at predicting the team’s velocity (how much “product” they can deliver during each sprint).

Commitment

Your boss still wants a commitment, however.  And that’s where we get to change the way we look at this (again).

The above diagrams all display how we converge on an estimate for a stable body of work.  However, we know that the body of work is constantly changing.

Backlog! [you say]

Yes!  The backlog.  The backlog is an ordered, prioritized list of user stories and bugs.  I was talking with Luke Hohmann of Innovation Games last month, and one of the most popular online Innovation Games is now the one they created based on prioritizing by bang for the buck.  Play it today online (for free!).  How cool is that?

The backlog represents the work the team is going to do – in the order in which the team is going to do it.  Over time, as we get smarter, we will add and remove items from the backlog – because we discover new capabilities that are important, and because we learn that some things aren’t worth doing.  We will even re-order the backlog as we recognize shifting priorities in the markets (or in our changing strategy).

As this happens, it turns out that the items at the top of the list are least likely to get displaced, and therefore most likely to still be part of the product by the time we get to the release.

Instead of thinking about uncertainty in terms of how long it takes, think about uncertainty in terms of how much we complete in a fixed amount of time. In agile, generally, we apply a timebox approach to determining what gets built.

Now, uncertainty, instead of manifesting as “when do we finish?” becomes “what will we finish?”

Your boss is rational.  She appreciates the constraints, she just wants to know what you can commit.  Every boss I’ve worked with has been willing (sometimes only after much discussion) to treat this uncertainty in terms of what instead of when.  They acknowledge that they need to translate (usually for their boss) into a “fixed” commitment.

The solution: commit to a subset of what you predict you can complete.

At the start of the release, you may have 500 points worth of stories.  Based on your team’s expected velocity, and the number of sprints in the release, you predict that you can complete 320 points worth of stories (5 people on the team, a team velocity of 40 points per sprint, and 8 sprints in the release).  Starting at the top of the backlog and working down, draw a cut-line at the last story you can complete (when you reach 320 points).  This is your prediction.

Now the commitment part.  You’ll have to figure out what you’re comfortable with.  Maybe for 8 sprints (say, 16 weeks into the future), you may only be comfortable committing to half that amount – 160 points.  Go back to the top of the backlog, and count down until you reach 160 points.  Everything above the line is what you commit to delivering.

Maybe you are comfortable committing to 240 points, maybe only 80.  This is like playing spades.  The more you can commit to, without missing, the better off you are.  Your tolerance for risk is different than mine.

You can also negotiate with your boss.  Commit to 160 points now, and provide an update after every other sprint.  More likely than not, you will be increasing the scope of your commitment with every update.

Mid-project updates of “we can do more” are always better than “we can do less.”  And both are better than end-of-project surprises.  This also allows you to have updates that look like this:

We didn’t know this at the start of the release, but X is really important to our customers – and we will be able to deliver X in addition to what we already committed.  Without slipping the release date.

Conclusion

Making commitments with an agile process is not impossible.  It just needs to be approached differently (if you want to stay true to agile).  The end result: better predictions, more realistic commitments, and the likelihood that each update will be good news instead of bad.

[Update: Changed initial image.  Thanks Dennis for the great photo!]

Estimating the “value” of features is a waste of time.  I was in a JAD session once where people argued about if the annoying beeping (audible on the conference line) was a smoke alarm or a fire alarm.  Yes, you can get to an answer, but so what?! The important thing is to solve the problem.

Solutions Versus Features

Everyone on that conference call had an immediate and visceral appreciation of the value of making the beeping stop.  That’s the power of solving a problem.  The methods of solving the problem – mute the offender, replace the battery, throw the alarm out the window – do not have implicit value.  They have an indirect value, in an “end justifies the means” kind of way.  But not direct value.

The same sort of thing applies when talking about prioritizing features.  Eric Krock (@voximate) just wrote a really good article, Per-Feature ROI Is (Usually) a Stupid Waste of Time, where he does two great things, and (barely) missed an opportunity for a hat trick.

The first great thing Eric did was look at the challenges of determining relative (ordinal or cardinal) value of “several things.”  He points out several real world challenges:

1. When you have a product with several things already and you want to determine the value of yet another thing – how do you allocate a portion of future revenue to the new thing versus the things you already have?
2. When thing A and thing B have to be delivered together, to realize value, how do you prioritize things A & B?  Relative to each other?
3. The opportunity cost of having your product manager do a valuation exercise on a bunch of things is high.  She could be doing more valuable things.
4. You won’t perform a retrospective on the accuracy of your valuation.  So you won’t know if it was a waste of time, and you won’t get better at future exercises.

The second great thing Eric did was reference a Tyner Blain article from early 2007 on measuring the costs of features.  I mean “great” on three levels.

1. As a joke (for folks who don’t know me, figured I’d mention that I’m kidding, just in case you get the wrong idea).
2. There is some good stuff in that earlier costing article about allocation of fixed and variable costs (with a handy reminder.
3. Eric’s article gives me an opportunity to shudder at the language I was using in 2007, see how much some of my thinking has evolved in four years, and improve a bit of it here and now.

What Eric slightly missed is the same thing I completely missed in 2007 – features don’t have inherent value.  Solutions to problems do have value.  He only slightly missed it because he got the problem manifestation right – it takes a lot of effort, for little reward, to spend time thinking about what features are worth.  I also missed the opportunity in an article looking at utility curves as an approach to estimating benefits, written two days after the one on cost allocation.  We were both so close!

People don’t buy features.  They buy solutions.

Valuing Solutions Instead of Features

Estimating the value of solutions addresses a lot of the real problems that Eric calls out.  It also has a side benefit of keeping your perspective outside-in versus inside-out.  Or as others often say, it keeps you “market driven.”

Anything that you’re doing, as a product manager, that has you focused on understanding your market and your customers and their problems is a good thing.  It may even be the most important thing.  I would contend that it eliminates objection 3 – the opportunity cost of estimating the value of solutions is minimal or zero.  There may be activities with more urgency, but off the top of my head, none that are more important, for a product manager.

Comment if I’m missing something (it’s late and I just got home from another week on the road).

The way I approach determining the value of a solution is by developing a point of view about how much incremental profit I will get when my product starts solving this additional problem.  Revenue can increase from additional sales, or from the ability to increase prices.  Cost can increase if new marketing and other operations (launches, PR campaigns, etc) are required to realize the incremental revenue.

I start with a customer-centric market model.

A given solution, or improved solution (as in “solves the problem better,” or “solves more of the problem”) – which only applies to some problems – is interesting to some customers, in some market segments.

A solution has value when it brings in incremental customers, in a targeted market segment.  It also has value when it reduces or prevents erosion of your current customer base (in a SaaS or maintenance-revenue model) to competitive solutions.

The time you spend thinking about buyer and user personas, the problems they care about, and the nature of those problems (which varies by persona) is not time wasted – or even spent “at the cost of doing something else.”

To make this useful, you have to have a forecast – without solution A, we will sell X; with solution A we will sell Y (and to whom).  A good product manager will be looking at sales, and will be able to reconcile the sales with the projections.  That helps with objection 4 (but doesn’t completely address it – you don’t know if your projections were accurate, so you can’t really know if your estimation is accurate).

This also helps you deal with challenge #1.  You’ve got a model that says “the current product works great for high school students, but not college students, because they also have problem A, which they solve today by…” Your intention is to create solution A, making your product viable to college students.  Allocate the incremental profits from college-student sales to solution A.

My approach to challenge #2 is a little more tactical.

Coupled Solutions

There are a couple ways that Eric’s “must deliver A and B” scenario are interesting, when looking at the value of solutions.

Scenario 1: Solution A solves part of problem X for persona M.  Solution B solves part of problem X for persona M.  Combined, they solve more of problem X for persona M.

This makes sense for “more is better” problems – where “more” solution yields “more” value.

In this case, I have a forecast (the more time I spend on it, the better it will be) that maps incremental sales to improved solutions.  The “first” solution to be released will have more value than the second.  If they are being released together, then I don’t care about the allocation – I combine them.

Scenario 2: If, however, the two solutions are valuable to different personas, then I treat them separately – even if they solve “the same problem,” it is not the same problem (for the same person).

Conclusion

Prioritization by “Bang For the Buck” is worth doing.  Just make sure you are prioritizing solutions, not features.

Also note: this article talked about valuation – what you do with that valuation, prioritizing by market, can be trickier.

Almost everything I’ve read about use cases focuses on describing what needs to be added to your product.  Agile development says “get it working first, make it better second.”  That means changing the way the software enables a user to do something they can already do.  How do you manage requirements for incremental improvement?

Iterative Development and Incremental Improvement

Iterative development is the process by which you release software in iterations – small, incrementally better versions of your software.  People usually think about this solely in terms of enable the most valuable capabilities first, then the next most valuable capability next.

That’s fine, when your product is new.  Eventually (or quickly!) you will reach the point when the next most valuable improvement is not to add a new capability, but rather, to make an existing capability more valuable.

Everything is an Upgrade

In a couple earlier articles about organizing migration projects and requirements for migration projects, I wrote about how migration is a bit of a misnomer.  Everything is a migration.

My argument in those earlier articles is that the problems you’re solving with your “new” solution are not new.  Your customers are currently solving them in different ways.  The relevant question for migration projects is around how much your users are changing the way they solve their problems.

[As a slight segue, failing to appreciate this distinction can lead you to a project that is based on a faulty problem statement.]

When you are delivering incremental improvements to your product, through iterative development, you are upgrading your software.  You are migrating your users from their old solution to their new solution.  It just so happens that you are replacing yourself, as you migrate them from the old version to the new one.

A viable strategy, that appeals to me personally, is to continuously innovate, disrupting your market, before someone else does.  With this approach, you are intentionally reinventing your solution, making it difficult for someone else to out-innovate you.  This is a great way to approach developing your roadmap strategically.

Your market will change.  Rapidly. Do you want to react to your competitors, or keep them on their heels while you stay on the balls of your feet?

The reverberations of the “new” Twitter still haven’t settled, and many of Twitter’s competitors are on their heels – some of them only now realizing that Twitter has always been a competitor and not just “a platform.”  The new Twitter doesn’t really change anything about how people use Twitter, except make it (markedly) better.

Avoiding Featuritis

When is it more valuable to improve what your software already enables, versus enabling users to accomplish more with your software?  Kathy Sierra introduced us to the concept of featuritis, the idea that too much is too much.

In an article on viral product management, I proposed that by making your software better, you can tap into an altruistic mechanism by which people will promote your product.  As an example, I proposed improving the usability of your software as a means to cross this viral tipping point.

One of the key ideas is that making it better for users makes your product better for your company.

Managing “Improvement” Requirements

Now that we all agree that there is value in making your software better [comment below if you disagree] the question becomes “How?!”

Use Cases can be used as the keystone to your requirements arch.  Sometimes, user stories are better than use cases, but use cases are perfectly agile.  When you’re starting a project, you want to apply an outside-in approach to defining the scope of that project – or more particularly, to define the scope of problems you are solving in your roadmap. This article will talk in the language of use cases, but identical concepts and approaches apply when using user stories as well.

When you have prioritized a use case as “the next most valuable capability to introduce” you add it to the backlog for your sprint.  The implementation team then provides feedback that use case is “too big” and you have to slice it up.  It is important that you don’t split the use case  in such a way that you only solve half the problem.

You also shouldn’t deliver a “bad” product.  In fact, the ideal way to introduce a new capability is to satisfice, and not introduce the “perfect” solution in your first iteration.  Make your first solution “good enough.”  Part of the art is defining “good enough,” but rest assured, it is not the same as “the best you can possibly do.”

Summarizing some key elements from above demonstrates the eventual reality you will face:

1. Every problem* your users face is already being solved, you are just providing a better solution.
2. There is diminishing, and eventually negative return on adding more capabilities to your product.
3. Your first release of a given capability will only be “good enough.”  That leaves room for improvement.

*Yes, you can pedantically define “the problem” as “the existing solution is not good enough” – but you still end up in the same place, so why bother?

Eventually, the value of improving something you’ve already released will be greater than the value of releasing something new.

What do you do?  You implement the same use case again.

If your product is Software as a Service (SaaS), you absolutely should be thinking about things this way.  Becoming better is a continuous improvement objective that is implicit in the economics of SaaS products.

Revisiting Use Cases

Not to be confused with re-use of use cases, revisiting a use case is specifically revisiting – with the goal of improving – the implementation that is already in place within your product.  This is a special case of a migration project – you’re migrating your users from your old solution to your new and improved solution.

You may be migrating to an identical process, perhaps with faster performance than your previous release was capable of.  Or you may be improving the procedure (improving usability, interaction design, visual design, etc) without affecting the process. Generally, a “make it better” use case improvement effort will have no more than a minor process impact.  Your users are still doing the same thing, they are just enjoying it more, or doing it more effectively.

When slicing use cases to make them fit within a single sprint, you may design them for a single user persona in the first release, knowing that you won’t meet the expectations of a different user persona until the next release.  In this case, your non-functional requirements, constraints, or acceptance criteria will be different.  Your use case may also be different (in the details) while appearing to be the same.  This also common scenario can be addressed with the same approach.

Find that old use case (from several iterations ago) and put it back in the backlog.  Remember, agile is about conversation, not artifacts.  If you need to add an explanation to the use case, because your team fixates on the fact that it is “already working,” add a qualifier that it needs to be “better.”  Then have a conversation, and explain how it needs to be better.

Is Design Part of Implementation?

Some teams organize such that designers (both architects designing code and designers designing interfaces are being addressed here) are part of the implementation team.  Other companies treat designers as stakeholders – providing guidance and input to the product managers and product owners.

When a “new design” is being requested from outside the team, include that design guidance as part of the input to the implementation team – through artifact and / or clarification.

When a “new design” is being requested of the team (the designer is part of the team), express the new acceptance criteria to the team.  Note that these need to be measurable requirements if they are to be considered good requirements.

Summary

There will come a time when the most valuable thing you can do is improve the user experience for a capability your product already embodies.  When that time comes, use the same use case again, updated with the new constraints, non-functional requirements, and acceptance criteria.

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!

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

Deep Dives

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

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

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

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

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

OK Stewart, that’s only 519 words.

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

User Goals

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

Corporate Goals

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

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

Alignment and Conflict of Goals

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

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

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

Vending Machine Example

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

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

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

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

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

Consider the following procedure I’m forced to endure:

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

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

Consider an alternate procedure:

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

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

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

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

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

Generalizing User and Corporate Goal Conflicts

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

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

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

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

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

Blue Ocean Strategy

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

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

Creating a Blue Ocean Strategy Map

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

 [larger image]

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

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

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

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

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

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

Personas

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

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

 [larger image]

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

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

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

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

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

Mapping Personas to Products

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

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

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

 [larger image]

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

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

Improving The Model

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

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

Conclusion

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

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

Three Goals of Growth

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

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

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

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

Growing Your Servable Market

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

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

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

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

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

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

Growing Your Market Share

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

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

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

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

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

Growing Your Paid Market Share

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

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

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

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

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

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

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

One Way to Bring it all Together

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

Conclusion

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

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

Old Rumors

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

New Rumors

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

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

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

Product Management

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

Should Dell enter the Cell Phone Market?

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

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

Kano Analysis

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

Kano analysis recap

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

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

Prioritizing Software Requirements – Kano Take Two

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

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

Differentiation

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

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

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

Conclusion

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

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

Planning by ROI.  Hmmm.  Isn’t that impractical?  In an econometric way, yes.  But you can still estimate the relative value of the capabilities / stories you’re planning for your scrum sprints.  The point is – don’t look only at value – also look at costs.  While “ROI” may be a poor choice of terms, “bang for the buck” is not.

Mea Culpa

In the previous article, Plan Your Next Spring By ROI: Part 1, I made a bad choice of sloppily using ROI (about a dozen times) to describe “bang for the buck.”

Just over a year ago, we showed how prioritizing by ROI delivers value faster.  The reason this works is that each sprint (or timebox) has a fixed capacity for work, so you want to cram as much value into that box as possible – not just do the most valuable thing first.  Here are a couple images from the previous article that show the impact of using this approach.

[...]

So far, we’ve argued that prioritization should be by ROI, and while accounting for other people, should be user focused.  Actually, nothing above is sprint-specific, the same concepts apply to any product planning and development approach.

Plan Your Next Sprint By ROI: Part 1

[Editor: Note - the author has also messed up again, this time by burying the lead at the end of the article.]

Giants.  And Their Shoulders.

I had a great conversation over the weekend with Luke Hohmann, founder and CEO of Enthiosys, and realized my mistake.  Consider the titles of three (excellent) articles Luke wrote earlier this summer:

1. Why Prioritizing Your Product Backlog for ROI Doesn’t Work (Part 1 of 3)
2. Developing Attributes for Backlog Prioritization (Part 2 of 3)
3. Prioritizing for Profit (Part 3 of 3)

Not to mention giving a presentation at Agile’08.

You’d think I would have noticed, and been more careful in my use of language.  Sorry about that.

Luke, in his first article, provides several arguments against econometric assessment of ROI, and I agree with all of his points.  In his second article, Luke goes into details about defining attributes for reflecting the goals of internal stakeholders, external stakeholders (buyers and users), and the system.  I promised to do the same in this article, but frankly, why reinvent the wheel?  Our differences from Luke’s article would at best be nuanced, so the best use of your time (and mine) is to just go read his second article.

Our experience is that successful Agile Product Managers have an almost natural, intuitive feel for prioritizing backlog items to drive profitable growth. Fortunately, this natural ability is greatly enhanced when they make the link between the backlog and their ability to drive profit explicit. As an aside, it is this set of attributes that most clearly distinguish the Scrum-centric role of a Product Owner with the full responsibilities of an Agile Product Manager.

Developing Attributes for Backlog Prioritization (Part 2 of 3)

Including Costs in Sprint Planning

There are two dimensions by which to keep costs in mind when planning a sprint.  The first is in determining how much work to schedule for any given sprint.  When you use timeboxing to plan a sprint, you’re saying “we have the capacity to do X work per sprint” and “we should only schedule X work per sprint.”  Your plans are based on estimates, so you need to have a feedback mechanism to make sure you’re doing a better job in planning each sprint than you did with the previous sprint.  Burndown graphs are a great way to do this.  The burndown provides feedback within the sprint too, not just at the end.

Mike Cohn, of Mountain Goat Software, gave a great presentation on how to estimate costs for an agile project.  Without giving it away, he proposed (starting on slide 14) using planing poker to get quick estimates of user stories [more details] at the product backlog level.  Then, more detailed estimates are created for the tasks within the sprint.  If your team uses use cases, you can choose to use use case points as a low-overhead estimation method (but not nearly as low as planning poker) to determine the initial estimates of costs.

A Planning Example

You have the following set of items being evaluated in your product backlog.  Note that there are a mixture of strategic, user-centric, and code-refactoring items under consideration.

• Profile Editing – As an insurance agent in the community, I want to be able to edit my profile to personalize my identity within the site.
• Data Abstraction Refactoring – The system’s data model is inelegant and needs to be refactored, if ongoing development is to be easier.
• Action Notification – As a manager of agents, I want to be notified whenever my agents submit quotes to potential customers.
• Grouping Items – As an insurance agent, I want to be able to group contacts, proposals, communications and other items, so that I can organize my work.
• Reporting – As a manager of agents, I want to be able to run reports to track financial metrics and activities by agent, product, geography, and time period, so that I can manage my team effectively.
• Serializable Objects – The system’s implementations for data backup and data export are redundant and brittle and should be refactored to clean up the code.
• Customer Centric UI – The user interface is currently product-centric in approach.  Our strategy to offer multi-vendor product lines will require agents to focus on customers first.

Using the value-estimation and cost estimation techniques outlined by Luke and Mike you determine the following value and cost estimates for each “story.”

If you were to ignore the cost estimates you would do the data abstraction refactoring and customer-centric UI stories first, followed by the profile editing, action-notification, and other tasks in order of descending value.  As it turns out, that is not the way to maximize value over time.  At first glance, the profile editing story looks like the biggest bang for the buck.

Create a scatter plot of value versus cost.

[larger version]

You can clearly see the differences in value and differences in cost of the different stories.  If, however, you add the element of value/cost – bang for the buck – and prioritize by it, you will schedule stories in a different order.  Value / cost is also the slope of a line from the origin of the graph to each story.  If you draw those lines, you see the following:

[larger version]

To maximize value delivery over time, work across the chart in a clock-wise direction.  Profile editing is the first task, but grouping items and data abstraction refactoring are tied for second place.  This is different because you’re prioritizing by bang-for-the-buck, not just bang.

Collaboration And Agile

When you consider the agile manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

© 2001, the above authors. this declaration may be freely copied in any form, but only in its entirety through this notice.

you see that there is an opportunity to take this even further.

Have Developers Improve ‘The Plan’

I proposed an idea to the development lead on an agile team a couple weeks ago.  A couple hours later, he pinged me to let me know he had just applied it and was very excited.  A quick whiteboard session (started with a version of the diagrams above), and he was able to immediately make his sprint better.

I told him that when I was still slinging code, and later, when working with teams of engaged and talented developers, I often ran into the problem of having a “cool capability” and wanting to get that capability into the current release.  I wasn’t pushing for the capability because it was high bang-for-the-buck, or even high-bang – I just thought it was cool.  So I would implement it.  Bad Scott, no biscuit.

What I proposed was that when a developer has a favorite feature, instead of just trying to squeeze it in, the developer should figure out how to make it cost less, until it had the highest bang for the buck.  Each initial cost estimate is a planning-poker estimate.  By spending cycles on design, a developer can figure out a cheaper way to implement it.  And that moves the story to the left on the chart.

Your challenge, visually, if you want to bump reporting up in the planning backlog, looks like the following:

[larger version]

You, as a member of the implementation team, have to come up with a design for reporting that is roughly one-third the cost that was originally estimated.  Do that, and it gets bumped up in the queue.  [And yes, I realize that very few developers get excited about reporting.]

The product manager‘s job is to make sure you get all the dots in the right place vertically.

The implementation team puts the dots in the right place horizontally.

Everyone embraces the ability to change the graph.  The product manager moves the dots up and down as she learns more about the needs of the market.  The implementation team moves them to the left (and sometimes to the right) as they design better solutions.

Quoting Luke again – “Our experience is that successful Agile Product Managers have an almost natural, intuitive feel for prioritizing backlog items to drive profitable growth. Fortunately, this natural ability is greatly enhanced when they make the link between the backlog and their ability to drive profit explicit.”

This feels intuitive to me.  What about you?

You’ve got a giant backlog of user stories and product capabilities.  How do you determine which stories to implement right now?  By the estimated value of each story?  Pick the ones the developers want to build next?  How about picking the stories that maximize the ROI of the sprint?  To do that, you need to estimate both value and cost.  While remaining agile.

ROI Refresher

In our earlier Definition of ROI: Return on Investment article, we provide an explanation and example of calculating ROI.  In short, ROI is the acronym for return on investment.  How much return do you get, as a percentage of what you have to invest.  If you invest $100 to get $120, your return is $20 (the profit).  Your investment is $100.  Your ROI is 20% (20/100).  Another way to think about it is bang for the buck.

Prioritizing by ROI versus Prioritizing by Value

You can prioritize based on value – “Do the most valuable thing first.”  And that is a good, but suboptimal approach.  We even suggested it as “the best” prioritization technique in our prioritization article from almost three years ago.  Since then, by continuing to focus on software product success, I’ve learned to believe in a better way.

Just over a year ago, we showed how prioritizing by ROI delivers value faster.  The reason this works is that each sprint (or timebox) has a fixed capacity for work, so you want to cram as much value into that box as possible – not just do the most valuable thing first.  Here are a couple images from the previous article that show the impact of using this approach.

Identified stories, from highest value to lowest value (V = Value, W = Work (or cost)).

If you can schedule 30 units of work in a sprint, your first sprint will deliver 19 units of value, and your second sprint will deliver an additional 9 units of value.  The thirs sprint delivers the remaining 15 units of value.  Why more value in the third sprint than the second?  Because you didn’t sort by ROI, you sorted by value – but were constrained by cost.  When you sort by ROI, you get the same tasks, in the following order:

With this sorting, your first sprint delivers 25 units of value, your second sprint delivers 9 units, and your final sprint delivers an additional 9 units of value.  There are more details in the original value-maximization article.

This is critical to executing a market-driven strategy that will dominate your competitors.  You not only have to stay tapped in to the market needs, but you have to deliver faster than the other guys, or your distinctive insights will be wasted.

Political Prioritization

Really?  Yes.  The first risk to the success of a project is that it gets canceled.  Only the projects that don’t get killed even have a chance to be right, and therefore maximize value for your customer (or company).  That means you need to prioritize in a way that satisfies your stakeholders.  After attending last year’s IBRF, I wrote the following article as an interpretation (and slight extension) of Roger Burlton’s very good presentation about process improvement.  When you’re tasked with improving a company’s processes, the first question you have to ask is “which ones should we improve first?”

From that article:

This analysis focuses on principal stakeholders. The goal of this analysis is to encourage your principal stakeholders, or sponsors, to prioritize the most valuable processes first. Not all stakeholders are created equal, so you have to weight the relative importance of each stakeholder. You can weight them politically, by influence, or by whatever factor is most likely to get buy-in from the executives.

Stakeholder Value Matrix

The end result is a prioritized list of processes to improve, based upon which ones cause the combination of most pain (current state) and most gain (when improved) across your stakeholders, based on maximizing the utility of the group of stakeholders.

Visually, the preceding diagram shows the end results of aggregating the stakeholder inputs in terms of pain and gain.  A couple utility curves are overlaid (arrow shows increasing utility) to show what to do first.  The 1,2,5 processes are clustered together in the “highest utility” or “most value” range.  This approach would focus on those processes first.

Persona Prioritization

When developing software, you should primarily be user-focused.  [Note: this is somewhat of a religious debate, I guess we worship at the chapel of UX.]  Luckily, most of the time, stakeholder goals and user goals are not in conflict.  However, to sell your solution, you need to make sure you are addressing both buyer goals and user goals.  Sometimes they are the same, like with consumer products, and sometimes they are not, like many enterprise software products.

As a product manager, you have to know when to listen to, and when to ignore the squeeky wheels.  If you’re in a start-up doing its second product, solving a new problem for a new market segment, you’re dealing with founder’s dilemma.  That founder has a bunch of stakeholder goals for you, and the juice to make sure you address them.  If you’re trying to get analyst’s attention [good article by April Dunford at Rocket Watcher], you may feel pressured to prioritize “check the box” features that may be important only to buyers and analysts, without actually adding value for the users.

Of course, you can’t ignore analysts and buyers and internal stakeholders.  If your product gets cancelled before you get to market, you’re done.  If analysts criticize or ignore your product (for some markets), you lose a lot of sales.  And if buyers don’t “think they want it”, they won’t buy.  You never get a chance to demonstrate value to the users.

But focusing solely on those folks means you won’t have a product that people love, and you won’t generate word-of-mouth, customer loyalty, or value for your customers.

So any solution needs to account for the needs of the users.  Organizing users into personas, and making strategic decisions about which ones are important will help.  Include the other people (buyers, etc) but use a persona-centric model for describing what you’re doing – just to make sure the users are at the center of your decisions.

Intermission

So far, we’ve argued that prioritization should be by ROI, and while accounting for other people, should be user focused.  Actually, nothing above is sprint-specific, the same concepts apply to any product planning and development approach.

In part 2, we’ll look at defining user stories and user persona.  We’ll look at the value of each story relative to cost, and show a couple low-overhead ways to easily visualize this info – both driving scheduling and motivating the team to improve.

Is your product successful because you were lucky, or because you were methodical and intentional?

Do you want to build a plan where you are dependent on good fortune, or do you want to make your own “luck?” Both approaches work, but only one makes sense as an intention. Slide 3 of your presentation to a venture capitalist should not say “And then we get lucky!”

Product Success Is Not Easy

Saeed Khan wrote a critique recently, in On Product Management, of an article by Phil Meyers on the Tuned In blog. Phil’s article is an analysis of the pending re-organization at Starbucks, and the one quote that Saeed keyed in on was:

At the end of the day, its simple. Create a product or service that your buyers want to buy and the rest takes care of itself.

Saeed’s point is that it is not that easy. A lot of hard work goes into creating a successful product. And Saeed’s right.

Maybe Phil’s point is that the executive should not worry about the details, and trust in his team to do all the hard work. But he doesn’t really come out and say that, so we can’t really back him up on that front. Let’s give him the benefit of the doubt anyway. There’s another point that Phil makes that is potentially disturbing:

Looking at metrics like average same day sales and products per square foot lead you down some strange paths. Schultz even admitted as much in a letter from the board about a year ago in which he worried about the company ‘losing its core’.

Yes, abandoning your goals to pursue your metrics is bad. But don’t abandon your metrics to pursue your goals – unless all you want to do is get lucky.

You might argue that a company like Animoto got lucky when their product spread virally within Facebook and their user base jumped from 25,000 to 700,000 users. But if you listen to the interview that Amber MacArthur did with co-founder Brad Jefferson, you will realize that it was only when they tweaked their product offering – a response to empirical analysis of product adoption metrics – did their success explode. I would argue that they made their luck by being intentional.

Empirical Processes

When you can perfectly model your business analytically, you can measure the inputs and know (with certainty) the outputs. As a college engineering student, I learned this. Real world processes can never be perfectly modeled analytically. As a professional engineer, I learned this too. Real world processes are empirical. The secret to great engineering is to apply analytics to those empirical processes to create disruptive innovation, and combine it with empirical controls that help you statistically predict the likely outputs. The answer is simply that neither analytics nor empiricism alone can help you achieve greatness.

Business processes are also empirical in nature. Even when you can devise an analytical model for the behavior of an isolated system, you have to acknowledge that no real world system is isolated. You have to expect unexpected inputs into the system. As Saeed points out, you have to apply analyses to make smart decisions when developing your process (or business model, or product). And what Phil appears to discount is that you also need to apply empirical measurements to your process (or business or product) to control the expected results.

Creating Successful Products Intentionally

This article proposes that there are two paths to product success. The first path is simple. Cross your fingers, then get lucky. The second path is harder. Be intentional.

1. Identify your market (and therefore your customers and competition).
2. Identify their problems, and select the ones you will solve.
3. Create a product roadmap (aka a “plan”) to solve those problems.
4. Design and implement solutions to the most valuable problems.
5. Get feedback on your solutions.
6. Incorporate your feedback into your plan (step 3) and repeat.
7. Revisit your market (step 1) and the problems you choose to solve (step 2) and repeat.

Note: Step 7 should occasionally replace step 6, so that you stay focused on your market, and not just an out-of-date snapshot of what used to be important to your customers.

1. Identify Your Market

There are a lot of ways to pick a market to focus on. You can chase demographics – there sure will be a lot of retired people in the US thanks to the baby-boomers. You can go with what you know – years of paying attention to an industry presents ample opportunities to understand the market. You can create an entirely new – blue ocean – market by solving problems people don’t even realize they have until you offer a solution. Choosing a market is the subject of many books, not just an item in a list.

Once you choose a market, you need to segment the market into groups of people who share the same problems and who value solutions to those problems similarly. You can apply market research to improve your market segmentation.

2. Select The Problems You Will Solve

You use elicitation skills to identify the problems that your customers face. And when you have to address multiple market segments, you can prioritize the problems across those market segments.

3. Create a Product Roadmap

Once you’ve prioritized the problems you are going to solve, create a product roadmap. Your product roadmap should show the problems you are solving, and the order in which you will solve them. When you define sequencing, you also must define your approach to scheduling product releases.

4. Design and Implement Solutions

There are two keys to successful execution of the plan you built with your product roadmap. First – use rolling-wave planning to define near-term details and long term vagaries. Second – make sure you have continuous integration as a key component to managing quality throughout the process, instead of checking quality at the end (or even worse – ignoring quality).

5. Get Feedback on Your Solutions

This is half of why agile (when done right) works [Can you believe the discussion over the last year on this article is up to 27 comments?!]. Feedback is not just something you get when sharing a prototype with stakeholders. Feedback is also something you must get as part an incremental release methodology.

You can even measure the ROI of your designs, and incorporate feedback at the design level.

6. Incorporate Feedback Into Your Plan

There’s no point in gathering feedback if your organization and your process are organized to resist changes to the plan. Contrary to what the Standish Group’s CHAOS study has always implied [and we've made this implicit mistake too], release schedules are not the primary measure of project success. In a fantastic article at Dr. Dobb’s Journal, Scott Ambler points out that in his survey results, almost two thirds of professionals find that doing the right thing is more important than meeting a project schedule.

Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.

Do the right thing. If the right thing involves changing the schedule, that doesn’t make it wrong. What makes this work is the fact that you are getting feedback early and often. It is a risk mitigation strategy, designed to reduce the possibility that you will create an unsuccessful product. It is not a strategy designed to keep your project on schedule no matter how mis-aligned you are to your market.

7. Revisit What You Are Doing And Why

If step 6 is small-scale course correction, this is large-scale course correction. You may discover that solving a big problem for your customers exposes a new “biggest” problem that wasn’t there before. By revisiting step 2, you can choose to tackle or ignore those newly discovered problems.

You may also discover that by leveraging your investments to date, you dramatically improve the ROI of solving problems in another valuable market segment. This is because even if solutions to those problems have the same value, solutions to those problems now have much lower costs (for you). By revisiting step 1, you give yourself the opportunity to best manage your strategy, your resources, and your plans.

Conclusion

Product Success may have an element of luck, but you should never plan to hit the lottery. Be intentional in what you will do, and a good plan, executed well and adapting to change, will get you there.

Prioritization is about maximizing the value you provide to your customers. When you have multiple sets of customers with different priorities, what do you do? You could try and find the lowest-common-denominator, and please everyone a little bit. But that would be the wrong thing to do – by trying to please everyone, you fail to delight anyone.

Setting Up A Prioritization Example

To keep it simple, imagine that your market can be divided into three distinct groups. You would represent each of those three groups with a persona. While working with customers in each group you identify that each group has a distinct set of priorities. You have five capabilities you want to introduce – represented by five features. You will be able to release one capability (feature) per release. Keep it simple for now by assuming they all have the same cost and time to implement.

Each group ranks the features 1 to 5. Each group ranks them differently.

One client I worked with would create a simple spreadsheet like the one above. Each group has a column, and each feature has a row. The number in each cell is the sequence of that feature, in priority order, for each group. That client would then add an “Aggregate” column, representing the sum of the values. My client would then sort the spreadsheet from lowest to highest aggregate value.

Feature 3 would be in the first release, then feature 2, feature 1, feature 5, and finally feature 4.

Each of the three most important features for any given group is highlighted in green, with descending intensity. This makes it easy to see that (for this example data) each group gets their most valuable feature in one of the first three releases. It takes until release 4 for all three groups to have their “top 3″ implemented.

You can call this the lowest common denominator approach. Relative value is averaged out across all of the groups. Each group has an equal say in what gets released when. One problem is that each group is (almost never) exactly as important as all of the other groups.

Prioritizing Features By Customer Importance

This approach, flaws and all (we’ll come to that) could be improved by taking into account the relative importance of each group. Consider adding a weighting value for each group. That weighting might reflect the size of the market segment, the strategic value, or a combination of factors that cause one market segment to be more important than the others.

The chart above shows the same example, except now groups 1,2, and 3 have an importance measure of 10,20, and 40. The aggregate value column now incorporates that weighting. Instead of just adding up the sequence values for each feature, the values are first multiplied by the importance of their group.

Counter-Intuitive Math

You would think that since the smallest numbers come first, you might want to divide by the relative value of the groups instead of multiplying. When you aggregate the sequencing, higher numbers (lower priorities) tend to push features to the bottom of the list, and lower numbers (higher priorities) tend to pull numbers to the top of the list. If you divide by the relative importance of each group, instead of causing their inputs to bubble to the top, you end up reducing the relevance of the inputs from that group. By multiplying you make each group’s inputs relatively more significant, as the relevance of the group increases.

From the color coding, you see thta group 3′s influence is greater than either group 1 or group 2′s influence. Also note that (for this example), group 2′s most important feature is scheduled ahead of group 3′s third most important feature – even though it is also the most important capability to group 1. The aggregate value column is now sorted, using the same approach as before, but with a weighting that favors the more important group.

The Problem With This Approach

The approach looks pretty clever, and it is not horrible. What it is is mediocre. And it encourages mediocrity. First, you get mediocrity because a feature that is “kind of appreciated” by all groups will get a lower aggregate value (and therefore a higher priority) than a feature that is incredibly super critically urgent for one group but wholly uninteresting to another.

Consider feature F1. It is (because we get to make up the examples here) critically important to Group 1. It is also completely irrelevant to group 2. This is because the people in groups 1 and 2 are very different. They care about different things. Because group 2 is uninterested in feature 1, group 1 has to wait until the fourth release to get it. Bummer for those losers in group 1.

Now consider feature F5. Group 1 doesn’t care about it, and they get it in release 2. Those guys are probably sharpening pitchforks and lighting torches.

They don’t get what they really want until release 4, and you can argue that this is ok because the other groups are more important. But you haven’t set expectations well. Group 1 thinks their inputs are fed into the mix, and your roadmap is for them just as much as it is for everyone else. Turns out, this approach is not very good for setting expectations with group 1.

Another Manifestation of The Problem

Now look at the flip side. Your most important market segment, group 3, does not get what they want in sequence. To keep our example exhilarating, imagine that each shaded feature (sequence 1,2, or 3) is a “must have” for the group that ranked it. No group will go live until at least the 1,2, and 3 (shaded) features are implemented. That means that group 3 – your most important market segment – cannot go live until release 4. Group 2 can go live after release 3. But group 2 is not the most important group. You tried to satisfy the biggest, most valuable group first – and it did not work.

Why? Bad math.

You cannot use “sequencing alone” to represent the value that each feature provides to each group. For one group, maybe only the first two features have a lot of value, and the other three are all relatively worthless. You get a form back from them that shows 1 through 5. But it does not show that the value of (the features sequenced first and second are ten times the value of the other three features.

Solving the Problem With Good Math

There is a solution. But it is so much more labor intensive that most teams won’t do it. You have to determine the value of each feature to each market segment. You can’t use sequence or priority as a proxy. It has to be a number. Then you can aggregate.

The Philosophical Problem With This Prioritization Approach

There is still a philosophical problem with this approach, even if you did solve it with the right math. As we mentioned before, you are creating a mediocre – and therefore sub-optimal – solution by aggregating (and effectively averaging) the value of each feature to each group. Those features that are “kinda nice for everyone” will beat out the features that one group is really passionate about, but other groups don’t care about. If you take this approach, why bother to even define personas – you’re subconsciously ignoring those insights. Market segments are dominated by the companies that put out the killer features. It would be “killer” for some users if their car could go offroad. And killer for others if it got great mileage. Another group might really care that it is showy and fast. If you prioritized a feature that helped each of those goals somewhat (say, really good tires), how passionate would your potential customers be? The offroad guys want a roll cage. The eco-hawks want a super-efficient engine. And the “all hat no cattle” guys want a wing on the back – and it should come in yellow.

You may find that your segments are so different that you need to treat them as different markets, or at least market different products to them. Otherwise, you end up with a car that goes offroad but cannot climb a 40 degree slope, that gets 25 miles to the gallon, and, while yellow, does 0 to 60 in 7 seconds. You don’t delight anyone. How much penetration will you get in any of those markets?

Not much.

The Better Way To Prioritize

Pick your most important market. Do the most important things to them first. Then go to your next most important market. Repeat. Your prioritized road map will look like the following:

Group 3 – your most important market segment – goes live as soon as possible. After release 3. Your next most important market segment goes live next. Until you run out of features and segments. Note – make sure you continuously reprioritize. You may, for example, discover a new feature that lets you double your penetration with group 3. You should probably do that before finishing a feature targeted at group 1 – even if group 1 is not launched yet.

Conclusion

Do the most important things, for the most important markets, first. Then add the next most important thing, after you learn through your incremental release plan, even if it means delaying the launch in a lower-priority market segment, in exchange for higher returns from an already served segment.

Instead of

Prioritize the present when planning your product. Neglecting the future is almost as bad as over-emphasizing it. The key is to incorporate your plans for the future correctly by making them play second fiddle to the present needs of your market. Serve both today and tomorrow – but prioritize today.

In The Long-Run, We Are All Dead

If you’ve had any macro-economics courses, you’ve heard the phrase “…in the long run” a million times. Supply and demand balance out in the long run. Monopolies are not profit-maximizers in the long run. The yield curve is an accurate predictor of…

You get the picture.

John Keynes (of Keynesian economics fame) said:

Long run is a misleading guide to current affairs. In the long run we are all dead.

You can make financial investment decisions based on the eventual outcome that is theoretically predicted. Keynes’ point is that practically speaking, the long run is too long.

The same holds true when making product management investment decisions.

Focus On The Now

Jeff Lash wrote a really good article on my birthday about the need to plan for the present [needs] and the likely future [needs] – and to not over-emphasis the future.

Understanding the long-term implications of decisions is important, though possibilities well into the future should not overshadow more pressing short-term decisions.

Plan for the present and likely future, Jeff Lash

Jeff talks about the need to make sure you address the current market demands. Jeff warns against the risk of rejecting “good enough for now” solutions when they fail the litmus test of meeting improbably future needs.

Planning for too far into the future often happens because people are in search of the “perfect” solution. (Surprise — there is never one!) A “good enough” solution might perform well for several months or years; unfortunately, those looking for the “perfect” answer will reject what is “good enough” and insist on a solution that is usually more complicated, more complex, and more expensive.

Plan…, Jeff Lash

Plan For Tomorrow Too

Jeff raises one of the major concerns with planning for tomorrow:

Another danger in planning ahead too much is that the farther into the future you try to look, the more likely you are that your predictions will be wrong.

The right way to deal with this is not to ignore tomorrow (because it is inherently risky), but to account for that risk.

Prioritization is inherently the making of investment decisions. You prioritize the present needs of your market ahead of the future needs. On the average, that’s how it works out. But you shouldn’t arbitrarily delay future needs. How do you compare the potential value of something way out on the horizon with something more immediate? We can look to economics (and management accounting) for techniques to do this.

Equivalent Measures

In accounting, you use the notion of net present value to create equivalent measures of the value of two different investment choices. This allows you to maximize your return on investment. You do the same thing when making product management decisions.

In product management, we prioritize based on ROI. More specifically, you maximize the overall value by prioritizing deliverables by value per unit of cost. This maximization strategy front-loads the value into your development schedule. In layman’s term, you’re getting the fastest high-value returns by working first on the use cases that have the highest value-to-effort ratio. Not the use cases that have the highest value.

This is exactly the same as financial ROI maximization. The hard part for product managers is in determining the right numbers to use. Once you have numbers, the rest is easy.

Discounting For Risk

To get the right numbers, you have to estimate or assess the value of any particular capability. We deliver most effectively when we plan each release at the use-case level. You also have to estimate the cost of delivering each use case. Depending on how you run your projects, you may want to flesh out the use cases and then develop detailed work breakdown structures and cost estimates. However, you can move more quickly by using use case points to estimate the level of effort (and therefore cost). Since your estimates of value are likely to be imprecise, you can make decisions “of the same quality” using use case points as you could with detailed cost estimates.

All of this math results in approximations, so you should always use your best judgment and “sniff test” the numbers. If the numbers are telling you something that you didn’t expect, either you don’t understand your market, or you made bad assumptions about value or cost.

This approach works for comparing “everything today” features or functionality. To properly incorporate tomorrow’s use case into the prioritization, you need to discount for the risk that your value-estimate is wrong. You do that by calculating the expected value of the use case. If you estimate a 10% chance that your use case is worth $100,000, then the expected value of that use case is $10,000. The expected value is the risk adjusted value. You use that risk-adjusted value in your prioritization.

Conclusion

In the real world, Jeff’s advice is almost always right: focus on the present, not the improbable future.

With the approaches outlined above, you can make a financial argument that will usually lead you to the same conclusions. But when it doesn’t, you’ll have the data to back it up. There are times when a long-term investment (for future use) is justified, even at the expense of delivering some immediate term value. If you completely neglect long-term investments, you’ll never be a visionary leader of your market.

If you over-emphasize long-term value, your product will be dead before your market is ready to benefit from it.

Do you recognize this early logo from Amazon.com? Future Now has a great article detailing how Amazon evolved their “add to shopping cart” implementation. From reviewing this summary of the evolution of one feature, we can see that Amazon decided there was value in reinvention. The improved the way their product did something over time. Have you?

Continuous Improvement

Software developers understand the value of continuous improvement. It is a core tenet of agile development – as you do more, refactor what you’ve done so that it is better. Some people who promote agile explain that refactoring is a barrier against spaghetti code and broken windows. That is certainly true, but there’s also merit in simply making the product better.

The key is to define “better.” Refactoring as part of implementing something new comes from a simple idea – “elegance” in design includes an analysis of how well the code solves the problems it is being asked to solve. When you add new functionality, you redefine the context by which you analyze. When you extend your code base in unanticipated directions, you are likely to be reducing the elegance of your solution. So you refactor, to make sure your design is elegant given the new context for analysis.

One of the development teams we’re working with right now is proposing a rewrite of a set of utilities that are part of an enterprise architecture. A small piece in a very large puzzle. Unfortunately, their argument is that “the code is not good.” Instead of looking at their specific situation, we can ask the question – “When is there value in rewriting?”

Value In Rewriting

First, we should define rewriting. Imagine that your software is a “black box.” It accepts inputs, and provides outputs. It does some work or analysis or magic or something inside the black box – you don’t know what. When you feed it an input, it responds with an output. Our definition of rewriting for the purpose of this discussion is that the “black box” view of the product does not change. The same inputs produce the same outputs. Not faster, not prettier, not less buggy, not more scalable, nothing. No (externally) perceivable difference.

In other words, the developers are saying “let me rewrite, instead of writing new code.” New code changes the behavior of the black box – the outputs are better or faster or different, inputs are handled differently, etc. A “noticeable” change. As product managers or analysts, we’ll assume that noticeable and valuable go hand in hand. :)

Newton’s First Law of Software: Software, when unmodified, behaves the same way it always has.

What are valid reasons for changing how it is written?

• Fiat. A corporate mandate may come down, stating that all software will be written in a single language, or will run in a specific environment. These types of mandates are intended to drive economies of scale and reduce costs by inspiring teams to leverage competence and knowledge across multiple products. Microsoft Office and Apple both apply this approach in designing consistent user interfaces to their products. People familiar with one application will be able to be productive with a second application more quickly. So there is potential future benefit here.
• Cost of Change. When a product is being actively modified, there is a cost associated with making those changes. That cost is a function of how hard it is to make those changes. Making the code easier to work with does have value, in that it makes the cost of change lower. There can also be benefits here, but they are probably smaller than the value of doing something new. Until they get big. That may be the genius of refactoring as you implement new functionality. By keeping the code base “always good”, you incur small incremental refactoring costs in the context of implementing new features. The argument is that these small costs immediately pay for the next incremental refactoring due to time saved in adding functionality. It is a positive feedback loop.

It rarely makes sense to just rewrite for the sake of rewriting. If development costs represent 20% of the cost of a solution, then you need to reduce development costs by 5% for every 1% of incremental value (from redesign or new functionality) that you postpone. You can easily show that a 5% reduction in development costs “pays for itself” quickly if you operate your development team as a cost center. You should instead be operating as a profit center.

Value in Redesigning

There can be dramatically more value in redesigning a product. Redesigning is one step up from rewriting. These changes are externally visible. The software still does the same things, only it does them better. Better can mean an improved user experience, higher quality, faster responses, more accurate analyses, higher scalability, etc.

From a requirements perspective, a redesign does not change any of the functional requirements. It changes the non-functional requirements. Since non-functional requirements exist to support specific goals, a change in non-functional requirements reflects a change in value. And value drives prioritization.

You can, and should, prioritize redesigns along with adding functionality. Amazon, as the Future Now article (hat tip to Mary Schmidt’s Idea Pool) indicates, valued the repeated attention to, and redesign of the “add to cart” button on their web page. They were clearly making intentional trade-offs between strategic goals. As an example, with one design, they promoted other corporate initiatives at the expense of conversion rates (turning users/clicks into transactions).

Is Your Product Improving?

Our unscientific perception is that most software product teams are myopically focused on “what else should we do” and are forgetting “what can we do better?” It may be that you’re tackling such a large problem that “more” overwhelms “better.” But you should do the analysis.

Learning how to write use cases can be tough, but it is simple compared to the balancing act of determining which use cases to write and how to manage the expectations of all the stakeholders that are involved. It can be a difficult balancing act to prioritize use cases to assure that you meet the goals of the business while satisfying the needs of the users.

Goal Driven Use Cases

In the world of structured requirements, we apply an approach of top-down decomposition to determine what we need to build.

In an article stressing the importance of non-functional requirements, we summarized the relationships from the above diagram as follows:

• Goals are achieved by enabling use cases.
• Goals drive non-functional requirements.
• Use cases are enabled by implementing functional requirements.
• Use cases influence non-functional requirements.
• Non-Functional Requirements define the characteristics of functional requirements.
• Functional requirements drive design decisions
• Design choices are restricted by constraints
• Design choices guide implementation
• Implementation is product

Non-Functional Requirements Equal Rights Amendment

The key element, with respect to this article, is that goals are achieved by enabling use cases. In other words, without the use cases that people* perform, the goals of the business can not be achieved.

[*Sometimes the use case is performed by a system - not all actors are people]

Principal Stakeholders Own Business Goals

We learned a lot from Outside-In Software Development, by Carl Kessler and John Sweitzer. One of the important things we learned is how to understand the goals of principal stakeholders. Principal stakeholders are the “owners” of the ROI that we are attempting to achieve with our product or solution. The business has the goals, but the business is an abstract entity. If the goal of the business is to increase sales by 10%, we can’t call up the business and ask “did we meet your goal?” We have to call up the vice president of sales. The business is organized so that there are people who are responsible for the initiatives and goals of the business – they are responsible for growth, profitability, costs, strategy. The insight we got from Kessler and Sweitzer is an appreciation that this ownership lies with one or more individuals.

When a goal has an owner, we can validate that we have met the goal. We can validate that we have satisfied the owner of the goal. You can’t do that validation with an abstract entity, a “business”, but you can with a person. Certainly, we can do the math ourselves, but if we want someone to pay the bills – and more importantly – invite us back to do more projects, we have to satisfy an individual. And that individual is our principal stakeholder.

Principals Own Use Cases

Our principal stakeholder owns the business goal – and therefore owns the use cases that enable that goal to be achieved. Our stakeholder will validate the completeness of our use cases by answering the question, “If we enable all of these use cases, will we completely meet your goal?”

End Users Own Use Cases

User-centered design is also one of our core principles, and an acknowledged best-practice. For many companies, it is more than mandatory – it is a way of life. The entire software development process is sometimes built around a focus on the end users. This approach puts the user in the center.

You can identify end user goals with the following approach:

1. Identify the actors that interact with the software.
2. Identify the personas that represent those actors – thus avoiding the elastic user syndrome.
3. Develop an understanding of the personal goals of the personas – and by extension, the actors through ethnographic research.

Stakeholder Goals: Principal vs. End User

This creates what appears to be a conflict – do principals own the use cases, or do end users own the use cases?

Mixing Interaction Design With Structured Requirements

One approach to resolving this conflict is to eliminate it by mixing interaction design with structured requirements. In this approach, the interaction design component applies end user ownership as an input to the design, but not the content of the use cases, as the following diagram shows:

In the diagram above, the changes (relative to the Wiegers process) are marked in blue.

The interaction design process starts with two parallel activities. On the left is the identification of corporate goals, which is analogous to the creation of an MRD. An MRD can be a reasonable mechanism for documenting the corporate goals. It provides more detail than “Increase profits” with statements like “Increase profits with improved pricing.” On the right side is the creation of personas to represent the most important users.

Interaction Design and Structured Requirements

This approach side-steps the issue by relegating the end users to “design input” and not allowing them to contribute to prioritization and management. For many applications, this is a great way to approach things. Specifically, it works very well when the user’s goals are tightly coupled or highly aligned with the principal stakeholder’s goals.

When Goals Conflict

User goals are not always aligned with stakeholder goals. In our earlier article on identifying these conflicts, we proposed a simple grid view for identifying these conflicts.

In that article, we looked at situations where the goals of the actor were primarily aligned with those of the principal stakeholder, and therefore the business. We discussed using the grid to inspire solutions that removed the conflicts. Two birds with one stone would be the easiest way to summarize.

What about when goals are implicitly in conflict – or even diametrically opposed? We’ve worked on systems where that is exactly the case. Consider a two-tier sales model, and products / websites designed for the people in the second tier.

Two-Tier Sales Models

Here are some common business models where the users have goals that are directly in opposition to the goals of the principal stakeholders.

• Automotive Manufacturer and Dealer. A website, designed by a car manufacturer, to allow dealers to improve their ability to sell cars. The automotive manufacturer makes money by selling cars to the end customer, and the dealer makes money by causing the sale to happen. The manufacturer is compensated by profits on the sale, whereas the dealer is compensated simply by making the sale. In other words, the dealer is motivated to lower the price because a sale at any price generates the same profit for the dealer. The manufacturer is motivated to raise the price because fewer sales at a higher margin generate the same profit, but higher ROA (return on assets) than more sales at a lower margin. This is an implicit conflict.
• Book Publisher and Book Retailer. A book publisher sets a price for sale to the retailer, and a suggested (list) price to the end customer. The retailer will typically pay a negotiated discount, in the form of a percentage off list, for the book. Any books not sold by the retailer are returned to the publisher or (usually) destroyed. The retailer does not have to pay for books that are not sold. The retailer has limited shelf-space, and makes money based upon a combination of the size of the discount and the number of books that are sold, regardless of publisher. The retailer is therefore incented to increase the discount, and thus increase profits for a particular title – and the publisher is incented to reduce the discount, and thus increase the profits for a particular title. Since the list prices are fixed, the retailer negotiates the discount, and as leverage over the publisher, gets to influence the placement of the book within the store. Each publisher is forced to compete with other publishers. These goals are also in conflict.
• High-Tech Equipment Manufacturer and Value-Added Reseller. A value-added reseller (VAR) provides solutions to end customers. They do this by combining products from manufacturers, and adding value – in the form of planning, custom engineering, installation services, etc. The VAR will negotiate a price with the end customer for a solution. The typical VAR sells products from multiple high-tech companies. The VAR will negotiate with the manufacturers to get the lowest possible prices from the manufacturers. The manufacturer wants the end-customer price (when it includes their equipment) to be as low as possible – to increase the number of sales that are made. The manufacturer gets the same profit (based on the price to the VAR) regardless of the end-customer price. Every dollar that the end-customer saves, the VAR loses in profit. The VAR makes profit on the difference between price-to-the-VAR and the final selling price. The VAR will also want to drive down the price it pays to the manufacturer. Reducing the price-to-the-VAR transfers profits directly from the manufacturer to the VAR. These goals are diametrically opposed.

When goals are in conflict like this, we can’t just relegate the “end user” goals to design inputs – we have to incorporate them into the prioritization process. In these examples, the “end users” are the VAR, the book retailer, and the automotive dealer.

Imagine that the high-tech equipment manufacturer sells networking hardware. The manufacturer has an internal (direct) sales force, as well as the VAR channel (indirect) sales force. The manufacturer identifies tools that help sales reps to close deals. Large purchases are commonly made at as much as 80% off list price. The list prices are irrelevant – they are not even guidelines in many cases. So the manufacturer develops tools to help sales reps know what prices to set for end customers.

Internal sales reps have generally well-aligned goals with principal stakeholders. The sales rep will be compensated based on a combination of revenue (sales) and margin (profits). This compensation model creates implicit alignment between the user goals (get a bonus) and the company goals (make profitable sales).

One approach to helping the sales rep close profitable deals is to share an indication of the profitability of the deal with the rep. The rep can (will!) set a price that is designed to maximize the sales rep’s bonus. If the compensation system is well designed – this is also optimal for the business, and therefore the principal stakeholder. The sales rep will get increased compensation for raising the price (and still closing the deal) by getting a percentage of the increase in margin. The sales rep is motivated to increase the manufacturer’s profits.

The VAR, however, should not know the profitability of a particular transaction. The VAR is motivated to lower the price (the price to the VAR) as much as possible – even at the expense of losing a “profitability bonus.” If the VAR is given a percentage of the increased margin (to the manufacturer) it comes at the cost of losing 100% of the change in price to the VAR. Remember, the VAR makes money on the difference between the price from the manufacturer, and the price to the customer.

Depending on the manufacturer’s business model, this could lower the priority of a margin-inspection capability, or dramatically raise the priority of features that restrict margin-viewing to only internal sales reps.

Also remember that the manufacturer and the VAR also have aligned goals – like closing the deal. And the VAR can close the deal with the manufacturer, or with products from a competitor. So the manufacturer is incented to provide valuable functionality to the VAR. The manufacturer cannot ignore the VAR’s needs, or the VAR will work with a competitor and the manufacturer will lose all the business.

You have to determine the value to the principal stakeholder of the value of the feature to the end user. In other words – even if a feature “hurts” the manufacturer, is the pain “worth it” because of the value of the relationship and expected future business that the company will do with the VAR?

Once the value of all of the functionality is identified, you can prioritize it. An enlightening way to visualize this value is with a value-delivery matrix. Thanks again to Roger Burlton for inspiring our approach to prioritizing based upon a combination of pain and gain.

Roger Burlton, of the Process Renewal Group, gave an excellent presentation Monday morning at the 10th annual International Business Rules Group: Developing a Business Process Architecture and Program of Change. A lot of good stuff about how to define, develop, and manage processes. One idea in his presentation was particularly compelling – that of driving process improvement strategy based on stakeholders. This approach looks at how much benefit the stakeholders can get from the improvement, and how much pain the current process causes them. A very compelling strategic prioritization tool.

Thanks Roger Burlton!

Thanks Roger, both for sharing your thoughts with us at the IBRF conference, and for giving me permission to write about this technique. We’ve adapted it a little bit. You can see a pure example from one of Roger’s presentations online (slides 15 – 17). Click on the “Other Resources” link from the Process Renewal Group’s main page, and select Implementation: The Payoff from Architecture and Program Management.  If you would like to follow up with Roger about this or any of his other works, he’s asked me to share his email address here rburlton@processrenewal.com.
We’ve simplified the example grids to show fewer processes, written out an explanation built from Roger’s (verbal) presentation, and introduced the notion of utility as a means to prioritize. The base idea comes entirely from Roger.

Stakeholders

Roger’s technique is a straightforward one – like all good ideas, it is obvious in a “I can’t believe I didn’t think of it” way. In short, you find the processes that are the most valuable to the most influential stakeholders – and you improve those processes first.

This analysis focuses on principal stakeholders. The goal of this analysis is to encourage your principal stakeholders, or sponsors, to prioritize the most valuable processes first. Not all stakeholders are created equal, so you have to weight the relative importance of each stakeholder. You can weight them politically, by influence, or by whatever factor is most likely to get buy-in from the executives.

Determining Value

Value, in this analysis, is a combination of pain and gain. To begin this analysis, you have to define the processes under consideration. You should have already done this as part of defining the scope of the project – and Roger showed us some compelling techniques for defining and managing the scope of the project. For each process, you perform two analyses.

• How much gain does each stakeholder stand to get from improvement of the current process?

For each process, for each stakeholder, identify if the gain from the proposed process improvements would be small (1), medium (2), or large (3). Use whatever normalizing scale you like – the key is to be simple, consistent, and directionally correct. You don’t need to have a detailed benefit analysis for each process.

You’re trying to prioritize, early on, which processes to work on.

• How much pain does each stakeholder feel due to the shortcomings of the current process?

Perform another analysis for each process and each stakeholder. This time identify the relative level of pain felt by each stakeholder, due to the inadequacies of the process. Use the same numbering scheme: low (1), medium (2), and high (3). The key is to be relatively consistent in your approach to assessing pain. It does not need to be an econometric assessment of risks and penalties, or a detailed model of lost opportunity and revenue. The goal is to approximate “how bad is it?”

Note that the “Combined Gain” and “Combined Pain” rows show the (stakeholder) weight-adjusted sums of the relative gain and pain levels. Each process then gets a ranking on the “most potential gain” and “most induced pain” scales. When you have a tie, remember to skip the next number when calculating rank. (e.g. if two processes in the example above had a combined pain score of 5, then they would both have a rank of 3 – and process #1 would have a rank of 5).

Pain Meets Gain

Next, create a graph with pain ranking along the vertical axis, and gain ranking along the horizontal axis. Plot each process on the graph. The processes in this example would look like the following:

There is a reasonable distribution of potential value for this example. Value is a proxy for utility when viewing this graph.

Intro To Utility Curves

If you were to overlay utility curves on the diagram, you would see that some processes are more valuable than others.

These utility curves also help us visualize the discontinuities in the diagram. Processes 2, 5, and 1 are more valuable than processes 3 and 4, which are more valuable than processes 6, 7, and 8 (not shown in the grids above).

Prioritizing Processes

Given the relative values of each process, as demonstrated with the utility curves, we can break up the staging – or prioritization – of the work to clearly convey which processes should be improved first.

And then we can also see which processes to prioritize for the second iteration.

As we complete the first set of processes, we should re-prioritize. Like all projects, we are aiming at moving targets. The second phase may not include processes 3 and 4. Our improvements to processes 1, 2, and 5 may not have been very effective – there may still be a lot of pain and gain to justify refactoring them again. However, there is value in communicating our plan as we know it today to the executives.

Processes 6, 7, and 8 may never get re-engineered. Since there is relatively little pain (impetus for change) or gain (value available from known changes), there may always be a better way to invest our resources.

Conclusion

Getting agreement from executives about what to do, or more practically, what to do first can be very difficult. By presenting a view like this to executives, you make it very easy for them to make decisions. And following Roger’s lead – you have the opportunity to convince them that it was their idea all along, and you only facilitated the plan.

I am a big fan of boxes and arrows, but this time, Jeffrey Davidson found a great article by Dan Willis before I did, and told me about it. Thanks Jeffrey! The article is about how to deal with the what and how of requirements and design – and it provides some really sage advice. But what got my attention was the lack of prioritization of requirements in his example.

One Man’s Trash

Dan’s article is about the difference between what and how. He provides good advice on changing the conversation to be what-centric, not how-centric. Dan is writing from the perspective of an information architect, and he defines what and how as follows:

As I started to work in jobs where some people communicated with one another using requirements, it seemed reasonable to keep separating “the what” from “the how.” These two definitions are the result:

• Business requirements: What the project, system, or solution needs to accomplish.
• Functional requirements: From a high level, how the project, system, or solution needs to accomplish what it needs to accomplish.

Are Useful Requirements Just A Fairy Tale? (and why an IA should care)

Although we used slightly different language, we wrote an article about how different people in the software development life cycle think about different artifacts created in the process. The following diagram sums it up:

Requirements Documents – One Man’s Trash…

Dan describes the product management view of the world in his article. It is a good article, and you should read it – his pragmatic solutions to common frustrations are good ones. They center around turning the conversation (with product managers) into one of What do you need? instead of How do you think I should build something?.

Prioritization Hell

As good as his article is about the frustration of mis-matched roles, here’s the paragraph that really got my attention:

First, you get a group of stakeholders in a room so they can “blue-sky brainstorm” to figure out how they want to improve their product. The group comes up with a list that has everything from “Make the little blue buttons bigger” to “Bring world peace.” The list goes to an engineering team who organizes the list into three categories: Things we can do now, things we can do by the end of the year, and things that will take a long time. They email the categorized list to a project manager who changes the categories to Phase 1, Phase 2, and Phase 3 and sets up a project schedule for the first 10 things in the Phase 1 list.

Dan Willis

Aargh!

This is why prioritization matters.

You should always prioritize the capabilities that yield the highest returns on your investments. Those returns may be based upon a measurement of risk, a strategy for gaining market share, or straightforward cost reductions. You can also refine this approach by applying the principles of Kano analysis to maintain a user-focus. You may need to balance the goals of users with those of stakeholders. But definitely don’t let someone prioritize features based on how long they take to implement.

Dan, we feel your pain!

Microsoft has a product called Zune that is a competitor to the Apple iPod. They just recently announced their second release – the new version of the Zune. Since Apple already dominates that market, Microsoft qualifies as a follower – how are they approaching the introduction of a new product to compete with an 800 lb. gorilla?

The iPod Product Family

There are several different iPods in the market, each targeting a different subset of the mobile entertainment market. Apple has audio and video players with different form factors, designed for different usage patterns. Those different designs have resulted in a feature-based market segmentation. That isn’t really a good way to think about the market – you should think about how the devices are used, not how many songs they hold. Nonetheless, when measuring the market, people look at the features as a means to segment.

Microsoft’s Early Approach

The product manager for Zune gave an interview on Windows Weekly – a TWiT network podcast with Paul Thurrott – several months ago. The product manager mentioned that they were targeting the Zune to achieve 10% of the 30 GB audio player market. I may be mis-remembering the details, but at the time I thought it was an oddly narrow target. The product manager wouldn’t talk in much detail, understandably, about the upcoming features that were planned for the next Zune. In the interview, they discussed how quickly the Zune came out.

At the time, I thought “OK, we’ll see what they have for the next Zune,” and I moved on.

The New Zune

The second generation of the Zune was just released, with new models and features. I read a commentary somewhere that said you’ll recognize the pricing model, because it is the same as the iPod. The Zune has models that are competitively priced with the iPod Classic products.

Tom Merritt, on Buzz Out Loud, commented that he understands the Zune strategy – first, come out with a player that is not as good as an iPod – then in the next release, make it “just as good” as the iPod. The third release will be better than the iPod, and the fourth one will be an iPod killer. He argued that Microsoft used a similar approach with Internet Explorer. Tom’s comments caused me to remember the earlier interview with the Zune’s product manager.

A Good Strategy?

This may be an excellent strategy. The ultimate success of the Zune will probably be influenced more by Microsoft’s ability to market the product than the relative merits of the Zune when compared with the iPod – but we can still learn from it. Here’s a generalized recipe that can be extracted from what Microsoft has done. Keep in mind that this is a strategy for entering a red ocean market, already dominated by a market leader.

1. First, segment the market. Pick one segment, and deliver a product that has only the must have features for that segment. This is your first release
2. Second, improve the product, delivering enough more is better features, and some surprise and delight features – for that segment. Release again.
3. Third, differentiate your product, so that it is more desirable to that segment than your competitor. Release again.
4. Finally, start tackling additional market segments.

Segmenting

Segmenting the market makes a lot of sense – Microsoft doesn’t have to be all things to all people. They don’t have to match all of the features of the iPod. They only have to match the features that are relevant to that market segment. Enough to start to compete. And with incremental improvements, they can potentially take over that segment.

Iterative Development

Having a smaller target allows Microsoft to not only release a first-version of the Zune with fewer features, it allows them to release more quickly. They don’t (yet) have to worry about a portfolio strategy – they can target a single user segment, and focus on delighting them. With enough distinctive capabilities, they can potentially differentiate their product from the competition.

Here’s a fairly harsh (and valid) critique of the first generation Zune, in comparison with the iPod. What the article doesn’t do is look at the strategy we’ve defined – it evaluates revision 1 against the “end game”, and the Zune comes up short. That’s a risk of introducing an initial “not a winner” product. But how much money are you losing if you wait until you think you can win before releasing the first one? Don’t get caught in a blender, segment your market analysis.
Every situation is different – you have to balance perception versus early sales. Will a first-gen product hurt future sales if it isn’t “ready to win?” If so, then you shouldn’t release it. But if it is a winner for some, or at least a competitor, it may make sense. I don’t think Microsoft will have trouble overcoming a poor reputation for the first release of the Zune. I wasn’t paying attention at the time, but I’ve heard Tom Merritt and others allude to how “crappy” the first iPod was. Doesn’t seem to bother anyone now.

Moving Targets

Apple will certainly present a moving target in the iPod by adding new features or improving existing ones. Microsoft will have to either predict and match the new features – in an endless battle of keeping up with the Jones’, or they will have to introduce new features that cause Apple to respond. Apple has “first mover advantage” and dominates the market. But Microsoft has a “second mover advantage” – they are able to learn from Apple’s investments in earlier products too.

There are two examples of features that show both Apple and Microsoft trying to redefine the “must haves” for the market. Apple just released the iPod Touch – an iPod with a touch-screen interface. And the interface is indeed very slick (I played with one over the weekend). People (in the targeted market segments) might decide that this is a significant differentiator, or they might not. The jury is still out.

Microsoft introduced the ability to squirt a song from one Zune to another. This “social networking” element would ideally allow people to share music, temporarily, with other people – who would then buy the music for themselves. There was a painful joke that the only squirting that was happening was on the Microsoft campus in Redmond, because that was the only place you were likely to get close enough to another Zune owner to squirt anything. Aside for that, the songs were over-protected with DRM (digital rights management, aka copy protection). A squirted song could only be played three times, and had a limited shelf-life. Once either limit was reached, the song was deleted from the recipient’s Zune. With the new version of the Zune, the calendar-based shelf-life has been removed (although you are still limited to X plays of the song).

We’re looking forward to watching both products evolve in the battle. Consumers win when there’s competition like this – so for now, even as a happy iPod shuffle owner, I’m rooting for the underdog. Yes, there is irony in calling Microsoft an underdog.

Different Business Models

There may also be advantages for Microsoft in having a different business model for their music player. Apple has certainly benefited from the iPod to iTunes to Apple computer “closed platform” linkage. While iTunes is available for non-apple computers, there is an implied linkage, and analysts believe a causal relationship that drives Apple computer purchases by iPod owners.

Microsoft is probably just trying to be a player in a profitable market.If you want to look at market share analysis for the Zune and iPod, and for PCs and Macs, read this article, instead of relying on the hazy data above. Those guys are way better at it than we are, and there’s a lot of conflicting data out there – this article seems very credible.

Conclusion

This article really isn’t a prescriptive one, as much as it is an exposure of a strategy writ large – pick a segment of the market, release iteratively, and attempt to displace the 800 lb gorilla. We’ll see if it works.