No two ways about it.
Customer development – working out what will meet the needs and solve the problems of your target users – is not straightforward.
The temptation can be to make your best guess and then proceed headlong, relying on strength of purpose, social virtue and blind faith to get you to the point where you (hopefully) have a product that people want to use, can use and actually changes their lives.
But that’s a whole load of hoping and guessing. Do it this way and you’re likely to fail. There are better ways. This article explains why you should challenge your product assumptions. In my next article I’ll then explain how to do it.
Right now, each of the Labs projects is exploring how to answer two key questions:
- What do people really want?
- What are we really building?
One of the best starting points for answering these questions is to bring your product assumptions into awareness and then challenge them. There’s a particular process you can use to do this. I’ll address this in part 2 but for now lets explore what it means to challenge assumptions about your product.
What is Challenging Assumptions?
It’s a way of thinking critically about your underlying assumptions and then testing them in a systematic way. It’s a better alternative to just asking people what they want and doing design by consultation. It’s also a better alternative to employing one or two young people in your development process and expecting it to work just because they are involved in this way (we still think it’s a good idea, but on its own it’s not a recipe for success).
Challenging assumptions invites you to take your empathy, understanding and ideas of what young people might want and test them. In the testing you then learn what they want. In the words of Christopher Bason “it starts by not accepting the project’s premises… … by challenging the underlying assumptions, our heritage, our current solutions and mindsets, and even the current tools and professions involved in tackling the problem… Allowing time, focus, and collaborative effort to address the underlying assumptions is different from the way most projects are implemented.”
Here’s some examples of underlying assumptions
- Young people will use our product because we think it’s a good product
- Services will pay for our product because its socially motivated
- Advertising revenue will be enough to sustain our product
- The kind of advertisers we want will be the kind that want to advertise with us
- Young people will use our product because it’s technically superior
- Customers will agree with our perception that the product is “great”
- The product will market and “sell” itself
- Other services will be desperate to recommend our product to users
- We can develop the product on time and on budget
- Its innovative so its unique and won’t face any competition
Why do it
At the moment the likelihood is that you’re guessing what people want and how they want it. You have a hypothesis based on a series of assumptions about the wants, needs, opportunities and limitations experienced by young people and your product idea.
You need to validate your assumptions before spending too much time or money going down one particular solution. And you need to prioritise which assumptions to challenge or you’ll be wasting time validating your assumptions.
If you don’t spend time upfront understanding your customer and their needs then you’re likely to build the wrong thing. I did this with my first advocacy website for young people with mental health issues. It looked original and cool but was difficult to navigate, because I hadn’t understood their needs for easy to find information. We sorted this a year later but by then we’d overspent and lost time.
Sixteen25 have just avoided the possibility of this happening with Keep the Trust, as Yvonne Anderson explains:
Keep the Trust will be a mental health training site for non-mental health practitioners. We initially planned to create a site that curated free existing third-party mental health training content. This was based on the assumptions that people wanted the existing content, did not know where to find it, and that some of them would be prepared to pay for it. Our assumed solution was to put all the content references and reviews into one website.
However, after deciding to take a lean approach to developing Keep the Trust, we realised that our assumptions were based on zero evidence that:
- Existing content is relevant to what people actually wanted now (most existing content predates 2011 and was dictated by Government agendas on what people should learn)
- Existing content is difficult to find
- Existing content has stable hosting and will remain accessible
- People would be prepared to pay for a means of accessing it
Based on this realisation our team decided that rather than testing these assumptions by finding out people’s views on existing content it would be better to find out what non-mental health professionals want and then create it. Within this the team will be testing the assumption that professionals would prefer smaller, bite sized pieces of learning.
Bringing it All Together
Spending time early on working out, challenging and testing your assumptions dramatically increases your chance of building the right product for the right people.
Next up on the Labs Blog: how to test your assumptions.