There’s a certain situation I’ve found myself in on more than a few occasions over the years, whether as a new PM of a product or a PM of a new product. I’m smoothening out the details of a feature, trying to tie up loose ends, enunciating each alternate/bad-case scenario carefully into acceptance criteria for the engineers (provided they read the PRD in the first place), and I can’t quite place my finger on the urgent business need of building that particular complexity.

It’s not a comforting thought to not be absolutely surefooted about using considerable capital to build a product/feature that isn’t critical for your customers; or something they’d truly care about; or miss it were it to be suddenly taken away from them. Engineering teams don’t come cheap and the primary function of product managers is to make sure that there’s a solid revenue return on every engineering investment.

And yet, time and again, I’ve seen companies, teams, projects with this same handicap. The vision is there — the company knows what it wants to achieve in the long term. A list of product offerings/features have been lined up too to get them there. They’re probably neck deep building this feature factory too.

But there’s a yawning gap in the middle: product strategy — that clear plan of action to achieve business outcomes by building things customers need or will want even if they’re not aware of that need yet.

I’ve read the opinions of many on the matter. Every major product expert out there has his/her version of a framework to master product strategy. There are many frameworks for developing product strategies. Some focus on the long-term: Blue Ocean, Get Big, Lead, Expand (GLEe) model.

Others are more holistic: Roman Pichler’s Strategy framework, Delight, Hard to Copy, Monetize (DHM) model. There are many, many more frameworks that cover product strategy.

I find most of them to be encompassed by or referring directly/indirectly to Porter’s 5 tests of strategy. Say what you will, the classics stand the test of time.

According to Porter, a good strategy must pass 5 tests. Here, I’ll break down what these tests mean with a checklist of questions to pass each test.

1. A Unique Value Proposition

What it means: Is your product solving a well-defined, important problem for a clearly identified customer segment? Is it differentiated in ways that matter to your users? (not just new tech features)

Ask:

• Who is your product for?
• What pain does it solve better/differently than alternatives?
• Can you express this in a sentence?

2. A Distinctive Value Chain

What it means: Are your product decisions (e.g. feature prioritization, workflows, integrations) aligned with unique capabilities your org/company has? Are you designing your delivery and UX choices around these?

Ask:

• Are your choices (features, design, pricing, channels) hard to replicate?
• Do you have a unique operational or technical strength that your product leverages?
• Are your delivery practices aligned with your positioning/ perception you want to create in the minds of your target customer group?

3. Trade-offs

What it means: Have you explicitly deprioritized certain customer segments, features, or markets, even when they seem tempting? Do you avoid being everything to everyone?

A common mistake many product teams make is adding an increasing number of features to create a bloated, complex product that in the quest to do everything, provides a poor user experience, has a vague value proposition, takes a lot of time to develop, and is costly to maintain.

Ask:

• What markets/customers are out of scope?
• Are you protecting your product’s clarity/ purpose?
• What won’t you build or support?

4. Fit Across Activities

What it means: Do your choices reinforce each other to make the whole stronger than the parts?

Ask:

• Do your product and engineering roadmaps align?
• Is your operations team ready/ capable to support new use cases accompanying new features?
• Is marketing and sales ready with a clear go-to-market strategy to get the product into the customers’ hands?
• Or are some choices contradicting others? (e.g. adding features that create more performance issues before engineering can build stable and scalable platform capabilities)

5. Continuity Over Time

What it means: The product strategy should remain stable and focused over time, allowing for refinement (not overhaul!) and sustained competitive advantage.

Ask:

• Is your strategy durable with room for adaptation? Or do you find yourself rethinking strategy every few quarters?
• Do stakeholders and teams (the larger product group, engineering, business) know where you’re heading?
• Do you feel the urge to pivot constantly?

A good product strategy will bring focus, alignment, and clarity. It’ll be the glue that aligns different priorities and also help you align stakeholders with the common product goal and business outcomes.

‍