Consumer Insights and Product Specifications

Turn customer evidence into explanations, decisions and testable requirements. Use behavioral research carefully, review how the design influences choices and measure whether the change helps.

Why this matters

An orphaned insight has evidence but no resulting decision. An orphaned requirement has a design choice with no clear evidence or rationale. Gotel and Finkelstein’s 1994 traceability analysis locates much of the problem before specification.

Connect insight statements to requirements, behavioral reviews and outcome measures. When the evidence concerns market perception, use it to test repositioning or a relaunch. Chapters 24 and 25 cover positioning and launch execution.

How people decide

Two systems, used as a model

Kahneman’s 2002 Nobel lecture and Thinking, Fast and Slow describe two modes, named by Stanovich and West. System 1 is fast and associative. System 2 is deliberate and effortful, but often accepts System 1’s impressions without checking.

Use the systems as a behavioral model, with two product implications:

• In-product decisions are mostly System 1. Accepting a suggested value, clicking the highlighted button, skimming a diagnosis card at 3 a.m. Users aren’t deliberating. Whatever is prominent, preselected or easiest tends to win.
• Enterprise purchase decisions are System 2 rituals wrapped around System 1 impressions. The RFP, the security questionnaire and the business case are deliberate. The impression formed in the first demo, the first number quoted and the first reference call shapes how all that deliberation goes.

Design accordingly. The responder flow should make the right next action obvious and the supporting evidence visible without effort. The buyer’s evaluation material should give System 2 what it needs: comparable claims, proof and risk controls.

Biases worth knowing, with their evidence status

Behavioral effects vary in strength and conditions. Keep their evidence status beside the design claim.

Anchoring. In Tversky and Kahneman’s 1974 experiment, participants saw a rigged wheel stop at 10 or 65 before estimating African UN membership. Median estimates were 25% and 45%, respectively. In deals, the first price or ROI figure can become a reference. Anchor claims in the customer’s measured costs.

Loss aversion. Prospect theory (1979) describes losses weighing more than equivalent gains. Gal and Rucker challenged broad claims in 2018. Mrkva and colleagues’ 2020 response found moderation by experience, domain knowledge and age. Apply this cautiously to expert buyers. This book interprets enterprise fear of visible blame as particularly important.

Choice overload. Iyengar and Lepper’s 2000 study found more interest but less purchasing with 24 jams than with six. Scheibehenne and colleagues’ 2010 meta-analysis found an average effect near zero. Chernev and colleagues’ 2015 analysis identifies conditions: complex options, difficult tasks, uncertain preferences and a choosing goal. Recommend paths for novice buyers while preserving expert control.

Defaults. Johnson and Goldstein’s 2003 organ-donation study found much higher consent under opt-out systems, with smaller differences in actual donations. Jachimowicz and colleagues’ 2019 meta-analysis of 58 studies and 73,675 participants found a medium-to-large average effect (d = 0.68), with wide variation, including null and reversed effects.

Social proof. Cialdini describes people looking to similar others under uncertainty. Use genuine references, advisory boards and measured benchmarks. Fabricated reviews and activity claims are deceptive patterns.

Defaults in enterprise software are policy

Enterprise defaults apply policy for every customer who leaves the setting unchanged: autonomy, data retention, alerts or telemetry sharing. Their effect can extend across many organizations.

Document each default’s owner, customer-centered rationale and measurement. High persistence with a default does not establish customer preference.

How B2B buying groups decide

A B2B insight must explain a group decision across users, champions, buyers, reviewers and procurement. Enthusiasm from one role may not resolve another’s veto.

Three features of group buying shape the insights you need.

Reduce approval risk. Security, procurement and legal may gain little personally from a purchase while bearing its failure. Explore fears and required proof. Reversible pilots, audit logs, scoped access and exit terms can address these needs.

Make claims reviewable outside sales. Gartner surveyed 646 buyers in August–September 2025 and reported in March 2026 that 67% preferred rep-free buying and 45% used AI in a recent purchase. This book infers that product claims must remain specific, evidenced and consistent when assistants summarize them. Audit those summaries.

Consensus is the product of artifacts. The champion has to sell internally to people who never saw the demo. The materials they carry (a business case, a security pack, a reference) decide whether consensus forms.

This book recommends a simple buying-group insight map: for each role, capture the job they’re doing in the purchase, the fear that drives them, the proof they need and the veto power they hold. It turns Chapter 01’s personas into decision insight.

