---
title: 'Strategy Decisions and Rationale (Addendum)'
source: notion
notion_id: '3032425b-f103-80b3-9f1a-d2b58a2d9b07'
migrated: '2026-04-02'
last_refreshed: '2026-02-05'
status: active
tags: [strategy, decisions, rationale, internal]
---

# Strategy_Decisions_and_Rationale_(Addendum)

**Last refreshed:** 2026-02-05

**Purpose:** A durable, portable record of my current thinking on EmpathyIQ’s strategy, portfolio, and how the architecture ladders from product promises down to what we build. This is meant to be queried, challenged, and updated over time.

**Role:** Decision + rationale record (includes founder/CTO context and working assumptions).

**Use for:** why we believe what we believe, what’s locked, what’s open, and the reasoning behind portfolio structure and launch posture.

**Not authoritative for:** current portfolio structure, readiness, or Now/Next/Later labels (see the portfolio CSV + interpretation/change guides).

**Precedence:** If this doc conflicts with the latest CSV labels, treat it as “context” and use the CSV + guides for the current state.

**Companion doc:** the “Confidence Story” narrative explains the end-to-end experience and differentiation; this addendum captures decisions, rationale, and open questions.

---

## 1) The core problem we’re solving (as I currently see it)

Enterprise client-side researchers already “do research.” They already have tools, vendors, agencies, templates, and ways of getting things done.

The real issue isn’t that they’re missing steps in the lifecycle. They’re missing **trust** and **continuity** across steps.

What’s broken is the invisible backbone:

- Too many handoffs
- Too many manual checks and specialist dependencies
- Too much rework late in the process
- Too much risk that the data is dirty or the story can’t be defended
- Too much “deck rebuild” from scratch
- Too much fragmentation between quant, qual, and institutional knowledge

So the suite can’t just say “we cover everything end-to-end.” They already have end-to-end coverage in practice (just messy). The real question they ask (implicitly) is:

> “Why should I rip out or coexist with my current stack?”
> 

The suite needs to win on system-level outcomes:

- **Reduced uncertainty**
- **Defensible decision-making**
- **Consistency and continuity**
- **Reduced operational burden (less babysitting)**

---

## 2) The portfolio “throughline”: Confidence vs Certainty vs Speed

### The market narrative today: speed

Most competitors sell some form of “speed”:

- faster studies
- faster analysis
- more qual at quant-like scale
- more with fewer people

Speed is real value, but it’s also table stakes language now.

### My current hypothesis: certainty (reduced uncertainty) is the real value

I think a stronger truth is this:

- Companies don’t ultimately want speed.
- They want **certainty** (or at least reduced uncertainty) so they can act without regret.

That “certainty” breaks down into three places where teams bleed time, risk, and trust:

1. Certainty we’re asking the right questions (and asking them well)
2. Certainty we’re collecting real, clean, decision-grade data
3. Certainty we’re surfacing the right insights and can defend them

Speed is often a byproduct of certainty:

- If we reduce rework and late surprises, the process becomes faster.
- If we make the chain defensible, the deck becomes faster to produce and reuse.
- If we detect quality issues early, fieldwork runs smoother.

### Why I’m careful with the word “certainty”

“Certainty” can sound like a guarantee, which research can’t honestly promise.

So the positioning I’m leaning toward is:

- **Reduce uncertainty**
- **Decision-grade confidence**
- **Defensible outcomes**
- **Fewer late surprises**

### The structure that still works (and maps to product design)

Even if “reduced uncertainty” is the umbrella, the best operating model I’ve found for actually building is:

**Confidence before / confidence during / confidence after research**

It’s specific, it maps to workflows, and it keeps us honest about what we’re improving.

---

## 3) Who we’re building for (DECISION – locked)

### ICP (current)

- Enterprise buyers (not individual subscribers first)
- Client-side researchers (explicitly not agency-side first)
- Lower tolerance for complexity
- Higher need for defensibility and trust

### Individual self-serve tier (DECISION - added 2026-08-29)

Enterprise remains the primary ICP. An individual self-serve tier is being opened alongside it, via Stripe checkout, to acquire users, volume and usage without waiting for full B2B SLAs and a sales function to be in place.

This is an addition to the ICP position, not a replacement. Enterprise client-side insight teams remain the buyer the product is designed around; the individual tier is an acquisition and usage motion.

It is also consistent with the DIY market thesis: an independent researcher is exactly the buyer an agency model cannot reach.

Pricing and account-state mechanics: [self-serve pause model](../../strategy/gtm/self-serve-pause-model-2026-08-29.md).

### Why this matters operationally

Even a great product can fail here if it requires an org change that the customer can’t absorb. So we need to design for:

- assisted onboarding
- guardrails
- reliability and governance
- a clear proof loop that makes adoption feel rational and safe

---

## 4) What the portfolio is (and why these tools belong together)

### Portfolio stance **(DECISION – locked)**

EmpathyIQ is a **Research OS / suite**. Not “just a survey tool.”

### Portfolio products (current list)

In the portfolio today:

1. **Platform (Shared Services)**
2. **Quantitative research platform**
3. **Qualitative discussion group platform**
4. **Qualitative AI interviewer** (outsourced integration, branded as part of EmpathyIQ)
5. **AI Knowledge repository** (query uploaded documents/reports via natural language)

Planned / future (not yet fully defined):
6. **Panel platform** (rudimentary; not yet built)
7. **Persona builder** (future concept)

### Why these belong together (the non-hand-wavy version)

These products belong together if, and only if, they reinforce system-level outcomes that point tools don’t deliver well.

The suite must be able to say:

- we reduce uncertainty *across* research types (quant + qual + knowledge)
- we reduce operational burden via shared primitives (identity, governance, audit trail, templates, reuse)
- we preserve continuity so insights compound instead of resetting every project

---

## 5) The delivery reality: SaaS vs software-under-service (WORKING STANCE / HYPOTHESIS)

### Founder belief (important context)

The founder’s view is that pure SaaS adoption in research is often an org change and the market historically hasn’t gone “all-in” on self-serve in large numbers. He believes “software under service” or “do-it-together” may be the durable wedge.

### My working stance

We can still build a product business, but we need delivery modes that match enterprise reality:

Delivery modes (strategy-level, not architecture):

1. **Self-serve**
2. **Do-it-together** (assisted adoption)
3. **Software-under-service** (managed delivery using our platform)

The risk is obvious: services can hijack roadmap and turn into bespoke chaos.
So the rule I want is: if we do service wrappers, they must be **productized** (repeatable templates + tight SKUs), not one-off custom work.

---

## 6) Launch posture and pilot ask (WORKING PLAN)

### Launch posture (current)

We likely launch with four products visible as a suite:

1. Quant tool (survey editor) — ~95% there
2. Discussion forum tool — owned, separate flow
3. AI Knowledge repository — being built; not deeply integrated yet
4. AI interviewer — outsourced integration, branded inside EmpathyIQ

The “suite posture” matters because the founder has consistently positioned the business as broader than a survey tool.

### Pilot (the ask)

Working pilot structure:

- handful of customers (already testing with Musgrave and UKOmnibus Group; aiming for Ryanair)
- ask them to run applicable research on the platform (quant and/or qual)
- bi-weekly conversations with us to get to root issues
- pilot for ~3 months, free, with a “break clause”
- target outcome: convert to a 1-year paid contract after the pilot (price TBD)
- ideally allow logo/name usage (discount incentives possible)

What we provide:

- high-touch onboarding
- direct channel support
- priority fixes for pilot blockers
- influence over shaping the product

### What “success” looks like (directional)

- consistent in-platform usage (studies launched, exports, knowledge repo usage)
- evidence of reduced uncertainty / reduced rework (proxy metrics)
- willingness to sign an annual contract (killer signal)

(Exact thresholds are OPEN until we see baseline behaviour.)

---

## 7) Our planning system: how we structure everything (canonical)

### Why we needed an architecture system

Founder conversations often move between the near-term build and the wider portfolio. I need a system that:

- shows how everything fits together
- makes scope and tradeoffs concrete
- keeps the portfolio discussion from looping forever
- lets us ladder features to outcomes and to the suite promise

### Canonical hierarchy (locked)

**Portfolio → Product → Core Workflow → Job Area → Feature Family → Feature → Document**

### Canonical system-of-record (locked)

- **Notion Architecture Nodes DB** is canonical
- nesting is represented via sub-items
- the main table stays lightweight for scanning and navigation
- details live in page bodies and nested Documents

---

## 8) Quantitative Research Platform: how it ladders

### Product promise (still being tightened)

The intent is:

- not another survey tool
- an end-to-end quant research product
- strongest value at the “fragile points” where teams second-guess, babysit, and rework

### Core Workflows (current)

These are the pillars of the quant product:

1. **Survey Design** (differentiating)
2. **Survey Deployment** (differentiating)
3. **Analysis & Insight** (differentiating)
4. **Data Access** (table stakes)
5. **Administration & Governance** (table stakes)

### How the “confidence model” maps

- **Before** = Survey Design
- **During** = Survey Deployment
- **After** = Analysis & Insight
- Hygiene foundations = Data Access + Admin/Governance

### Survey Design (the “before” thesis)

What I think matters most here:

- reassurance that the design is methodologically sound
- nothing important overlooked
- internal consistency
- reduced reliance on specialist review
- less fragile handoff to programming
- less manual formatting and renumbering-type effort
- easy collaboration with stakeholders/clients without chaos

### Survey Deployment (the “during” thesis)

The biggest deployment pain I’m focused on:

- real people vs bots
- data quality signals (speeding, straight-lining, etc.)
- flagging and removing/handling bad responses early
- fewer fieldwork manager “tests” and firefighting mid-field

If we crack this, fieldwork becomes calmer and more reliable, and confidence rises fast.

### Analysis & Insight (the “after” thesis)

Two major drains:

1. Deck/report creation is painfully manual and repetitive
2. Open ends are time consuming to interpret and synthesize

A real differentiator would be:

- reusable reporting outputs
- the ability to define and reuse slide structures/templates
- pull forward prior presentation patterns without re-entering everything
- structured, defensible synthesis (especially for open ends)

