Approve draftReady for beta
Create simple pricing material for conversations
Put together a short commercial explainer that helps the founder talk through pricing without improvising.
Pricing and commercial model
Open workstream contextBack to Overview
Decisions to be made
The approvals and decisions to work through with the founder.
Use this page to run the founder conversation in sequence: review drafts, approve what is ready, make the immediate calls, and then work through the follow-on decisions once the beta shape is set.
Approve now
Drafts that need founder review
Approve draftIn progress
Build the one-pager
Create a short follow-up document that can be sent after meetings or shared internally by prospects.
Sales motion and demo readiness
Open workstream contextApprove draftIn progress
Turn the positioning into sales-ready proof claims
Turn the positioning into a few simple claims the founder can use in demos and sales conversations.
Category and positioning
Open workstream contextApprove draftReady for beta
Prepare answers to common questions
A combined objection-handling FAQ now exists and provides the baseline internal answer set for common sales questions.
Sales motion and demo readiness
Open workstream contextDecide now
Open founder calls that still shape the launch
Make decisionLaunch critical
Choose the endorsed-brand line and contracting identity
How visible should <un>known and Empathy Research be in the buyer-facing beta story, and what identity should buyers believe they are contracting with?
Current recommendation: Use an endorsed-brand posture in beta: let the product stand on its own name, while clearly borrowing parent trust in the footer, company wording, and early procurement conversations.
Open options and background for Choose the endorsed-brand line and contracting identity
Options on the table
Recommended
Endorsed brand posture
Balances trust and separation. <un>peel leads, with <un>known or Empathy Research visible as the parent or operating context.
Quiet parent visibility
Lead buyer-facing conversations with <un>peel as the primary identity. Advantage: feels more commercially independent. Risk: gives up group credibility in early procurement and legal-confidence conversations.
Parent-led posture
Maximises inherited trust, but makes the BU feel less like a distinct product business with its own commercial future.
What this changes
- This affects contract language, website company wording, trust-centre framing, and procurement confidence.
- It also shapes how much the founder can lean on existing reputation versus selling a net-new business unit.
- The endorsed-brand line only becomes real once the legal scaffold for pilot selling is explicit.
Make decisionLaunch critical
Choose the first delivery model for pilots
Which pilot delivery mode best fits current maturity: pure enterprise SaaS, assisted do-it-together delivery, or a more explicit software-under-service offer?
Current recommendation: Treat high-touch assisted delivery as the best current fit for pilot maturity unless the founder wants to push harder toward pure SaaS. It preserves the software direction while matching the current state of onboarding, proof, and live customer support.
Open options and background for Choose the first delivery model for pilots
Options on the table
Recommended
Assisted do-it-together delivery
Most honest near-term posture. Keeps the long-term SaaS direction while leaving room for founder-led support and product shaping in early accounts.
Pure enterprise SaaS from day one
Cleanest commercial story, but risks overstating repeatability in onboarding, trust, and support.
Productized software-under-service
Can accelerate adoption if tightly scoped, but only works if it stays repeatable rather than turning into bespoke services work.
What this changes
- Assisted delivery commits the founder to more hands-on customer work in early pilots and affects staffing expectations.
- It also changes what can be promised in contracts, proposals, and sales conversations without founder involvement.
- The definition of 'assisted' is still not explicit enough operationally and is tracked as a separate gap.
Make decisionLaunch critical
Confirm the minimum legal scaffold for founder-led pilot selling
Can founder-led pilots be signed under the current interim structure, or must the separate-BU legal and company identity pack be completed before the first pilot agreement is sent?
Current recommendation: Make an explicit call on the interim contracting route now. If founder-led pilots can be signed safely under the current structure, constrain that route tightly to founder-led pilot use. If not, treat BU legal setup as a hard blocker before the first signature.
Open options and background for Confirm the minimum legal scaffold for founder-led pilot selling
Options on the table
Recommended
Use an interim founder-led pilot route
Fastest route if leadership is comfortable with the interim contracting identity. Should stay tightly constrained to founder-led pilots rather than broader selling.
Finish the BU legal pack before signing
Cleaner and lower-risk in procurement terms, but slows the first pilot agreements if legal setup is not already near-complete.
What this changes
- This gates the first pilot agreement more directly than most other founder decisions on the page.
- It also shapes the endorsed-brand line, privacy/terms wording, and how much wider sales activity is safe.
- If the interim route is approved, it still needs a narrow scope: founder-led pilots, not open-ended general enterprise selling.
Make decisionLaunch critical
Confirm whether <un>peel has enough confidence to carry beta
Does <un>peel have enough founder confidence to remain the market-facing identity through early-selling beta, or should a formal naming review happen before broader market activation?
Current recommendation: Keep <un>peel as the beta identity unless confidence in the name has materially changed. If confidence is low, trigger a deliberate naming review now rather than quietly carrying doubt into wider launch materials.
Open options and background for Confirm whether <un>peel has enough confidence to carry beta
Options on the table
Recommended
Confirm <un>peel for beta
Fastest path. Preserves the current naming system, website language, and platform story without forcing immediate rework.
Trigger a formal naming review now
Slower path, but cleaner if confidence is genuinely low. Better to reopen deliberately than to keep building on a name the founder does not trust.
What this changes
- If this changes later, the site, company wording, deck language, and trust materials all become rework.
- The founder should not enter broader beta activation with a name that still feels provisional internally.
- This is a confidence confirmation, not a blank-sheet naming exercise.
Appendix briefs
Brand architecture and spinout postureMake decisionLaunch critical
Decide which price anchors become public in beta
Should the beta site publish the current price anchors publicly, and when should those anchors enter live pilot conversations?
Current recommendation: Publish the current beta price anchors and keep everything beyond those anchors conversation-led: Starter at GBP 220 per seat per month, Foundation from GBP 1,500 per month, Growth from GBP 5,000 per month, and Enterprise as custom. Only do this if plan definition, entitlements, and usage tracking are tightened enough that the page stays honest.
Open options and background for Decide which price anchors become public in beta
Options on the table
Recommended
Public anchors, conversation-led detail
Most balanced option. Signals that pricing is real, while keeping usage rules, pilot-to-paid terms, and exceptions inside live conversations.
Keep pricing private for now
Reduces the risk of overexposing immature packaging, but makes the business feel less concrete in early founder and buyer review.
Publish full public packaging
Most transparent option, but also the least honest if plan definitions, entitlements, and procurement support remain underbuilt.
What this changes
- This directly affects the website build, deck language, and buyer expectation-setting.
- It only works if entitlements, usage tracking, and plan definitions are locked tightly enough to support a public page.
- The founder still needs a separate rule for when pricing enters live conversations and demos; that sequencing is currently an explicit gap.
Make decisionLaunch critical
Lock the positioning translation matrix
How should confidence, reduced uncertainty, defensibility, and audit trail map across buyer, founder, and procurement contexts?
Current recommendation: Keep confidence as the workflow-facing and customer-facing lead term, and formally translate it into reduced uncertainty, defensibility, and audit trail language where procurement and governance stakeholders need more precision.
Open options and background for Lock the positioning translation matrix
Options on the table
Recommended
Use a translation matrix by audience
Confidence remains the external research story, while defensibility, reduced uncertainty, and audit trail become the procurement and proof-language translations.
Force one term everywhere
Simpler to manage, but it flattens the layered positioning model already present in the strategy work.
Lead with procurement-first language
Could help in risk-sensitive conversations, but makes the broader GTM story drier and less distinctive.
What this changes
- Website headlines, founder intros, sales collateral, and procurement answers all need the same language map.
- Without a translation rule, the narrative drifts between documents and starts sounding less intentional than it is.
- This is a language-governance decision, not a beauty contest between isolated terms.
Related drafts
Sales-ready proof claimsAppendix briefs
Confidence narrative and category framingMake decisionLaunch critical
Set the gating strategy for broader beta selling
Do we start with founder-led pilots only, and what milestones unlock founder-approved referrals or wider sales-led outreach?
Current recommendation: Start with founder-led pilots only. Define the unlock milestones now: minimum DPA and procurement pack, at least one usable proof or permissioned case-study path, and explicit founder sign-off on what broader selling is allowed to promise.
Open options and background for Set the gating strategy for broader beta selling
Options on the table
Recommended
Founder-led only until milestones are met
Safest near-term posture. Matches the current legal, procurement, and trust-readiness reality while keeping a deliberate expansion path.
Founder-approved referrals as an intermediate step
More permissive than founder-led only, but still keeps a gate between bespoke founder selling and a broader sales motion.
Enable broader enterprise outreach now
Potentially faster top-of-funnel motion, but it raises the burden for DPA, proof, and procurement completeness immediately.
What this changes
- This determines what the sales team is empowered to do, not just what the founder can explain live.
- It also defines whether the website is a founder-review asset, a private-preview credibility layer, or a broader enterprise selling surface.
- The founder needs a clear answer on who decides when each trust milestone has been met and the next gate can open.
Decide next
Follow-on founder calls once the immediate beta shape is set
Review next
Clarify how Research Architect is included in beta access
Beyond the current named-brand beta rule, should Research Architect stay a curated part of full-platform beta access, become standard packaged scope, or stay selective until the architecture is firmer?
Current recommendation: For private beta, keep Research Architect available inside curated full-platform beta access for named-brand customers. Do not yet turn that into a blanket standard promise for every customer until the architecture and buyer-definition questions are firmer.
Open options and background for Clarify how Research Architect is included in beta access
Options on the table
Recommended
Curated beta access for named-brand customers
Most practical near-term rule. Lets the product appear in real beta work without pretending every buyer should receive the same promise by default.
Make it standard beta packaging now
Cleaner commercial story, but riskier if the architecture and buyer-language questions are still moving.
Pull it back out of beta scope again
Safer if confidence drops, but would now create avoidable inconsistency with the agreed beta product-map rule.
What this changes
- This changes proposal language, demo flow, and what buyers think they are getting in beta.
- It keeps Research Architect visible in live beta work without pretending the architecture question is finished.
- The remaining next-step decision is not whether it can appear in beta at all, but how broadly that promise should be made beyond curated founder-led access.
Appendix briefs
Platform brand, SKU logic, and shared servicesReview next
Define Research Architect in buyer language
What is Research Architect in buyer language: a pre-design context tool, a brief-to-method planning layer, or the gateway to all projects?
Current recommendation: Define Research Architect narrowly for now as the pre-design context and brief-planning layer that helps teams gather the right context before they design research. Keep the broader gateway-to-all-projects ambition as direction until product architecture catches up.
Open options and background for Define Research Architect in buyer language
Options on the table
Recommended
Pre-design context and brief-planning tool
Most honest near-term definition. It matches the current concept and avoids overclaiming co-design or universal workflow ownership.
Buyer-facing research planning system
More expansive and potentially more commercial, but risks getting ahead of current product truth.
Universal gateway to every project
Strongest strategic story, but should wait until the architecture decision is resolved and proven in-product.
What this changes
- This shapes how the founder explains the platform lifecycle before the sellability question is even answerable.
- A tighter buyer definition makes the later sellability decision more concrete and less speculative.
- This is important next, but it does not block the first beta motion as long as curated beta access is handled honestly rather than sold as a blanket mature promise.
Related drafts
Sales-ready proof claimsAppendix briefs
Platform brand, SKU logic, and shared servicesReview next
Formalize the pilot success scorecard
How do we formalize the pilot success signals already emerging in customer conversations into a repeatable scorecard for conversion and proof?
Current recommendation: Formalize the success signals already visible in pilot work: product readiness and workflow improvement, team capability and adoption, and a commercial signal such as willingness to continue or convert. Lock this before the second pilot-to-paid conversation, not after.
Open options and background for Formalize the pilot success scorecard
Options on the table
Recommended
Formalize the current ad-hoc signals
Most practical next step. Turns what is already visible in pilot interactions into a reusable founder and GTM tool.
Keep using qualitative founder judgment
Flexible in the short term, but harder to defend in proof, prioritization, and conversion conversations.
Wait for a full metrics system
More rigorous on paper, but too slow if it prevents fast learning from early pilots.
What this changes
- Without this, pilot-to-annual conversion stays subjective and harder to defend.
- It also weakens future proof packaging because success was never formalized up front.
- This matters next, but it does not block initial beta launch if the founder treats it as a short follow-on formalization task.