Persuasion, manipulation and the law

Where the line is

Order, prominence, wording and defaults influence behavior. Judge whether that influence serves the user’s goals.

Brignull coined dark patterns in 2010 and now favors deceptive patterns. His catalog includes hidden costs, cancellation obstruction, forced action, misleading wording and fake urgency or social proof. Mathur and colleagues’ 2019 crawl of about 11,000 shopping sites found 1,818 instances across seven categories.

This book offers four tests to separate persuasion from manipulation. A design choice is acceptable when:

1. It serves the user’s own goal, not only yours.
2. It would survive disclosure. If you explained the design rationale to the user, they wouldn’t feel tricked.
3. It’s symmetric. Getting out is as easy as getting in; declining is as easy as accepting.
4. It uses true information. Urgency, scarcity, social proof and prices are real.

A choice that fails any one of the four needs to change or be justified in writing by someone accountable.

The regulatory position in 2026

Regulators now name dark patterns explicitly. State their positions precisely; they differ between jurisdictions and they’re still moving.

United States. There’s no dedicated federal dark-patterns statute. The Federal Trade Commission enforces through Section 5 of the FTC Act (deceptive or unfair practices) and, for subscriptions, the Restore Online Shoppers’ Confidence Act (ROSCA). The FTC’s September 2022 staff report, Bringing Dark Patterns to Light, which followed a 2021 public workshop, defines dark patterns as design practices that trick or manipulate users into choices they wouldn’t otherwise make. It groups them under four headings: designs that induce false beliefs, designs that hide or delay material information, designs that lead to unauthorized charges, and designs that obscure or subvert privacy choices. On subscriptions it restates that cancelling should be at least as easy as signing up, through the same medium.

In September 2025 Amazon agreed to a $2.5 billion settlement of the FTC’s 2023 complaint about Prime enrollment and cancellation: a $1 billion civil penalty and $1.5 billion in customer refunds, with required changes including a clear way to decline Prime and cancellation through the same method used to sign up. Amazon neither admitted nor denied the allegations. Separately, the FTC’s broader “click-to-cancel” rule was vacated by the Eighth Circuit in July 2025 on procedural grounds, without a ruling on its merits. ROSCA and state auto-renewal laws still apply, and reports in early 2026 indicated the FTC was reopening rulemaking. Check the current status with counsel before relying on any of this.

European Union. Article 25 of the Digital Services Act (Regulation (EU) 2022/2065) bars providers of online platforms from designing interfaces that deceive or manipulate users or otherwise materially distort their ability to make free and informed decisions. It names three areas for Commission guidance: giving certain choices more prominence, repeatedly asking for a choice already made, and making it harder to terminate a service than to subscribe to it. Article 25 doesn’t apply where the Unfair Commercial Practices Directive or the GDPR already covers the practice. Note its scope: it binds online platforms, a defined DSA category, and most B2B SaaS consoles aren’t online platforms. Treat it as a design standard worth adopting, and get legal review before treating it as an obligation for your product.

Two further EU instruments matter for AI-era products. The AI Act’s Article 5, which has applied since 2 February 2025, prohibits AI systems that use subliminal, purposefully manipulative or deceptive techniques to materially distort behavior in ways likely to cause significant harm, and AI that exploits vulnerabilities due to age, disability or social or economic situation. And the Commission has consulted on a Digital Fairness Act expected to address dark patterns, addictive design and subscription traps; as of this writing the proposal hasn’t been published, and law-firm briefings expect it in November 2026.

From insight to specification

What makes an insight

A finding says what happened: “40% of diagnoses were rejected last month.” An insight says why it happened and what follows: responders reject diagnoses when they can’t verify them quickly, because a past wrong answer taught them to distrust uncited claims.

Stanford’s point-of-view statement uses [user] needs [need] because [insight]. This book adds evidence, buying context and confidence:

• Who: role, context and position in the buying group.
• Observed: the behavior, with its evidence (interviews, usage data, tickets).
• Because: the motivation or constraint that explains the behavior.
• Tension: what they want against what stops them.
• So we believe: the implication for the product.
• Confidence: high, medium or low, and what would change your mind.

Test four properties: non-obvious, explains behavior, grounded in evidence and implies action. Retain an explanation only when its evidence and implications hold.

Traceability from insight to requirement

Gotel and Finkelstein distinguish pre-specification traceability, linking requirements to people, evidence and reasoning, from post-specification traceability, linking them to designs, code and tests. Maintain both directions.

