MIndPeer • Product
I moved the product off documents and onto decisions.
MindPeer is an AI workspace for people who have to defend the answer they give — analysts, consultants, the people whose work gets challenged in a room. I own its architecture: the object model, the vocabulary, and what gets built. Then I design it.
Role
Lead Product Designer. Sole designer on the product.
Own
Product architecture, object model, IA, design system, specs
Team
Engineering, a CTO, subject-matter experts. No product manager.
Status
In build. Structure settled, surface still moving.
01 · The problem
Ask any chat AI a hard question and you get a fluent paragraph back. It reads well. You cannot take it into a room where someone asks how do you know that, because the reasoning is gone the moment the message scrolls away.
That is the actual job for an analyst. The answer is the easy half. The hard half is the trail behind it — what was claimed, what it assumed, what evidence supported it, where that evidence came from, and what would have to be true for it to be wrong.
Today that trail lives in people's heads, in email, and in a deck somebody rebuilt from scratch three weeks later. MindPeer is an attempt to make it an object instead.
The market is full of tools that produce answers faster. Very few of them help you stand behind one.
02 · The decision
This is the call I am most willing to be judged on, so it goes second.
When I came onto it, the product was organised around the document. You made a report, and everything else hung off it — sections, sources, comments, versions. It was a reasonable place to start, because a report is what the client physically receives.
It was still wrong. A report is a format. It is one of several ways the work gets handed over, alongside a deck, a model, a memo, or a two-line recommendation in a meeting. Organising the whole product around one output shape meant the product could not describe the thing that actually persists: the decision a client is stuck on.
So I argued to rebuild the model around the decision, and to demote reports to an output. Reasoning attaches to the decision. Artifacts get generated from the reasoning, in whatever shape the moment needs. The trail survives the format.
The uncomfortable part is what it cost. Features that made sense under a document-centred model stopped earning their place, including a few I had already designed and was quite fond of. Those got cut. I would rather delete my own work than defend a structure I no longer believe.
03 · The object model
This is the spine of the whole thing. If a new feature does not fit here, either the feature is wrong or the model is — and both are worth finding out early.
When I came onto it, the product was organised around the document. You made a report, and everything else hung off it — sections, sources, comments, versions. It was a reasonable place to start, because a report is what the client physically receives.
It was still wrong. A report is a format. It is one of several ways the work gets handed over, alongside a deck, a model, a memo, or a two-line recommendation in a meeting. Organising the whole product around one output shape meant the product could not describe the thing that actually persists: the decision a client is stuck on.
So I argued to rebuild the model around the decision, and to demote reports to an output. Reasoning attaches to the decision. Artifacts get generated from the reasoning, in whatever shape the moment needs. The trail survives the format.
The uncomfortable part is what it cost. Features that made sense under a document-centred model stopped earning their place, including a few I had already designed and was quite fond of. Those got cut. I would rather delete my own work than defend a structure I no longer believe.
Context — who the work is for. Deliberately boring, deliberately nested.
04 · Governance
The assistant in MindPeer does a lot. It drafts claims, surfaces contradictions, argues against the analyst on purpose, and proposes what to look at next. All of that is useful and none of it is allowed to be final.
So I separated the two. The AI can propose anything. Only a person can commit a judgement — accept a claim, set a confidence, lock an artifact.
That rule is enforced in the data layer, not signposted in the interface. A tooltip saying "AI-generated, please verify" is a disclaimer. It is not a control. Making the boundary structural means it holds even in the parts of the product I have not designed yet, and even when someone builds a feature in a hurry.
Proposes
The assistant
Drafts, decomposes, finds gaps, argues back, ranks what to do next, keeps the trail current.
Commits
A person
Accepts a claim, sets confidence, resolves a challenge, locks an artifact. Attributable, always.
Want the rest
The screens are under NDA and stay that way. The reasoning behind them is mine to talk about, and I am happy to walk through any decision on this page — including the ones I got wrong first.