Workstream 3
Product Discovery Assistance
Most software risk begins before anyone writes code.
Customers, founders, operators, and technical teams often start with different versions of the same problem. Product Discovery Assistance is the part of Kanbien focused on turning early stakeholder conversations into visible stories, decisions, follow-up questions, and approvable work before the build begins.
The Problem
The problem with vague requirements
Software teams rarely fail because nobody can type code. They fail because the requirement stays fuzzy for too long: the wrong person answers the wrong question, assumptions get buried in chat, and delivery starts before the decision points are visible.
AI can make that worse if it rushes from conversation to output without showing what it understood, what remains uncertain, and who needs to approve the next step.
The Bet
Discovery should become an inspectable product artifact
The bet behind Product Discovery Assistance is that early requirements work can be made visible enough for humans to steer, correct, and approve while the harness keeps track of context.
Instead of treating discovery as a loose transcript, the workflow routes stakeholder input into stories, tasks, decision points, and follow-up questions that can be reviewed before the feature compiler or front-end builder take over.
What It Does
What Product Discovery Assistance does
- Turns stakeholder conversations into a visible discovery trail.
- Separates known requirements from open questions and assumptions.
- Routes follow-up questions toward the right subject matter area.
- Creates story and task shaped outputs that humans can review.
- Feeds clearer inputs into the build harness when the work is ready.
Why It Matters
What this makes possible
The goal is not to replace product judgement. The goal is to make product judgement easier to apply while the work is still cheap to change.
- Stakeholders can see what has been understood before build work starts.
- Missing decisions become explicit instead of silently turning into implementation risk.
- Teams can move from interview to story to build input faster.
- Approval cycles can happen around clear slices of work rather than vague promises.
- The build harness receives better inputs, which reduces downstream rework.
Flow
A public version of the pipeline
Step 01
The conversation is captured as working material
The initial interview is treated as structured product input, not just a transcript or a loose chat history.
- Business context
- Stakeholder goals
- Constraints
- Success signals
Step 02
The harness shows what it thinks it heard
The system makes its interpretation visible so a human can correct scope, terminology, risk, and implied requirements early.
- Problem summary
- Audience
- Assumptions
- Known unknowns
Step 03
Follow-up questions are routed by subject matter
Unclear areas are turned into specific questions so the right person can answer before the build path hardens.
- Policy question
- Workflow question
- Data question
- Approval question
Step 04
The work becomes value-shaped slices
Discovery output is converted into stories that describe what needs to change for a real user or operator.
- Actor
- Outcome
- Acceptance notes
- Open decisions
Step 05
Approved stories become build-ready work
Stories are broken down into smaller tasks with boundaries clear enough for implementation planning.
- Frontend task
- Backend task
- Docs task
- Proof task
Step 06
Humans keep control of the handoff
The output is not treated as final until the right person can approve, redirect, or reject the next build step.
- Approved scope
- Deferred items
- Rejected assumptions
- Next workstream
Evidence
Evidence in the repo
The public evidence is the shape of the planning harness: discovery packets, taxonomy routing, story breakdowns, task breakdowns, decision records, and issue reconciliation notes that turn ambiguous input into reviewable work.
- Discovery packets: record the problem, audience, scope, and open questions.
- Taxonomy routing: keeps different kinds of product input from being treated the same way.
- Story breakdowns: turn discovery into smaller slices of product value.
- Task breakdowns: convert approved stories into implementation-ready work.
- Reconciliation notes: capture what was missed and strengthen the next loop.
Boundary
What I am not publishing
The public version explains the purpose, shape, and evidence of Product Discovery Assistance. The detailed interview prompts, routing rules, scoring logic, private customer examples, and internal orchestration workflow are intentionally private.