The primary reason why startups fail isn’t because of poor product development, but because we waste time, money, and effort building the wrong product. In other words we don’t fail to develop the product but customers for the product.
Even though building a product is the purpose of a startup, product development actually gets in the way of learning about customers. This is a little counter-intuitive, but the classic product-centric approach front-loads some customer involvement during the requirements-gathering phase but leaves most of the customer validation until after the product is released.
There is a time when the startup disengages from customers for weeks or months while they build and test their solution. While they are learning a lot about product development, we stop learning about customers. It is during this time, that the startup is vulnerable to either building too much or being led astray from building what customers want.
This is the fundamental dilemma described by Steve Blank in The Four Steps to the Epiphany, in which he offers a process for building a continuous customer feedback loop throughout the product development cycle that he terms ‘Customer Development.’
Even though customers hold all the answers, you simply cannot ask them what they want, as Henry Ford said, If I had asked people what they wanted, they would have said faster horses. A lot of people cite the preceding quote and declare it hopeless to talk to customers. But hidden in this quote is a customer problem statement: had customers said faster horses, they would really have been asking for something faster than their existing alternative, which happened to be horses.
A startup is an experiment, it’s about following a hunch that you’ve identified a problem or an unserved need in the market, but does your proposed solution provide a good product-market fit? Like any experiment, you need to test your assumptions and use the results to validate your learning, before committing significant investment.
The customer development framework developed by Steve Blank is an integral part of the Lean Startup methodology, used to test underlying assumptions and the business model. The approach suggests you keep your initial product scope small – a Minimum Viable Product (‘MVP’) – and develop for the few, not the many. The call to action - ‘get out of the building’ - drives you to test face to face with target/potential users and customers.
The objective of customer development is to test your MVP in search of product/market fit - your MVP is a process, besides being a product - to discover and validate that you have identified the market for your product, built the right product features that solve customer needs, tested the correct methods for acquiring and converting customers, and deployed the right resources to scale the business.
The aim is to understand the problem, testing your hypothesis about the problem you are solving, not pushing your product. Feedback from these tests from your target audience will enable you to learn and iterate, and ultimately improve your product.
It’s not about collecting facts, but gaining insight into your target customers and market. You need data, you are looking for pattern recognition and validated learning – you need sufficient data points to provide insight, to gain an accurate and deep intuitive understanding. Ultimately, the aim is to ‘pivot’, from the feedback and achieve product-market fit with version 1.0 minimum feature set.
Given the right context, customers can clearly articulate their problems, but it’s your job to come up with the solution – as Steve Job said, it’s not the customer’s job to know what they want. Customer development isn’t simply talking to customers but a collection of learning tactics that when deployed correctly yields the fastest way to both learn and build what customers want.
So, what are the best tactics to secure the most productive customer development interviews?
One person at a time Focus groups are a group-think, distraction-filled mess. Avoid them and only talk to one person at a time.
Know your goals and questions ahead of time Have your assumptions and thus learning goals prioritised. Decide who you want to talk to and target interviewees accordingly. Prep your basic flow and list of questions. You might veer off the plan to follow your nose, which is great, but go in prepared.
Separate behaviour and feedback in discussions Decide up front if your focus is going to be on learning user behaviour and mind-set, or getting direct feedback or usability insights on a product. Do not mix the two in the discussion or things will get distorted.
Get psyched to hear things you don’t want to hear If you don’t do this, you might find yourself convincing your interviewee, or even hearing what you want to hear. This is called ‘confirmation bias’ and we are all very susceptible to it. Your goal should be learning.
Disarm ‘politeness’ People are trained not to call your baby ugly. You need to make them feel safe to do this. Ask them up-front to be brutally honest, and that this is the very best way they can help you. Explain that the worst thing that could happen is to build something people didn’t care about.
Ask open-ended questions Sometimes it is hard not to ask a yes/no question, but always follow up with an open-ended question like ‘why?’ or ‘tell me more about that experience’.
Focus on actual behaviour, not speculative or abstract feelings People are not very good at predicting their actions, or knowing what they want. Your job is not to ask the person for the solution, but to figure out the best solution, and then validate that your solution is actually right.
People like to talk about features and solutions. When you are in learning mode, don’t let that dominate the conversation. Try to keep things factual. Get them to tell you stories about how they previously experienced a problem, if they tried to solve it (or why not), and what happened. Get them to tell you stories about using other products that are in the same domain space.
Listen, don’t talk Try to listen as much as possible, keep your questions short and unbiased - don’t embed the answer you want to hear into the question. Don’t rush to fill the silence when the customer pauses, because they might be thinking or have more to say. Make sure you are learning, not selling.
Follow your nose and drill down Anytime something provides a new insight you’ve not heard before, drill down with follow up questions. Don’t be afraid to ask for clarifications and the ‘why’ behind the ‘what’.
Replay back to confirm For important topics, try repeating back what the person said. You can occasionally get one of two interesting results through this. In the first, they correct you because you’ve misinterpreted what they said. In the second, by hearing their own thoughts, they’ll actually realise that their true opinion is slightly different, and they will give you a second, more sophisticated answer. After the meeting, reflection and look for patterns and apply judgement.
Customer development interviews will not give you statistically significant data, but they will give you insights based on patterns. They can be very tricky to interpret, because what people say is not always what they do. You need to use your judgement to read between the lines, read body language, to try to understand context and agendas, and to filter out biases.
However, it is the opportunity to sit face-to-face in front of a potential user of customer and use human judgement based on human connection that make interviews much more useful than surveys. Ultimately, you are better off moving fast and making decisions from credible patterns than dithering about in analysis paralysis.