Product Knowledge Workbench
Menu

For product and business teams

Put models to work on product decisions without losing trust in the output

Product Knowledge Workbench helps a product person turn an idea into requirements, designs, a clickable mockup, and a handoff bundle for engineering, with models doing the drafting and your organization's approved knowledge as the only thing they draft from. It asks you before it guesses, every statement points to the passage it rests on, and nothing changes behind your back.

  • Who it is for Product people and the business teams around them who want help from language models, and the reviewers, engineers, and administrators who work with them.
  • The problem What a model writes from scattered, unapproved documents cannot be trusted. Nobody can tell which policy it read, whether that policy was current, or what it made up.
  • What changes Only approved knowledge goes in. Each stage asks what the knowledge cannot answer, cites what it can, and is checked. Engineering receives a bundle it can verify.
An initiative overview with one card per stage, from framing to handoff, each showing its status, its artifacts with stale badges, and the gaps the workbench found.
An initiative in the workbench. Each card is a stage from framing to handoff, with its status, its artifacts, and what is stale.

What you do with it

Four steps take an idea from your organization's documents to a handoff. You can try each one on one computer with a fictional sample organization.

  1. Bring in what your organization already knows

    Connect a Confluence space, a public website, or a shared folder, upload Word, PDF, Markdown, or spreadsheet files, or type in what people know but never wrote down.

    Produces: Documents waiting in the review queue, kept in step with their sources.

  2. Approve what can be used

    A reviewer reads each document and approves or rejects it, adding corrections and notes beside the source text. Only approved documents reach the workbench and can be cited.

    Produces: Approved knowledge, each document with who approved it and when.

  3. Start an initiative and answer a few questions

    Write the idea in a few sentences. Before each stage drafts, it asks you two or three short questions, only about what the approved knowledge does not answer, such as who has the problem and how success is measured. Then it frames the idea, finds what the knowledge says, and drafts requirements.

    Produces: A problem framing, discovery findings with conflicts and gaps, and requirements with citations, each recording your answers.

  4. Carry it through to a handoff

    Continue through user flows, wireframes, a UX specification, visual design in your design system, and a clickable mockup with a walkthrough, then export the bundle for engineering.

    Produces: A handoff bundle with stories, acceptance criteria, the mockup, and every citation resolved, in the folder shape your engineers' method reads.

Who it is for, and what changes for each

  • Product teams

    A first draft at every stage from what the organization already knows, with conflicts and gaps found before anything is built on them, and every claim traceable.

  • Business teams

    Your policies and know-how become the only thing models work from. Your reviewers decide what counts, and every decision leads back to its passage.

  • Engineering

    A handoff you can check and plan from, with stories, Given, When, Then scenarios, the mockup and its walkthrough, and the evidence behind each requirement.

  • Administrators

    Choose the models, local or hosted, hold the keys, set budgets, see every cost, and keep each organization's data apart.

It sits beside the tools you already use

The workbench does not replace your wiki, your design tool, or your tracker. It meets them at three hand-offs, and each one leaves a record.

  • Knowledge in

    It reads from your wiki, websites, and folders, and keeps up with them. A changed source comes back for review while the approved version stays in use.

  • Decisions recorded

    Your answers to its questions, the open questions you decide, the stages a reviewer marks ready, and the changes you choose to keep are all stored on the version they shaped.

  • Bundle out

    Engineering receives files with a published structure, written in the layout their spec-driven method reads (the specification files engineers and their coding agents work from), with planning prompts for the work left to them.

Why you can trust what it writes

Most tools that use language models produce a confident draft and leave you to check it. The workbench is built the other way around.

What it costs to run, and where your data stays

The workbench runs where you run it: on one computer, or on a virtual machine of your own with TLS and nightly backups. Your documents, artifacts, and search indexes stay in its database. What leaves is what a model call sends to the provider you chose, and restricted passages only ever go to a model you run yourself, such as the local embedding service that ships with it. Running it costs your model provider's charges and the machine; every call is recorded with its cost, and budgets can stop spending.