Choose what you need to learn
Write the uncertainty as a question: will a defined customer complete a booking, submit a request or pay for a service? Choose a small group of users and identify the evidence that would change your next decision. A long feature list without a learning goal makes it difficult to decide what belongs in the first release.
A booking pilot that answers one question
Example hypothesis: will invited customers submit a booking request for a weekend workshop? Invite 40 people, record the complete funnel and interview people who stop. The following invented numbers illustrate why a signup count alone is insufficient.
| Stage | Illustrative result and next question |
|---|---|
| 40 invitations → 24 visits | Did the other 16 see the invitation, or was the offer irrelevant? |
| 24 visits → 12 requests | Check slot availability and the point where the form is abandoned |
| 12 requests → 8 attended bookings | Investigate response delay, payment and reminders for the four drop-offs |
Keep the essential journey complete
Reduce the number of use cases rather than leaving the core task unfinished. A booking pilot still needs an available slot, a submitted request, an understandable status and a staff response. Some back-office tasks can remain manual if responsibility is clear and users are not misled about what the service does.
Plan the decision after launch
Agree the review period, measures and support owner before release. Collect both completed actions and the reasons users stop. Use that evidence to choose between improving the flow, changing the proposition or stopping the experiment. A fixed delivery promise is less useful than a scope with understood dependencies and acceptance criteria.
Before you proceed
- Name the first users and the question the release will answer.
- Test the full customer and staff journey.
- Agree launch dependencies and the next decision point.
