Why I haven’t found a more accurate way of capturing user needs than Tony Ulwick’s Outcome Statements?

I usually write my posts in the weekend, but since I spent a large part of my day today in translating a lot of unstructured customer requests into articulated job stories, I succumbed to the urge of writing a quick post about it. Writing clarifies a lot of things in your own mind just as teaching does. Also, sharing it in public with fellow product people gets me a lot of feedback and the ideas are refined for the better.

In a recent interview (at 4:00 min) Satya Nadella said, “The purpose of our business is to meet unmet, unarticulated needs of our customers”. The moment I heard that sentence, it rang a bell in me. Our customers are not great at explaining us their needs. Even if you ask your customers, they might not be able to articulate their needs accurately. That is exactly why Satya uses the phrase, “unarticulated needs”. It is we as product managers (value creationists) who need to immerse ourselves into our customers world and identify their real unmet needs and pain points.

Now, if customers are not good at articulating their needs, what should you do about capturing them accurately?

What has worked for me well is translating customers unarticulated, unstructured need into a structured format. I learnt this format from Tony Ulwick from his very popular book, What Customers Want.

I also had the privilege of attending a workshop by Tony Ulwick himself at Munich here in Germany, which solidified some of those theories I had picked from his book.

Outcome Statements

During my product discovery efforts, I engage in a lot of qualitative research. As I collect all the information, I structure their needs in the following format that includes four parameters:

• Direction of improvement: Whether to minimize or increase?

• A unit of measurement: What is it that we are trying to minimize or increase?

• Outcome desired: What they’re trying to get done and why ?

• Contextual clarifier: What is the context in which the job occurs — circumstances, constraints, and barriers?

Structure provides a consistent definition of job success

You might think this is over-analysis and wondering if it is worth the pain. Well these were my thoughts too initially, but over time I found them immensely useful to understand and solve the right problem.

Conforming to a specific structure and following a set of stringent rules helps because if there are differences in structure, terminology, and syntax from statement to statement, it can introduce unwanted sources of variability that alter the importance and satisfaction ratings customers give the statements.

• Direction of improvement and unit of measurement: This provides you the direction of success. This also helps you clarify the KPI of your need. For example, if an outcome states, “minimize my effort to do something”, you can actually measure the success of the feature by measuring if the effort was minimized eventually. The requisite KPI is embedded within the outcome statement. Hence, it brings a lot of focus, clarity and direction to solve the problem accurately.

Here is an example of how I applied the structure in outcomes within my product:

Helps define the scope of feature

What this also helps you with is, it can define the scope of your feature. If you have been a product manager for sometime, you would realize that a feature can have unlimited scope. It needs a lot of discipline to limit the scope, promise to build less and still deliver maximum impact.

This is what I do to accurately define the scope of my feature. I list out all the outcomes statements in the format explained above and ask my customers to rate it on importance and satisfaction scores on a Lickert scale of 1 to 5.

The opportunity score is calculated as Importance + (Importance — Satisfaction).

The more important the need is for the customer and the less satisfied he is, the greater is the opportunity for value creation.

This score helps us in prioritizing the outcomes and you can make an informed choice of which outcomes you want to achieve first and ignore the rest.

Sometimes, to keep things simple, I just ask customers to rate only on importance.

Does these job stories interfere with user stories?

No they don’t. Job stories (outcome statements) are written during discovery phase when you are doing user research and understanding the customer problems.

User stories are written much later for the scrum team to develop the features.

Please let me know if this made sense to you and also provide feedback. Also let me know if you apply this to your work.

Also let me know if you have a better way to capture user needs.

Here’s a picture with Tony Ulwick at his workshop in Munich.