This book’s traceability rules are simple enough to check with an AI harness every sprint:

1. Every requirement traces back to at least one insight, or to an explicitly named strategic, compliance or technical driver. “The VP asked” is a driver; write it down as one.
2. Every high-confidence insight traces forward to a decision: build, defer or reject, with a reason.
3. Every requirement carries an acceptance criterion and a success metric. For AI behavior, the metric is an eval with a threshold (Chapter 31).
4. Results flow back. When the metric comes in, update the insight’s confidence. An insight that drove three releases and moved nothing should be demoted.

The specification as a behavioral document

Read the specification as decisions about user behavior. Give three areas explicit treatment.

Behavioral design decisions. Every default, framing, choice set and prompt in the spec is an intervention. Write each down with its rationale and the four-test result from the persuasion section above.

AI behavior. For AI features, specify expected outputs, when the system should decline or escalate, how confidence and evidence are shown, and which evals gate release. Chapter 31 covers evals in depth.

Acceptance criteria in Given, When, Then form. Behavior-driven development’s format (“Given [context], when [event], then [observable outcome]”) forces each requirement into something a test or an eval can check. If you can’t write the “then,” the requirement isn’t finished.

Communicating insights: the insight brief

Use a one-page insight brief to carry the evidence and decision to accountable stakeholders.

Follow Minto’s pyramid principle: insight and decision first, then evidence. Include sources, sample size, strength, contrary evidence, affected roles and revenue, options, recommendation, confidence and an ask with owner and date. Put method detail last.

Separate observation from interpretation. Scrolling past a summary is observable; distrust is an explanation to test. Include contrary evidence so reviewers can assess confidence.

Tailor the brief by audience without changing its substance. Executives want the implication, the risk and the ask. Engineering wants the behavior, the edge cases and the acceptance criteria. Sales and marketing want the buyer’s language, verbatim. Chapter 34 covers persuasive writing in more depth.

Relaunch and repositioning

Misclassification, wrong competitive comparisons or misunderstood value may call for repositioning, and a substantial change may justify a relaunch.

Dunford works through competitive alternatives, differentiated capabilities, customer value, target customers and market category. Her triggers include unexpected competitors, different responsive segments and entry into new segments. This book adds substantial capability changes and trust events that require a visible reset.

Reserve relaunches for substantial perception changes. Fix quality and onboarding problems directly before attracting more customers to the same experience.

A relaunch plan covers the trigger and its evidence; the positioning delta (old against new, for each of Dunford’s five components); target segments and the message for each buying-group role; the product changes that ship with it; the plan for existing customers; channel and enablement; metrics with baselines; and risks with a rollback. The existing-customer section is where relaunches go wrong ethically. Migrations that happen silently, contracts that change on renewal without clear notice and exports that become harder after the switch are the B2B versions of hard-to-cancel and sneaking.

Measure the relaunch against a baseline set before launch. Leading indicators: qualified pipeline in the new category, win rate against the new competitor set, sales-cycle length, message recall in win/loss interviews and activation of the new capability. Lagging indicators: net revenue retention, expansion and churn in migrated cohorts. Compare cohorts rather than totals, and set the review date in advance so the result can’t be quietly reinterpreted. Chapter 25 covers launch execution and Chapter 30 covers migrating customers off retired products.

How to apply it

This method runs alongside continuous discovery (Chapter 01). It takes a body of evidence to a decided, specified and communicated change in about four weeks.

Week 1: Frame and synthesize.

1. Write the decision you need to inform, with its owner and date. Insight work without a decision drifts.
2. Gather the evidence through your harness’s connectors: interview snapshots, call recordings, tickets, post-incident reviews, usage reports. Use approved tools for customer data.
3. Ask the harness for a first-pass clustering, with every claim cited to a source record. Read the sources behind the top clusters yourself.
4. Map the buying group’s decision: job, fear, proof and veto for each role.

Week 2: Write insights and brief them.

5. Write three to five insight statements. Test each against the four criteria (non-obvious, explains behavior, grounded, implies action). Kill the ones that fail.
6. Write the insight brief for the decision owner. Review it with one skeptic before it goes out.
7. Get a decision: build, defer or reject, recorded in the decision log.

Week 3: Specify and review.

