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
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.
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
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 detailIn 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 detailFounder decisions
Calls affecting this area
Needs a call
Decide how hands-on we are with the first customers
Start with a hands-on, 'we will help you through it' approach for the first trials. Keep the long-term goal as software that customers can use more independently, but do not pretend the first customers need no support.
Review in readiness checklistNeeds a call
Decide how involved Empathy Researchers are in the product launch
Make Empathy Researchers active launch partners. Use the platform for studies it can support now, ask researchers to design within current limits where reasonable, and maintain a short list of true Focus Vision blockers rather than treating every incumbent feature as a launch prerequisite.
Review in readiness checklistNeeds a call
Decide which products need case studies versus customer reviews
Use full case studies for system-level workflow proof, especially Research Guard, Trust Centre, Quant Surveys, Insight Navigator / Segment Lens, and panel operating-model work. Use customer reviews or short quotes for specific usability wins such as survey testing, translation review, crosstab rollups, data management improvements, and email editing.
Review in readiness checklistNeeds a call
Decide how we get approval for Musgrave brand references
Treat named Musgrave brand references as blocked until approval is confirmed. Ask Declan to help secure permission or decide which references must be anonymised or removed before broader website sharing.
Review in readiness checklistCome 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 checklistAppendix briefs
Evidence links