Product Intelligence — Prototype Companion

1. Workspaces as shared product memory

What the feature is

• Every product, capability, or initiative gets its own workspace — a single shared container for everything the team knows about it.
• The left navigation is persistent: a person can move between SMS Initiative, Provider Search, Drug Cost Estimator, Shopper Profile, and Plan Recommendation without losing their place.
• Two memory types exist. Product / Capability Memory holds durable knowledge for a long-lived product. Initiative / Problem Memory holds knowledge for a specific effort, so the knowledge outlives the temporary team.
• Anyone can create a workspace in a few seconds: a name, a type, and an optional description. No taxonomy or setup is required before knowledge can go in.

Requirements

• A workspace is the unit of memory and the unit of access; every knowledge object belongs to exactly one workspace.
• Workspace navigation is always visible and shows the memory type, so people can tell durable product knowledge from initiative knowledge at a glance.
• Creating a workspace requires a name and a type only — everything else is optional and can be added later.
• Memory type is visible metadata in the prototype; in production it should drive lifecycle rules such as archiving an initiative and promoting its durable knowledge into a product workspace.
• Workspaces must support membership, roles, and access control before any real content is stored.

About the mock data

Five fictional workspaces ship with the prototype, with SMS Initiative as the fully populated demo. Newly created workspaces start empty and live only in the current browser session.

2. Effortless knowledge capture

What the feature is

• Adding knowledge takes seconds and requires no classification: upload a file, add an image, write a note, or paste a link.
• The person adding content never has to decide whether it is a decision, a requirement, or a risk — that is the system's job.
• Capture is available directly from the workspace Overview, so contributing is never more than one click away from where people already are.

Requirements

• Four capture methods are first-class: file upload, image upload, free-text note, and link.
• No required fields beyond the content itself — no tags, folders, or categories at capture time.
• Every captured item retains who added it and when, and remains viewable as an original source forever.
• In production, capture must handle real documents (PDF, Office, images with OCR), size limits, virus scanning, and permissioned storage.
• Capture should eventually happen where work already happens — chat, docs, design tools, and email forwarding.

About the mock data

Uploads are not stored anywhere. Files are recorded by name and type only, and note and link text is kept in browser memory for the session.

3. AI organizes content into candidate knowledge

What the feature is

• As soon as something is added, AI reads it and proposes structured knowledge: decisions, approvals, requirements, owners, risks, dependencies, evidence, and open questions.
• Nothing AI proposes is treated as true. Proposals appear as candidate knowledge awaiting human review.
• Each candidate shows what was extracted, the type it was classified as, and the source it came from.

Requirements

• Extraction runs automatically on every addition; the contributor does no structuring work.
• Candidate knowledge is a distinct state from trusted knowledge and is visually separated everywhere it appears.
• Every candidate carries a traceable link back to the exact source it was derived from.
• In production, extraction quality needs measurement: precision and recall per knowledge type, and a feedback loop from confirm/dismiss decisions.
• Extraction must be re-runnable when models improve, without duplicating knowledge people already reviewed.

About the mock data

Extraction is simulated with a short delay and deterministic rules over the added content. No model is called and no content leaves the browser.

4. Human confirmation before anything is trusted

What the feature is

• The Knowledge tab is where a person reviews what AI proposed and confirms or dismisses each item.
• Confirmed items become trusted knowledge and start powering answers. Dismissed items disappear from the workspace.
• Trusted knowledge is organized by type — requirements, approvals, owners, dependencies, risks — so people can browse what is settled.

Requirements

• No candidate becomes trusted without an explicit human action.
• Confirm and dismiss are both recorded with the person and timestamp, and both are reversible.
• The review queue must show its size clearly so review backlog is visible rather than hidden.
• Production needs rules for who may confirm, and a way to prevent review from becoming a single-person bottleneck.
• Conflicting knowledge must be detectable — when a new source contradicts trusted knowledge, someone has to be told.

About the mock data

A pre-seeded set of candidates ships with SMS Initiative so review can be demonstrated immediately. Confirmations and dismissals reset when the browser session ends.

5. Ask this workspace — answers with confidence and sources

What the feature is

• People ask questions in their own words, or pick from suggested questions tailored to the workspace.
• Answers are short and direct, and every answer is explicitly marked Known, Uncertain, or Unknown.
• An Unknown answer is a valid, useful result: it tells the team the workspace does not contain the knowledge, instead of inventing it.
• Every answer lists the sources behind it, and each source opens a drawer with the excerpt and an explanation of why it supports the answer.

Requirements

• Answers are grounded only in confirmed knowledge and source material inside that workspace — never in general model knowledge.
• Every answer states a confidence level, and the system never expresses more certainty than its evidence supports.
• Every claim is traceable to a source excerpt a person can read in one click.
• Unknown must be a first-class outcome with a clear next step, such as adding the missing source or raising an open question.
• Production requires retrieval over real content, citation accuracy checks, latency targets, and answer-quality feedback from users.

About the mock data

Answers are matched deterministically from a fixed set of question-and-answer pairs about Flow A and Flow B. Sources, excerpts, and rationale are authored fictional content.

6. Decisions and open questions as durable objects

What the feature is

• Decisions are not buried in documents — they are records with an owner, a date, a status, and the sources behind them, filterable on their own tab.
• Open questions are tracked the same way, so a team can see what is unresolved instead of rediscovering it later.
• Resolving an open question can immediately record the outcome as a decision, closing the loop in one step.

Requirements

• Decisions and open questions are first-class objects, not text inside a note.
• Each carries owner, status, date, and links to supporting sources.
• Both are filterable and browsable independently of the documents they came from.
• Resolving a question can create a decision, preserving the link between the two.
• Production needs supersede semantics: a newer decision must be able to replace an older one, with the history intact.

