Yesterday I met with entrepreneurs on opposite ends of the spectrum but united by a shared question: What should I do next?
The first entrepreneur was firmly in the “have an idea/trying to make it good” stage, involving a pretty substantial physical consumer product plus intelligent sensing software. The second was in the “$10 million in revenue/need more paths for growth” phase, capturing big enterprise deals (good!) but failing to acquire new customers in less than a nine-month sales cycle (bad!).
Like the question that united them, the answer was the same: get in the trenches and discover what customers value through customer discovery work.
Good discovery is straightforward: a lightweight way to test ideas that optimizes for learning and validates value using the customers’ perspective. But too often, customer discovery work is overly siloed, not executed with an open mind, and too focused on technical feasibility. While the latter is important, market-facing questions are now as big – or sometimes bigger – than the technical ones. If you’re not asking questions like, “Would you value a solution like this coming from us?” or “Who else in the market claims to provide similar value?” or “Will you trust us?” at the same time you’re probing functional product value, then you’re missing half of the equation.
In the case of the earlier stage entrepreneur, she needed to probe more on value before building a physical prototype. Asking if customers would choose to spend money on her fitness solution over other wellness-oriented products they already spend on would yield some really valuable, product-shaping intel.
The later stage entrepreneur needed more focus on what his customers valued most, not the broad range of functionality his product already had: “Of these five things I showed you, can you stack rank which you value most?“ “What would get you to say ‘Wow!’?”
I see this same challenge – not effectively using the discovery process method – cropping up in our portfolio all the time. Our friends at SVPG have written about Product Discovery in depth, which is why we asked them to do a Product Learning Lab to unpack these and other important product management fundamentals. These are the takeaways:
Customer Discovery & De-Risking Product Investments
- Separate discovery from delivery. Discovery is pushing more on ideas and experiments that yield solutions with validated VALUE for customers. Evidence that you’re doing this well is having many ideas you’ve thrown away, not just optimized. Optimize for velocity of learning.
- True customer discovery means assessing risks before you build. Most ‘MVPs’ are too heavy-weight. Be lighter weight in prototyping. Focus more on if people will buy it, use it, and do so from YOUR COMPANY. Remember, none of you are in a category alone. Someone will always claim they can do something similar or better.
- Increase frequency of customer contact. Best modern practice is a minimum of three customer touches a week and deploying continuous customer discovery (versus only validating before you build). There are plenty of tools that let people get in front of users, but there is also no substitute for getting out of the building and seeing customers using your products in their daily lives. Context impacts perception of value.
- Six is a magic number. The minimum number of “earlyvangelists.” The minimum number of people outside the building to give a directional signal on an idea (you don’t need tons!).
Organizing for Innovation
- Ideal ratios for product teams: 1 PM, 1 designer, 1-10 engineers (4-6 is average) + fractional time from PMMs, data analysts. Consider if you’re a little underinvested in design; they are often who drives discovery ideation, which is why this often doesn’t happen enough in B2B companies.
- Measure teams by outcomes not outputs. Outcomes are tied to business metrics ex: “reduce costs while maintaining engagement” or “drive a step-function revenue increase from our core product” or “customer can deploy Poc in <5 min and >90% automated test coverage” OKRs should be done at the team level, which means they are de facto cross-functional.
- Product managers need to be customer experts. When they first start, product leaders should have 15 to 30 customer conversations as a baseline. If they don’t know more about your customers than you do, they need to get out of the building more.
- Don’t ship your org chart to customers. Your product is an experience to your customers. They don’t know (or care) who does what, so make sure the experience is designed and shipped holistically.
- Early stage: lots of work will need to be done (design, data, product marketing) where you won’t have a dedicated person. You need to examine your org structure and having dedicated roles when you hit ~15 to 18 engineers. Without the rest of the org growing along with eng, then you won’t have the customer value-validation engine in place essential to build great product.
- Scaling stage: this is where coaching and culture + articulated product vision become critical tools. It’s essential for everyone to stay aligned and for teams to make good independent decisions. You’re trying to capture problems upstream, not when they hit customers.
- How do you know your team structure is working? There are decreased interdependencies being managed. Teams feel empowered and morale is strong.
- There is now a robust toolset for product managers. We had a comprehensive review of tools in every product category. Modern tools now let you segment feature usage by retention and total account value, so you can know with data what the customers who you retain and pay the most value the most. The days of guessing are gone!
As we told our companies, we are thrilled to hear about what teams choose not to do and what they learned from all their customer contact. What constitutes value is completely contextualized by what matters to your customers (not your investors!). So do more to get out there and find out what your customers care about!