Planning in the dark

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.