About the mock data

The SMS Initiative decisions and open questions are authored fictional records covering opt-out handling, vendor selection, consent language, and Flow B architecture.

7. Source traceability

What the feature is

• Any source referenced anywhere — in an answer, a decision, or a knowledge item — opens a drawer showing the excerpt and why it matters.
• The team can always get from a conclusion back to the raw material behind it.
• Files, notes, and team members each have their own view, so people can browse the workspace by source as well as by knowledge.

Requirements

• Every knowledge object links to at least one source; unsourced knowledge is not trusted knowledge.
• Source view shows the excerpt in context plus the reason it supports the claim.
• Sources remain available and immutable even after the knowledge derived from them changes.
• Production must respect source-level permissions: seeing an answer must never leak an excerpt the person cannot access.

About the mock data

Source documents are fictional — SMS_FlowA_Copy_v4.pdf, Legal_Review_Notes.pdf, Flow B Architecture.png, kickoff notes, and a vendor comparison. Excerpts are authored text, not extracted from real files.

8. Automation and capture connectors

What the feature is

• People should not have to stop what they are doing and upload content manually.
• Every workspace gets a dedicated email address; forwarding a thread or CC'ing the address captures the message and its attachments.
• Slack and Microsoft Teams get a right-click 'Add to Product Intelligence' message action that sends a thread to the chosen workspace.
• Calendar integrations can auto-capture meeting invites, recordings, and transcripts after calls end.
• Folder and document-tool watchers can pull in new files from shared drives, Sigma, Figma, and similar sources as they are created or updated.

Requirements

• Connectors must be opt-in per workspace and respect the source system's permissions — seeing an answer must never leak content the user cannot access.
• Each connector must record the original source URL, author, and timestamp so traceability is preserved.
• Auto-captured content should enter the same candidate-review queue as manually added content; AI still proposes structure and a human still confirms.
• Admins need clear scopes: which channels, folders, or calendars are included, what is excluded, and how retention maps to the workspace lifecycle.
• Failed or noisy imports must be visible and recoverable, not silently dropped.

About the mock data

No real connectors exist in the prototype. The roadmap document 'Product-Intelligence-Capture-Connectors-Roadmap.md' describes the phased plan: email forwarding first, then Teams/Slack message actions, then calendar and transcript capture, then folder and tool watchers.

Future roadmap

• Phase 1 — Email forwarding: every workspace gets a unique inbound address; users forward threads or CC the address to capture messages and attachments with original headers preserved.
• Phase 2 — Message actions: right-click 'Add to Product Intelligence' in Microsoft Teams and Slack to send a thread or message to a chosen workspace without leaving chat.
• Phase 3 — Meeting capture: calendar integrations auto-capture invites, recordings, and post-call transcripts; optional bot joins to record only when explicitly invited.
• Phase 4 — Folder and tool watchers: subscribe to shared drives, Figma, OnDrive, and similar sources so new or updated files enter the candidate-review queue automatically.
• Phase 5 — Smart filtering and deduplication: suppress duplicates, ignore routine notifications, and surface only net-new content for review so the queue does not drown the team.
• Phase 6 — Delivery systems: connect Jira, Aha and code repositories to each workspace so requirements, risks and decisions link to the epics, tickets and pull requests that carry them out, and drift between what was agreed and what shipped becomes visible.

Cost and benefit at a glance

Planning figures for a 150-person organization. Costs are model spend only; benefit is expressed as the cost of answering one question the way the team answers it today.

What one answer costs

What a two-person search looks like

These are not dramatic events. They are tiny, repeated moments of friction.

• SMS opt-out language: a PM searches Slack, Drive, and Jira for 10 minutes, then DMs a compliance analyst who searches email for another 10 minutes. 20 minutes × 2 people ≈ $50.
• Flow B architecture decision: an engineer finds an old doc referencing meeting notes, then asks the architect who finds the recording and scrubs to the decision point. 25 minutes × 2 people ≈ $60.
• AEP landing-page approval: marketing searches email threads, then asks the product owner who searches their inbox and forwards a thread from three weeks ago. 15 minutes × 2 people ≈ $37.

Monthly model spend per person

Three scenarios at 150 people

Add roughly $300–$800 / month of non-model infrastructure. All-in base case is about $850 / month, excluding engineering time.

Break-even

Other ways to say the same thing

• 136 avoided 30-minute two-person meetings per year — about 2.6 per week.
• 136 hours of one person's time per year — about 2.6 hours per week.
• About one minute of saved time per person per workday across the organization.
• $68 per person per year, or $5.67 per person per month.

Business-outcome comparisons

Productivity hours are hard to defend alone. Pair the cost with outcomes the team already tracks. These use placeholder values — replace them with the organization's actual numbers.

• Medicare Advantage enrollments: if one enrollment is worth ~$500 first-year value, the tool costs the equivalent of ~20 enrollments per year.
• AEP launch delay: if one week of delay costs ~$50,000 in opportunity, preventing one delay every ~5 years pays for the tool.
• Member retention: a 0.1% improvement on a meaningful book of business can dwarf the annual run cost.
• Compliance incident: if one incident costs ~$100,000 in fines and rework, preventing one incident every ~10 years covers the cost.

How the benefit gets measured

• Controlled task comparison: time ten real recurring questions with and without the workspace, and record whether the answer was correct.
• Workflow proxies measured by the product itself: time to answer, repeat questions, decisions re-litigated, onboarding ramp, and rework.
• Avoided-incident value modelled separately and never blended into the hard numbers — one compliance miss, one rebuilt integration, one delayed launch.

These figures are planning estimates for the prototype conversation, not vendor quotes. Re-check against live model pricing before committing to a budget.