Product strategy: avoid these 6 pitfalls while defining it
Lofty product strategy pitches buzzwordy with dense diagrams have become a norm. There's no issue with them, per se, but most are just words lacking insights. After seeing several pitches over the last decade, I see a few recurring themes of what not to do in your strategy formation.
Firstly, a strategy document should take you through a journey. Begin with painting a picture of the status quo with underserved needs. Then, what's the big picture view of the future state. Finally, it builds a bridge between the current state and the future with the actions required.
A goal is not a product strategy.
I cannot count how many times I heard in various webinars and presentations something like, "our strategy is to drive revenue up by X%" or "user engagement by Y%." Your desire or goal is not a strategy, something you can use to devise concrete actions.
Any strategy — if you call it that — has to be actionable. That's forming your team's charter for several quarters or years. You depend too much on your team's willpower to make it happen by not providing enough details. Identify and avoid it. Hope is never a strategy.
No details of the competitive landscape.
A thorough review of the status quo is essential to understand the lay of the land and how and where to deploy your forces. A frequent mistake is calling out the macro environment or stating that what we're doing is so unique we don't have any competition.
Understand that the competition does not just come from other solutions in the market alone. Anything your target customer is doing today is what you're competing with. If there's an analog system —paper-based and process-oriented — as their current solution, you compete with that unnamed solution.
For existing solutions with deeply ingrained habits, you need to devise specific plans (as part of your strategy) for addressing the inertia of habits and resistance to change. So, your strategy should identify all forms of competitive forces and prescribe the steps in detail.
I cannot emphasize enough leveraging JTBD theory and empathy interview techniques from Design Thinking.
No clearly defined metrics.
Not having a Northstar is like shooting in the dark. Your team will be jam-packed with activities, but they're moving millimeters in a million directions. So your strategy should always call out specific metrics to bridge your strategy and concrete actions (tactics).
In cases where a metric is difficult to obtain, use proximate metrics that can work as a gauge of progress. For example, going with an engagement metric like new users added is a reasonable proxy when you're not monetizing aggressively (as an early-stage product). Likewise, customer satisfaction is critical as you plan on solidifying the product-market fit.
By calling them out, your project team can evaluate which metrics are currently available and which ones require instrumentation in the code to enable.
No clear distinction between assumptions and known knowledge.
To impress investors and others, the presentation decks have many bold claims without qualifying them from the confidence perspective. However, if you're not calling out known unknowns, you must prepare for a rude awakening when reality strikes — it always will.
In your product strategy work, present the confidence level on the items you're more confident in than the others. It's okay not to have confidence over some of your claims, but not calling them out is not okay.
Embrace hypothesis-driven thinking. Based on everything we know, here's how we anticipate things to play out, and here's a metric (or two) we track to get there. Be humble and transparent in your predictions.
No actionable guidance.
Not describing actions to tie your product strategy is prevalent, unfortunately. Leave out the details stating that they are the "implementation details." Implementation details include which tech to deploy, network architecture, technical design, etc. However, while defining strategy, you should describe what it takes to achieve the desired outcomes based on your diagnosis and guiding policies.
The most common items are:
how much does that cost
how many resources do you have
what's the opportunity cost for the things not addressed
what org structure changes, if any, are required
which items need experimentation
how your actions line up and feed into each other
Too much emphasis on "how."
Talking too much about the tech details is the other extreme from the previous item. The strategy deck speaks only about the tech deployment and raves about the uniqueness. Unique tech is perhaps your differentiator in the market. Maybe. Ask every one of those startups which thought so too.
Technology is a means but not the end. Emphasize it as much as you need in your strategy if you feel you have a winner but don't stop there. Go on and describe what customer and business benefit your solution provides. Delve deeply into them.
Say you're using cloud tech and AI with your data; that's great. Say it out loud. Now, go on and explain why you have an (unfair) advantage over the other players in that area. Tech adoption is a function of time. You may be early to the game, but other players are not that far off in the world of disruption.
Most of your strategy document emphasizes the "why" and "what" of the solution. That provides your stakeholders and investors confidence that you're thinking this through and not relying on what's hot today in technology.
In conclusion, defining a formidable product strategy is hard work. However, a thoughtful approach that covers the gamut of status quo (before) to disruption (after) by laying out a path (actions) will make it well worth the effort. Also, note that strategy is never static. Review it regularly to adapt to the new forces and information. Keep an open mind!