Website decision register

Raw source preview

Raw, unprocessed file text shown below. Preview truncated for readability.

---
title: GTM Website - Decision Register
status: active
created: 2026-04-13
updated: 2026-04-22
purpose: Record open messaging decisions that should not be settled accidentally in implementation.
---

# <un>peel Website - Decision Register

## D-001 - Middle pillar label

**Status:** Decided for now  
**Current live default:** `Protect`

**Why it was reviewed:**  
The original `Collect` label kept the three-part rhythm neat, but it created too much risk that researchers would read the second pillar as fieldwork execution rather than fieldwork protection.

**Decision:**  
Use `Protect` in the live site because it keeps the same rhythm while making the during-fieldwork job immediately legible.

**Alternatives worth keeping for later review:**
- `Collect`
- `Verify`

**Decision trigger:**  
Review after first buyer feedback on the homepage mechanism section and switch only if a stronger label emerges from real buyer language.

---

## D-002 - When to expose the broader platform ambition publicly

**Status:** Open  
**Current live default:** Keep the public site today-biased

**Why it is open:**  
The broader long-term ambition is real: become the system of record for research, support external projects inside one container, and eventually widen access to trusted customer understanding across the business. That is strategically important, but not all of it is ready to claim publicly today.

**Current rule:**  
Do not lead with the future suite vision before the product truth can support it.

**Decision trigger:**  
Revisit when product readiness and launch timing make the broader story defensible.

---

## D-003 - Hero clause wording (now the full three-beat line)

**Status:** Under review — beats 1 and 3 decided; beat 2 recommendation recorded 2026-06-15 (`Stay in control.`), final lock pending the pilot mini-test in the decision trigger  
**Current live default (confirmed 2026-06-16):** `Answer faster. Stay in control. Make it travel.`, verified live in `website/site/components/sections/PeelHero.tsx` (the hero hardcodes its copy; the `homepageContent.ts` hero value was stale and has now been corrected to match). Beat 2 (`Stay in control.`) is live as the working choice; final lock still pending the Musgrave mini-test in the decision trigger.  
**Working direction (2026-06-12):** `Answer faster. Stay in control. Make it travel.` — full draft block at `website/homepage-hero-draft-2026-06-12.md`; runner-up for beat 2: `Stand behind it.`

**Why it was reviewed (round 1):**  
The previous wording, `Keep the context`, was too generic and underperformed against the first two clauses in the hero.

**Why it was reviewed (round 2):**  
`Build on what you know` was warm and human but pointed toward the accumulation/memory frame rather than the corroboration/validation frame. When the third pillar was renamed to Validate (D-012), the hero clause pointed in a different direction to the platform framework. `Validate the answer` was chosen over `Validate what you know` because "the answer" names the specific moment of pressure — a finding being challenged, a claim needing to hold up — which is the precise scenario the product addresses.

