<un>peelFounder GTM
Back to GTM checklist
In progressFounder decisions linked

GTM pillar

Proof, Pilots, and Onboarding

Show why buyers should believe the product, how pilots are meant to work, and how a customer gets to value in an early beta motion.

What this covers

  • Mechanism proof, pilot signal, and proof packaging
  • Pilot structure, onboarding path, and first-value experience
  • What success should mean before a pilot converts

Why it matters in GTM

Early SaaS GTM is won by proof and first value, not by polish alone. This pillar makes clear whether we can support the claims we are making and how the first customer experience is supposed to run.

Where we are now

We have real product proof and real pilot activity, but not yet a simple repeatable way to show that proof and onboard customers.

Biggest gap

We still need reusable proof, a cleaner onboarding plan, and a simple scorecard for what a successful pilot looks like.

Underlying items

The strategic and tactical work inside this pillar

Open checklist slice
In progressFounder decision

Proof and credibility

Current proof splits into three layers: mechanism proof is strong, pilot signal is real but mostly unpermissioned, and named commercial proof is still absent. The missing piece is not whether evidence exists, but whether it can be packaged and claimed safely in market-facing materials.

Open tactical detail
In progressFounder decision

Onboarding and pilot operations

The operating model is already visible in the repo: high-touch pilot, bi-weekly feedback, direct support, and annual-conversion intent. What is missing is the reusable package that explains exactly what happens after a buyer says yes and how success is measured.

Open tactical detail

Founder decisions

Calls affecting this area

Open readiness checklist
Needs a call

Approve the assisted private-beta delivery model

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.

Review in readiness checklist
Needs a call

Confirm Empathy Research as an early customer, not just an internal user

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.

Review in readiness checklist
Needs a call

Approve the proof standard for each type of sales claim

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.

Review in readiness checklist
Needs a call

Decide which customer names, quotes, and proof can appear publicly

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.

Review in readiness checklist
Come back later

Decide how we will judge whether the first trials worked

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?

Review in readiness checklist