Skills / Product-management

Inspired

The most important thing is to discover a solution that is valuable, usable, feasible, and viable — before you ask a single engineer to write a line of production code.

Inspired brings Marty Cagan's SVPG product framework to your conversations — the same methodology behind product teams at Google, Netflix, and Amazon. It guides product managers through the Four Big Risks assessment, continuous customer discovery, and the shift from output-driven roadmaps to outcome-driven OKRs. Built for PMs who want to run empowered product teams, not feature factories.

By Marty Cagan  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisInspired

Input

“We want to add an AI-powered spend analysis dashboard to our B2B finance app. CFOs would see anomaly alerts and budget forecasts automatically.…”

Diagnosis

Let's run a Four Big Risks assessment before you take this idea to engineering.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Stop building features. Start solving problems customers actually have.

Cagan's framework centers on a foundational split between Product Discovery and Product Delivery — two parallel tracks that most teams dangerously conflate. Discovery is about rapid, cheap validation; Delivery is about building correctly at scale. Before any engineering commitment, every product idea must clear the Four Big Risks: Value Risk (will customers want it?), Usability Risk (can they figure it out?), Feasibility Risk (can the team build it?), and Business Viability Risk (does it work legally, financially, and operationally?). Discovery is executed through a prescriptive toolkit — weekly customer interviews, concierge tests, Wizard of Oz tests, low-fidelity and live-data prototypes — all designed to fail fast and cheaply. Teams structured as empowered product teams (given problems to solve, not features to build) are held accountable to business outcomes tracked through OKRs, not delivery velocity measured on roadmap completion.

The problem

Most product teams are feature factories: engineering builds what's on the roadmap, PMs write PRDs, and months of development ship to customers who don't use it. Cagan identifies the root cause as conflating discovery and delivery — committing engineering resources before validating that any of the four risks (value, usability, feasibility, viability) have been addressed. Feature roadmaps institutionalize this failure pattern.

The solution

Run your product ideas through the Four Big Risks before committing a single sprint — so your engineering team builds things customers love instead of a graveyard of unused features.

You bring

A product idea, feature request, or problem you're evaluating
Context about your customers, team structure, and business constraints
Your current roadmap or backlog (optional — to diagnose feature-factory patterns)
Specific discovery questions or customer interview goals

You get

A Four Big Risks scorecard identifying your highest-priority validation gap
A discovery plan specifying which techniques (prototype, concierge, interview) to run first
A draft Opportunity Assessment in SVPG format — a structured PRD replacement
A reframed roadmap structured around outcomes and OKRs instead of features and dates

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, before and after, the full transcript, and the skill answering live in the channel where the work happens.

Fig.01  —  The same situation, two ways

Specimens A · B

Specimen ABefore

Without the skill

Your CEO got excited about an AI dashboard after two customer conversations at a conference. Engineering has scoped it at 8 weeks. The roadmap shows it shipping in Q2. No one has talked to a CFO since the conference. Three weeks into the sprint, your lead engineer asks what data format the anomaly alerts use — and nobody knows.

×The situation as it arrives — before the methodology is applied.

Specimen BAfter

With Inspired

After six customer interviews, you discover CFOs don't investigate anomalies themselves — they assign it to controllers. You pivot the target user, reframe the core job-to-be-done, and run a low-fidelity prototype test in week two. Engineering starts with a validated problem statement, a clear user, and a Usability Risk already addressed by prototype feedback. The 8-week build ships to users who actually needed it.

◦The same situation once the methodology holds.

Fig.02  —  A real session, unedited

In-app · assistant

InspiredClaude

Inspired

Let's run a Four Big Risks assessment before you take this idea to engineering. Tell me about the product or feature you're evaluating — what's the core idea, and who is the target customer?

We want to add an AI-powered spend analysis dashboard to our B2B finance app. CFOs would see anomaly alerts and budget forecasts automatically. Engineering estimated 6–8 weeks.

Good — let's stress-test this across all four risks before those 8 weeks start. First, Value Risk: do you have evidence CFOs will actually use this, or change behavior based on the alerts? Have you interviewed any CFOs about how they currently investigate spend anomalies today — and what they do with that information?

Honestly, this came from our CEO who talked to two customers at a conference. We haven't done structured interviews yet.

That's your highest risk right now — Value Risk. Two anecdotes from a conference is idea validation, not demand validation. Before touching engineering, I'd run 5–8 continuous discovery interviews with CFOs focused on one question: 'Walk me through the last time you caught a budget anomaly — how did you find it, what did you do with it, and what would have made that faster?' You're not pitching the feature. You're learning the existing behavior. If CFOs aren't currently investigating anomalies at all, an alert dashboard won't change that — it'll just be ignored.

That makes sense. What about the feasibility side — our ML team is pretty confident they can build the anomaly detection.

Feasibility Risk looks lower here — you have the ML capability. But there's a secondary Feasibility question: data access. Anomaly detection only works if you have clean, complete transaction data. What's the quality of the financial data you'll have access to at the CFO level? The Viability Risk I'd also flag is compliance — financial forecasting tools can trigger regulatory questions around what counts as 'financial advice.' Worth a quick legal check before you build. So your risk stack is: Value Risk (highest — needs interviews), Viability Risk (medium — legal check), Feasibility Risk (lower — ML is in-house but data quality TBD).

I hadn't thought about the compliance angle at all. So what's the actual discovery plan here?

Here's the two-week discovery sprint: Week 1 — run 6 customer interviews using a problem-framing script (I can help you write it) focused on the existing anomaly detection workflow. If you hear consistent pain around current gaps, move to Week 2: build a low-fidelity prototype — static mockups of the dashboard and alert UI — and run usability tests with 3 CFOs. Simultaneously, get your legal team to flag any compliance boundaries. At the end of two weeks you'll have answered Value and Usability Risk cheaply, before a single line of production code. Want me to draft the discovery interview script and the opportunity assessment?

