Product Knowledge Workbench
Menu

Journey: a product person

From an idea to requirements, with a conflict found and resolved

A product person has an idea: customers keep calling to ask where their onboarding checks stand, and they should be able to see it online. They have a few hours, an organization full of policies and procedures, and no wish to read all of them. Here is what the workbench does with them.

  1. Step 1

    They write the idea down

    Create initiative: a title, the idea text with guidance on what to include, an optional knowledge scope, and a design system choice.
    Creating an initiative from an idea, with an optional knowledge scope and a design system to choose now or later.

    They create an initiative with a title and a few sentences: who has the problem, what they want, and what is out of scope. They limit the initiative's knowledge to the onboarding documents. The initiative opens on its overview, with eight stages ready to start and none of them required to go first.

  2. Step 2

    Framing asks what the documents cannot tell it

    A question round in a stage's run panel before it drafts: three questions, one answered by choosing an option beside the passage the knowledge base already holds, one skipped and shown as an assumption, and one waiting for a free-text answer, with the time the run waits until and the actions to send the answers or stop asking and draft.
    A question round in the run panel, from the design renders, shown on another sample initiative. Each question says why it is asked; a skipped one becomes an assumption. From the design renders; a capture of the application is not available yet.

    They start problem framing. Before it drafts, it searches the approved knowledge for what a framing needs. The procedures say which checks exist and who runs them, so it shows those passages instead of asking. Nothing says how many customers call or what success would look like, so it asks: a round of three short questions, each with a sentence on why it matters. They pick an option for one, type an answer for another, and skip the third, which becomes an assumption in the draft.

  3. Step 3

    The framing run drafts while they watch

    A framing run on the run panel's test data, which drafts a framing about billing disputes. The phases, the log, and the draft update as the run goes.

    The run carries on: retrieving, then drafting. The draft forms on screen: the audience, the outcomes, the constraints, the non-goals, and the sources it consulted, with their answers recorded on the version as their input. Each model call shows its tokens and its cost. They could redirect the run with an instruction or edit the draft before it finishes; this time they let it propose, read it, and keep it.

  4. Step 4

    Discovery finds what is known, and what disagrees

    Discovery findings with their citations, a conflict between two documents recorded as an open question with both passages, and the gaps with coverage counts.
    Discovery findings. The finding on driver's licenses carries the conflict, and the summary counts findings, conflicts, and gaps.

    Discovery asks one question, which part of the problem to dig into first, then searches the approved documents and groups what it finds into findings, each with its citations. It also finds a disagreement: the customer due diligence procedure accepts a driver's license when the address matches, while a reviewer's note records that branches accept licenses without the address check. The workbench does not pick a side. It records the conflict as an open question with both passages, and lists the topics nothing approved covers as gaps.

  5. Step 5

    Every statement can be checked in place

    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.
    A citation's popover with the passage, its location and version, the approver, and its status.

    They open a citation beside a finding. It shows the passage, where it sits in the document, the version, who approved it and when, and whether it is still current. One more click opens the document at that passage. Nothing in the findings is unsupported except what is marked as an assumption.

  6. Step 6

    They resolve the conflict, then the requirements follow it

    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.
    The requirement set, with citations or assumptions per requirement, the screens that implement each one, and the coverage of each non-functional category.

    The open question is a product decision, so they decide it: a driver's license is enough when the address matches. They mark the question resolved with that note. Requirements asks two things the documents leave open, which outcomes come first and how fast the status page must load, and then turns the framing and the findings into functional and non-functional requirements. The requirement on driver's licenses cites the procedure it follows; the load time target cites their answer. Privacy and reliability show as gaps, because no approved document covers them.

  7. Step 7

    A second opinion, recorded as such

    A reviewer reads the requirement set on its stage page and marks the stage ready. The owner's own self-check is shown as a different kind of mark, so anyone reading the initiative later can tell which stages a reviewer confirmed. If the requirements change, the mark is shown as outdated rather than silently carried over. From here the initiative goes on to flows, designs, and a mockup, each stage asking its own questions first.

What the product did for them

  1. It asked only what the approved knowledge could not answer, recorded the answers as theirs, and turned a skipped question into a visible assumption.
  2. It found two sources that disagreed and turned the disagreement into a decision for a person, with both passages in front of them.
  3. It drafted a framing, findings, and requirements from approved knowledge and their answers only, with every statement cited or marked as an assumption.

Next journey: a reviewer