8. Draft the specification with linked insight IDs, acceptance criteria and success metrics.
9. List every behavioral design decision in it. Run the behavioral design review, including the dark-pattern check, with design, engineering and someone from legal or compliance for anything touching billing, consent or data.
10. Build the traceability table. Have the harness flag requirements with no upstream insight and insights with no downstream decision.

Week 4: Commit and measure.

11. Agree baselines and the review date for each success metric before work starts.
12. If the insight concerns market perception rather than a feature, open a relaunch plan and test the new positioning with five to ten customers before committing a launch moment.
13. After release, update insight confidence with the results and close the loop in the brief.

The AI lens

Building AI-powered products: trust is a behavioral question

For AI products, the most important consumer insight is usually about trust: when people rely on the system, when they don’t, and whether that matches how good it actually is.

John Lee and Katrina See’s 2004 review, “Trust in Automation,” set the goal that still holds: calibrated trust, where trust matches the system’s actual trustworthiness. Too much trust produces misuse (accepting wrong answers); too little produces disuse (ignoring right ones).

Dietvorst, Simmons and Massey (2015) found algorithm aversion after observed mistakes. Logg, Minson and Moore (2019) found algorithm appreciation among lay users, with experts discounting advice. Together, these suggest overreliance before errors and underuse afterward. A 2018 Dietvorst study found users more willing to use imperfect algorithms when they could modify outputs.

Human approval alone cannot establish effective oversight. Vaccaro, Almaatouq and Malone’s 2024 meta-analysis of over 100 experiments found human-AI combinations worse on average than the better performer alone. Losses centered on decision tasks and gains on content creation. AI Act Article 14 requires high-risk-system oversight to address automation bias.

Specify trust as behavior. Put evidence where the decision happens. Show confidence honestly. Let users adjust the output rather than only accept or reject. Measure both acceptance and wrong acceptance, because a rising acceptance rate is good news only if the accepted answers are right. And treat manipulation by AI as a dark pattern: an agent that flatters, pressures or exploits a user’s situation can fall under the AI Act’s Article 5 prohibitions, which apply in the EU.

Doing the work with AI

Moran and Rosala’s NN/g guidance, reviewed January 2026, treats transcription, summaries, initial grouping and redaction as delegation candidates. Keep interpretation and fact checks with researchers. Earlier Liu and Moran research found missing visual context, vague claims and weak citations. Use checkable outputs.

Frame questions, check source citations and judge confidence. Request counts with record IDs. Ask for contrary cases and unclassified records so clustering does not conceal differences.

The Beacon case: why responders don’t accept the diagnosis

Synthesis. You connect the harness to design-partner call recordings, support tickets and post-incident reviews, and ask it to group every rejected diagnosis by the stated reason, citing the record for each. You read the sources behind the largest cluster yourself. The pattern: responders reject diagnoses when the supporting evidence isn’t on the first screen. They scroll past the card to open logs and verify by hand. Several cite the wrong-rollback incident by name.

The insight. “On-call engineers like Dana need to verify a proposed root cause in under a minute, because since the wrong-rollback incident they treat any uncited claim as wrong.” It passes the four tests: the team had assumed accuracy was the constraint (non-obvious), it explains the scrolling (behavior), it’s grounded in calls and session evidence, and it implies a design change. It fits the pattern of algorithm aversion: after one visible error, trust in later answers dropped.

The brief. The VP and engineering leads receive one governing point: trust, more than accuracy, constrains adoption. Two partners accept most diagnoses without opening evidence. Flag that contrary finding as possible overreliance.

The buying group. The map sharpens it. Priya fears the agent will make things worse. Dana fears being blamed at 3 a.m. Marcus fears an ROI story that won’t survive his CFO. Sam fears uncontrolled production access and needs AI Act documentation for EU sales. Leo fears margin erosion across 60 customers. None of them names a smarter model as the first need.

The behavioral design review. The Act approval gate fails two of the four tests. “Approve” is visually dominant over “Reject,” which pushes System 1 toward approval and invites automation bias. And the admin console nags admins to expand the autonomous allowlist after every successful action. The fixes: medium-risk actions now require the evidence summary to be shown before approval is possible; the default autonomy level stays conservative; allowlist expansion becomes admin-initiated only; and turning autonomy off is one step, the same as turning it on.

