Ubiquity Extended Team member Veronica Pinchin shares how startups can find and hone product market fit through employing several customer development/product management techniques she's learned over the last decade in product at Google, Mixpanel, Sidewalk
Welcome, everyone, to our Ubiquity University session on the path to product-market fit. Ubiquity Ventures is a pre-seed and seed-stage firm investing in software beyond the screen. That means that we back entrepreneurs that are moving software beyond the screen and computers into the real physical world, often using smart hardware and machine learning. Today, we're lucky to have Ubiquity extended team member Veronica Pinchin to talk us through the path to product-market fit. Veronica, please take it away.
Thanks, Sunil. So today, I'm going to be talking about how to build a product that achieves product-market fit. So before we get started, I've been working in product management for about a decade now, and I find it's always helpful to return to the simple statement that product management is putting customers at the center of everything that you do. So today, I'm gonna talk about how to leverage this philosophy to build towards the holy grail for young startups, which is product-market fit. To quickly define product-market fit, I'm stealing this often cited definition from a Marc Andreessen blog post from a while back. That is, "Product-market fit means being in a good market with a product that can satisfy that market." Marc then goes on to describe what that feels like. And I'm not gonna read this whole quote aloud, but the gist of it is, you can always feel when product-market fit is happening, and you can also feel when it isn't happening. So if product-market fit is the goal, let's put that in context. I stole this slide from a article that I read from Nikhyl Singhal, who's a VP of Product at Meta and former CPO of Credit Karma. But I think it's a pretty common illustration of the different phases of a company, and I think it's important because I think that the role of product management really changes at these four phases of a company or a product. And today, we're gonna focus on the role of product management during that product-market fit stage where you really have maybe a seed of an idea, you have a prototype, maybe you have a couple customers, and you're really trying to find something that really achieves product-market fit. And diving into that, I'm going to talk about the role of product management during that product-market fit stage in three sections, problem, product, and playbook. I like alliteration. We're gonna start with the problem.
So first of all, and this is actually true no matter what stage of a product or company you're in, you need to really live and breathe the problems that your customers are facing. So what this means is a couple things. It means you need to understand the problem better than they understand it themselves. You need to understand the competition, how the competition is trying to solve the problem. And you need to develop a perspective on how you are going to solve the problem differently than other companies or products in the market. And once you have a deep, deep understanding of the problem that you're solving and the clients that you're solving it for, you're gonna use that problem as the core of your product vision.
And no matter what stage you're in as a product or a company, as a product manager, it's really important to define a clear product vision for a couple of reasons. First of all, it helps to align the goals and actions that you take with the problem and things that you believe. It provides a framework for decision-making that you and your team can use to make decisions more effectively and quickly. It inspires and motivates your team. It also attracts customers and investors who share your vision and believe in the problem that you're solving. And it helps differentiate your company from its competitors. And so that's kind of why you wanna build a product vision. And in terms of what it should include, your product vision should really be centered around that problem that you're solving. It should identify who you're solving it for. And it should also identify how your approach is different. Now, a couple things to call out or things to keep in mind as you're building your product vision as a product manager, the first thing, and I can't say this enough times, is to really focus on the customer problem that you're solving. I think a very common mistake that PMs, founders, companies make is falling in love with a particular solution, I've actually done this myself, and spending too much time or cycles on something that's ultimately not going to work. I think the second thing to keep in mind in setting your product vision is that the market always wins. So what's really important is that the problem that you're solving, the vision that you articulate, is going after a market that is both big enough to be interesting, and where the competitive forces at play, it will actually allow you to establish a foothold and grow in that market. And then finally, you need to know an approach that's different. You basically need to differentiate yourself.
So here, the best startups and products I believe have a slightly contrarian view to solving a problem, so they're solving a problem differently than other folks in the market. There's lots of great examples we can look to here. One that I love actually is Airbnb, who, when they first launched, everyone thought they were completely insane, that people would never want to rent out their homes, bedrooms, et cetera. And they had a very different and contrarian view of what staying in a city or belonging in a place might look like, and it actually allowed them to totally disrupt the hotel industry before really anyone was even taking them seriously.
So there's no one right way to write a product vision, but this is a template that proliferates around the internet, so I included it here just to kind of look at for some helpful framing. I think that this is kind of one way that you can take the problem that you're solving and articulate it in a really clear way that allows you to be very specific about what you're solving, who you're solving it for, and why you're different. And this is a very detailed version of a product vision. You can also boil this down into something much shorter that actually allows you to bring to life who you are as a company and product in a way that resonates with customers. And so here, I have some product visions from companies that you've probably heard of. And if you are articulating your product or company vision well, a customer or a client should actually be able to identify who you are just from your vision. So going through these one at a time, I think it's helpful to try and guess what company you think this might be. So a company whose vision is to accelerate the world's transition to sustainable energy by designing, manufacturing, and selling high-quality vehicles and energy storage products. That's Tesla. Next, blazingly fast email built for high-performance teams. This is a smaller, lesser-known company, but if you know them, you probably guessed this. Superhuman. And finally, and slightly more abstract, to create a world where anyone can belong anywhere. Airbnb. Okay, so at this point, let's say you have a problem worth solving in a market that you believe is worth going after, and you've articulated it in the form of a product vision that your team is excited about.
So how do you go from that problem and that vision to an actual physical solution or product that your customers love and are willing to pay for? Well, answer's easy. You go back to this slide and mantra from the very beginning of all things, product management, which is putting customers at the center of everything you do. And at this stage, when you're going from a problem to a solution, honestly, no matter what stage your company is in, that means optimizing and iterating towards customer love. So I actually think this Paul Graham quote summarizes it well for an early startup, and what this quote says is that when you launch, there have to be at least some users who really need what you're building. Not customers who just think it would be kind of nice or convenient, but people who really urgently need the thing. And usually, this group of users you're going after is going to be pretty small, and there's a easy reason, simple reason, for that. It's because if there was a large number of people who needed something this urgently and you could build it with the amount of resources that a small startup has, chances are someone else would have built it already. And so what this really means is that it's better to make something that a small number of people want a large amount rather than something that a large number of people want a small amount.
And so if your goal is really to identify these customers who deeply need and want your product and to really earn their love, how do you actually identify you're on the right track? Luckily, there's actually a way to measure that. So what you wanna do at this stage is really measure customer love, and there's a lot of different ways to do this. Gmail actually is a great example, where Gmail's initial goal internally at Google was to get to 100 happy Googlers before rolling out broadly to external clients. Turns out Googlers are extremely hard to make happy. This was a very high bar. And ultimately, by meeting that bar, I think the legend goes, and I think Eric Schmidt might have actually been the one who challenged them to that, that actually allowed them to build a product that had product-market fit. Other ones that I think are commonly used are NPS, or churn, which is an inverse love metric. But the one that I'm actually gonna focus on for the next couple slides, because I think it's less well known and has some interesting benefits, is this percent of customers that would be very disappointed if they couldn't use your product. And the reason that I wanna focus on this one is because I think it's one of the few metrics that you can actually use as a leading indicator to very rapidly understand how you're achieving product-market fit. And so this metric is actually originally coined by Sean Ellis, who ran Growth in the early days of Dropbox and Eventbrite. And what he did is he actually asked users, "How would you feel if you could no longer use the product?" And he measured the percentage that answered very disappointed. And after benchmarking nearly 100 startups with that question, Ellis found that the magic number was 40%. Companies that struggled to find growth almost always had less than 40% of users respond very disappointed to that question, whereas companies with strong traction almost always exceeded that threshold. And so the idea is that you can send the survey to customers, ask them that question, and see what comes back.
So let's assume that this is what comes back. What you're gonna do now is you're gonna actually use the results from that survey to both focus on the customers that you're building for and also to build your roadmap. And so how are you gonna do that? First, you are going to ignore the customers completely who would not be disappointed at all if they couldn't use your product. These customers are gonna be very hard to win. They may have different needs than your actual bullseye priority segment. And they're going to basically muddle your roadmap with features that you don't need to build. Next, you're gonna take the clients who really love the product and would be very disappointed if they could no longer use the product. You're gonna get a list of all the things that they want and the features that they need, and you're gonna build more of that. And then finally, and most kind of interestingly, and probably the hardest part, is taking the percent of users that would be somewhat disappointed and figuring out which sub-segments of that group are winnable, and basically try to convert those users to becoming very disappointed by building the products and features that they're asking for. And so what you're gonna do is you're gonna end up splitting your roadmap between building features for the very disappointed group in order to deepen their love and maintain your product moat. And you're gonna build for the somewhat disappointed sub-segments that you think are winnable, with the goal of making them very disappointed.
And so let's say you have a group of five things or a set of five things that your very disappointed users want, and a set of five things that you're somewhat disappointed users want. You still have to sequence and prioritize those. And in terms of how to do that, I find an impact and effort chart, it's kind of one of the oldest, you know, tools in the book, but I find it to be very simple and effective. So you're gonna take the things that those two segments of customers are asking for, plot them on an impact and effort chart, and very simply, do the easy things first. So if you're gonna start with high impact, high effort, then do actually the low impact, low effort. And the reason that you're gonna focus on the low-effort things is because at this this point, the goal in my experience and opinion is really speed. And so by doing anything that's high effort, you're gonna actually slow down that iteration and learning process. Over time, you might start to consider the high-impact and high-effort items, but at this point, you really wanna just continue to generate feature ideas and move as quickly as possible to getting something that actually wins customer love.
And so before I move on, actually, I just talked about a product-market fit framework and a way of building a roadmap that really ruthlessly iterates towards winning and growing a set of loyal customers that love you. I don't think you've actually fully achieved product-market fit unless you've also figured out a way to monetize those users and also validated that the number of users in that market is actually big enough to be interesting. I've already talked about the kind of market dynamics piece a little bit, but in terms of just the profitability of the customers, I think very simply, it's helpful to look at this and basically make sure that the value of a new user is bigger than the acquisition cost of bringing that user in. And so I believe that if you basically, if this is true, if your value of each new user's greater than your acquisition cost, and also more than 40% of your users would be very disappointed that they couldn't use the product, and you have a market that you've proven is interesting, you are basically at the point where you've achieved product-market fit and you are on your way to building a large and thriving business.
And so last but not least, you now, you've articulated your product vision, you have your roadmap of prioritized features. As a product manager, one of your jobs, obviously, is to execute quickly and iterate towards a great product and actually ship product features. So how do you do that? To be honest, this presentation could be a whole separate module, and there's tons of resources out there on how to effectively be a product manager and manage product development. So I'm going to keep it very simple and high level and just call out the things that I think are the most important in each of these three stages.
Prototyping, which is just building something to test. Learning, which is where you test it and learn how users react. And then iterating. I'm just gonna walk through each one of these. So things to remember, in my opinion, in the prototyping stage. So first of all, doing non-scalable things. So paper prototypes. Figma click-throughs. Manually doing things that you might automate in the future, even if it's on, you know, pen and paper or manually in the backend. People physically calling, for example.
Second, building an end-to-end playtest as fast as possible. The graphic on the right tries to illustrate this. And I think playtest actually comes from board games or video games where the idea is that it's the first, it's an end-to-end experience that actually allows someone to play the game, so rather, being fast to build your onboarding experience and then fast to build, you know, an action you can take in the product. You actually wanna be fast to building the first end-to-end version, so actually building a scooter or a bike as opposed to just building the wheels and the chassis first in the illustration on the right. All of this also comes down to optimizing for speed to learning. So I think aggressive deadlines really help here, not over-complicating things. And then finally, not falling in love with your idea or product. This is a hard one. And so just because you like an idea or you think it'll work, if it doesn't look like it's working, at this point, you should consider it disposable and not get stuck in a sunk-cost fallacy.
Next, learning. Second phase of product development. Here, you now have something that you can actually put in the market and test and learn from. And the idea is that once you have built something as a prototype, you wanna use both quantitative and qualitative approaches to understand what's working and what's not. Again, tons of resources out there that'll show you a lot more here. But on the quant side, what you wanna do is you wanna track metrics and usage. I think it's helpful to understand how clients are using the products and features 'cause you'll often see things that they wouldn't tell you 'cause they may not even realize. I think there's also value in surveys. So surveying your customers to understand what they like, don't like, what's working for them, what they want more of, what they want less of. On the qualitative side, I think it comes down to really talking to as many customers as you possibly can, as often as you possibly can. So here, recruiting an informal product advisory board so that you have quicker feedback loops and easy access to a set of customers. I love watching users in their natural habitats. That doesn't mean using an online recording, you know, session recording. It actually means going to their home or following someone around, seeing, you know, are they on the bus when they're opening the app? Are they at work? Where are they? Are they on mobile or desktop? How are they using it in those moats? So actually watching them in their natural habitat. This is especially important, obviously, for anything hardware-based. And so doing it in a natural habitat as opposed to bringing them into the office. And then once you have all those learnings sort of really well documented, you should write everything down at this stage, look for themes, identify things that you think you wanna iterate and improve on, then you're in the iteration stage. So here, you iterate on feature scope and design. In my opinion, I think it's very important at this stage to really focus on quality. So if the goal for your initial build stage is really speed, I really believe in maintaining a very high-quality bar to earn customer love and trust by the time that you're kind of getting to GA. And then you're just gonna continue to learn and listen to your clients and customers. You're gonna continue to track the percent of very disappointed users and refresh the list of priorities that they want in each group. And hopefully you're gonna start seeing your percent of very disappointed creeping up over time. And you're gonna just continue iterating there.
And so that's all for today, and I'm gonna wrap up just by summarizing the things that I talked about. First of all, you wanna become obsessed with the problem that you're solving and use it to craft a clear product vision. Next, you wanna take that product and problem vision and translate that into something that wins customer love with the goal of having more than 40% of your users be very disappointed if you could no longer use their product. And you're gonna craft your roadmap based on looking at the features that's going to increase that percent. And finally, you're going to execute against your roadmap in a rapid and iterative way that optimizes for learning, speed, and user feedback. Thanks.
Thank you, Veronica. I really appreciate that overview about how to find product-market fit with the detailed advice. Again, this has been a Ubiquity University session. We would love to hear from you. If you'd like to set up a meeting, we're at pitch.ubiquity.vc, and I myself, I'm at sunil at ubiquity.vc. So thank you again.