Go-to-market hypotheses
User, sponsor, and problem
The proposed primary user is a B2B SaaS launch lead assembling readiness from several functions. Evidence contributors need to understand which prerequisite they own; a potential budget sponsor would be the product operations or release-function leader accountable for a repeatable review process. These roles and buying assumptions require discovery and are not validated segments.
Positioning and alternatives
The positioning hypothesis is an inspectable readiness conversation: who owns the prerequisite, what evidence is supplied, and why a decision changed. Alternatives include an existing project tracker, a checklist in a shared document, or a facilitated readiness meeting. The product must demonstrate a reason to switch; displaying a new dashboard alone is insufficient.
Proposed sequence
- Conduct five formative fictional-data sessions and resolve recurring misunderstanding of gates, evidence, or simulation.
- Run the proposed 20-participant study only after the task protocol is stable. Use the PRD's 18/20 explanation and 17/20 unassisted-completion targets as decision inputs.
- If comprehension and repeated problem evidence support further work, design a consented, bounded pilot with a sponsor and an agreed data policy. The current prototype does not accept real launch information for such a pilot.
A later pilot could compare time and errors in reconstructing a decision with the team's existing method. Collect a baseline first; no time-saving percentage, demand, revenue, pricing, or adoption result is claimed.
Pilot operating decision
Before a bounded pilot, the sponsor must name the recurring review, participants and review time it will consume, the current-method comparison, and a data owner. The cost under consideration is the effort to run that comparison, not a price or ROI claim. Exit if the sponsor cannot name a recurring decision, the existing method gives participants the same or better context, or a minimal data boundary and retention path cannot be agreed.
Decision tests before a pilot
| Decision maker | Decision to test | Evidence that permits the next step | Stop condition |
|---|---|---|---|
| Launch participant | Does the readiness rule improve the current review conversation? | The participant explains the seeded blocker, the evidence boundary, and the consequence of a regression without assistance. | The participant prefers the existing method because it gives the same decision context with less effort. |
| Product operations or release sponsor | Is a bounded pilot worth funding? | A recurring review problem is documented, a current-method comparison baseline is defined, and a sponsor accepts an explicit data boundary. | There is no recurring problem, no accountable sponsor, or no acceptable data boundary. |
| Product team | Should the sample accept real inputs or integrations? | Formative work establishes workflow comprehension and a specific provenance, permissions, retention, and recovery proposal exists. | The next request is only for dashboard breadth or an unscoped connection to operational systems. |
Investment gates
A real product would need evidence provenance, identity, permissions, retention, support ownership, and privacy/security review. Keep deployment, paging, and traffic control outside the scope until separately authorized. Stop the commercial path if users understand the sample but prefer their existing process or cannot identify a recurring problem worth funding.