How to make hard product decisions
Product managers make decisions. It’s what we do.
You’ll make all kinds of strategic and tactical decisions, often at a frantic pace. Some decisions are easy and obvious–you make them almost reflexively–and some are daunting and difficult.
During your product’s life, you’ll face choices like whether you should build or buy tools, whether to build for cloud, on-premises, or hybrid deployment styles, whether to focus on APIs or slickly designed front-ends, facing forks in the road that determine go-to-market targets, and sequencing capabilities across your tech stack. Let’s focus on two decision patterns: the fork in the road and the sequence.
The fork in the road
There is a category of product where core functionality relies on integration with 3rd party applications or services. Sometimes, the functionality manages some aspect of that 3rd party system. In this case, the fork in the road is whether to integrate deeply with a few applications or to penetrate less deeply into the target system but integrate across a broad set of those systems.
Which path you choose substantially impacts your go-to-market motion. Your ideal customer profile, user journey, and buying journey look considerably different when you integrate deeply than when you spread your integration capabilities broadly.
Your decision may also depend on the integration points offered by your target system. Most modern applications and cloud services provide decent APIs for integrating or managing configurations, data, and user behavior. Older applications and services force more creative approaches.
Here’s the conundrum. If you choose to deeply, customers will always ask you to support some application or service you don’t already support. Deeper integrations are complicated, require specialized knowledge of the target system, and take a long time to build properly.
If you choose to integrate broadly, many customers will ask for deeper integrations. Broad integrations will deepen by degrees, one customer at a time. So you’ll try to do both. This could be okay if your end goal is to provide deep integrations across all your target systems. Decide to follow both options very deliberately. Don’t choose this path by not deciding. The specific requirements of deep integrations tend to be very customer-specific and not always market-driven. You build sophisticated features that only a small subset of your customers use. Your support burden explodes, and your product becomes complicated. Your product is sticky, but you’ll struggle to build a large market presence.
Sequencing
Sequencing is often confused with prioritization, but these are actually two different things.
Prioritizing is ensuring you’ve identified the “next-up” work correctly. Priorities are tactical decisions made weekly, which product managers apply to a small body of work, such as a feature enhancement.
Sequencing is a strategic decision. Should we build a large bundle of features before or after we deploy the tech stack to a second cloud platform? Should we update the API’s security model before we swap out the back-end data storage? Or after?
Suppose you are building a new cloud or SaaS service. Such projects tempt product managers to build cool features from the get-go. This approach is a mistake because the functionality is only useful with a good sign-up and sign-in experience. Your cloud service also needs analytics to observe and measure your user’s journey, a framework that should be in place before you start building features.
When the team finally starts on features, start with the API and build the sparkly UI on top of the API. Teams often do this in reverse, struggling to retrofit an API behind the UI and ending up with tightly coupled features and spaghetti code.
It’s an understandable mistake. Everyone loves a beautiful, well-designed UI. Products with neat UIs demo well and look mature even when functionally nascent. The sales and marketing teams love these products. UIs are flashy. APIs are boring.
But building the API before the UI has a ton of advantages.
First, you probably need some kind of an API for your UI regardless. So treat your API as a first-class citizen of your product. Assume every API will be user-facing and publicly accessible. Deciding your API and all its endpoints could be public forces good practices around security, documentation, and API stability. The approach makes you think about backward compatibility at the outset. When you decide to rewrite your UI using a shiny new front-end framework (when has this ever happened?!), you’ll have a stable API against which to develop.
Second, there will always be a subset of customers who prefer to manage your application or service using an API instead of a UI. This is especially true when they use DevSecOps tools and techniques. A product with a robust API expands the user personas you target and broadens your reach within your ideal customer profile.
Managing decision implications
Forks in the road and sequencing are ‘inside-out’ product decisions, internally driven but with customer implications.
Choosing an API-first approach means your UI functionality will lag behind what is possible through the API. Your customers might appreciate this approach, and the market views the product as developer-focused. But your sales motion targets C-level executives, and you’ve inadvertently created a mismatch between what that user persona wants to see and what your product can show them.
Your product’s adoption is decent, but revenue growth stagnates. Your sequencing decision resulted in product-usage fit but not product-market fit. Oops.
Perhaps you decided to build very deep integrations with a few target systems. Your go-to-market motion relies on joining those target vendors’ ecosystems and selling your product through their marketplaces. However, each vendor believes they have a sufficient solution to the problem you solve. Those vendors decide not to let you into the marketplace, shutting off the path to your ideal customer profile.
Your product hypothesis depends on the value you provide by integrating across those target systems. The individual vendors’ financial incentives prevent them from seeing the market your way. You plead with them to access the customers in their ecosystem, but those pleas fall on deaf ears.
Now, you face another hard decision: change the product or adapt the go-to-market motion?
Getting it right, making mistakes
You can also decide not to decide by deferring decisions. Not deciding is the most common mistake. The second most common mistake is choosing both options. Most product failures result from the team drowning, trying to support too many ICPs, too many user personas, and following both roads at every fork.
We mythologize the efficacy of mistakes. The prevailing wisdom asserts that you aren’t trying hard enough if you never fail. Maybe.
Choosing a product approach that determines a go-to-market direction has risks. What if that approach is wrong, or the timing is off? Deciding not to decide is a risk you can manage and eliminate.
You will make mistakes, so make sure to make them early enough in your product’s lifecycle that you have time to pivot to the correct decision. I have a mantra–formulate the plan, execute the plan, stick to the plan–that reminds me to stick it out through difficult times. Listen closely for the signals that let you know to make those pivots earlier than you think you should.
Getting decisions right depends on commitment. Do your research, gather your data, weigh risks and benefits, and align the product organization on the outcomes of the decision. Measure those outcomes and decide what thresholds determine when to reevaluate. Revisit those measures continually.
Data-driven decision making
Data optimizes your decision-making. The statement seems so obvious it borders on trite.
Diligently gathering data and feeding it through a ‘bias engine’ is akin to deciding not to decide.
Common sense tells you that building your API before your UI makes sense. There might be some data behind this, too. During discovery and early voice of the customer interviews, more than 75% of your customers tell you they have tools and processes that drive their preference to use the API and eschew the UI.
Your engineering team is solid, your sole UX designer is swamped and weeks behind, and everyone decides that customer feedback is amongst the best they’ve ever heard. The team charges ahead on the API and defers important UI work.
Collectively, the team ignores the information that these users are typically tasked to investigate and experiment with new technologies and don’t have final decision-making authority or budgets to buy new products. They make recommendations to C-level executives and their teams, who are used to working with UIs and dashboards. The buyer knows they need your product; they just don’t have a way to use it.
A subtle but important bias blew up your product-market fit and go-to-market.
Gather data very early in your product’s lifecycle. Customers will absolutely tell you what they want. Still, you must design suitable experiments, ask the right questions, and allow them to answer to find data that resists your organization’s inherent biases.
Deciding who decides
Limit debates about deciding who decides.
If it makes sense, apply frameworks to align the team on who does, who consults, and who decides. Don’t bog down in the frameworks, though.
The product leader should make the product decisions.
The product leader should decide about feature bundling, pricing, and packaging. The product organization will already have figured out the ideal customer profile, user personas, how to create quick time-to-value, and product delivery timelines. Pricing and packaging are outcomes of that knowledge.
The marketing leader decides the types and frequency of campaigns to drive awareness and adoption of the product.
The sales leader decides how to compensate the team, win customers, and drive revenue.
Determining who should make decisions is usually as obvious as this.
Continuous, consistent communication
Focus more on what makes decisions effective: continuous, consistent communication.
You have to tell your teams, heck maybe the whole company, what you’ve decided, why you made that decision, and how you will measure the success of those decisions every week. Early in your company’s or product’s lifecycle, you may need to remind everyone daily.
Continuous, consistent communication is the only way to make decisions stick.
Don’t skip this step in your decision-making.