Free until October 1. Lock your foundation and run your first client diagnostic before your Q1 pipeline conversations start.

Join the beta

A Good Diagnostic Ends in Two Verbs

Most AI tools can write you a scored report. The failure mode is what happens at the end of it: recommendations scattered across banners, cards, and destination pickers — homework, not decisions. We rebuilt the T2D3 OS GTM Diagnostic so every report ends in ONE ranked list of recommended moves, and every row takes exactly one of two verbs. Accept casts a signal verdict and creates the named work item in a single gesture; Dismiss teaches the system what to stop suggesting. Here is why two verbs beat four buttons, and what your report's ending says about your AI stack.

Stijn Hendrikse · Aug 27, 2026

ShareLinkedInXEmail

Every AI tool on the market can write you a report now. A scored audit of your go-to-market, your website, your content, your pipeline — pick a vendor, paste a URL, get twelve pages of findings. The reports are getting genuinely good. And almost all of them share the same failure mode, which has nothing to do with the analysis: the ending.

A report ends, and then what? In most tools, the answer is homework. The findings sit in prose. The recommendations are scattered — some in a summary banner, some embedded in chapters, some behind an export button. Turning any of them into actual work means re-reading, re-deciding, copying into your task tool, and assigning it yourself. The AI did the analysis; you do the operations. That handoff is where most AI-generated insight goes to die.

We know because we built that exact failure mode ourselves, shipped it, and got called on it.

The maze we built first

The GTM Diagnostic in T2D3 OS grades a company's go-to-market — foundation, motions, evidence — into a scored, chaptered report. The analysis was solid. The ending was a maze.

At the top sat a triage banner summarizing what mattered most. Below it, priority cards, each with its own "add to actions" button. Inside the chapters, more embedded suggestions. And when you did decide to act on something, a four-way destination picker: should this become a project task, an OKR, a calendar item, a note? Every element was individually defensible. We had reviewed each one. Together, they asked a first-time user to learn four different interaction patterns to do one thing: act on the report they just paid attention to.

A beta user told us, politely, that after reading the report he wasn't sure what to do next. That sentence is the whole indictment. A diagnostic whose reader finishes unsure what to do next has failed at its only job, no matter how good the analysis was.

One list, two verbs

The rebuilt report ends in one place: a single ranked list called Recommended moves. Every recommendation the diagnostic produces — the priority findings, the proposed execution work, all of it — lands in that one list, ordered by the AI's own judgment of what matters most. No banner, no scattered buttons, no parallel surfaces.

Each row takes exactly one of two verbs:

Accept does two things in one gesture. It casts your verdict — this is signal, the machine read my business correctly — and it creates the actual work item, named right on the button. When you have a live project, the button reads "Accept → task in your project." You are not accepting an idea and then going somewhere else to operationalize it. The click is the operationalization.

Dismiss is not a delete button. It casts the opposite verdict — this is noise for us — and that verdict is kept. The system is told, explicitly, that this class of suggestion missed.

Two more things ride on every row. Consequence chips show what accepting will create before you click — a task, with its name — so the verb is never a mystery box. And grounding shows which of your own signal sources the recommendation stands on: the interviews, documents, and locked foundation modules it was reasoned from. You are never asked to accept a recommendation you can't trace.

Where did the four buttons go?

The destination picker didn't disappear — it got demoted, and the demotion is the design lesson.

Once a move is accepted, a quiet "Send to…" menu appears on the row: also send it to an OKR, a calendar slot, wherever else it should live. Additive, optional, after the fact.

Here is the principle we had violated in the first version: destination choice is logistics, not judgment. Whether a move becomes a task or also feeds an OKR is a routing question. Whether the move is right is a judgment question. The old design forced logistics before judgment — pick a destination to express an opinion — which is exactly backwards. Your attention is the scarcest input in the system. An interface that spends it on routing decisions the machine could default sensibly is wasting the one resource it exists to conserve. The new default is the obviously correct one (a task in your active project), it's named on the button, and the exceptions are one small menu away — after you've decided.

Every verb is training data

The part that makes this more than a UX cleanup: every Accept and every Dismiss is captured human judgment, and it flows back into the system.

This is the pattern the whole T2D3 OS is built on — AI drafts, human verdicts are collected at the moment of decision, and the verdicts ground what the AI drafts next. A dismissed class of moves stops being suggested. An accepted pattern earns rank. The diagnostic you run next quarter is not the same product you ran this quarter, because it has your verdicts in it. Generic AI tools generate; they don't learn your judgment, because they never ask for it in a form they can keep. Two verbs, cast at the exact moment you're forming an opinion anyway, is the cheapest possible price for that.

The report that maps your first hour

The same redesign reached the front door. A brand-new org used to land on the Growth Stage tab facing a form. Now, before any input exists, it opens with the map instead: the four steps of the first hour — confirm your growth stage, run the GTM Diagnostic, size your targets, commit your first OKRs — each with the same one-line contract: the AI drafts, you confirm.

That contract is the thesis. We run T2D3 OS on the leader-leader model: the system behaves like a competent teammate who drafts before being asked, ranks its own work, names the default, and reserves the human for what only the human can give — the verdict. A recommendation, on this model, is not content to be read. It is a decision request. And a decision request deserves an interface with exactly as many verbs as there are decisions: two.

Ask your current AI tools what happens at the end of their reports. If the answer is "you read it and then you do the work of acting on it," the analysis was never the product. The ending is.

The one-list report is live for T2D3 OS beta organizations now — run a GTM Diagnostic and finish it in two verbs.

Join the conversation

Put this playbook to work — with the OS built for it.

T2D3 OS turns the method behind this guide into working modules: ICP, personas, positioning, content, and a full GTM plan. Start free.