Reply to Inspired…

What the skill is doing

01Four Big Risks Assessment

02Discovery Plan Design

03Opportunity Assessment Writing

Fig.03  —  The same skill, in the channel you already use

WhatsApp · live

9:41

IInspiredtyping…

Messages are end-to-end encrypted. No one outside of this chat can read them.

Today

We want to add an AI-powered spend analysis dashboard to our B2B finance app. CFOs would see anomaly alerts and budget forecasts automatically. Engine…9:14✓✓

Let's run a Four Big Risks assessment before you take this idea to engineering.9:14

Tell me about the product or feature you're evaluating — what's the core idea, and who is the target customer?9:15

Message

The same skill, where the work happens.

No new app to learn. The methodology runs over the WhatsApp Business API, so the answer lands as a reply in the thread you’re already in — same rigour, zero context-switch.

◦Reads the situation, names the pattern, returns one concrete next move.

◦Delivered in seconds, inside a conversation that already exists.

Specimen · WhatsApp Business API · live

Capabilities

What it does, specifically.

Each capability is a distinct move drawn straight from the source methodology — not a generic assistant guessing.

CapabilityC-01

Four Big Risks Assessment

Evaluates any product idea or feature against Cagan's four risk dimensions: value, usability, feasibility, and business viability. Surfaces the highest-priority risk and recommends the discovery technique best suited to address it cheaply before engineering commits.

◦ MethodDirectly maps to Cagan's core thesis in Inspired that every product idea carries these four risks, and that discovery's job is to de-risk all four before entering the delivery track.

CapabilityC-02

Discovery Plan Design

Builds a sequenced plan of discovery activities — customer interviews, prototypes (low-fidelity, high-fidelity, live-data), concierge tests, or Wizard of Oz tests — matched to your product's specific risk profile and available time.

◦ MethodBased on Cagan's prescriptive discovery toolkit from Inspired, which defines each technique's appropriate use case, required fidelity level, and the risk type it addresses.

CapabilityC-03

Opportunity Assessment Writing

Guides you through writing an Opportunity Assessment — Cagan's structured replacement for traditional PRDs. Covers the five key questions: What problem are we solving? Who are we solving it for? How does success get measured? What alternatives exist? Why are we uniquely positioned?

◦ MethodBased on Cagan's explicit prescription in Inspired to replace feature specs and PRDs with opportunity assessments that start from customer problems rather than solutions.

CapabilityC-04

Feature-Team vs. Empowered-Team Diagnostic

Assesses whether your team is operating as a feature team (mercenaries executing a roadmap) or an empowered product team (missionaries accountable for outcomes). Identifies structural and behavioral indicators and suggests concrete changes.

◦ MethodBased on Cagan's missionaries-vs-mercenaries framework in Inspired and Empowered, which defines the specific conditions — autonomy, accountability, skill depth — that distinguish the two team types.

CapabilityC-05

OKR Roadmap Reframe

Takes a feature-centric roadmap and reframes it as an outcome-based OKR plan. Converts 'ship X feature by Q3' commitments into 'improve Y metric by Z%' objectives with key results tied to discovery validation milestones.

◦ MethodBased on Cagan's explicit argument in Inspired that feature roadmaps are a root cause of product failure, and his prescription to replace them with OKR-driven outcome roadmaps bridging vision to quarterly team objectives.

Tested

Graded before it shipped.

Every skill is scored against independent scenarios for methodology fidelity before it goes live — not vibes, a rubric.

What it produces

OutputD-01

Four Big Risks Scorecard

A structured assessment rating your product idea's exposure to each of the four risks on a 1–5 scale, with the highest-risk dimension flagged and a recommended discovery technique attached to each gap.

OutputD-02

SVPG Opportunity Assessment

A completed opportunity assessment document in Cagan's format — problem definition, target customer, success metrics, competitive alternatives, and team fit — replacing a traditional PRD before any engineering work begins.

OutputD-03

Discovery Sprint Plan

A sequenced two-week discovery plan specifying which prototype or test to run (and at which fidelity), who to recruit for customer sessions, and what learning question each activity must answer before advancing.

OutputD-04

Outcome Roadmap (OKR Format)

A reframed roadmap organized by quarterly OKRs — each objective tied to a customer or business outcome, key results tied to measurable indicators, and features listed as hypotheses rather than commitments.

The source

Grounded in the original work.

Every answer traces back to a real source and the practitioner who wrote it — not a secondhand summary. Here is the source of record.

Source authorA-01

Marty Cagan

Marty Cagan is the founder of Silicon Valley Product Group (SVPG) and former VP of Product at eBay and senior executive at Netscape and HP. His book Inspired (2008, revised 2018) is widely considered the definitive text on modern product management, and has been required reading at companies including Google, Amazon, and Microsoft. He followed it with Empowered (2021) and Transformed (2024), forming the canonical trilogy on the SVPG product model.

Status · Inspired by Marty Cagan’s work — not yet claimed. Are you Marty Cagan?

Primary sourceS-01

Inspired: How to Create Tech Products Customers Love

by Marty Cagan

Founder of SVPG; former VP Product at eBay; author of Inspired, Empowered, and Transformed; advisor to product teams at Google, Apple, Netflix, and hundreds of startups.

Read the original ↗

Citationsvpg.com

In the build queue

Be first to run it.

Inspired is being built right now. Leave your email and we’ll tell you the moment it goes live.

Notify meEmail

At launchI have a product idea I need to take to engineering next week, but I'm not sure we've really validated it. Can you walk me through a Four Big Risks assessment so I know what we're missing before we commit the team?