If you’re a startup or development team looking to expand into new product areas, a lot rides on finding product-market fit. Like, say, the existence of your company, or your ability to create something of value for your customers. You know, the little things.
For engineering and tech leads, trying to plan development before you have product-market fit can feel like driving in the dead of night without headlights. (Even the term “product-market fit” can mean different things to different folks. For our purposes, consider it the extent to which your product meets prospective customers’ needs.) Maybe you have some basic competitive analysis, a high-level understanding of your users’ pain points, or demographic information about your target customers, but it’s not enough to give you a clear sense of direction. You’re squarely in the “explore” phase of Kent Beck’s 3X (explore, expand, extract) framework, evolving your idea through continual, incremental experimentation.
Being in this space can feel daunting; I know because I’ve been there too. In 2020, I led the team that launched project tracking at Gusto, a feature set that allows business owners to monitor their workforce costs across projects. It was an ambitious undertaking that involved a great deal of uncertainty in terms of what functionalities we were going to build and how we would release them, especially in the early planning phases.
Our experience taught us that you have to get comfortable with that discomfort. The unknowns that are part and parcel of developing a product without clear product-market fit can be demotivating for teams that aren’t used to it, but ambiguity is a normal part of the process. The good news is that it’s possible to find your way in the dark.
Reframe your expectations
In her book Bird by Bird: Some Instructions on Writing and Life, writer Anne Lamott reflects on how strange it is that we drive at night, when we can only see a few hundred feet in front of us. And yet, we still manage to get where we’re going. When planning a product before you have product-market fit, you similarly have to accept that visibility will be limited. The most you can realistically know is the work ahead of you for the next few weeks, the next month, or some other compressed time frame. Beyond that, the road is shrouded in fog, and you’ll need to reassess, revisit, and revise when you get there.
With that in mind, resist the urge to map out your whole project from start to finish. Your plans could be rendered inaccurate very quickly, so you’re likely better off investing that effort into other parts of the process, like determining your hypothesis, tweaking your metrics, and testing your assumptions.
Your team will also have to get used to taking a slow-burn, incremental approach to development. Engineering leads often assume they need to know everything before they can get started; instead, consider what’s essential to know up front and what can wait until later. Gather input from stakeholders to determine the direction for your first iteration. Is there existing UX research about pain points customers are experiencing? Does the sales team have call data you can look at? Take stock of the unknowns, too—these can encompass anything from feature prioritization to what browser users will prefer to consume your product in—but recognize that there will be time to find those answers along the way.
When my team was building project tracking, we didn’t yet have the user research, experiment results, or survey responses we needed to understand what product-market fit looked like. There were a lot of eyes on our team, which made us feel like we had to plan and estimate everything perfectly from the outset. But what we really needed to do was put aside the ideal feature set we’d envisioned during our initial planning sessions and release the product one quick “slice” (as we called our iterations) at a time, evaluating user feedback and tweaking the next iteration as we went. We had to get comfortable releasing v0, even if it wasn’t the fully loaded version we’d imagined.
Outline your hypothesis
The first thing you’ll need when working toward product-market fit is a hypothesis. What’s the software solution you believe will address an unmet need for your user? This gives you a target to aim for, even if you have to revise it as you go. Build something small and narrowly scoped to test it, then get feedback, iterate, and repeat—the tried-and-true MVP approach.
Next, you’ll establish some preliminary metrics. These will let you assess whether you’re moving toward your objective and when you’ve achieved the level of product-market fit that means it’s time to invest in further development. It can be hard to predict the most appropriate metrics for an unlaunched feature, but consider your metrics—which might encompass feature adoption, customer feedback, survey results, or net promoter scores—a jumping-off point as you amass information and input. You’ll also select a North Star metric (or metrics) that will help you determine when you’ve achieved product-market fit—for example, a 30 percent increase in engagement with the product or a 25 percent reduction in customer churn.
Beyond validating your hypothesis, your metrics should help you better understand your customers’ needs. When we were building project tracking, for instance, we were focused on shipping the first version quickly, so we only built the functionality to track full-time employees’ salaries. But our funnel metrics revealed that business owners who employed hourly workers were opting out because their overall workforce cost numbers were inaccurate. Once we realized this, we prioritized adding hourly employees into the next feature slice, which boosted adoption rates.
RAT out your riskiest assumptions
The Riskiest Assumption Test (RAT) is a construct for testing the assumptions that will have the biggest impact on your product before you start building. A strong complement to the MVP approach, it can be used to validate assumptions related to your product, customer, business model, and software design.
Imagine your app’s financial feasibility hinges on the presumption that it will achieve a specific customer acquisition cost (CAC), the per-customer cost of selling and marketing a product. To validate this assumption, you could release an ad for the app and track how many installs it generates. If not enough people engage with the ad or convert to app installs, you’d design another ad and continue tweaking the value proposition—and your product plans—until you achieve the necessary CAC.
Early in the development of project tracking, we only had a vague understanding of how one of our user personas preferred to track time spent in projects. Based on an early set of designs, we created a testing plan to validate the proposed UX flow with a set of six customers. The responses we received prompted us to change course and create a different time-tracking flow for that particular persona. Leveraging the RAT allowed us to learn what resonated with our users; if we hadn’t taken the time to get their input, we might have had to make large and expensive adjustments much later on—or, worse still, we might not have found product-market fit at all.
Descope, descope, descope
When you’re thinking about building something new, it’s tempting to imagine the fully fleshed-out version, the one with all the shiny bells and whistles. The problem is, there’s still so much you don’t know. If you build the Titanic of feature sets, it’ll be all but impossible to move fast. If you carve a canoe, on the other hand, you can launch quickly and find out whether your customer is even interested. You might save yourself months building the Titanic.
As we worked on project tracking, my team had to have some tough conversations about cutting scope. We realized that given the immensity of our vision—project tracking would touch so many parts of the existing product—and the project’s ambiguities, releasing features in slices would be the fastest way to learn from our customers and change direction as needed. Whenever we were close to launching our next slice, our engineering, product, and design teams would get together to evaluate the feedback from previous launches and agree on the highest-priority features to work on next.
This fast-paced, iterative approach meant we had to think deeply about sequencing and resist the urge to add that “one extra thing” to each slice. At first this was tough because we were used to creating more complete product sets. But within a few weeks, as we launched our first slice and collected feedback, we started to enjoy it. We found new ways to build nimbly, playing with pilots and beta groups, sequencing tech debt, and shaving off features with manual workarounds. For example, for an early project tracking slice, the tech lead on our team—I’ll call her Jamie—manually onboarded new customers from a pilot list, allowing us to put off building an onboarding flow. We jokingly called the new feature “Jamie-as-a-service.”
Once our team had embraced the principles of prioritization, incremental development, and descoping, the need to estimate precise story points for each feature became unnecessary, since each particular slice of functionality was already tightly scoped. Our stakeholders were aligned with this approach because they’d been part of those team discussions from the beginning, so we didn’t need to keep having the “when will this be done” conversation. And, steadily, we started to make progress toward our metrics.
About six months in, we achieved our definition of product-market fit—a certain percentage of returning customers within a three-month period—and it was time to think about next steps. For our team, that meant pausing further product enhancements so we could address some of the tech debt we’d accrued in the early stages, when we were focused on speed.
Make friends with ambiguity
Getting comfortable with discomfort isn’t easy, but it’s vital to finding product-market fit. This exploratory phase of product development demands that you take stock and continually reassess what you need to accomplish.
As an engineering leader, it’s important to remind your team that moving fast doesn’t mean working harder, or longer, or on the weekends. And it definitely doesn’t mean releasing a perfect product from day one. It requires cutting scope, iterating over time, and being more at ease with putting out a feature that’s not fully baked in order to learn what customers want.
You’re not going to get everything right from the outset, and that’s okay. The goal is to learn as you go: formulate a hypothesis, establish metrics, derisk, gather feedback, iterate, rinse, and repeat. Once you embrace the uncertainty, working on finding product-market fit isn’t just a challenge, but a thrill.