I built a hypothesis-driven ideation workflow using Claude skill
Give it a problem statement and a handful of assumptions; It researches and risk-ranks those assumptions, frames testable hypotheses, sketches feature concepts w/ wireframes, and builds a validation plan with clear pass or fail thresholds.
What's a Claude skill
A skill is a saved set of instructions Claude follows whenever a matching task comes up. Instead of re-explaining my process in every conversation, I wrote it once, tested and iterated with a real use case, and Claude now applies the same research discipline and judgment calls to any new idea I bring it.
Why this exists
This helps give a head start on a product idea I have, based on assumptions I've picked up from my own experience or from research data. It takes my understanding about the product and the raw data I've collected, and structures it in a format that gives me a direction for validating the idea.
Product ideation is usually inconsistent. How rigorous it is depends on who's doing it, how much time they have, and what they remember to check. I wanted a process that applies the same bar every time: the same research discipline, the same way of deciding which assumptions matter most, and the same hypothesis structure, regardless of how rushed I am or how much data I have.
Inputs and outputs
What goes in is deliberately minimal. What comes out is a structured plan you can act on.
Inputs
Problem statement
The idea or feature being considered
Target user (optional)
My current understanding of what the end user would look like
Supporting assumptions
In my own words, no particular structure required
Outputs
Risk-ranked assumptions
Stated by me or sourced through research
Testable hypotheses
Numbered H1, H2, H3...
Feature concepts, with wireframes
One to three per hypothesis
A validation plan
Pass or fail thresholds per concept
Success metrics
Leading and lagging indicators
One shareable document
A first draft of the product strategy document
How it works
Eight stages run in order. I approve each section while moving forward and findings get approved only with a valid source attached.
Gather the inputs
I give it a problem statement and whatever assumptions I already have. If I don't have a target user defined yet, it doesn't block on that, it waits and builds one from research once it's actually needed, further down the process.
Build and research the assumptions
Each assumption gets checked against real market data, usage stats, or survey findings, with a link to the source every time. It also researches competitors and similar products, since what established players choose to build says something about which problems are real.
stated assumptions → research backed consolidated list
Rank by risk
Before any hypothesis gets written, every assumption is scored on two questions: how much is riding on it, and how much real evidence already supports it. The ones that are both important and unproven get tested first.
consolidated assumptions → priority order
Frame testable hypotheses
Each hypothesis names the solution, the specific user segment, the predicted outcome, and the reasoning behind it. For a genuinely new product, the outcome stays directional rather than guessing at a number with no baseline to justify it.
top-ranked assumptions → well-framed hypotheses
Propose feature concepts and wireframes
Each hypothesis gets one to three concrete feature ideas. It also builds wireframes for each one, so the concepts are something a person can actually visualize, not just read about.
hypotheses → feature concepts + wireframes
Define validation and thresholds
For every concept, it picks the lightest test that can still produce a real signal, such as an interview or a survey, and states up front what result would count as a strong success, a partial one, or a failure.
feature concepts → test plan + pass/fail thresholds
Set success metrics
For each concept, it lists what to watch early, such as adoption signals in the first week, and what to watch later, such as retention, satisfaction, and revenue.
concepts taken forward → leading + lagging metrics
Consolidate into one document
Everything gets pulled into a single write-up, a first draft of the Product Strategy Document. This is primarily to share and discuss with stakeholders how I'll be moving forward. Iterations to this document will happen as product research progresses.
everything above → product strategy document
Proof it runs end to end
I ran the full workflow on a test idea: an app to help groups plan outings with friends, family, or colleagues. In one pass it produced seven ranked assumptions, three testable hypotheses, six feature concepts with wireframes, and a validation plan. All this neatly drafted into a product strategy document. I used this test idea to shape the output of the workflow better.
None of this has been tested with real users yet. That is what the validation plan calls for next. What the workflow does is strategize from start to finish: it collects the main inputs from me, does the initial legwork of gathering data points, and structures the findings using the hypothesis-driven approach into an actionable plan.
Wireframes from Hypothesis 1: Guided Outing Builder
