How to build and communicate a compelling product vision

Executive overview

Most PMs lack a clear, standing vision — and without one, teams ship without direction. The fix is a structured process: deeply understand the top problems your users face, develop a vivid picture of the future state, and then systematically bring your team, stakeholders, and leadership into that story.

Ebi Atawodi (YouTube, Netflix, Uber) shares a framework she calls clarity and conviction — clarity on the problems worth solving, conviction on the future you're building toward. A strong vision is lofty yet attainable, free from today's constraints, and grounded in a potent user problem.

A good PM's job is not to collect research and output a roadmap — it is to curate problems, build conviction, and make the destination vivid enough that the whole team wants to sail toward it.

What makes a vision good

• Must be lofty enough to be exciting and attainable enough to feel real
• Imagines the world free from today's tech constraints or org limitations
• Anchored in a specific, painful user problem — not a generic purpose statement
• Distinct from mission: vision is the destination picture; mission is the purpose for going there
• Uber's vision: a world of continuous trips where cities reclaim parking space — concrete, visual, believable
• A vision should survive 3–5 years without rewriting; if you're refreshing yearly, the work wasn't done

How to develop a vision: the empathize step

• Maintain a living document of the top user problems — not a one-off exercise, a permanent artifact
• Ask every partner (engineering, design, research, marketing, ops) to submit "10 things you should know" before strategy sessions
• Use the product yourself: upload videos, make purchases, feel the friction
• Distill inputs to the top three problems; these become the North Star that doesn't move
• Infrastructure and tech debt are user problems too — own them, don't outsource them to eng

How to communicate a vision: formats that work

• Once upon a time narrative: problem state → inciting event → future world (simple, memorable, scalable)
• Fake news article: write the TechCrunch headline you want to see in five years; add a subhead; go as far as writing the body
• Sketch or storyboard: work with a designer to draw the future — one image is worth the whole document
• Pick the format to match the audience; the point is to make the destination vivid, not to be comprehensive

Evangelizing the vision: three concentric circles

• Start with the core team — every PM, engineer, and designer must be able to articulate the vision themselves
• Present it multiple times; people need repetition before it percolates
• Keep the strategy doc open for comments (not view-only) — friction polishes the thinking
• Bring stakeholders in early by asking for their "10 things" input; they feel heard when the final vision references their problems
• Take it to leadership as high as possible; let them pull you back rather than self-censoring upfront
• Use a short link or evergreen doc so anyone can find and reference it — "go/studio-vision" becomes cultural shorthand

The narrative document: insights, strategy, big rocks

• A two-page doc (max four pages) that answers: what are the problems, what's the approach, what are the three to five biggest bets
• Big rocks are sequenced, not a laundry list — like building a cocktail, ice first then pour
• This document refreshes quarterly or annually; the vision behind it is evergreen
• It is not the vision itself; it is the narrative that earns the right to build toward it
• Useful for onboarding, partner alignment, and replacing 50-slide stakeholder decks

The craft of product management: clarity and conviction

• Clarity = cutting through noise to name the real problem; it shows up in every email, every meeting, every doc
• Conviction = a feeling — not certainty — about the right path forward; "product sense" is built by immersion and curiosity
• If you can describe "our five priorities," you don't have conviction — stress-test by asking which single one you'd build with five engineers
• Never bring leadership two options with pros and cons and ask them to choose; do the work, pick one, name the risk you need help with
• PMs who become question-aggregators or roadmap-updaters are not doing the job; the job is curation and direction

Building a product culture

• Culture evolves whether you intend it to or not — intentional evolution beats reactive recovery
• Uber: principled confrontation and toe-stepping allowed cash to be tested despite CEO opposition
• Netflix: "freedom with responsibility" and "highly aligned, loosely coupled" enabled structured debate leading to the ad-supported tier
• Google/YouTube: loose macro values allow micro-cultures to form by product area — cloud, search, YouTube each feel different
• Create team culture explicitly: agree on values with your cross-functional partners (PM, eng, design) before problems arise
• Know your EM's birthday, work anniversary, and career goals — the relationship carries the work

Becoming a PM and getting better at the craft

• Start practicing product management before you have the title: pick any app, list the top 10 problems, sketch the solution
• The goal is to train product sense through repeated reps — so when opportunity comes, you're prepared, not lucky
• Trust your gut and judgment; if an AI could produce your strategy doc from raw research, you haven't done the PM work
• "How might we" is a fertile question — it opens brainstorms without locking in a solution