The Landscape-First Product Strategy Doc
A bullet-driven Google Doc that builds an unbroken logic chain from company mission down to a single team priority.
- Difficulty
- Moderate
- Time to result
- ~weeks to results
- Steps
- 8
- Confidence
- 95%
Rather than starting with a solution, Crowley writes a long, plain-bullet strategy document that front-loads an exhaustive 'landscape' and honest current-state accounting before naming any opportunity or bet. Writing it all down surfaces the real challenge, and sharing it openly lets disagreements attach to specific points rather than the whole plan. The doc is primarily homework for the author to be confident in the decision; a summary up top serves readers.
Origin
Developed by Maggie Crowley in response to repeated 'be more strategic' feedback (which she notes disproportionately hits women and underrepresented PMs), and prompted by an engineer who kept pushing to understand why they were building what they were building.
Core principles
- 01Start from context, not solution; earn the bet
- 02Everything should be shareable with no secrets
- 03You should be able to trace mission -> individual team priority as one logic chain
- 04Disagreement becomes 'I don't agree with this point,' not 'I don't agree with you'
- 05Most conflict is really an information gap
- 06Not every feature needs a strategy; use this for bigger, longer-timeline, higher-impact questions
How to run it
- 1
State mission and goals
Open with the company (and team) mission and any high-level framing of what you're working on. Plain bullets, not fancy.
Pro tip Include the team-level mission too, since it's usually more specific than the company's.
- 2
Dump the landscape
Write an expansive section on what's happening: business state, product state, point of view on the market, competitors, a SWOT analysis, and key risks. Screenshots of competitors' marketing sites are fair game.
Pro tip This is where the doc earns its length; going deep on a competitor or market dynamics can run many pages.
- 3
List current business goals
Capture the current quarter's or planning cycle's goals so the strategy is anchored to what the company is actually working on right now.
- 4
Give an honest current-state accounting
Assess where you actually are: what works, what doesn't, bottoms-up feedback from users/customers/teams, support tickets, and crucially the technical hurdles and tech debt your engineers keep harping on.
Pro tip Explicitly surface big pieces of tech debt and upcoming technical decisions; they constrain what's possible.
- 5
Name the opportunity
After writing everything down, let the top one or two opportunities bubble up: where to play, where you can win, and why, based on your unique competitive advantage.
- 6
State the challenges / what must be true
Identify what will be hardest about pursuing the opportunity, reframed as 'what has to be true about the world for that to work.'
- 7
Propose the solution and plan
Take a swing at what you'd build and how it might work (about three bullets), then a plan: how you'd sequence it, what the team would need to look like, and roughly what it would cost.
Pro tip Add a summary at the very top (pyramid/Minto style) so a reader gets the point and recommendation above the fold.
- 8
Share it and invite shredding
Share the doc with everyone. Take it to your engineering counterpart first and ask them to tear it apart, then let disagreements attach to specific points in the logic chain.
Pro tip Go to your engineering counterpart first and literally ask them to 'shred this... rip it apart... vomit comments on it.'
Watch out Don't be precious about your work; most people will only skim the summary, and that's fine, the value is that YOU did the work.
In the wild
Crowley describes finishing the exercise, landing on three things worth doing, then looking at the roadmap and finding it bloated with unrelated legacy commitments, so ~90% of resources track against things that don't support the strategy.
→ Even without authority to scrap the roadmap, the doc lets a leader critically evaluate whether current work is still the most important and where the gap is.
Common mistakes
Jumping to the solution
Skipping the landscape and current-state accounting means the bet isn't grounded, and disagreements become personal instead of about specific data points.
Over-applying it
Writing a full strategy for a tiny slice of product you already have user feedback on just over-complicates simple decisions.
Is it for you?
Best for
Directors and senior PMs facing annual/quarterly planning, a potential pivot, or a big new opportunity, especially those told they need to 'be more strategic.'
Not ideal for
PMs working on a small feature with clear user feedback, where a full strategy doc is overkill.
From the transcript
“I just wrote out a Google doc and I started with like okay and not fancy these are just bullets what is the mission like…”
“then I had this big section that was just like the landscape and in that section I put in you know what's going on with…”
“where are your technical hurdles like what are what are the big pieces of tech debt”
“what's the opportunity from all of that what's going to Bubble up as the top one or two opportunities for your team where do you…”
“what has to be true about the world for that to work”
“you should be able to walk all the way from your company's Mission down to the individual priority on your team and see the logic…”
“it doesn't become like I don't agree with you it becomes I don't agree with this point”
From the episode
Mastering product strategy and growing as a PM
Maggie Crowley (Toast, Drift, Tripadvisor)