Vision, Strategy & Bets
You've been in the meeting where two smart people argue about a feature for an hour before it dawns on everyone that they're picturing completely different products. That's a vision problem - and it's the most expensive kind, because it compounds silently until something ships that nobody actually wanted. Vision names where the product is going and why; strategy maps the route there. On most teams the product manager drives this, but it only holds if designers, engineers, and stakeholders are in the room when it's set - misaligned direction is far cheaper to fix now than after it's built.
Learn on the move: press play and turn your commute, walk or drive into time that grows your design career.
Listen to the full Vision, Strategy & Bets course on DesignPath
Write the Future Press Release
The working-backwards technique is one of the most effective tools at this stage - Amazon built a whole culture on it. The team writes a future press release describing the finished product from the user's perspective: what problem it solves, why it matters, what makes it different. If you can't write that press release clearly, the vision isn't clear enough yet.
Vision work should answer:
- What problem are we solving, and for whom?
- What does success look like in one year? Three?
- What constraints - technical, legal, budgetary - define the playing field?
- How does this fit the broader business model?
Then Write the Spec
Vision is alignment; the spec is the artifact that holds it. Without one, every person on the team is quietly building a slightly different product.
A good spec separates functional requirements (what it does) from non-functional ones (how fast, how secure, on which platforms), and it's written in plain language - if a stakeholder or a developer can't read it, it can't do its job. Treat it as living, with a status and a changelog, not a document you finish once.
Draft it with AI, then interrogate it.Hand AI your vision notes and have it produce a first spec - requirements, key flows, and open questions. The value isn't the draft; it's the gaps it surfaces. Read it critically and fill what it missed.
Time spent here is never wasted. Changing direction during strategy costs days; changing direction during development costs months.
Product Landscape vs Roadmap
Improving a product that's already live is like changing a tire on a moving car. The system is running, users depend on it, and you can't stop it to fix it - every change happens under operational conditions. Scott Himmer's framing turns that constraint into a way of prioritizing.
Diagnose Like Tire Damage
Himmer uses tire damage as a triage model for product problems:
- Sidewall gash - critical failures that demand an immediate stop (security breaches, major outages).
- Slow leak / puncture - persistent problems like poor onboarding that erode adoption gradually. The dangerous ones, because they look manageable.
- Bald treads - neglected maintenance with no regular pruning: the deferred catastrophe.
Tech debt is a strategic area, not a chore.Ignore it and "it will slow your car down or cause it to break down altogether." The opposite instinct - a "feed the machine" mentality of endlessly adding features without fixing the foundations - just accumulates debt and makes every future change harder and riskier.
Trade the Roadmap for a Landscape
Himmer proposes replacing checkbox roadmaps with a product landscape - a way of thinking about product health before planning execution:
- Platform Radar - a 10,000-foot view that identifies improvement areas from customer pain points, vision alignment, and internal data, before detailing features or timelines.
- Strategic areas for improvement - defined by outcomes, not features.
- Flexible scope - unlike a fixed-timeline roadmap, the landscape adjusts as the market and the company evolve. It's a living picture, not a commitment.
Assemble a Pit Crew
Breakthroughs need cross-functional input without a wall of formal meetings. Himmer's answer is a pit crew - UX designers, researchers, PMs/owners, support reps, architects, engineers - who give quick, targeted input on proposed solutions. It breaks silos without adding overhead, replacing slow approval chains with fast consultations. The crew scales with the company: smaller orgs run it lean and informal-but-intentional; larger orgs formalize it with a charter and RACI (Responsible, Accountable, Consulted, Informed).
Ship Incrementally
- Break work into pieces that fit existing workstreams - no "big bang" releases.
- Assess effort, complexity, and scalability per piece.
- Use small front-end tweaks to lay groundwork for larger structural change.
- Balance new features against maintenance, deliberately. One large case unified 200+ systems by shipping "good-enough" pieces with backlogged enhancements - each "crafted with a vision toward the whole" - rather than waiting for perfect.
Where AI Helps
AI can help you map the landscape and build the case for unglamorous work.
Prompt: "Here are our top customer pain points, internal data signals, and known tech debt [paste]. Cluster them into strategic improvement areas defined by outcomes (not features), triage each as critical / slow-leak / neglected, and draft an argument connecting the tech-debt items to a strategic initiative."
AI drafts the clustering and the business case; you set the strategy.It can organize signals and articulate why tech debt matters, but which areas your team actually invests in is a judgment grounded in your real constraints.