The spec. The “evidence-first diagnosis card” traces INS-07 to REQ-21: show the top three evidence items, each with a source link, above the fold. Acceptance criterion: Given a diagnosis with cited evidence, when the card renders, then the three highest-weighted evidence items and their source links are visible without scrolling. Success metrics: diagnosis acceptance rate and wrong-acceptance rate, measured through post-incident review, with an eval set built from resolved incidents through the Learn capability.

Pricing. For per-resolved-incident pricing, the business-case template anchors on each customer’s own measured cost of an incident hour, from their data, rather than an industry figure. The pricing page keeps the old and new plans side by side so customers can compare (Chapter 15 covers the pricing decision itself).

The relaunch. The evidence supports repositioning Beacon from “AIOps alert correlation,” where it’s compared with features bundled into observability platforms, to “agentic incident resolution,” where the main alternative is humans plus runbooks plus chat. The relaunch plan works through Dunford’s five components, old against new. Classic customers get a published sunset timeline, no silent auto-migration and one-step data export. The scorecard has baselines set before Northlight Live: pipeline in the new category, win rate against startups building ops agents, sales-cycle length, Beacon Agents activation, autonomous resolution rate, NRR in the migrated cohort against today’s 118%, and gross margin against today’s 72%.

Product 360 artifacts

# Insight statement · INS-[xx] · [Product] · [Date]

**Owner:** [PM]   **Status:** Draft / Briefed / Decided / Retired   **Linked decision:** [decision log entry]

## The insight in one sentence
[User] needs [need] because [explanation of the behavior].

## Structure
- **Who:** [role, context, position in the buying group]
- **Observed:** [the behavior, stated as observation, not interpretation]
- **Evidence:** [n interviews, usage report, tickets, reviews, with source IDs]
- **Because:** [motivation or constraint that explains the behavior]
- **Tension:** [what they want] versus [what stops them]
- **So we believe:** [implication for the product]
- **Confidence:** High / Medium / Low
- **What would change our mind:** [specific evidence]

## Quality test
| Test | Pass / Fail | Note |
|---|---|---|
| Non-obvious: the team was not already acting as if this were true | | |
| Explains behavior: says why, not only what | | |
| Grounded: traces to at least two independent sources | | |
| Implies action: a reader knows what to do differently | | |

