For the past couple of months, Richard Warner and I have been working with a number of teams to help them better work together. Each of the teams contains a Product Manager, UX Researcher(s), UX Designer(s), and Big Data Analysts who are working in an Agile manner.
Last week Richard and I sat down to work through one of the problems we are facing. A number of teams are using some kind of “Agile Canvas” derived from the start up community. It was our feeling that these canvases are driving the wrong behaviour in the teams. The most popular canvas with our teams is the one taught by Roman Pilcher.
You start with a strategic statement of intent. Then you list the Target Group (Customer Segment/Market), Needs, Product, and finally value. As Richard and I were chewing this over, we realised that although this was a great canvas for a start up, it lead to the wrong behaviour for enterprises. Value is an after thought. For a start up, you establish your product in the market and then think about revenue models, which often means being bought out by another more established company (The Instagram approach). As an established enterprise, this is a risky approach as you may develop a product that is not sustainable. If you pull the product, your customer will stop trusting you which will impact your existing business. At this point we decided to use “Break the Model” from Feature Injection to model the different order in which you perform the tasks. We realised that there are a number of different valid paths you would take based on the nature of the insight driving your discovery process.
We realised that a design hypothesis that we test potentially contains a number of sub-hypotheses.
A design hypothesis needs to contain each of these sub-hypotheses. However the order in which you build up the design does not matter as long as the Feature/Design is the last thing you consider.
Richard and I looked at all the different combinations of order in which you could create the design hypothesis.
So here is our working hypothesis. Depending on your insight, you need first to establish the outcome, market and needs. Once you have these three, they form the design brief for the UX designer to design the “feature”.
The feature should always be the last part of the hypothesis. If you start with a “request for a feature”, this should be regarded as an insight (tea-bag). If we end with the outcome, customer or needs, they will likely be ignored. If you end with the outcome, you may be subject to reputational risk if you have to pull the feature because it is not sustainable (not a problem for startups who are looking for an IPO exit). If you end with the customer, you will not know who should like the feature and who should not. You may lose an important customer segment without realising it. If you end with the need, you may deliver a product that nobody wants, like Segway or Betamax. Betamax was higher quality but did not satisfy the need of fitting a movie on a single tape.
The PM is responsible for establishing the correct outcome. Data Analysts and UX Research are responsible for providing insights and customer segmentation (market). The PM/UX Rearcher/Data Analyst and UX Designer “pair” to identify the customer segment and associated insight that is most likely to deliver the outcome. From the insights, they create hypotheses about the customer needs to be satisfied. Note that sometimes, the process starts with an outcome, sometimes with a need, and sometimes with a customer segment. It should never start with feature. If the starting point is a request for a feature, this should be treated as an insight.
The combination of Outcome, Customer Segment (Persona) and Needs form the design brief. e.g. In order to increase blah, as a blah, my need is blah. ( A Job Story ). There may be several job stories. e.g. The need to learn quickly at the expenses of a slower process, and the need to learn slower in order to have a faster process. Each design brief may result in several designs.
It is the responsibility of the PM and UX Researcher to confirm whether the designs have achieved the design brief. The designs can then go through Melissa Perri’s “Bad Idea Terminator” process. We start with the fastest and cheapest ways to invalidate a hypothesis, gradually moving on to more expensive methods. (e.g. Team/Expert review, Usability Testing, then MVT, and finally full production)
As soon as we get a UX design, we can create the Given-When-Then scenarios to describe it’s behaviour.
This process will help us split the design (Epic) into several Epics. Once we have the Epics with GWT scenarios, we can easily slice them into user stories.
At this point it is pretty easy to identify the APIs (services) needed to deliver the application.
This whole process is summarised as follows:
Richard and I are looking for feedback on where we got it wrong. 🙂
The IT Risk Manager 
March 14th, 2015 at 12:41 pm
Hi this is a great article.
I have not used an Agile canvas before. Looking at the Value box, it seems to be focused on value to the company, as opposed to value in terms of what the customer values. Have I got that right?
March 14th, 2015 at 1:46 pm
The outcome is the value to the company. Satisfying the needs of the customer generates value for the customer and as a result they change their behaviour so that the company achieves its outcome.
March 14th, 2015 at 10:01 pm
Hi Simon. Yes, that’s correct.
The Value to the customer is represented by their Need. When working through this we found that UX Research always preceded this part.
Of course the “Customer” is not homogenous so we use the Customer section to explicitly detail who these needs apply to and for whom we are building these hypotheses.
March 16th, 2015 at 11:51 am
Thanks Chris, it was interesting to see your thought process there. You may be interested to know an interesting quirk in your handwriting: where you wrote “cust”, I often mis-read the “s” as an “n” making a very different word. Surprisingly, there was no loss of precision or understanding 🙂
April 14th, 2015 at 2:29 am
Chris, nice post. One thing stands out to me, more as a means of sparking a question.
You mentioned part of the way through the post “The combination of Outcome, Customer Segment (Persona) and Needs form the design brief. e.g. In order to increase blah, as a blah, my need is blah. ( A Job Story ).”
I’ve seen some writing on the idea of Job Story as a replacement for user stories. I’m curious, based on practice rather than theory, do you find yourself using job stories all the time now in lieu of user stories, or do you find one form works best in certain context compared to others.
Thanks.
April 14th, 2015 at 8:32 am
Hi Kent
One of our UX Designers is a big fan of job stories. The others are less bothered. I included job stories for completeness.
Only time will tell whether job story becomes a dominant format like the Connextra format (“As a… I want… So that…”). One point against it is that it is quite subtle and not that easy to remember whereas the Connextra format’s strength is it is obvious and easy to remember.
The job story format is more focused on customer segment and user needs than the “Design brief of Outcome, Segment and Needs”. i.e. It does not focus on the outcome desired by the organisation. Not surprising as it is a UX tool.
What everyone is taking about are “Jobs to be done” by Hayden Christiansen (The Innovator’s Dilemma guy). The idea that that people have a job to be done, and the same product can be hired to do more than one job. e.g. A thirsty person needs a tea bag to make a cup of tea. A hungry person needs a tea bag to stain the curry.
Does this answer your questions?
April 14th, 2015 at 3:26 pm
Umm… not exactly. I’m familiar with Job Stories and their derivation from Jobs to be done after reading some of the writings about it. In fact, for a while I was trying to find a way that the Jobs to be done idea could be applied practically in a project setting, but didn’t have anything going on at the time where I could try it out, so I tabled that thought. When I saw the Job Story idea come up I thought maybe someone had the same thought and had tried it out.
Thing is most of the writings have a slight feel of the “new cool thing” and I wanted to get a pragmatic assessment of whether they were actually helpful, or people were using them because user stories are so last decade.
From reading your response, I assume (but would like to clarify) that your team is using them because one of the UX designers is a fan, though everyone else is fairly “meh” about them and haven’t seen a huge lift.
This isn’t surprising because I found that format in general isn’t as necessarily as important as the shared understanding it drives. I can see where the Job Story formulation drives a different understanding of context and was wondering whether folks found it more helpful in some, well, contexts, than others.
July 6th, 2015 at 9:01 am
[…] To explain the squiggles in the diagrams below, here’s the full version of the Product Management process that Chris Matts and I arrived at: […]
July 21st, 2015 at 9:26 am
Hi,
Great post and methodology. Do you have any example showing how you fill the information in “Customer”, “Need” and “Outcome”? For me, without seeing it sounds too close to a user story: As … I want to … so that I …
Thanks!
July 27th, 2015 at 3:56 pm
Hi Maria
Sorry for the delay, I was on holiday last week. Thank you for your question.
There are similarities to the Connextra formet “As a.. I want… So that…”, however there are key differences. The So that is easily incorporated. Instead of a customer, we are looking at a segment of customer with a particular need. The big difference is the “I want” versus the need. The need described in the article would be the need the customer segment has whereas the “I Want” in the story format describes a solution.
For example. We identify that beach users (Segment) have a need for getting warm (need) and if we satisfy that need, they will give use money (outcome). The user story would be As a beach user I want a cup of tea so that I will give money to the cafe.
The key point we are trying to get across is separate the need from the solution.Clearly articulate the need ( get warm ) from the solution ( cup of tea ). This leaves open the option for other solutions e.g. ( blankets, jumpers, bon fires ) etc. This approach helps you find more options and allows the process to be transparent and manageable.
Does this help?
Chris
April 12th, 2018 at 4:00 pm
[…] you need first to establish the outcome, market and needs. Once you have these three, they form the design brief for the UX designer to design the […]