Approve draftReady for beta
Create simple pricing material for conversations
Review the current EUR pricing explainer so the founder can handle beta commercial conversations consistently.
Pricing and commercial model
Open workstream contextBack to Overview
Choices to be made
The choices to work through with the founder.
Use this page as a meeting guide: check the drafts, make the choices that affect the first customer trials, and park the less urgent choices until the basics are agreed.
Approve now
Drafts to check first
Approve draftIn progress
Approve the buyer follow-up one-pager copy
Approve the content for a short buyer-facing follow-up asset before it becomes a designed page, PDF, or shareable link.
Sales motion and demo readiness
Open workstream contextApprove draftIn progress
Turn the positioning into sales-ready proof claims
Approve a short set of maturity-aware claims built around answering faster, staying in control, and making insight travel.
Category and positioning
Open workstream contextApprove draftReady for beta
Prepare answers to common questions
The FAQ now reflects current positioning, EUR pricing, assisted beta, and product maturity; its competitor claims still need an August recheck.
Sales motion and demo readiness
Open workstream contextDecide now
Choices to discuss on Friday
Needs a callImportant before first customers
Confirm we set up as our own separate company
Do we stand this up as its own company with its own legal identity, with Empathy Research, Futavista and DB among our first customers, and our primary focus a SaaS platform for the whole insight industry rather than internal tools for the <un>known family?
Suggested answer: Confirm the separate company. If the founder wants this kept inside Empathy instead, that needs to be said now, because the legal, brand, and certification work all branch from this one call.
Needs a callImportant before first customers
Decide whether we are sticking with <un>peel for the first customer trials
Are we happy enough with the <un>peel name to use it with early customers, or do we need to stop and review the name before more material is built around it?
Suggested answer: Keep <un>peel for the first customer trials unless there is a serious concern about the name. If there is doubt, deal with it now rather than carrying that doubt into customer meetings.
Needs a callImportant before first customers
Decide how much we reference Empathy Research and <un>known
As a separate company, how visibly do we reference Empathy Research and the <un>known family in our marketing and customer materials?
Suggested answer: Lead as our own company, and reference Empathy Research where it adds credibility, especially as an early customer. Keep the <un>known lineage light, present where useful but never the headline.
Needs a callImportant before first customers
Approve the direction for our own visual identity
Do we build our own visual identity for the new company, or carry over the look and colours from the <un>known family?
Suggested answer: Build our own visual identity so the look fits the business we are creating. Avoid grandfathering in a palette and style built for a research group.
Needs a callImportant before first customers
Approve the positioning story for external use
Do we approve the current story, Answer faster, Stay in control, Make it travel, with our end-to-end research lifecycle as the differentiator, for use everywhere?
Suggested answer: Approve the current speed, control, travel story and the whole-lifecycle distinction. Use confidence, audit trail, and defensibility only where they answer a specific buyer question.
Needs a callImportant before first customers
Approve the EUR pricing and beta package rules
Are the public EUR price anchors, plan inclusions, pilot rules, and path into annual contracts commercially sound enough to use consistently?
Suggested answer: Keep the public anchors at Starter EUR 260 per seat per month, Foundation from EUR 1,750 per month, Growth from EUR 5,850 per month, and Enterprise as contact us. Approve the included capabilities explicitly and keep unenforced usage limits, support exceptions, and pilot-to-annual terms inside proposals and live conversations.
Needs a callImportant before first customers
Approve the assisted private-beta delivery model
What exactly do we include in a founder-led, high-touch beta, where does that support stop, and how does each pilot move toward a paid annual relationship?
Suggested answer: Use a productized assisted-beta model: defined onboarding, a named support channel, scheduled reviews, bounded priority-fix commitments, an agreed evidence or quote ask, and an explicit route into a paid annual plan. Do not allow the beta to become open-ended consulting.
Needs a callImportant before first customers
Decide who owns outbound sales, and when we go wider than founder-led selling
Who is the official outbound sales team driving new business, and at what point do we move beyond founder-led selling and approved warm referrals?
Suggested answer: Keep founder-led selling as the current perimeter, name the owner for outbound, and agree the observable signals that unlock a wider motion so it does not happen by accident.
Needs a callImportant before first customers
Approve the gates for widening sales beyond founder-led beta
Which legal, product, proof, support, and sales-material checkpoints must be complete before access widens beyond founder-led pilots and approved warm referrals?
Suggested answer: Keep founder-led pilots and explicitly approved referrals as the current perimeter. Widen only after the contracting identity, privacy/DPA minimum, product-maturity map, proof rules, support capacity, and approved sales promises are in place.
Needs a callImportant before first customers
Green-light the new entity and its legal document set
Do we register the new business entity and build a full new legal document set, and re-contract existing customers under it?
Suggested answer: Green-light the entity registration and the new legal set now, since the lead time runs to months, and plan to re-contract Empathy Research, DB, Futavista, Musgrave and UKOmnibus under the new company.
Needs a callImportant before first customers
Agree the certification plan and timing (ISO and security)
What do we commit to for ISO and security certification, and by when, given that a separate company lets us certify only ourselves and the dev team?
Suggested answer: Commit to a scoped certification plan for the new entity and the dev team, with a realistic timeline, and treat it as a launch dependency rather than an afterthought.
Needs a callImportant before first customers
Decide the website release gate beyond private beta
Can the current website be used for controlled beta conversations now, and which exact blockers must close before it is shared or promoted more broadly?
Suggested answer: Approve the current site for controlled founder-led beta use once product truth and unpermissioned proof are corrected. Keep broader promotion gated until the legal/company minimum and customer-reference rules are complete.
Needs a callImportant before first customers
Set the official public go-live date
When do we go public, website live and the company announced, given that the entity, contracts, and certification need to be in place first?
Suggested answer: Set a target go-live date anchored to the legal and certification lead time, and confirm it once those timelines are known. Do not announce publicly before the entity and contracts exist.
Needs a callImportant before first customers
Approve what is live, beta, selected-customer-only, or directional
What can every buyer purchase today, what can selected customers access in beta, and which products should appear only as clearly dated roadmap direction?
Suggested answer: Use one maturity-labelled commercial map backed by the current roadmap and technical confirmation. Allow curated access where appropriate, but never turn access to the full designed product set into a blanket promise or describe future capability as generally live.
Needs a callImportant before first customers
Decide which customer names, quotes, and proof can appear publicly
Which named organisations and anonymous pilot quotes on the website are approved for external use, and what should be anonymised or removed until permission and source evidence are recorded?
Suggested answer: Create a simple proof-permission register. Keep only references that are owned, sourced, and approved; anonymise or remove everything else until permission is recorded. Ask Declan to route any customer approvals through the correct relationship owner.
Needs a callImportant before first customers
Approve the proof standard for each type of sales claim
Which claims require before-and-after evidence, which can use mechanism proof or a short review, and which must wait until a product is genuinely in customer use?
Suggested answer: Use mechanism proof for capabilities that can be shown now, before-and-after case studies for material workflow or outcome claims once there is real usage, and short permissioned quotes for feature-level wins. Do not use future-product ambition as present-day proof.
Needs a callImportant before first customers
Confirm Empathy Research as an early customer, not just an internal user
Do we treat Empathy Research as one of our first paying customers who uses the platform for real studies, rather than as an internal team waiting for full Focus Vision parity?
Suggested answer: Treat Empathy Research as an early customer that uses the product seriously now. Keep a short list of genuine Focus Vision blockers rather than treating every incumbent feature as a launch prerequisite.
Decide next
Choices to come back to later
Come back later
Decide how to explain Research Architect in normal buyer language
When a customer asks what Research Architect is, do we describe it as a planning helper before a study starts, a bigger research planning system, or the front door to every project?
Suggested answer: Explain Research Architect as the place where teams gather the right context and shape the brief before designing research. Keep the bigger 'front door to every project' story as the future direction until the product is ready to support it.
Come back later
Decide how we will judge whether the first trials worked
What simple signs will tell us a customer trial has worked well enough to continue, renew, or turn into a proof story?
Suggested answer: Use a short success checklist: did the product work in the customer's real workflow, did their team actually use it, did it save time or improve confidence, and is there a clear signal they would continue or pay?