Skills / Ux-design

Lean UX

We need to get out of the deliverables business and into the outcomes business.

Lean UX is a hypothesis-driven design framework that fuses Lean Startup thinking, Agile development, and UX practice into a structured, outcome-focused process. Built around the Lean UX Canvas and a precise hypothesis statement format, it gives product teams a repeatable way to articulate what they believe, surface their most dangerous assumptions, and design the smallest possible experiment to learn fast. Developed by Jeff Gothelf and Josh Seiden, it's the methodology that moved the product community from 'ship features' to 'achieve outcomes.'

By Jeff Gothelf  ·  Free

Use this skill See it in action

Specimen 01 · Live diagnosisLean UX

Input

“We're building a notification feature for our SaaS app. The team thinks that if we add smart notifications, users will log in more often. But we…”

Diagnosis

Before we design anything, we need to surface what we believe — and which of those beliefs might be wrong.

Full transcript ↓

Calibrated referenceagent-skills.ai

The gap

Get out of the deliverables business and into the outcomes business

Lean UX centers on two interlocking tools: the Lean UX Canvas — an 8-box structured artifact teams fill in collaboratively, moving from business problem through user outcomes, solution ideas, and hypothesis formulation to experiment design — and the Hypothesis Statement, a fill-in-the-blank template ('We believe that [doing this] for [these users] will achieve [this outcome]. We will know we are right when we see [this metric].'). Before any design work begins, teams run Assumption Mapping: listing every business, user, and technical belief underlying the product direction, then ranking each assumption by risk (importance × certainty) to identify what must be tested first. Proto-Personas provide lightweight, collaboratively built user archetypes — a 4-quadrant card capturing demographics, behaviors, needs/goals, and current solutions — that let teams move quickly without waiting for months of research. The process closes with Minimum Viable Experiment design: the least amount of work (Box 8 of the Canvas) needed to validate the highest-risk hypothesis before committing to full development.

The problem

Most product teams operate in the deliverables business: they define features, estimate stories, ship code, and measure velocity — never pausing to ask whether any of it changed user behavior. The result is products built on untested assumptions, discovered to be wrong only after months of expensive development. Lean UX exists because teams need a structured way to make their beliefs explicit, rank them by danger, and test them before committing to build.

The solution

Walk away with a completed Lean UX Canvas, a set of testable hypothesis statements, and a ranked assumption map — a clear picture of what you believe, what you don't know, and the smallest experiment that will tell you if you're right.

You bring

A product idea, feature request, or business problem you're trying to solve
Some sense of who your target users are — even rough assumptions work
A desired outcome: what change in user behavior would signal success
Any existing beliefs about what the solution should look like

You get

A completed Lean UX Canvas with all 8 boxes filled, ready to guide your team
One or more properly formatted hypothesis statements with testable success metrics
A ranked assumption map that tells you which belief to test first
A proto-persona card for each key user type, built from your current knowledge
A minimum experiment design specifying the smallest test that will validate your highest-risk hypothesis

In action

Watch the methodology work.

Three specimens from a single real session: the same situation, unaided and calibrated, 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 AVague

Unaided

“Your team has been debating notification designs for two weeks: push vs. email, daily vs. weekly, personalized vs. generic. The roadmap has 'Smart Notifications' scoped for the next sprint. No one has written down what success looks like, and the word 'outcomes' hasn't come up once. Three untested assumptions are driving every decision, and no one knows which one will sink the feature if it's wrong.”

×Vague — nothing concrete to act on.

Specimen BCalibrated

With Lean UX

“You have a completed Lean UX Canvas the whole team aligned on in one session. Your hypothesis statement names a specific metric — teammate invitations up 15% in 7 days — so you'll know in two weeks whether the feature worked. Your assumption map identified one belief so risky that you ran 10 user interviews before engineering wrote a single line of code. Those interviews revealed users weren't inactive by accident — they'd hit a confusing onboarding step and abandoned the product. The notification project is paused. The onboarding project just jumped to the top of the roadmap.”

◦Specific, grounded, and ends with one clear next step.

Fig.02  —  A real session, unedited

In-app · assistant

Lean UXClaude

Lean UX

Before we design anything, we need to surface what we believe — and which of those beliefs might be wrong. Lean UX starts not with wireframes but with assumptions. Tell me about the product or feature you're working on: what problem are you trying to solve for the business, and what change in user behavior would tell you that you'd succeeded?

We're building a notification feature for our SaaS app. The team thinks that if we add smart notifications, users will log in more often. But we haven't really defined 'more often' or why that matters to the business.

Good — you've already spotted the gap. 'Log in more often' is an output metric; it doesn't tell you whether users are getting value or whether the business benefits. Let's fill in Box 2 of the Lean UX Canvas — Business Outcomes — before we go any further. A business outcome has to describe a measurable change in user or customer behavior that signals the business is healthier. What would users actually do differently if notifications were working? Complete more tasks? Reach a milestone they were stalling on? Invite teammates they'd been meaning to add?

Honestly, we think users who log in more often end up inviting their teammates — and that's what drives our expansion revenue.

Now we're getting somewhere. Teammate invitations driving expansion revenue — that's a real business outcome you can measure. Let's make this a hypothesis statement:

'We believe that sending personalized activity notifications to inactive users will cause them to return to the app and invite at least one teammate within 7 days. We will know we are right when we see a 15% increase in teammate invitations from users who receive notifications compared to those who don't.'

Before we call that done — what are the assumptions buried inside it? I can see at least three that could be wrong. Can you spot them?

I guess we're assuming inactive users actually *want* to come back? And that notifications are what's stopping them, not something else entirely?

Exactly. Here's your assumption risk map:

