Review

This book needed to be written. It highlights the dangers of an iteration-led approach and exposes flaws in traditional goal-setting while introducing a practical method for setting and following a vision. I appreciated how it challenged existing thinking, but the "Radical Product Thinking" approach didn't feel like a fundamentally new perspective to me.

You Might Also Like:

Product Direction

The process of product execution is easy to explain. There’s a plethora of off-the-shelf activities, processes and frameworks new product managers can apply. Product strategy though is more elusive. Although it’s easy to frame it’s hard to do, as each situation is different. As a result product strategy books can leave you feeling a little lost. Product Direction does a commendable job of defining a step by step guide to creating a product strategy, defining a strategic roadmap and setting OKRs.

andrewclark.co.uk

Book Review and Summary: Strategize by Roman Pichler

In Strategize, Roman Pichler explains how product managers can escape the trap of day-to-day operations and focus on defining a clear and effective product strategy. The book emphasizes the importance of a strong product vision, a well-articulated strategy, and a tactical roadmap to ensure long-term success. Pichler outlines how to segment the market, identify key customer needs, and define a unique value proposition. He introduces tools like the product vision board and scorecards to track progress, and stresses the need for regular strategy validation through experimentation and data. Ideal for product managers seeking to balance vision, strategy, and execution.

andrewclark.co.uk

The Vision Driven Leader

There are better strategy books, I’ve linked to some below. This book is best thought of as an introduction to strategy through the narrow lens of a creating a vision. If you’re really interested in improving your strategy skills, you’ll need to read something else.

andrewclark.co.uk

Key Takeaways

The 20% that gave me 80% of the value.

Being vision-led matters, but the hard part is translating a vision into a real product without losing direction. Many organisations are becoming iteration-led: tinkering, reacting to short-term pressures, and letting whatever is most visible (revenue targets, loud customers, internal politics) determine what happens next. That's how teams land in local maxima; solutions that are "good enough" inside today's constraints, yet structurally unable to reach the breakthrough they were aiming for. Long-running iteration stories can reinforce this trap: a system can be stretched and patched for decades until progress stalls and a fundamentally new approach is required.

Iteration isn't the enemy. The problem is treating iteration as the way you discover where you're going, rather than the way you refine how to get there. Without a destination you can picture in detail, feedback loops can take you anywhere that looks incrementally better on a narrow metric. A vague vision ("go north and have the best road trip") still leaves you at the mercy of whichever turn looks easiest in the moment. Standard advice like setting a Big Hairy Audacious Goal often add drama without adding clarity about the end state you're trying to create for real people.

Radical Product Thinking reframes the work around the change you want to bring about, then treats the product as the mechanism for engineering that change. "Radical" means fundamental and far-reaching: thorough enough to help you curate initiatives and help with decision making. The Three Pillars of Radical Product Thinking:

1. Think of your product as your mechanism for creating change; the "product" can be software, a service, a policy, research, or an operational workflow, as long as it's the vehicle for impact.
2. Envision the change before engineering the product; define the end state and intended impact first, so you can build and evaluate what matters (and spot unintended consequences).
3. Connect vision to day-to-day activities; translate the vision into strategy, priorities, and concrete tasks so execution consistently produces the desired change rather than motion for its own sake.

When teams don't anchor on a clear vision, they tend to catch predictable "product diseases" that make good products go bad.

• Hero Syndrome: when leaders prioritise the scale and public visibility of their impact over the quality of the solution itself. Driven by a desire to "go big" or satisfy investors, companies focus on valuation and expansion rather than solving genuine customer problems.
• Strategic Swelling: a fear of missing out and an inability to say "no," this disease results in bloated products packed with too many features. Resources are spread thin across a fragmented strategy, diluting the product's overall impact and confusing the market.
• Obsessive Sales Disorder: This condition manifests when long-term strategic goals are repeatedly sacrificed to secure short-term wins. Product roadmaps become fragmented by one-off feature requests to close immediate deals, causing the company to lose its strategic direction.
• Hypermetricemia: An overreliance on measuring data without understanding which metrics actually drive success. By optimising for vanity metrics or tracking everything indiscriminately, organisations fail to focus on the meaningful outcomes that truly benefit the customer.
• Locked-In Syndrome: This happens when organisations rigidly adhere to familiar technologies or approaches due to past success or existing expertise. By focussing on the solution rather than the problem, companies fail to innovate and miss out on better, emerging alternatives.
• Pivotitis: The tendency to drastically change direction whenever difficulties arise, rather than pushing through challenges. Often disguised as a strategic pivot, this results in confused teams, erratic product offerings, and a failure to solve specific problems.
• Narcissus Complex: A condition where an organisation looks inward at its own goals and financial needs to the exclusion of the customer. This self-absorption leads to decisions that optimise for the company's benefit while neglecting user needs or safety.

