My goal in any product development effort is to get an iteration in front of users as quickly as possible so I can see real users interact with it and respond to their emerging needs. The quicker I can build that first MVP, the sooner the feedback loop of engaging with users can take over. Over time, I have developed my own personal theory of product prioritization and backlog building that I will use this space to outline. It has helped me quickly build a product backlog and then apply market validation concepts to find the first MVP.

I have had the benefit to hear from a lot of great teachers on product prioritization. Two concepts, one from agile and one from traditional waterfall, stuck together in my head and said “well, that could be really helpful”. These two ideas are Story Mapping and Kano. From those two methodologies I started to experiment with my real backlog and using problem interviews as a basis, found a great way to build customer empathy into prioritization. This is the result.

This is a long post because I have outlined several different product management theories at a high level. Feel free to skip around if you are already familiar with these theories. See the bottom of this post for more resources on these concepts. I’m going to break these into two major phases: Backlog Building and Prioritization

Backlog Building

Problem Interview

Before you can really start prioritizing a list of features you have to understand the customers pains and gains.  In other words, problem understanding must come before solution prioritization. According to Lean, the goal is to develop customer empathy around their jobs to be done so you can build out a list of products and services that aid them in those jobs.  There are a wide range of methods to do this but its best to start with one of the lowest cost methods: problem interviews.

I really love problem interviews because they provide a great structure to have a conversation with customers focused on them within the framework of a specific problem space.  The goal of a problem interview is to talk through a specific customer job to be done to understand all the pains and gains.  A problem interview should never include suggest a solution, testing out pricing, or making a pitch.  Multiple problem interviews across multiple customer segments are necessary to fully understand a complete problem space. 

An effective problem interview happens in three parts:

• Setting the stage: Establish the goal of the conversation, determine demographic information and how they measure success.
• Uncover the problems: Talk through the current situation, identify their pain points, discuss how they are solving the situation today.
• Wrapping up and next steps: Summarize what was discussed, ask permission to follow up, document results.

The most important thing to remember during a problem interview is your role is to listen and build empathy, not to offer solutions.  After a number of problem interviews you can go through your notes and find commonalities.  These become the basis for defining the products and services you will build.

Story Mapping

Okay, so you understand the customers’ needs now you need to organize it into a coherent set of features. This is where story mapping helps you out. Basically what you do is organize your personas and the jobs to be done you learned about in your problem interviews at the top of a board. Then flesh out the features that address those jobs to be done. Often I will spend some up front time creating a basic backbone of the features that I believe we need. Then I invite the development team and we work jointly to break those features into stories. As a group we will also add features. It looks something like this when it’s all done:

I recommend spending some time with Jeff Patton’s book here to fully build out this but it should feel like any other backlog building exercise, just a lot more visual and explicit. This process will take time and it’s worth it because it will simplify all the decision making you have to make moving forward.

Prioritization

Okay, we have a backlog, now how do we know how to prioritize it? There are a lot of prioritization methods and they generally fall somewhere on a spectrum between statistical analysis and instinct. Regardless of what method you use, it is essential to make your assumption visible. Even purely statistical models have assumptions built in.

I generally prefer an approach that is in the middle of these two extremes called Simplified Kano. To understand how we simplify Kano we first need to understand the Kano model.

Kano

Kano is a method of turning client’s stated pains and gains into statistical data for setting feature priorities.  Like most models of this sort, the first goal is to make the assumptions underlying decision making visible and then apply market and user intimacy to rank priorities.  The process starts by surveying users on a series of features trying to discover two things:

1. Would you even consider a solution that did not include this?  E.g. it is a must have.
2. If a solution had this would it amaze and motivate you?  E.g. it is an exciter.

Since Kano is a survey method it relies on statistically significant sampling and carefully phasing of questions to not sway the respondents.  The survey method itself is not a good way to find you customer’s pains or gains or build the backlog.  A process like problem interviews needs to be applied first.

You start by having customers rate different features against these two motivators by having them rate their feelings about having and not having the feature as one of the following:

• I like it
• I expect it
• I am neutral to it
• I can tolerate it
• I dislike it

With all that data you can then place the feature into one of five categories:

Categories here that affect prioritization are Must-Have, Performance, and Attractive. Must-Have items should be prioritized first because customers will not look at a solution without them. Performance comes second. These are features that will start to define your key differentiators. Attractive features help with differentiation but not as much as performance features.

Reverse features are interesting, you want to actively avoid these based on survey results. Often, though, I find that both these and the faulty results features require more conversation with customers about those specific features.

You can also use some more advanced statistical analysis to plot out the features including rank ordering, but I will not get into that here.  Our goal today is to understand the model.

Simplifying Kano

Kano is a great if you have a large customer base that actively participates in surveys to provide a statistically significant sample.  I have rarely had the luxury of large enough user base or time for statistical analysis.  Here, Simplified Kano comes to the rescue.  Again, this method can not replace the upfront work of getting out of the building (whether literally or figuratively) and talking to your users.  If anything, this method relies heavily on you, and your organization, building that client intimacy habit.

If you have that client intimacy habit, however, Simplified Kano can prevent overburdening your customers with surveys and requests for interviews. I have occasionally seen engaging with customers tip over into customers feeling they are taking the lead in your product development! Not a good place to be with a customer.

Another weakness of Kano is that it only represents the customer perspective. There is another perspective that can heavily impact prioritization: the developers. Building based solely on what the customer’s want may unintentionally leave out foundational or risk mitigation features customer’s expect but can’t articulate. These are features like compliance with regulations or preventing data hygiene issues that can ruin a business.

So how do you do this?

Invite anyone in your organization that can present the customer perspective into the space where you have your story map laid out on a wall. Give them two sets of colored stickies and ask them to dot vote on which stories would be expected by customers or excite customers. Then do the same thing with your developers with the questions of what stories are foundational or mitigate risk. It is important to ask the customer perspective first. The result looks something like this:

I often find that the client perspective leans towards exciters because it is harder for both clients and the folks in your organization that represent them to focus on the mundane. On the other extreme, the developer perspective tends to lean more heavily to risk mitigation.

At this point it is the Product Manager/Owner’s job to review all those marks and add their own if they feel like anything needs adjustment.

Bringing it Together

Okay, now here is the magic sauce that allows you to find your first thin cut. It’s important to remember a thin cut of a product is to get features in front of users so you can start getting feedback. So in your initial release you should almost never have all the stories associated with a feature. As users start giving you feedback, the stories lower in the stack will change.

Reorganize the cards with marks on them. Any cards with a customer perspective of ‘expected’ plus any developer marks goes to the top of the column. Then any cards with a ‘exciter’ plus developer mark. Then any developer marks and finally the rest of the customer perspective. Why do I lean so heavily on the developer perspective? Because I have always built software in an enterprise environment with significant regulations. A startup or less regulated software would prioritize customer features over risk mitigation.

Then you get to draw a line. This is the time to also talk about how big stories may be so you can get a sense of the level of effort your MVP will require and adjust your line as needed. Depending on the characteristic of your organization and how many votes you give your participants you may end up with really large MVP that will need to be further broken down. The result looks something like this.

Now go forth and build great software!

Resources:

As always, I want to acknowledging others’ work that has inspired my own thinking.

• Agile Product Owner training through Agile for All by Peter Saddington about a method he called Simplified Kano.
• Kano as described by the wonderful Folding Burritos Guide to the Kano Model which is not for the weak of heart.
• Jeff Patton at a DSM Agile conference and his book on a method he calls Story Mapping.
• Eric Ries’ The Lean Startup gives a good overview of different build customer empathy and test customer segments.
• O’Reilly Running Lean is also a good resource for learning the basics of lean.
• A great overview of Problem Interviews, and specifically fending off the intrusion of sales attempts into the problem interview.
• Customer canvas including pains, gains and jobs to be done from Strategyzer.