## Contrary evidence
- [What doesn't fit, with source IDs]

## Forward trace
| Decision (build / defer / reject) | Requirement IDs | Date | Result when measured |
|---|---|---|---|
| | | | |

# Buying-group insight map · [Product or deal type] · [Date]

**Decision being studied:** [purchase, renewal, expansion, adoption of a capability]
**Evidence:** [win/loss interviews, call recordings, security reviews, CRM notes]

| Role | Person or persona | Job in the purchase | Fear | Proof they need | Veto power (none / soft / hard) | Evidence |
|---|---|---|---|---|---|---|
| End user | | | | | | |
| Champion | | | | | | |
| Economic buyer | | | | | | |
| Technical evaluator | | | | | | |
| Procurement or legal | | | | | | |
| Partner (if any) | | | | | | |

## Where consensus stalls
[Which role, at which step, and why]

## Risk-reduction features this implies
| Fear addressed | Feature or artifact (pilot, audit log, exit clause, security pack) | Owner |
|---|---|---|
| | | |

## How AI assistants describe us
[What a buyer's AI assistant says about our product for this role's key question, and where it is wrong or vague]

# Insight brief · [Headline in one sentence] · [Date]

**To:** [decision owner]   **From:** [PM]   **Decision needed by:** [date]

## The insight
[One sentence. Lead with it.]

## Why it matters for this decision
[The so-what: what the decision is, and how this insight changes it]

## Evidence
| Source | Sample | What it shows | Strength (strong / some / weak) |
|---|---|---|---|
| | | | |

**Observation:** [what we saw]
**Interpretation:** [what we think it means]
**Contrary evidence:** [what doesn't fit]

## Who is affected
[Roles, segments, number of customers, revenue at stake]

## Options
| Option | What it means | Cost | Risk |
|---|---|---|---|
| A | | | |
| B | | | |
| Do nothing | | | |

## Recommendation
[Option and reason, in two or three sentences]

## Confidence
High / Medium / Low. This would change if [specific evidence].

## The ask
[Decision required], owner [name], by [date].

# Behavioral design review · [Feature or flow] · [Date]

**Reviewers:** [PM, designer, engineer, legal or compliance where billing, consent or data is involved]
**Spec:** [link]   **Markets:** [US / EU / other]

## 1. Choice architecture inventory
| Element | Type (default, framing, ordering, prominence, choice set, prompt, AI suggestion) | Current design | Intended effect on behavior | Rationale |
|---|---|---|---|---|
| | | | | |

## 2. Persuasion or manipulation: four tests (per element)
| Element | Serves user's own goal? | Survives disclosure? | Symmetric (out as easy as in)? | True information? | Verdict |
|---|---|---|---|---|---|
| | | | | | Keep / Change / Escalate |

## 3. Dark-pattern check
Mark any that apply and name the screen and element.
- [ ] Sneaking (items, renewals or changes added without clear notice)
- [ ] Hard to cancel or downgrade (exit harder than entry)
- [ ] Preselection that favors us over the user
- [ ] Obstruction (data export, account closure or opt-out made laborious)
- [ ] Hidden costs or hidden subscription terms
- [ ] Trick wording or confirmshaming
- [ ] Visual interference (the option we prefer is dominant, the other hidden)
- [ ] Nagging (asking again for a choice already made)
- [ ] Fake urgency, scarcity or social proof
- [ ] Comparison prevention (plans or prices hard to compare)
- [ ] Privacy choices obscured or subverted
- [ ] AI-specific: agent that flatters, pressures or exploits the user's situation

Regulatory lenses to note (confirm applicability with counsel): FTC Act Section 5 and ROSCA (US); DSA Article 25 for online platforms, UCPD and GDPR (EU); AI Act Article 5 for AI systems (EU).

## 4. AI trust check (AI features only)
- Is evidence shown where the decision is made?
- Is confidence shown honestly, including uncertainty?
- Can the user adjust the output, not only accept or reject?
- Are acceptance and wrong acceptance both measured?
- Does the design guard against automation bias at approval points?

## 5. Defaults register
| Default | Value | Owner | Rationale | Share of customers who change it | Review date |
|---|---|---|---|---|---|
| | | | | | |

## Outcome
Approved / Approved with changes / Escalated to [name]. Changes required: [list]. Signed off by [names] on [date].

# Product specification · [Feature] · v[n] · [Date]

**Owner:** [PM]   **Design:** [name]   **Engineering:** [name]   **Status:** Draft / In review / Approved

## 1. Context and linked insights
| Insight ID | Insight (one sentence) | Confidence |
|---|---|---|
| | | |

Other drivers (strategic, compliance, technical): [list, named as drivers]

## 2. Users and buying-group roles affected
[End users, champion, economic buyer, technical evaluator, procurement, partner]

## 3. Goals, non-goals and success metrics
- Goals:
- Non-goals:
- Success metrics with baselines and review date:

## 4. Functional requirements
| Req ID | Requirement | Traces to | Acceptance criterion (Given, When, Then) | Priority |
|---|---|---|---|---|
| REQ-[xx] | | INS-[xx] | Given [context], when [event], then [observable outcome] | |

## 5. Behavioral design decisions
| Decision (default, framing, choice set, prompt) | Choice made | Rationale | Four-test result |
|---|---|---|---|
| | | | |

## 6. AI behavior (AI features only)
- Expected outputs and format:
- When to decline, ask or escalate:
- How evidence and confidence are shown:
- Evals that gate release, with thresholds:
- Human approval points and what the approver sees:

## 7. Non-functional requirements
Security and access, audit logging, latency, availability, data residency, accessibility, cost per action.

## 8. Risks and review results
- Behavioral design review outcome: [link and verdict]
- Open questions:
- Risks and mitigations:

## 9. Traceability
| Insight ID | Opportunity or job | Req ID | Acceptance criterion | Success metric | Verification (test or eval) | Status |
|---|---|---|---|---|---|---|
| | | | | | | |

Requirements with no upstream insight or named driver: [list or "none"]
High-confidence insights with no decision: [list or "none"]

# Relaunch plan · [Product] · [Launch moment] · [Date]

**Owner:** [PM]   **Marketing lead:** [name]   **Decision maker:** [name]

## 1. Trigger and evidence
Trigger: Unexpected competitors in deals / Value resonates with a different segment / New segment entry / Capability outgrew the category / Trust reset
Evidence: [win/loss, pipeline, interviews, with sources]
Why this is perception, not product quality or onboarding: [reasoning]

## 2. Positioning delta
| Component | Today | After relaunch | Evidence |
|---|---|---|---|
| Competitive alternatives | | | |
| Differentiated capabilities | | | |
| Value | | | |
| Target customers | | | |
| Market category | | | |

## 3. Segments and buying-group messages
| Segment | Role | Message | Proof |
|---|---|---|---|
| | | | |

## 4. Product changes shipping with the relaunch
[List, with spec links]

## 5. Existing customers
- What changes for them, and when:
- How they are told (channel, notice period):
- Migration: opt-in or scheduled, with a published timeline; no silent migration
- Data export and exit: [how easy, confirmed by the behavioral design review]
- Contract or pricing changes and how they are disclosed:

## 6. Channels and enablement
Sales, partners, customer success, documentation, and the content AI assistants will summarize.

## 7. Metrics and baselines (set before launch)
| Metric | Type (leading / lagging) | Baseline | Target | Cohort | Review date |
|---|---|---|---|---|---|
| Qualified pipeline in new category | Leading | | | | |
| Win rate vs. new competitor set | Leading | | | | |
| Sales-cycle length | Leading | | | | |
| Message recall in win/loss | Leading | | | | |
| New capability activation | Leading | | | | |
| NRR, expansion, churn in migrated cohort | Lagging | | | | |

## 8. Risks and rollback
| Risk | Signal | Response | Owner |
|---|---|---|---|
| | | | |

Prompts

Goal: Get a first-pass synthesis you can verify, with every claim traceable to a record.
Paste in (or connect the harness to): interview snapshots, call recordings or transcripts, support tickets and review notes for one question. Use only tools approved for customer data, and redact personal identifiers first.

I need to understand [question, for example: why customers reject X / why deals stall at Y]. Using only the material provided:

1. Group the records by the reason or behavior they show. Name each group from the customer's point of view.
2. For each group, give the count of records and list every record ID. Quote one representative line verbatim with its ID.
3. Separate what customers did (observed behavior) from what they said (stated reasons).
4. List the records you could not classify, and the records that contradict the largest group.
5. Note any group that appears in only one customer, segment or buying-group role.

Report counts with source IDs. Ground each claim in the records and label unresolved interpretations as questions.

Check the output: open the records behind the two largest groups and confirm the quotes and counts. Read every unclassified and contradicting record yourself; that's where the model is most likely to have smoothed something over.

Goal: Move from "what happened" to "why it happened and what follows."
Paste in: the cited themes from your synthesis and the decision you need to inform.

For the decision [decision], turn these themes into at most five insight statements. For each, write:
- One sentence: [user] needs [need] because [explanation].
- Who, Observed, Evidence (with record IDs), Because, Tension, So we believe, Confidence (high/medium/low) and what would change our mind.

Then grade each against four tests, pass or fail with a reason: non-obvious, explains behavior (why, not what), grounded in at least two independent sources, implies action. Rewrite or drop any that fail. Flag any "Because" that goes beyond what the evidence shows and label it as a hypothesis.

[themes]

Check the output: for each surviving insight, ask whether your team was already acting as if it were true. If yes, it isn't non-obvious. Confirm the "Because" with at least one customer before briefing it.

Goal: Produce a one-page brief that leads with the decision and shows evidence honestly.
Paste in: the insight statement, the evidence table, the options you see and who will read the brief.

Write a one-page insight brief for [reader and role] who must decide [decision] by [date]. Lead with the insight in one sentence and why it matters for this decision. Then: evidence (sources, sample, strength), clearly separated observation and interpretation, contrary evidence, who is affected and what is at stake, two or three options including doing nothing, a recommendation, confidence and what would change it, and the ask with owner and date.

Write for this reader: [executive: implication, risk, ask / engineering: behavior, edge cases, acceptance criteria / sales: buyer language]. Put method detail after the decision and evidence. Match confidence to the evidence supplied.

[insight, evidence, options]

Check the output: confirm every number matches your evidence table. If the brief contains no contrary evidence, add it or say there was none; a brief with no disconfirming data reads as advocacy.

Goal: Find choice-architecture problems before they ship or before a regulator finds them.
Paste in: screenshots or descriptions of the flow, the relevant spec sections and the markets you sell in.

Review this flow for [feature]. For every default, framing, ordering, prominence decision, choice set, repeated prompt and AI suggestion:
1. Describe the element and its likely effect on user behavior.
2. Apply four tests: does it serve the user's own goal; would it survive disclosure of the rationale; is it symmetric (exit as easy as entry, decline as easy as accept); does it use true information?
3. Check it against these patterns: sneaking, hard to cancel, preselection, obstruction, hidden costs, trick wording, confirmshaming, visual interference, nagging, fake urgency, scarcity or social proof, comparison prevention, obscured privacy choices.
4. Note which regulatory lens might apply: FTC Act Section 5 and ROSCA (US); DSA Article 25, UCPD or GDPR (EU); AI Act Article 5 for AI behavior. Say "may apply; confirm with counsel" rather than giving a legal conclusion.
5. Propose a specific fix for each issue, naming the screen and element.

[flow and spec]

Check the output: walk the flow yourself as a user trying to leave, decline or export. The model can miss issues that only appear across several screens. Send anything touching billing, consent or personal data to legal.

Goal: Find requirements with no reason to exist and insights nobody acted on.
Paste in: the insight register (IDs and one-line statements, with confidence) and the specification or backlog export.

Compare these two documents.
1. For each requirement, name the upstream insight ID or named driver (strategic, compliance, technical). If none, say "none."
2. For each high-confidence insight, name the requirement IDs or recorded decision that respond to it. If none, say "none."
3. For each requirement, say whether it has an acceptance criterion in Given, When, Then form and a success metric. List the gaps.
4. Flag requirements whose acceptance criterion would pass even if the linked insight's problem were not solved.

Present the result as a traceability table plus two lists: orphaned requirements and orphaned insights.

[insights]
[spec]

Check the output: spot-check three links the model claims. Orphaned requirements aren't automatically wrong, but each needs a named driver or a conversation.

Goal: Check that an AI feature aims for calibrated trust, not maximum acceptance.
Paste in: the feature spec, the approval or acceptance flow, the metrics you track and any incident history.

Act as a human-factors reviewer. For this AI feature [feature]:
1. Identify where users might over-rely on the output (misuse) and where they might ignore correct output (disuse).
2. Check whether evidence and confidence are visible at the moment of decision, and whether users can adjust the output rather than only accept or reject.
3. Check approval steps for automation bias: is approving easier or more prominent than rejecting or inspecting?
4. Check whether the metrics distinguish acceptance from correct acceptance. Propose a wrong-acceptance metric if missing.
5. Describe how trust would likely change after one visible error, and what the design does to recover it.

Base claims on the material provided; mark anything else as a hypothesis to test.

[spec, flow, metrics, incidents]

Check the output: test the riskiest scenario with real users or design partners. A review on paper can't tell you how a tired responder behaves at 3 a.m.

Goal: Decide whether a relaunch is warranted and what would change.
Paste in: win/loss notes, recent pipeline by competitor and segment, current positioning, the capability changes and customer quotes. Use approved tools for CRM data.

Using April Dunford's five positioning components (competitive alternatives, differentiated capabilities, value, target customers, market category):
1. Describe our positioning today as the evidence shows it, not as our messaging claims it.
2. Say whether the evidence shows a repositioning trigger: unexpected competitors in deals, value resonating with a different segment, new segment entry, capability outgrowing the category, or a trust reset. Cite records.
3. Test the alternative explanation: is the real problem product quality or onboarding rather than perception?
4. If a trigger is present, draft the positioning delta (today versus proposed) for each component.
5. List what existing customers would experience and any step that could feel like a forced or hidden change.

[evidence]

Check the output: test the proposed positioning with five to ten customers in the target segment before committing to a launch moment. If step 3 found a product problem, fix that first.

Anti-patterns

Checklist

• The decision the insight work informs is written down with an owner and a date.
• Synthesis cites a source record for every claim, and someone has read the sources behind the main themes.
• Each insight statement passes the four tests: non-obvious, explains behavior, grounded, implies action.
• The buying group’s decision is mapped: job, fear, proof and veto for each role.
• Every behavioral claim the team relies on is labeled with its evidence status, and conditional effects are treated as hypotheses.
• Every default in the spec has an owner, a rationale and a measurement.
• The insight brief leads with the insight and the ask, separates observation from interpretation and shows contrary evidence.
• The specification links each requirement to an insight or a named driver, with acceptance criteria and success metrics.
• The behavioral design review, including the dark-pattern check, is complete, with legal involved for billing, consent and data flows.
• AI features specify how evidence and confidence are shown, and measure wrong acceptance as well as acceptance.
• Any relaunch has a trigger backed by evidence, a positioning delta, an existing-customer plan with no hidden changes, and baselines set before launch.
• Results flow back to update insight confidence after release.