Over the years, I’ve worked with countless product strategies across various frameworks (OKRs being the most common) and have seen both successes and recurring pitfalls. The two biggest challenges I consistently encounter in product strategy are:

1. Missing ‘The Why’. Too often, product leaders hold critical customer and business context in their heads, only for it to vanish after a long-winded presentation. Without a written record, teams are left guessing, missing the deeper purpose behind the strategy.
2. Missing ‘What success looks like’. The hardest—and most crucial—part of any strategy is defining clear, actionable measures of success. Too often, teams bury this at the bottom of a document in a short bulleted list when it should be the absolute foundation. Defining success can’t be an afterthought—it must lead the strategy.

By improving these two areas, 90% of product strategies would be vastly improved and provide a better shot at success (although still no guarantee of success).

Introducing: V2OOO (Vision, Values, Outcomes, Outputs, Obstacles)

There are plenty of amazing resources on this topic (Marty Cagan and John Doer being some of my top picks), and the Salesforce V2MOM framework is the closest I’ve found to successfully capturing holistic product strategy, with a few tweaks based on my learnings and to address the two biggest challenges that I frequently see and refined to: V2OOO (Vision, Values, Outcomes, Outputs, Obstacles). These refinements update the language to reflect the product operating model and restructure the document to prioritize the more important topics first (i.e., outcomes over outputs).

“Docs”, not “decks”

I firmly believe that effective product strategy should be captured in written narratives—long form. No slide decks, no flashy presentations. The power of written narratives has been championed by visionaries like Steve Jobs and Jeff Bezos, emphasizing clarity, depth, and rigor. The V2OOO structure is a simple document structure with 5 sections.

I can’t count the number of times I’ve seen a twenty-page product strategy that was painfully crafted end up sitting on a shelf collecting dust. Inspired by Amazon’s 6-pager approach, I’ve found that constraining the length of the documents significantly enhances effectiveness. My rule of thumb for document length is based on the length of time you’re committing to having a deep discussion/debate on the strategy:

• For a one-hour meeting (20-minute silent study hall, 40-minute discussion): Six pages excluding the appendix.
• For a 30-minute meeting (10-minute silent study hall, 20-minute discussion): Three pages excluding the appendix.

This approach forces teams to be intentional about strategy, ensuring that the most critical elements receive the focus they deserve.

1. Vision – The story of your customer’s future state.

Picture a world where your customers rely on your product so naturally that it feels indispensable. Maybe it’s the app they open first thing in the morning, the service that saves them hours of work, or the tool that helps them achieve something they never thought possible. What’s changed for them, and why does it matter? How has their experience improved, and why is it meaningful?

This vision must be anchored in the customer’s perspective. It’s all too easy to fall into the trap of using language focusing on our internal team or company, which will derail the rest of the strategy.

2. Values – Your principles guiding decision-making.

Explicitly stating your first principles is incredibly helpful both for the author of the strategy to explicitly think through what they are optimizing for, and accelerates decision-making by team members when faced with trade-offs during execution.

Stack ranking the values helps to clearly communicate priorities. For example, a product team might prioritize ‘customer trust’ over ‘speed to market’, ensuring decisions align with long-term user satisfaction. Another team might value ‘innovation’ over ‘cost efficiency’, pushing boundaries even if it means higher initial expenses.

3. Outcomes – How you will measure success.

Setting meaningful measures is the hardest part of strategy. Crafting an ambitious Objective is easy, but defining the right Key Results is where things often go wrong.

Each outcome should consist of:

1. A specific and measurable impact on your customers and/or company. Clearly define how it connects to broader cross-functional or company-level goals.
2. A baseline of the current state and a target for where you want to be in the strategic time horizon.

Flags to watch out for:

1. Avoid “binary outcomes” (e.g., launching Project X by Date Y)—these are the outputs to achieve your goals and not indicators of success.
2. If your outcomes are lagging measures, ensure you have additional visibility into the leading measures. For example, if revenue growth is your lagging measure, track leading indicators like user acquisition rates, engagement levels, or trial-to-paid conversion rates to gauge progress early.

4. Outputs – The specific deliverables that will help you achieve the outcomes.

Now that you’ve defined what success looks like, how are you going to get there? The “outputs” are your hypothesized roadmap to success. Instead of listing every task, focus on the key initiatives you believe will drive meaningful impact.

For each output:

1. Define a hypothesis for impact—Why do you believe this initiative will move the needle?
2. Set a clear definition of done—Avoid scope creep by setting minimum requirements.
3. Estimate investment needed—Use simple estimates (e.g., “person-months”) to align on resources.
4. Provide an expected timeline—Ensure clarity on when to expect value.

What are you choosing not to do? Explicitly listing what’s not prioritized prevents assumptions that unlisted workstreams will still happen.

5. Obstacles – Anticipate challenges before they derail progress.

Great! You have a “perfect strategy”… What could possibly go wrong? Premortem practices help increase project success by proactively identifying risks before they become problems.

Common obstacles include resourcing constraints, dependencies on other teams, shifting priorities, and unforeseen technical challenges. By anticipating these risks early, you can communicate them effectively, assess their impact, and plan mitigation strategies.

Final Thoughts: It’s not about the document at all

Disclaimer: Every mental model is wrong…some are useful. Take this template if it helps, leave it if it doesn’t.

The goal isn’t just to document a plan, but to ensure that teams focus on what truly drives meaningful progress. The format and practices above don’t really matter—what matters is creating clarity and alignment.

“The goal of product development isn’t to make products. Your job is to change the world.” — Jeff Patton (User Story Mapping: Discover the Whole Story, Build the Right Product)

Use whatever works for your team and continuously improve from there. Any framework that works for you is better than no framework at all. And if you think you don’t have a process, you do—it’s just unintentional.

Sidenote: I’m wondering if V2OOO is better renamed to something like…V-TWOOOO, or V2O3? ;)

I’m always learning and iterating. I’d love to hear your thoughts—drop me a line!