These failures are rarely about capability; they're about direction, incentives, and the absence of a shared decision logic.

A practical way to stay vision-driven is to treat the core of product building as a single, connected five-element process:

1: Define a vision that is specific enough to steer decisions.

A good vision has three traits: it's centred on a real problem you want solved (even if your company didn't exist), it describes a tangible end state people can visualise, and it is meaningful to both the team and the people affected. Detail matters because it creates exclusion: if every opportunity fits, the vision is too broad to guide tradeoffs. The vision must galvanise customers as well as employees; customers won't care that you want to be "#1," but they will care that you understand the status quo pain, why it's unacceptable, and what a better world looks like.

A useful template avoids "wordsmithing" and forces substance:

Today, when [identified group] want to [desirable outcome], they have to [current solution]. This is unacceptable because [shortcomings]. We envision a world where [shortcomings resolved]. We are bringing this world about through [approach].

Pressure-test the vision by making sure it answers five questions with concrete detail: whose world you're changing (prioritise segments explicitly), what their world looks like today (workarounds, constraints, real costs), why the status quo is unacceptable (consequences if unchanged, validated as meaningful to them), when you'll know you've succeeded (observable signposts), and how you'll bring about the change (the mechanism you'll build and improve). If the end goal is audacious, pair it with a near-term evolution statement that's achievable and roadmappable while pointing at the longer arc.

Spreading the vision requires co-ownership and lived experience. A fast way is a group exercise: everyone fills the template with sticky notes, differences are surfaced, and the team converges on a shared version they can describe in their own words. Internalisation accelerates when people see users struggling with the status quo and witness the relief the envisioned future would create ("visionary moments"). Then translate the vision into role-level responsibility so each team and individual can articulate how their work contributes to the collective change.

2: Craft a strategy that makes the vision buildable.

Vision answers "where" and "why"; strategy answers "how" in a way that's coherent across product, business model, and delivery. A practical structure is RDCL: Real pain points, Design, Capabilities, Logistics. Start with validated pain points, not assumptions; "real" means both valued (people will pay, switch, or sacrifice to solve it) and verified (confirmed through research beyond your own intuition). Design is not aesthetics; it's the interface and identity that shape how users experience relief, including how the product should make them feel. Capabilities are the enabling assets under the hood (technology, data, content, infrastructure, expertise, partnerships, trust). Logistics covers how the solution reaches users and stays usable (channels, pricing, onboarding, installation, training, support).

Iteration belongs here, but in a disciplined role: use it to test and refine RDCL assumptions, not to let the loudest feedback define the strategy itself. Without that anchor, teams "micropivot" sprint to sprint, accumulating contradictory features and fragmented effort. With it, learnings update the strategy deliberately, and the mechanism improves while staying aimed at the same end state.

3: Prioritise by balancing vision fit and survival.

Daily decisions are tradeoffs between progress toward the vision and the short-term risks that could kill the product. A simple 2×2 (vision fit vs survival) creates a shared language so teams can explain why something is worth doing without hiding behind spreadsheets or authority. The quadrants clarify intent: Ideal (good vision fit, improves survival), Investing in the Vision (good vision fit, worsens survival), Building Vision Debt (poor vision fit, improves survival), and Danger (poor fit, worsens survival). The goal isn't perfection; it's a bias toward Ideal plus selective Investing, while minimising Vision Debt and avoiding Danger unless it unlocks a necessary future move.

Define survival explicitly as the single biggest risk that could shut you down (financial, stakeholder, tech/operational, legal/regulatory, personnel). Write a short survival statement as a team: what the risk is, what happens if it comes true, what amplifies it, and what mitigates it. If you incur vision debt (custom one-offs, misaligned integrations, revenue tactics that trade off trust) name it openly and plan how to pay it down before it compounds into confused customers and demotivated teams.

4: Execute and measure through hypotheses, not vanity metrics.

A product is "successful" only if it creates the change the vision describes, so measurement must reflect that change rather than whatever is popular to track. Treat vision and strategy as hypotheses under uncertainty. For each strategic bet, state the causal link:

If [experiment], then [outcome], because [connection].

Use a simple execution plan that ties together key metrics (signals of progress toward the vision and whether strategy elements work), hypotheses (why the work should move those metrics), and activities (the tasks needed to run the experiment, often your sprint backlog). Lean and Agile become the operating system for running experiments fast, but they stay vision-driven because every increment is framed as learning toward a defined end state. MVP "scrappiness" is contextual: minimum viability is whatever the user's real pain requires, which may demand reliability and completeness in mission-critical contexts.

Avoid turning product metrics into performance goals. Goal-setting frameworks can narrow attention, discourage exploration on complex problems, and incentivise gaming or unethical behaviour, especially with stretch targets. Replace goals-based management with a collaborative cadence: align on what you'll measure (and educate stakeholders if needed), create a safe environment to discuss metrics honestly, and manage progress through frequent feedback and course correction rather than fixed targets.

5: Build a culture that makes the above sustainable.

Culture can be treated as a product too: the mechanism that maximises intrinsic motivation so people choose to invest in the vision rather than take shortcuts. A practical rubric maps daily work along two dimensions (satisfying vs depleting, urgent vs not urgent) yielding four quadrants: Meaningful Work (satisfying, not urgent), Heroism (satisfying, urgent), Organisational Cactus (depleting, urgent), and Soul-Sucking (depleting, not urgent). A healthy culture expands Meaningful Work and shrinks the other three. That requires identifying root causes: incentives that glorify firefighting, bureaucracy and misalignment that create painful admin work, and unfairness or "superchicken" behaviour that suppresses collective performance.

This links directly to intrinsic motivation: purpose (clear vision and strategy), autonomy (shared decision logic through prioritisation), and mastery (hypothesis-driven learning and progress). Psychological safety is the enabling condition; teams need it to challenge ideas, admit mistakes, surface risks, and learn from metrics. It can be modelled through fallibility (making it safe to be wrong), direct communication (care personally, challenge directly), and accessibility (frequent, genuine interactions that reduce interpersonal risk). Diversity is part of culture engineering: if some groups systematically experience larger danger quadrants, the organisation won't retain talent or build products that work for everyone.

Put together, the book's argument is simple and demanding: stop short-termism, define your direction consciously. Make the change you want to: create the anchor, then build a coherent chain from vision to strategy to prioritisation to execution and measurement to culture. Iteration remains essential, but it becomes a tool for refining the mechanism, not a substitute for deciding the destination.

Deep Summary

Longer form notes, typically condensed, reworded and de-duplicated.

Introduction:

• Vision-Led: Having a vision seems to be important. But taking a product from vision to reality is difficult. Being vision-led isn’t a recipe for success in and of itself though.
• Iteration-led: Easy to fall into along the way, when you’re tinkering and focused on the short term. You can end in a local maximum.

The Boeing 737 Max failure was a 40 year iteration story. It reached a local maximum and a new plane is required to progress further.

Without being able to picture your destination in the long term, your short-term needs are the most visible and determine your direction.

Applying the iteration-led approach in our organizations means that products often don’t reach their full potential. They tend to become bloated, fragmented, directionless, and driven by the wrong metrics.

Occasionally an iteration-led company will hit a local maximum, and do well. Thus entrenching the model in business practices.

The point isn’t that iteration is bad. It’s that we don’t put enough emphasis on being vision-led and there hasn’t been much written about that.

If your vision is as broad as “to go north and have the best road trip,” your feedback-driven iterations could take you to Boston or lead you to Toronto. Taking a vision-driven approach means your vision drives your iterations so you end up where you intended to.

The most practical advice today on staying vision-led has been foggy(setting a BHAG; a Big Hairy Audacious Goal) and is leading companies astray.

Radical Product Thinking helps you build vision-driven products and innovate smarter. It helps you find the global maximum by thinking about the change you want to see in the word. The product then becomes an improvable system to bring about that change. Your product should be led by the change you it’s intended to create.

Radical products are vision-driven, have a clear reason for being, which drives strategy, prioritisation and execution.

Part 1: Innovating Smarter Requires a New Mindset

Chapter 1: Why We Need Radical Product Thinking.

Radical Product Thinking is needed when you're trying to create transformative change, not just improve what already exists. Iteration can produce "good" products that optimise a narrow goal, but it tends to trap teams in local maxima; solutions that look strong inside today's constraints yet fall short of the breakthrough you actually need. The difference shows up when a product is engineered end-to-end to deliver a specific change in the world, rather than assembled from familiar parts to ship quickly.

An iteration-led approach, especially when paired with success measures that collapse into a single financial KPI, rewards short-term optimisation: grow users, lift revenue, hit the next quarter, satisfy investors. It's like capturing a few pieces on a chessboard and mistaking that for winning the game.

Focusing on improving a product in the short-run too much can result in drift, bloating and inconsistency. Be careful of setting up a feedback loop that answers ‘what seems to be working now’… being guided by the loudest customer request, the latest market trend, or the board's pet idea….takes you further away from the important conversation: "where should we go."

Lean Startup and Agile are valuable for feedback-driven execution: tight loops, incremental delivery, and learning from real use. The failure mode is treating them as a substitute for vision, as if the destination will reveal itself through experimentation. Feedback tells you how users respond to what you built; it doesn't define the change you're trying to create. Without a North Star, you can move fast and still end up somewhere you don't want to be: high activity, mounting complexity, and steadily less coherence.

"Radical" here doesn't mean reckless; it means fundamental and far-reaching. Thorough enough to be curative rather than cosmetic. Radical Product Thinking (RPT) means starting from the change you want to bring to the world and treating the product (broadly defined) as the mechanism that engineers that change, so the intent permeates design decisions, organisational boundaries, and daily work.

The Three Pillars of Radical Product Thinking:

1. Think of your product as your mechanism for creating change; the "product" can be software, a service, a policy, research, or an operational workflow, as long as it's the vehicle for impact.
2. Envision the change before engineering the product; define the end state and intended impact first, so you can build and evaluate what matters (and spot unintended consequences).
3. Connect vision to day-to-day activities; translate the vision into strategy, priorities, and concrete tasks so execution consistently produces the desired change rather than motion for its own sake.

Compared with iteration-led work, RPT flips what iteration is for. In the iteration-led model, iteration determines where you go next and the "vision" often shifts to match what tests well; it's reactive optimisation for local maxima. In RPT, the vision is anchored in the change you want to see, and iterations refine how to get there; the goal is purposeful pursuit of the global maximum. Practically, that means fewer "product diseases": less scope creep, fewer contradictory features, less drift caused by treating every piece of feedback as a compass.

Singapore illustrates vision-driven product thinking at national scale. Independence forced clarity about the impact to create: a stable, non-communist, economically viable society with equality across races, built as a "first world oasis" that could attract global businesses and serve as a platform into the region. That vision was converted into a strategy with prioritised initiatives: cleanliness, safety, meritocracy, low corruption, efficiency, a shared language; implemented through sequenced programmes that first built broad buy-in (education and norms) and then used enforcement for the wilful minority. Execution wasn't ideological; it was pragmatic iteration in service of a stable destination: test what works, keep it, discard what doesn't, and revise the approach when outcomes diverge from the vision.

The same pattern shows up in how high-performing public services are designed: each agency defines the impact it aims to create, treats the service as its product, designs the experience around that intent, and continuously improves using user feedback. The point isn't the polish; it's the alignment: vision translated into design goals, operating processes, and measurable experience, repeated up and down the hierarchy so every team's "product" contributes to the collective impact.

Lean and Agile give speed; Radical Product Thinking gives direction. Speed without direction is just faster wandering; direction without execution is just a poster. Combine iterative execution with a vision-driven approach and you get velocity: fast movement towards a deliberate end state, with feedback used to improve the mechanism rather than to decide the mission.

Chapter 2: Product Diseases

If you don’t have a clear vision, your products could become bloated, fragmented, directionless, and driven by irrelevant metrics. They catch product diseases:

• Hero Syndrome: when leaders prioritise the scale and public visibility of their impact over the quality of the solution itself. Driven by a desire to "go big" or satisfy investors, companies focus on valuation and expansion rather than solving genuine customer problems.
• Strategic Swelling: a fear of missing out and an inability to say "no," this disease results in bloated products packed with too many features. Resources are spread thin across a fragmented strategy, diluting the product's overall impact and confusing the market.
• Obsessive Sales Disorder: This condition manifests when long-term strategic goals are repeatedly sacrificed to secure short-term wins. Product roadmaps become fragmented by one-off feature requests to close immediate deals, causing the company to lose its strategic direction.
• Hypermetricemia: An overreliance on measuring data without understanding which metrics actually drive success. By optimising for vanity metrics or tracking everything indiscriminately, organisations fail to focus on the meaningful outcomes that truly benefit the customer.
• Locked-In Syndrome: This happens when organisations rigidly adhere to familiar technologies or approaches due to past success or existing expertise. By focussing on the solution rather than the problem, companies fail to innovate and miss out on better, emerging alternatives.
• Pivotitis: The tendency to drastically change direction whenever difficulties arise, rather than pushing through challenges. Often disguised as a strategic pivot, this results in confused teams, erratic product offerings, and a failure to solve specific problems.
• Narcissus Complex: A condition where an organisation looks inward at its own goals and financial needs to the exclusion of the customer. This self-absorption leads to decisions that optimise for the company's benefit while neglecting user needs or safety.

Part 2: The Five Elements of Radical Product Thinking

3. Vision

A product is the mechanism for creating change, so the work starts by defining the change precisely enough that a team can build toward it and recognise when they’re drifting away from that. A durable vision can be modest and still scale if it stays anchored in the lived problem, not in market share, status, or corporate ambition.

A good vision has three characteristics:

• It’s centred on a real problem you want solved (even if your organisation didn’t exist)
• It describes a tangible end state people can picture.
• It’s meaningful to both the team and the people affected.

When those traits hold, the vision survives leadership changes because it’s grounded in responsibility and shared stakes, not in slogans.

A visualisable end state beats abstract virtues. “Empower people” or “be the leader” is easy to remember but too vague to guide tradeoffs; it can’t tell you what to do next week or what to refuse. Detail creates decision filters: if every opportunity fits, the vision is too broad.

The vision has to galvanise customers as well as the team because it becomes the foundation of messaging and trust. Customers won’t rally behind your desire to “be #1”; they will rally behind a world where their problem is clearly understood, the status quo is treated as unacceptable for specific reasons, and the path to relief is credible.

A quick test: ask team members and a handful of customers to describe the vision in their own words: parroting a tagline signals memorisation, not internalisation.

Radical Product Vision Statement Template:

Today, when [identified group] want to [desirable outcome], they have to [current solution]. This is unacceptable because [shortcomings of current solutions]. We envision a world where [shortcomings resolved]. We are bringing this world about through [basic technology/approach].

The vision should be detailed enough to exclude certain actions that aren’t compatible. You can pair it with an evolution statement to help layout the end gold if you need:

Radical Product Evolution Statement:

We started by changing the way that [customer segment] did [activity/outcome] through [basic technology/approach].

We’ve learned and grown since then, and now believe that the next big step is [end state].

The vision statement must answer five questions; each one forces clarity that prevents drift and "hero" narratives that sound inspiring but don't match what's actually being built.

1. Whose world are you trying to change? Name the specific group you intend to impact; "everyone" hides tradeoffs and produces generic solutions. If multiple groups are affected, list and explicitly prioritise them; this priority will shape your product choices, conflict resolution, and what you measure as success.
2. What does their world look like today? Describe what they're trying to accomplish and how they currently do it, including constraints, workarounds, and the costs (time, money, risk, dignity). This is the grounding that keeps the team solving the real problem rather than designing for assumptions.
3. Why is the status quo unacceptable? Spell out the consequences of leaving things as they are; if you can't articulate them, you may be "disrupting" without necessity. Also validate that the people you want to help actually feel the pain; if they don't experience the status quo as a problem, your "better" future won't pull them in.
4. When will you know you've achieved the vision? Define a concrete end state with observable signs so you can tell progress from motion. The more visual and specific the end state, the easier it is to course-correct without debating philosophy.
5. How will you bring about this change? State the mechanism: product, service, workflow, policy, or technology; so the vision becomes buildable. Treat the mechanism as improvable: execution will reveal where it must evolve, but the change you're aiming for should remain the anchor.

Spreading the vision requires making it co-owned and felt, not just announced. Run a short group exercise: write the template on a whiteboard, have each person fill the blanks with sticky notes (who/what/why/when/how), then reconcile differences until the team can defend one shared version; revisit it on a cadence that matches market volatility (e.g., monthly in fast-changing contexts, twice a year in stable ones).

Internalisation accelerates when people experience the status quo and the relief your solution enables. Create "visionary moments" by putting team members in direct contact with users' frustrations and letting them witness credible reactions to the envisioned future; videos that show the struggle and the intended resolution can scale this exposure across the organisation.

Translate the collective vision into role-level responsibility. Make it explicit how each function contributes to the end state, and define behaviour and standards that reflect the vision (e.g., quality, fairness, customer care), not just output targets. Encourage teams to write their own aligned visions so direction propagates across organisational boundaries and day-to-day decisions stay tethered to the change you set out to create.

4. Strategy

Once you have a vision, you need a product strategy to identify how you’ll get there. Even when aligned behind a radical vision, a product can go awry in the absence of a cohesive strategy.

Product Strategy means asking four questions:

• Real Pain Points: Validated problems or desired that your product addresses. What’s the pain that triggers someone to use your offering?
• Design: Product interface and identity. What functionality in your product solves the pain?
• Capabilities: Enablins assets (tech, content, data, relationships, expertise) What capabilities or infrastructure do you need to deliver on the promise of the solution?
• Logistics: Pricing, delivery, installation, support. How do you deliver the solution to your users?

Product design, capabilities and logistics must be aligned to the validated problems. A good product strategy must be grounded in reality by testing assumptions.

The 4 steps to crafting your own RDCL strategy:

1. Discover Users' Real Pain Points

To build a successful product, you must identify specifically who your users are and what problems trigger them to engage with your solution. You must ensure pain points are "Real" by validating them rather than relying on intuition.

• The Validation Formula: Validated = Valued (users are willing to pay or give up something to solve it) + Verified (research confirms the need exists beyond your own assumptions).
• Who is the specific target user? What are they trying to achieve? Have we confirmed through observation that this pain is shared by others?

2. Design Your Radical Product

Good design is not just aesthetics; it is the strategic shaping of how a user interacts with and perceives your product. It consists of the Interface (how users access features) and the Identity (how the product makes them feel).

• Don't just optimise the status quo; design based on the user's underlying motivation.
• What emotions do users feel when facing their pain, and how should the product make them feel (e.g., relieved, excited)? What features support the user's ultimate goal?

3. Define Your Capabilities

Capabilities are the "special sauce" under the hood that powers your design. While the user experiences the design, the capabilities are the assets that allow you to deliver on that promise.

• Tangible (data, technology, architecture, infrastructure)
• Intangible (relationships, trust, partnerships, processes).
• What unique resources, infrastructure, or expertise do you possess (or need to develop) to deliver this solution better than competitors?

4. Define Your Logistics

Logistics cover the entire customer experience surrounding product acquisition and support. Rather than treating these as afterthoughts, align them with the user’s real pain points. Avoid forcing business models (like subscriptions) where they do not fit the user's needs.

• Channels, platforms, pricing, training, and maintenance.
• How does the product get into the user's hands? What platform will they use (e.g., mobile, paper, web)? What is the pricing model? How will you support or train them?

The role of iteration:

• Test, Don't Lead: Iteration should not be the primary driver of product development ("iteration-led"), as this often leads to optimising for short-term financial metrics rather than long-term value.
• Validate Strategy: Instead, iteration is used to test and refine a pre-defined RDCL strategy (Real pain points, Design, Capabilities, Logistics). You first put a "stake in the ground" based on research, and then use iteration to validate those assumptions against reality.
• Ultimately, iteration serves as a feedback loop that updates your strategy based on real-world execution, acting as the bridge between your high-level vision and your daily tactical activities.

5. Prioritisation

Prioritisation is how vision shows up in daily choices. Most decisions trade off "vision fit" (progress towards the change you want) against "survival" (reducing the biggest near-term risk that could shut you down). Over-index on vision and you may not last long enough to reach it; over-index on survival and short-term metrics replace purpose as the product's real direction.

Use a simple 2×2 rubric with vision fit on one axis (poor → good) and survival on the other (worsens → improves). Plot initiatives, deals, features, and tasks as sticky notes. The point isn't precision; it's shared intuition…so everyone can explain tradeoffs, make calls without waiting for a few leadership folk and stay aligned without micromanagement.

• Ideal (good vision fit, improves survival): advances the vision while lowering risk. Prioritise heavily here, but don't let it crowd out longer-term bets.
• Investing in the Vision (good vision fit, worsens survival): strengthens the long-term trajectory but raises short-term risk (time, cash, stakeholder patience). Take selectively, sized to what you can afford.
• Building Vision Debt (poor vision fit, improves survival): reduces near-term risk while pulling you away from what the product stands for. Use sparingly, explicitly, and with a plan to "pay it down."
• Danger! (poor vision fit, worsens survival): increases risk and moves away from the vision. Avoid unless it clearly unlocks a future move that matters.

Survival means "the biggest risk that could kill the product tomorrow," not "general uncertainty." Risks usually fall into a few buckets: financial (cash/runway), stakeholder (sponsorship/budget), technology/operational (can't scale or ship required capability), legal/regulatory (blocked or sued), personnel (key person loss). You can't outrun every predator at once; pick the one or two most immediate risks and align around them.

Make survival explicit with a short group-written statement:

• Currently, the greatest risk to our product's existence is [risk].
• If this happens, we won't be able to continue operating because [end consequence].
• This risk is more likely if [amplifiers].
• We can mitigate it by [reducers].

"Vision debt" works like technical debt: it can buy time, but interest compounds. Common sources include custom one-offs to close deals, piling on integrations/features that don't belong, borrowing a competitor's core assets, or revenue moves that trade off user trust/privacy/well-being. If you choose it, label it as vision debt, explain why it's necessary for survival, and put repayment into the roadmap; otherwise teams see drift as loss of conviction and customers see inconsistency.

"Investing in the vision" is how you prove the vision is real: fixing technical debt, funding user research, and doing R&D often slows short-term output while improving long-term capability and differentiation. The right amount depends on survival risk; the wrong amount is either starving the future or ignoring the runway.

Use the rubric as a communication tool, not a one-time exercise:

1. Restate the two axes (your specific vision definition and your current survival statement).
2. Plot options together and force the "why here?" conversation for each sticky note.
3. Bias towards Ideal, reserve capacity for Investing in the Vision, minimise Vision Debt, and treat Danger! as exceptional.
4. Share the quadrant map to communicate the plan, structure hard conversations (especially about tradeoffs), and make your product intuition legible to stakeholders.

Revisit as conditions change. Survival risks evolve, and different teams may have different "survival" definitions (e.g., R&D team = tech feasibility; growth team = cash or stakeholder support). The value comes from repeatedly aligning on the axes, then using the same simple picture to explain decisions across the organisation.

6. Execution and Measurement

A product is only “successful” if it creates the change your vision describes, so execution and measurement have to be built around that change rather than around whatever metrics are easiest or most fashionable.

Popular indicators like engagement, NPS, signups, or even revenue can climb while the product reinforces the wrong behaviour, because they often measure convenience or extraction rather than progress toward the intended outcome.

Treat vision and strategy as hypotheses under uncertainty. Each strategic bet is an assumption about cause and effect; measurement exists to validate (or falsify) those assumptions, then refine the strategy and experiments accordingly.

“Data-driven” only helps when the data reflects the change you’re trying to engineer.

Use a hypothesis-driven loop that makes the connection between what you ship and what you measure explicit:

• If [experiment], then [outcome], because [connection].

This forces clarity on why an activity should move a metric, and prevents “shipping features” from becoming the goal.

A simple execution-and-measurement template keeps this grounded in daily work:

1. Key metrics: the few indicators that show whether you’re moving toward the vision and whether each element of the strategy is working (not proxies that merely look good).
2. Hypotheses: the “if/then/because” link between the experiment and the metric.
3. Activities: the concrete tasks required to run the experiment; in Agile teams these become sprint work.

Lean and Agile fit naturally here as execution engines: they help you run the experiments, learn fast, and iterate. The constraint is that iteration must be driven by the hypotheses implied by your vision and strategy, otherwise you end up “customer-led” by the loudest requests and trending metrics. MVP scope also follows from strategy and pain: “minimally viable” can mean high reliability in mission-critical contexts and scrappy prototypes in low-stakes ones.

Resist turning product metrics into performance goals. Goal-setting frameworks often narrow attention to a few numbers, discourage experimentation on complex problems, and can incentivise gaming, corner-cutting, or unethical behaviour: especially with stretch targets and accountability tied to hitting them. Measurement should support learning and ethical improvement, not pressure people into optimising the scoreboard.

Replace goals-based management of product metrics with a collaborative measurement cadence:

1. Align on what you'll measure: agree on the metrics that indicate progress towards the vision and validate the strategy; educate stakeholders if these differ from "traction" clichés.
2. Create a safe environment to discuss metrics: teams must be able to present real results (including bad news) without punishment, or they'll selectively report and managers will lose signal.
3. Manage progress through regular feedback: review baselines, discuss desired direction and pace, and adjust priorities and experiments continuously: accountability through transparency and iteration, not through fixed targets.

7. Culture

Culture can be treated like a product: a mechanism that creates an environment where intrinsic motivation thrives and the behaviours you need (investing in the vision, not taking shortcuts that accumulate vision debt) become the default.

Culture is the cumulative experience of daily work and interactions. Most days are implicitly a tradeoff across two dimensions: whether the work feels satisfying or depleting, and whether it feels urgent or not.

A simple 2×2 makes that tradeoff discussable and actionable:

• Meaningful Work (satisfying, not urgent): deliberate progress on problems that matter; the “do more of this” zone.
• Heroism (satisfying, urgent): firefighting under pressure; occasional urgency can be energising, but persistent heroism is a burnout factory.
• Organisational Cactus (depleting, urgent): bureaucracy, approvals, reporting, and admin that feels painful yet unavoidable; too much makes the org sluggish.
• Soul‑Sucking (depleting, not urgent): chronic drains like self-censorship, managing up, unfairness, or toxicity that erode energy over time.

A clear culture vision is simply: make the Meaningful Work quadrant larger and the three danger quadrants smaller. The rubric is a tool to surface how people actually experience work (not how leaders intend it), so the team can align on what’s driving each quadrant and what should change.

Run an honest mapping conversation: list recurring activities/interactions, place them in the quadrants, then focus on root causes (not symptoms). Just like real product work: Identify the real pain point, design the intended change, build capabilities, and fix logistics/incentives: so culture change becomes an executable plan rather than values-wordsmithing.

Each danger quadrant has predictable levers. Heroism shrinks when workload and deadlines become sustainable and rewards shift from “rescues” to prevention and steady delivery. Organisational Cactus shrinks when you target the worst bureaucratic friction points and address underlying misalignment that creates endless meetings/overruns before you add process “best practices.” Soul‑Sucking shrinks when you reduce unfairness and stop tolerating “superchicken” behaviour that boosts individual output by suppressing others; keep accountability, but balance it so high performers aren’t punished by having to compensate for chronic underperformance.

Diversity requires more than hiring. Minorities are more likely to experience larger danger quadrants: more soul‑sucking through discrimination and slights, more heroism from stereotype pressure and high-stakes scrutiny, more cactus through grunt work and reduced autonomy, and less meaningful work through underutilisation. Measure and discuss the distribution of experiences (often best via anonymous, segmented signals) so you can see where specific teams, managers, or groups are carrying disproportionate load and fix the system, not the person.

Psychological safety is a prerequisite for these conversations and for doing RPT well (challenging ideas, sharing hypotheses, admitting mistakes, learning from metrics). It can be deliberately modelled and reinforced through:

• Fallibility: making it safe to be wrong and correct course.
• Direct communication: caring personally while challenging directly.
• Accessibility: frequent, genuine interactions that lower the interpersonal risk of speaking up.

Part 3: Making Our World a Little More Like the Oe We Want to Live In

8. Digital Pollution

Iteration-led products optimise for financial metrics and often accept unintended societal harm as collateral damage, reinforcing the false choice that you can either be successful or make the world better. The pattern isn't limited to a few "big tech" companies; any team chasing local maxima can create downstream effects it never intended.

"Digital pollution" is the societal damage caused by unregulated, metric-driven digital growth, analogous to environmental pollution from unregulated industrial growth. It's hard to see in the moment because the underlying decisions usually aren't malicious: they're rational optimisations for engagement, revenue, growth, or convenience.

Five common forms show up repeatedly:

• Fuelling inequality: products and models that encode bias, amplify stereotypes, or shift risk from firms to workers, widening economic and social gaps.
• Hijacking attention: designing for constant interruption and validation loops that increase stress and reduce deep thinking and nuance.
• Creating ideological polarisation: engagement incentives and recommendation algorithms that reward outrage, push users into "rabbit holes," and erode shared reality.
• Eroding privacy: defaulting to collecting and retaining data "just in case," normalising surveillance and enabling manipulation; privacy functions as a collective protection, not a niche preference.
• Eroding the information ecosystem: business models and distribution systems that make truth easier to game, increasing disinformation and reducing trust in what's real.

The same product category can either settle for a local maximum (serving one group well while excluding or harming others) or pursue a global maximum by embedding equity and societal impact into the design constraints: even when that extra effort doesn't immediately show up in standard financial metrics.

Charities can't carry the responsibility of societal well-being alone; businesses shape far more daily life. Sustainable progress requires companies to pursue profits with a clear purpose, designing products as mechanisms to create an intended end state and measuring success by progress towards that end state: not just by what spikes engagement or revenue.

9. Ethics

Building products is closer to practising medicine than making widgets: you identify a problem, intervene with a "treatment," and that intervention can have side effects at scale. Modern products can reach millions fast, so harm can compound before anyone fully understands what's happening; "move fast" becomes dangerous when the blast radius is society.

Ethical responsibility is often dodged with familiar excuses: "If we don't build it, someone else will," "we'll be the good guys," or "it's the user's responsibility." That logic normalises harm the way litter spreads when everyone sees a dirty car park—each individual act feels small, but the aggregate outcome degrades the commons.

Prisoner's Dilemma explains why this pattern persists. If each company optimises for its own gain (growth, revenue, engagement) and ignores downstream damage, the dominant strategy is to "defect," and the likely equilibrium is a suboptimal world of uncontrolled digital pollution. Collective well-being improves only when organisations cooperate by designing for the global maximum, not local maxima.

Escaping that equilibrium takes a holistic push, not a single lever:

• Intimidation / consequences: regulation and enforcement to deter harmful behaviour.
• Incentives: economic and reputational advantages for responsible behaviour, not just punishment after scandals.
• Inspiration: tapping intrinsic motivation—people generally want their work to improve collective well-being, but they need clear accountability and visibility into real-world effects.

Compartmentalising "do well" (profit) and "do good" (philanthropy) doesn't fix the damage created by core business models and product decisions. If the product creates harm, donating later is a weak correction mechanism and often misaligned with what society actually needs.

A practical Hippocratic Oath of Product means baking ethics into the five elements of product building:

• Vision: centre the vision on the user's problem and the change you want for them, not on your status, valuation, or shareholder outcomes.
• Strategy: align the business model's incentives with user well-being so "doing the right thing" isn't fighting the revenue engine.
• Prioritisation: make values real by letting ethical considerations change what you choose and what you refuse; don't treat principles as wall art.
• Execution and measurement: measure success by progress towards intended impact (and watch for unintended consequences), not just usage, growth, or revenue.
• Culture: normalise purpose beyond profit, and build psychological safety so anyone can flag harm, misalignment, or unethical shortcuts without retaliation.

The goal isn't altruism at the expense of survival; it's responsible profitability. Profit keeps the mechanism alive, but the mechanism must be designed and steered so it improves users' lives without creating collateral damage that accumulates into digital pollution.

Conclusion

• Create a compelling vision of the change you want to bring about.
• Craft a strategy to give you an actionable plan.
• Prioritise so that your vision features in your everyday decision making.
• Measure what matters to know if you’re making progress toward your vision.
• Embed your purpose in your organisational culture.