**Why it was reviewed (round 3, 2026-06-12 — scope widened from the third clause to the whole trio):**  
A raw-source audit of the Phase One corpus (debrief PDF full text + both persona docs) found that the trio's proof beats rested on drifted evidence. Finding-level defensibility ("a finding being challenged, a claim needing to hold up" — the round-2 rationale) is an **EmpathyIQ thesis, not a recorded Phase One fear**: the debrief contains no defend-language, none of the 19 rated challenges concerns defending research, and the recorded defence pressure is budget-level and UK-only. Meanwhile the corpus's top validated unmet need — insight travelling beyond the debrief (IE #1, "delivery problem, not methodology problem") — had no beat at all, and "validate/trusted answers" is the most competitively saturated claim in the category (Stravito, Market Logic, Dovetail, Forsta). Canonical evidence base: `market-analysis/phase-one-validated-pains-and-positioning-evidence.md`.

**Round 3 direction:**
- Keep a three-beat hero (see D-014 resolution — no fourth clause).
- Beat 1 stays `Answer faster.` — validated pain, table stakes, opens the conversation.
- Beat 3 becomes the travel/activation clause; working default `Make it travel.` — the validated #1 unmet need takes the highlighted climax slot.
- Beat 2 is the open slot (replaces `Defend the work`): it must bridge speed and travel without asserting a fear the research didn't record. Candidates under evaluation; selection criteria: validated or honestly-thesis posture, product-true at release, not competitively saturated, fits the 2–4 word rhythm.
- `Defend` / `Validate` language moves below the fold as mechanism copy (Research Guard, Trust Centre, Insight Navigator), per D-012's working copy rule.

**Recommendation (round 4, 2026-06-15 - positioning cross-check):**
Lock beat 2 as `Stay in control.` over the runner-up `Stand behind it.` A June 2026 positioning review (`strategy/positioning-exploration-connected-evidence-2026-06-15.md`) cross-checked an externally-proposed pivot to a "connected / trusted evidence" lead and found it would re-import the two problems round 3 removed: `Stand behind it.` echoes the finding-level-defensibility thesis the audit demoted, and "trusted / validated" is the most saturated claim in the category. `Stay in control.` is the stronger bridge between `Answer faster.` and `Make it travel.`: it maps to a validated constraint (ungoverned spread / dashboard fatigue, evidence base pain #5), it is product-true at release (human-in-the-loop review across Research Guard and Trust Centre; "your team makes every call"), and "control / governance" is materially less saturated than "trusted / validated" across Stravito, Market Logic, Dovetail, and Forsta. Final lock still gated on the pilot mini-test below (Musgrave: Shannen, Cliona).

**Previous defaults:**
- `Keep the context` (original)
- `Build on what you know` (second version)
- `Validate the answer` (third version, live)

**Decision trigger:**  
Beat 2: test 2–3 candidate trios with pilot ICP contacts (Musgrave: Shannen, Cliona) before locking; review the full hero after first buyer feedback on first-screen takeaways.

---

## D-004 - Product taxonomy in navigation and site architecture

**Status:** Decided for now  
**Current live default:** `Tools in <un>peel / Trust layer`

**Decision:**  
Use the public taxonomy:

- `Tools in <un>peel`
- `Trust layer`

**Why it was reviewed (first pass):**  
The original `Research tools / Trust layer` structure explained the proposition cleanly, but underplayed how buyers evaluate and buy the platform. The revised structure better reflects the commercial model:

- `Tools in <un>peel` = the things teams buy and use directly, explicitly inside one platform
- `Trust layer` = the differentiators that come with what they buy

**Why it was reviewed (second pass — platform-first IA pass):**  
`Research tools` implied tools were standalone peer products rather than features of one platform. `Tools in <un>peel` makes the platform relationship explicit in the group label.

**Alternatives considered:**
- `Research tools`
- `Research workflows / Quality checks / Evidence layer`
- `Research tools / Quality layer`
- `Products / Trust layer`

**Decision trigger:**  
Review after first buyer reactions to the platform-first taxonomy and route structure.

---

## D-005 - Rename `Questionnaire Reviewer`

**Status:** Decided for now  
**Current live default:** `Research Guard`

**Decision:**  
Rename the product to `Research Guard`.

**Why it was reviewed:**  
`Questionnaire Reviewer` is clear for the current use case, but it is too narrow for the broader direction of reviewing other kinds of research work over time. The replacement needed to stay trust-led, productized, and aligned with `Trust Centre`.

**Alternatives kept on record:**
- `Research Review`
- `Research QA`
- `Study Review`
- `Design Review`
- `Research Assistant` - rejected for this product because it feels too generic and too chatbot-like

**Decision trigger:**  
Review after early buyer feedback on the renamed trust-layer products.

---

## D-006 - Rename `Knowledge Base`

**Status:** Decided for now  
**Current live default:** `Insight Navigator`

**Current job to solve:**  
Name the product that acts as the system of record for customer knowledge, lets teams ask questions at project level and platform level, and will increasingly help surface corroborating evidence across studies over time.

**Why it was reviewed:**  
`Knowledge Base` is descriptively accurate but undersells the product as a buyable tool. The replacement needed to balance:

- commercial clarity
- product distinctiveness
- fit for project-level and platform-level querying
- room to grow into cross-study corroboration and evidence surfacing

**Decision:**  
Use `Insight Navigator` as the public product name because it:

- feels more like a buyable tool than `Knowledge Base`
- keeps the idea of guidance and retrieval without sounding administrative
- works for project-level and platform-level questioning
- leaves room for stronger corroboration across studies as the product matures

**Alternatives kept on record:**
- `Research Navigator` - strong option, but less directly connected to the customer-knowledge outcome
- `Knowledge Manager` - clearer on ownership, but sounds administrative and less premium
- `Research Memory` - strong strategic story, but weaker if the main interaction is asking questions
- `Evidence Navigator` - strong on rigor and traceability, but colder and less intuitive
- `Evidence Assistant` - literal, but still carries some generic AI-assistant fatigue
- `Research Assistant` - better as the in-product conversational experience than as the SKU name
- `Customer Expert` - rejected in principle; too awkward and overclaim-heavy

**Current working rule:**  
Treat `Research Assistant` as a possible interface description, not the product name, unless later user research clearly supports it.

**Decision trigger:**  
Review only after first buyer reactions to `Insight Navigator` and the updated product taxonomy.

---

## D-007 - Rename or keep `Trust layer`

**Status:** Open  
**Current live default:** `Trust layer`

**Why it is open:**  
`Trust layer` is strategically coherent, but it may read more like internal architecture language than buyer language. The current label needs testing against how insight leaders naturally describe Research Guard and Trust Centre.

**Current rule:**  
Keep `Trust layer` live for now, but treat it as a naming hypothesis rather than a locked brand asset.

**Alternatives under consideration:**
- `Built-in trust`
- `Research safeguards`
- `Trust infrastructure`
- `Quality layer`
- `Built-in quality`
- `Built-in confidence`

**Decision trigger:**  
Review after first buyer conversations and replace it if buyers consistently reach for clearer quality, safeguards, or validation language.

---

## D-008 - Tool naming and route strategy

**Status:** Decided for now  
**Current live default:** Surveys, Discussion Groups, AI Interviews at `/platform/*`

**Decision:**  
Rename tool pages to simple functional labels and move canonical routes from `/product/*` to `/platform/*`:

- `Survey Platform` → `Surveys` at `/platform/surveys`
- `Online Discussion Platform` → `Discussion Groups` at `/platform/discussion-groups`
- `AI Interviewer` → `AI Interviews` at `/platform/ai-interviews`
- `Insight Navigator` stays, moves to `/platform/insight-navigator`

Old `/product/*` routes redirect to new `/platform/*` routes.

**Why it was reviewed:**  
`Survey Platform` and `Online Discussion Platform` implied each tool was its own platform, contradicting the platform-first commercial model. `AI Interviewer` named a persona rather than a tool. The `/product/` URL pr