Startups and Customer Feedback
When startups receive (hopefully) lots of customer feedback and suggestions on product improvements/features they wish to add, how do you go about deciding which suggestion/feedback to implement on first?
I just finished taping the future courses on Lean Startup and Design Thinking, which help with some of your questions, so let’s go deeper in a few weeks. For now, a few thoughts:
I want to start with the observation that customer feedback is hard. Customers often say they want things they do not in fact use. Other times they do things and you do not know why. You generally want a data gathering approach that is both quantitative and observational (what are the customers actually doing) and qualitative (what do they say they want and why, even if their actual actions betray what they say).
How you prioritize is where the art of running a startup often comes into practice, and it will vary depending on where your company is in its life cycle. Your product management function (which may just be you in the beginning) will constantly prioritize the development tasks based upon the entirety of circumstances (more on this in the Agile lesson).
Especially in the beginning, you want to validate your riskiest assumptions. Would someone use this feature at all? Could I build it? Can it scale? Your growth and value hypotheses are crucial. Once you have some traction, you want to test the metrics that matter most by stage and business model (again, a whole lesson coming up). In some cases, that metric is retention, so customer cancellations (i.e., “churn”) is crucial. In other cases it might be the viral growth coefficient.
You usually divide features for your MVP into must haves, performance features, and delight features. Depending on what you wish to test (often the delight features), you prioritize those. If you always prioritize building what will validate the metric that matters most or the assumption which is most crucial at the moment, you will rarely go too wrong.
Once your product is more mature, you often end up having a triage system and a system of progressing to new versions. Major bug fixes, of course, usually come first. You want to be in a continuous deployment cycle, constantly testing and building business cases for your new features. When you are testing, you ideally will be getting customer feedback from the actual customer actions (are they cancelling, are they recommending it to friends, etc.) and their subjective feedback (surveys, interviews, etc.)
Random new suggestions for features often throw a wrench into your product roadmap, which is why you need to listen. Sometimes customers alert you to market gaps or features which are better than your original ideas. Other times, they are too narrow or misguided. I think this point leads to your second question, as it relates to how you assess and measure an opportunity for a new feature or product.
Does the quantity (ie. a lot of customers saying I want this feature to be added) matter over quality (this is a huge pain point and win but only solves for a few customers)? I’d assume the time to implement these features/suggestions matter as well?
The measurement of the satisfaction/importance gap is crucial. I have a nice set of graphs to illustrate this point visually in the Creating Lean class. Ideally, you want something important to customers and with a largely unsatisfied need. I do not recommend building a new product for a satisfied market (usually a commodity play) or for a small subset of users (a niche play). Of course, it is never so simple as a clean graph. You also have to look at return on investment to build a product, which can include the price a customer would pay, the revenue model (recurring or one time, for example), the likelihood you can own that market (through a patent or some other exclusionary technique), and whether you could build it cheaply and quickly enough to matter. If a core niche customer demographic is willing to pay $100,000 a year in licensing fees, the new product might be worth it, especially if you can do it quickly and own the market. If you see the need, others likely do also, so timing is crucial. Early MVPs will help you assess the viability of both your market and willingness of customers to pay.
See also: 1.102: Creating Lean and 1.103: Design and Data
Responses