Product Knowledge Workbench
Menu

Who it is for

For product teams

You own an idea and need to turn it into something engineering can build. The workbench drafts each step with you from your organization's approved knowledge, asks you the few things that knowledge cannot answer, shows you where every statement came from, and tells you plainly what it could not find.

A requirement set: each requirement with its kind, priority, status, and either citations or an assumption badge with its reason, and the screens that implement it.
A requirement set. Each requirement shows its citations or an assumption badge, its priority, and the screens that implement it.

What changes for you

  • You start from a draft, not a blank page

    Every stage drafts its artifact from the approved documents and the stages before it. You read, steer, and decide, rather than collect and transcribe.

  • You are asked, not second-guessed

    Before a stage drafts, it asks two or three short questions about what nothing approved covers. What it already found, it shows you with the passage instead of asking.

  • Problems surface early

    Two documents that disagree become an open question with both passages in front of you, before a requirement is built on either. Missing topics are listed as gaps.

  • You can defend every line

    Each requirement cites the passage it rests on, or is marked as an assumption with its reason. In a review, the evidence is one click away.

From an idea to a handoff

  1. Write the idea

    Create an initiative with a title and a few sentences on who has the problem, what you want, and what is out of scope. You can limit it to chosen sources, tags, or paths.

    Produces: An initiative you own, with eight stages ready to start.

  2. Answer the framing questions

    Framing asks what your idea and the knowledge leave open: who has the problem and how often, what they do today, how success is measured, and who decides. Answer, pick an option, skip a question, or tell it to stop asking and draft.

    Produces: Your answers, recorded on the framing as your input, with who answered and when.

  3. Let the workbench frame and investigate it

    The framing workflow writes a problem statement, the audience, outcomes, constraints, and non-goals. Discovery searches the approved knowledge, groups what is known into findings, and reports conflicts and gaps.

    Produces: A problem framing and discovery findings, each finding with its citations.

  4. Draft requirements you can defend

    Functional and non-functional requirements, each with at least one citation or an explicit assumption with its reason. Every default non-functional category is covered or marked as none.

    Produces: A requirement set with priorities, open questions, and a coverage summary.

  5. Shape the experience

    User flows, wireframes, a UX specification, and visual designs built from your registered design system, then a clickable mockup with a walkthrough of the main path. Point at an element on a rendered screen to change it or leave a note for the next draft.

    Produces: Flows, screens, and a mockup that opens in the browser and works offline.

  6. Hand it over

    Export the bundle in the layout your engineers' spec-driven method reads, the specification files they and their coding agents work from. It holds epics and stories with Given, When, Then scenarios, the mockup, the citations, and the open questions, checked as it is built.

    Produces: A handoff bundle engineering can read in the product or as files.

You stay in charge of every run

The run panel while a workflow drafts a problem framing. The phases, the cost, and the draft update as the run goes.

A run shows its progress from the first second: the phase it is in, what it searched for, the questions it is waiting on, the draft as it forms, and what each model call cost. You can redirect it with an instruction, edit the draft while it runs, cancel it, or resume it from its last checkpoint. A cancelled run saves nothing, and its last draft is offered back to you. Each stage page opens on the stage's current output, with its versions, its staleness, and the answers you gave, which you can change and regenerate from.

It tells you what it does not know

A citation opened on a discovery finding: the cited passage with its document, location, approver, and excerpt, and a link to open the document there.
Discovery findings with a citation open, showing the passage, its version, its approver, and whether it is still current.

Conflicts between documents become open questions that quote both passages. Topics the knowledge does not cover are listed as gaps with the searches tried. A question you skip becomes a visible assumption, never a silent guess. A passage marked restricted that could not be sent to a model is reported, not silently skipped. You decide each open question: keep it, resolve it, or mark it not relevant.

Change your mind without losing work

The staleness panel on a requirement set: one row per reason, naming the document that changed, each with regenerate, keep as is, and merge.
Why a requirement set is stale, one reason at a time, each with the three responses.

Stages are a default order, never a gate. Go back to any stage, edit by hand, or skip ahead. Before a change, the workbench tells you how many artifacts it will make stale. Afterward each one shows why, and you choose: regenerate it, keep it as is with a note, or merge the new version with your edits. Nothing is overwritten; every version stays.

How it fits the way you work

You keep your wiki, your design tool, and your tracker. The workbench reads from the first, builds screens from the design system you already maintain, and hands engineering files they can import into the last. You own each initiative; reviewers read along and mark the stages they have checked.