Inactive users want to return — if they churned intentionally, no notification will help. Importance: high. Certainty: low. → Riskiest assumption.2. Lack of notification is the main barrier to return — it might be onboarding friction, a missing feature, or pricing. Importance: high. Certainty: low. → Also high risk.3. Returning users will invite teammates — the causal link between login and invitation isn't proven. Importance: high. Certainty: medium.

Box 7 of the Canvas asks: what's the most important thing to learn first? Your answer is now clear — not which notification format converts best, but whether inactive users are even reclaimable.

We've actually never talked to users who went inactive. We just assumed they needed reminders.

That takes us straight to Box 8: what's the least work needed to learn what you need? Ten customer interviews with recently inactive users. No engineering. No design sprint. That's your minimum experiment, and it costs a week, not a sprint. If they say 'I just forgot about the app,' you build the notification. If they say 'I couldn't figure out how to use the core feature,' you've just saved your team six weeks of building the wrong thing.

Reply to Lean UX…

What the skill is doing

01Lean UX Canvas Facilitation

02Hypothesis Statement Builder

03Assumption Risk Mapping

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

WhatsApp · live

9:41

LULean UXtyping…

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

Today

We're building a notification feature for our SaaS app. The team thinks that if we add smart notifications, users will log in more often. But we haven…9:14✓✓

Before we design anything, we need to surface what we believe — and which of those beliefs might be wrong.9:14

Lean UX starts not with wireframes but with assumptions.9:15

Tell me about the product or feature you're working on: what problem are you trying to solve for the business, and what change in…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

Lean UX Canvas Facilitation

Guides you through all 8 boxes of the Lean UX Canvas in sequence: business problem, business outcomes, users, user outcomes, solution ideas, hypotheses, most important thing to learn, and minimum experiment. Each box builds on the previous, ensuring your team's thinking is coherent before any design work begins.

◦ MethodBased on Gothelf and Seiden's 8-box Canvas structure, designed to be completed collaboratively as a team artifact before any wireframes or user stories are written.

CapabilityC-02

Hypothesis Statement Builder

Takes your product context and converts it into one or more properly formatted Lean UX hypothesis statements. Each statement names the feature or action, the target user, the expected outcome, and the specific metric or signal that will confirm or refute the belief.

◦ MethodImplements Gothelf's fill-in-the-blank hypothesis template: 'We believe that [doing this] for [these users] will achieve [this outcome]. We will know we are right when we see [this metric/signal].'

CapabilityC-03

Assumption Risk Mapping

Elicits all business, user, and technical assumptions underlying your product direction, then helps you rank each by two axes: how important it is to the product's success, and how certain you are that it's true. The resulting map identifies your riskiest assumptions — the ones worth testing immediately.

◦ MethodBased on Lean UX assumption mapping, which classifies assumptions across three domains (business, user, technical) and ranks them by importance × certainty to surface the highest-risk beliefs before committing to solutions.

CapabilityC-04

Proto-Persona Workshop

Builds lightweight user archetypes using a structured 4-quadrant format: demographics and background, behaviors and usage patterns, needs and goals, and current solutions the user relies on. Proto-personas are based on your current knowledge and assumptions — not months of research — so teams can move fast while staying user-centered.

◦ MethodImplements Gothelf's proto-persona format, designed to be assembled collaboratively in a single session and revisited as real research accumulates, rather than treated as a gated research output requiring stakeholder sign-off.

CapabilityC-05

Minimum Experiment Design

Maps your highest-risk hypothesis to the smallest possible test artifact — landing page, concierge test, paper prototype, or functional spike — and defines exactly what you'll measure and what result would confirm or invalidate the hypothesis.

◦ MethodCorresponds to Boxes 7 and 8 of the Lean UX Canvas: 'What is the most important thing to learn first?' and 'What is the least amount of work we need to do to learn it?' — producing a concrete test plan before any sprint commitment is made.

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

Lean UX Canvas

A completed 8-box canvas covering business problem, target outcomes, users, user benefits, solution ideas, hypothesis statements, learning priorities, and experiment design — the team's shared belief system before any build begins.

OutputD-02

Hypothesis Statement Set

A set of formally structured if-then belief statements, each naming the feature, target user, expected outcome, and measurable signal — formatted for team review, stakeholder alignment, and experiment prioritization.

OutputD-03

Assumption Risk Matrix

A categorized list of business, user, and technical assumptions underlying your product direction, ranked by importance and certainty, with the riskiest assumptions clearly flagged for immediate testing.

OutputD-04

Proto-Persona Card

A 4-quadrant user archetype covering demographics, behaviors, goals and needs, and current workarounds — built from existing team knowledge in a single session, ready to anchor design decisions until real research data arrives.

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

Jeff Gothelf

Jeff Gothelf is the co-creator of Lean UX and co-author (with Josh Seiden) of the O'Reilly book Lean UX, now in its third edition and the defining text on hypothesis-driven product design. He also co-authored Sense & Respond with Seiden. Gothelf coaches executive and product teams at organizations worldwide on Lean and Agile UX practices and is a frequent speaker at major product and design conferences.

Status · Inspired by Jeff Gothelf’s work — not yet claimed. Are you Jeff Gothelf?

Primary sourceS-01

Lean UX: Designing Great Products with Agile Teams (3rd Edition, O'Reilly)

by Jeff Gothelf

Co-creator of Lean UX; O'Reilly author (3 editions); co-author of Sense & Respond; executive coach and speaker on outcome-driven product development.

Read the original ↗

Citationjeffgothelf.com

In the build queue

Be first to run it.

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

Notify meEmail

At launchMy team is about to build a feature but we're all working off different assumptions and haven't agreed on what success looks like. Can we use the Lean UX Canvas to get aligned and figure out what we need to test first?