The Proper Uses of Speed in Product Discovery
tl;dr:
- Product discovery is a search process through a many-dimensional possibility space
- Dimensions of that possibility space encompass customer needs and potential solution capabilities
- Product/market fit is the successful discovery of an area of high "fit" in the possibility space, where solution capabilities and customer needs cluster together tightly
- I would now define capabilities as the possible features, and you're actually only exploring a solution mix
- "Customer needs" is the "market" part of product/market fit. I wouldn't think of customer needs as exploring a similar space. Why?
- Customer needs are bound up in actual customer markets, of which there are few.
- We have to discover the needs of a particular market, but that discovery is not the same thing as iterating through all possible combinations. Rather, it's just Talking to Customers and understanding the needs of a particular group.
- Finally, we can only truly test fit by delivering the actual product (even a crappy first version of it) to the customer.
- Lightweight tests of product/market fit like Selling The Product Before You Build It and Interactive Mockups can help, but they have a margin of error. Regard the feedback from those systems as ultimately untrustworthy.
- There are different strategies for searching the space more rapidly and the deployment of those strategies is critical for the most effective search
- The best way to go fast is to appropriately deploy search strategies
- "Speed of action" and "moving quickly" is useful at the tactical level once appropriate strategies have been deployed
Mathematically, you can think of product discovery as solving a global optimization problem. You need an "algorithm" that will prevent you from landing on a local maximum.
"Basic research" and "invention" is like creating previously un-explorable capability dimensions.
Silicon Valley product discovery methods don't generally invent anything - they are a set of tools for rapid exploration of what is currently possible to find valuable, yet-unexplored (but not unreachable) areas of the space.
Strategies
Learn by building/launching
- This is equivalent to brute force exploration.
- You can only build where you've already done some exploration - you have access to a certain amount of the map based on your past learnings and experience. You can only choose to "build" or "launch" within known areas that are somewhat explored. (This is similar to known knowns, known unknowns, and unknown unknowns).
- Building/launching is expensive and time-consuming.
- But it's very high fidelity. The answers you get will be near approximations of what full solution delivery within a space would be.
- Lots of tactics here:
- MVP
- "Wizard of Oz" prototype
- Billboard test
- Pre-sell a solution
Look at past failures - the Elephant graveyard
- People who have explored this space in the past have a partial map. You can explore more rapidly by learning what they learned.
- Downside is their map may be outdated.
- They may have learned the wrong things from their failure.
- But this is a low-cost, effective way to do a quick "sketch" of the general possibility space.
- Pay special attention to the search strategies they deployed and the breadth of their search of the space!
- Did they build one thing, have it fail, then declare it dead?
- Look for "what sunk my battleship questions?"
Customer Discovery
- Talking to customers, the right way, can lead to a quick map of the "customer need" dimensions.
- Actually - no it doesn't.
- Measuring a customer pain scale and customer needs can help with hypothesis formation for which solution sets would be likely.
- More importantly, it helps you know whether a problem is painful enough for a customer to try to solve it.
- Better mousetraps aren't better enough?
- This is enormously effective because it effectively reduces dimensionality of the space. This results in an exponential reduction in total search time.
- Lots of tactics here, some better, some worse:
- Mom test
- Customer Pain Scale Ranking
- Wilcox's customer development questions
- "Don't talk about your solution!" / magic wand fallacy
- Dogfooding (I am the customer; what would I want?)
Competitor Research
- Competitors have a partial map of the space.
Risks and Mitigations
- Can help to limit areas of the map that are strictly off-limits because they're too risky
- Can help to understand constraints when exploring certain areas (mitigations we'd have to have in place)
- This is almost like exploring the materials of the areas of the map. For example, "searching over here would be like driving through mud - super slow and dirty."
Hypothesis-Driven Development
- Use the scientific method to construct experiments based on what areas still need to be searched
- This is equivalent to looking at the map as it currently stands, and devising a test that would help you explore a large area of the map at once. For example, think of the idea of "binary search" along a dimension - is it more like A or B? This cuts a single dimension in half.
The Proper Uses of Speed
Ok, I promised to talk about speed in the context of product discovery, but so far I've only talked about strategies. Whence speed?
A few take-aways:
- The fastest way to explore a space is to quickly employ lightweight strategies that search large areas of the possibility space quickly.
- "How can we go faster?" is an extremely useful question at the level of tactics. How can we design a faster test for this? How can we build a smaller MVP that gives us the same learning? How can we get high-quality information from more customers more quickly?
"Can we launch this in half the time?" is the wrong question when it comes to product discovery.
"How can we most quickly and effectively search/test the solution space?" is the appropriate framing. And that question can yield unbelievable speed. When speed is confused for lots of activity or "time to launch", speed becomes detrimental.
If you prioritize tactical speed over everything else, it will dictate which strategies you pursue (with the potential of not thinking in terms of strategies at all), which will ironically slow down your search and potentially guarantee that you won't discover an answer.
Speed and timeboxing
Another way of thinking about speed and product discovery is how valuable the solution would be if we figured it out.
Low value solutions should probably have a tighter overall timebox (spend no more than 2 weeks on this), which would then dictate the strategies chosen, and those would drive tactics. Note that a smaller timebox necessarily means less exploration of the possibility space.
High value solutions (things that would change the company) may be worth investing more time (you have up to N months), which would then lead to a different set/ordering of strategies with different tactics employed. This could lead to a larger explored area and a higher likelihood of finding a good solution, and potentially a better solution (not getting trapped on a local maxima).
Do Things That Don't Scale
- Interestingly, "Do things that don't scale" is a mantra for focusing learnings on getting the right solution configuration without having to worry about operational / scaling challenges at first.
- Focuses on early learnings.
- You do have to learn to scale or operationalize a solution, but scaling characteristics are dependent on the solution set.
- Focusing on scaling too early is wasted learning
- See Premature scaling can stunt system iteration