### Data Access (hygiene)

I don’t currently see a strong differentiator here.
The plan is to keep it table stakes and revisit only if customers show a real pain.

### Administration & Governance (hygiene)

Needs to be solid and boring:

- project/study lifecycle
- permissions
- audit logs
- organization and retrieval
If it’s weak, enterprise adoption dies.

---

## 9) Platform (Shared Services): what it is and why it exists

The platform exists so the suite can behave like an enterprise product:

- identity/auth
- authorization and governance
- billing and entitlements (SKUs across products)
- observability and reliability

I’ve listed platform workflows as:

1. Identity and Access Management
2. Authorization and governance
3. Observability
4. Billing, Entitlements & Access

There has been overlap in naming historically (“governance and access” vs “admin and governance”). This needs rationalization, but the intent is clear: platform = shared foundations.

---

## 10) The architecture’s practical job: build decisions, not documentation

### What this architecture is for

- show laddering from features → job areas → workflows → product promise → portfolio promise
- expose gaps (missing job areas, missing feature families)
- connect the suite direction to clear near-term build choices
- keep us honest about whether we can actually deliver the promises we write

### What it is not for

- exhaustive lists of every component
- listing every question type or export permutation
Those belong in Documents.

---

## 11) Interview evidence: how we validate and evolve strategy

### What I’m using interviews for (next 10 interviews)

- validate whether “confidence before/during/after” is differentiating or hygiene
- validate what actually drives willingness to pay
- identify the fastest success loop
- figure out the most efficient delivery mode for adoption

### The key shift I’m making

Instead of interviewing purely to validate a story, I want interviews to reveal:

- the earliest win that creates momentum
- the biggest uncertainty points (where they lose trust)
- what they do today to reduce uncertainty (workarounds)
- what they would pay to remove

### What I’m explicitly probing now (added emphasis)

I will include an “uncertainty probe” block:

- where do they feel uncertainty most?
- what’s the cost of being wrong?
- what do they do to defend decisions today?
- what’s “enough certainty” to act?
- forced tradeoff: speed vs reduced surprises/defensibility

---

## 12) Competitive reality check (why this matters)

I saw a competitor-style announcement (Discuss/Voxco/Ascribe) that sounded eerily similar to the language we’ve used (connected qual + quant + AI, one flow, confidence, etc.).

This is a signal:

- the suite story is becoming more common
- the words alone won’t win
- we must win on execution: time-to-value, adoption, defensibility, and real operational burden reduction

---

## 13) The biggest risks I’m watching

### Risk 1: “Suite posture” becomes strategy instead of an outcome

If the suite is treated as the product, we can waste months on brand architecture debates while build decisions stall.

The suite is not the strategy. The outcomes are.

### Risk 2: Overclaiming “certainty”

If we pitch certainty as guarantees, we’ll lose credibility with serious researchers. The safer and truer framing is “reduced uncertainty” and “defensible decisions.”

### Risk 3: Services gravity

Software-under-service can accelerate adoption, but can also trap us into bespoke work.
If we go there, it must be productized and repeatable.

### Risk 4: Disconnected point solutions

If we build separate “AI features” at each stage with no shared backbone, we’ll create a Frankenstein suite.
Even if we ship stage wins first, we need thin shared primitives (signals, audit trail, reuse structures).

---

## 14) Current open items **(OPEN)**

1. Is “confidence before/during/after” a differentiator or hygiene?
2. Is “reduced uncertainty” the better umbrella language (and how do we prove it)?
3. What is the fastest success loop per product (quant, qual, knowledge repo, AI interviewer)?
4. Pricing + packaging for enterprise conversion after pilot (still OPEN).
5. Panel platform scope (what do we mean by “panel”?).
6. Persona builder definition and feasibility.
7. Final rationalization of platform workflow taxonomy (remove overlap).

---

## 15) How I expect to use this artifact (practically)

- As the “brain” of the project folder so I don’t have to restate context in every chat.
- As the source I can challenge when new evidence appears (“does this still hold?”).
- As the guide for interview processing and architecture updates.
- As the anchor for founder/CTO discussions that move from portfolio direction into concrete build decisions.

---

## Appendix: Exporting this to a PDF (quick options)

### Option A (fastest): Notion

1. Paste this markdown into a Notion page
2. Export → PDF

### Option B: Google Docs

1. Paste into Google Docs (it handles headings well)
2. File → Download → PDF

### Option C: Obsidian / Markdown to PDF

Use any markdown-to-pdf exporter (Obsidian plugin or external).

If you want, I can format this doc with explicit page break markers suited to your exporter.

---

**Project instructions**

This project contains multiple strategy artefacts with different roles.

- Use the **Portfolio CSV** as the source of truth for current structure and scope.
- Use the **Strategy Interpretation Guide** to understand labels, readiness, and workflow meaning.
- Use the **Change Semantics Guide** to interpret differences between CSV versions.
- Use the **Confidence Story / Strategy Narrative** to understand differentiation and intended end-to-end experience.
- Use the **Strategy Decisions & Rationale (Addendum)** for founder context, locked decisions, and open questions.