Product development / 03
An MVP needs a first customer, not a smaller wish list.
The spreadsheet has forty features. Cutting it to twenty feels like progress, but it still does not explain why someone would use the product tomorrow. Start with the first customer’s job and follow it to a result they would return for.
Write the transaction in one sentence
For an illustrative booking product: a customer finds an available session, reserves it, pays and receives confirmation; the provider sees a reliable booking. That sentence is more useful than a list saying dashboard, AI, payments and notifications.
Decide what would challenge the idea. A completed first booking? A second paid visit? A provider choosing to keep using the system? Pick a signal close to the problem you intend to solve. A registration count alone may tell you very little.
Hypothesis
Who will pay, and what job do they need done?
Journey
One path from the request to a completed outcome.
Pilot
Real users, with errors and manual help made visible.
Decision
Use the evidence to continue, change direction or stop.
This is a scope example for a booking service. For another product, change the hypothesis before changing the feature list.
Separate a prototype, a pilot and a first product
A prototype helps test whether people understand an idea or an interface. It may contain simulated data and need no working payment or account system. A pilot tests a bounded service with real participants and an explicit support arrangement. An MVP needs to complete the core customer task under the conditions you have promised. These are useful but different deliverables. Calling all three an MVP makes proposals hard to compare and acceptance difficult to define.
Write down the decision the first release must support. Perhaps a provider will pay to reduce scheduling work, or a customer will return for another session. Define who participates, how they arrive and what would count against the hypothesis. Do not choose a number only because it looks impressive in a pitch deck. A small group completing a meaningful task can reveal more than many registrations from people who never needed the service. Keep the uncertainty visible when interpreting the result.
Draw the whole customer journey before the screen list
Follow one person from discovering the offer to receiving the promised result. Include the moments between screens: an email that arrives late, a provider confirming availability, a payment whose result is still pending. Mark what the customer knows at each point and what the business must know to continue. This exercise often reveals missing states that a list of “login, dashboard, checkout” conceals. Those states affect trust even when they do not require another elaborate page.
For a booking product, the provider’s side matters as much as the customer’s confirmation screen. The provider must see the right session, contact route and payment state. If the first release serves only one provider and one service, say so explicitly. That is a legitimate scope choice. Omitting a recovery path for an interrupted booking is a different choice: it changes whether the promised task can be completed. Review the journey with both sides before deciding which features to postpone.
Use manual work deliberately during the pilot
A person can handle unusual scheduling requests, review uncertain documents or prepare an initial report while demand is being tested. Make that work visible in the scope and in the operating model. Identify who performs it, how the request reaches them and how the user sees progress. Hidden manual work creates misleading cost and capacity assumptions; explicit manual work can be a sensible way to learn before building a complex administrative system.
Record how often those interventions occur and how long they take. If every supposedly simple booking requires a founder to repair the data, the pilot has exposed a core reliability issue. If a rare special request takes a few minutes, automating it may remain a low priority. Preserve enough structure to replace a manual step later: a clear status, an owner and an event history are more useful than scattered private messages. Treat operations as part of the product experiment.
Scroll sideways to see all columns.
| Feature | Pilot decision | Acceptance check |
|---|---|---|
| Time selection and booking | Build the complete journey | Two users cannot claim the same slot |
| Unusual rescheduling | Let an administrator handle it manually | The request has an owner and a visible status |
| Payment, if needed to test demand | Confirm payment on the server | A repeated notification cannot create a second purchase |
| Rewards and referrals | Wait until the core demand is tested | Evidence links the feature to repeat purchases |
Choose web or mobile from the task
A responsive web application is often a practical starting point when a user follows a link to complete an occasional task. A dedicated mobile application has a stronger case when repeated use, device capabilities or offline operation materially change the experience. List those requirements before discussing frameworks. “We want an app” may mean that the customer wants convenient access on a phone, which is not automatically the same as maintaining separate store releases.
Compare the whole operating burden: account setup, release review, supported devices, updates and support. If an agency proposes a shared codebase, ask what remains platform-specific and how those parts are tested. Conversely, do not force a browser-only implementation onto a task that genuinely depends on device behaviour it cannot provide reliably. Use an early technical experiment for the uncertain capability. A small verified experiment can settle the architecture question more effectively than a long comparison of fashionable technologies.
Inspect integrations and data before agreeing the date
An apparently simple product may depend on a calendar, payment provider, CRM or an existing database. Verify access and the exact operations required before treating those integrations as solved. Check sample data, identifiers, usage limits and test environments. A connector listed in a marketplace may not support the operation your journey needs. A supplier’s estimate should state assumptions about these dependencies, especially when access or documentation is controlled by another organisation.
Agree which system is authoritative for each state and how conflicting updates are handled. If a booking is cancelled in the provider’s calendar, what should the customer portal display? What happens when a payment notification arrives before the booking update? You do not need to build every conceivable integration failure into the first sprint, but you do need a safe state and a visible recovery route. These decisions protect the core journey and make the delivery estimate more honest.
Test access with two ordinary accounts
Create two normal users in the test environment and try to reach one user’s records through the other account. Check both the interface and the server response. Hiding a button does not establish permission to read the underlying data. Define roles around actual responsibilities: customer, provider and administrator, for example. Keep the first model simple, but ensure that consequential actions are checked where the data is accessed or changed.
Include account recovery, invitations and the removal of access in acceptance. A user may leave a company or an invitation may be sent to the wrong address. Decide how the product handles those events without exposing another person’s records. Ask who can view support data and how that access is controlled. These are ordinary product requirements, not extras reserved for a later enterprise edition. A narrow first release can still maintain clear boundaries between its users and their information.
Confirm payment independently of the browser
A customer may close the checkout tab, lose a connection or refresh while the provider is processing a payment. The product needs a payment state that can be reconciled with the payment service rather than relying only on a browser success screen. Distinguish pending, successful and unsuccessful outcomes in a way that lets the user understand what to do next. Avoid offering another payment blindly when the previous result is still being checked.
Use the provider’s documented server notifications and verify their authenticity. Make processing safe when a notification arrives more than once or in an unexpected order. Test the resulting order and booking records, not just the callback response. Include the operational path for a refund or a payment that needs investigation, even if a person performs that work during the pilot. A clear manual recovery procedure is better than an impressive checkout animation that leaves support unable to explain the customer’s charge.
Evaluate AI only where it is part of the promise
If the product’s main job is to interpret documents or answer questions from a knowledge base, AI quality belongs in first-release acceptance. Assemble representative inputs, define acceptable outcomes and include cases the system should decline or send for review. Separate errors caused by missing source information from errors in interpretation or in the action taken afterwards. A single attractive example is not enough to show that the feature supports the promised customer task.
Also consider the operational cost of uncertainty. Who reviews a questionable result, what can the customer correct, and what happens if the model service is unavailable? A fallback may be a queued request, a limited response or human assistance. Choose it deliberately. If AI is merely an optional shortcut around an otherwise complete booking journey, it can be postponed. The decision follows the product hypothesis, not a requirement to put an assistant into every new interface.
Compare proposals using the same acceptance story
Give each potential development partner the same short customer journey, sample data and list of observable outcomes. Ask them to separate discovery, design, implementation, integrations, testing and handover. Make dependencies and exclusions visible. Two totals are difficult to compare if one includes operating instructions and failure recovery while the other covers only a demonstration. Clarifying that difference early is more useful than negotiating a percentage discount on an ambiguous scope.
Include the review process: who answers product questions, who accepts completed work and how a change is recorded. Ask for intermediate deliverables that prove progress along the journey rather than only a collection of finished screens. A technical uncertainty may justify a bounded investigation before a fixed implementation estimate. Keep a reserve for identified uncertainties and state what triggers its use. This makes budget discussions concrete without pretending that a new product has no unknowns.
Instrument the decision you need after launch
Track the steps that reveal whether the core task is being completed: a valid request, a confirmed booking, a successful payment or a repeated use, depending on the hypothesis. Distinguish attempts from successful outcomes and avoid counting the same server event twice. Review where people stop, then inspect the surrounding experience before deciding that another feature will solve the problem. A pricing question, unclear offer or failed confirmation may explain the behaviour more directly.
Keep the first review tied to the original hypothesis and the actual participants. Small samples can expose usability defects without proving broad market demand. Record what remains uncertain and what evidence would change the next decision. Build another major feature when there is a reason connected to customer behaviour or operating cost. If the basic task is not valued, adding a referral programme or more dashboard charts is unlikely to clarify why. The first product should help you decide what deserves further investment.
Cut breadth before cutting reliability
Start with one customer type, one service and one booking flow. An administrator can handle unusual requests manually if the process is explicit. You may not need a referral programme, five pricing plans or automated reports yet.
Keep the unglamorous parts of the core journey: validation, permissions, payment state and recovery. Test a second account trying to view someone else’s booking. Refresh during payment. Submit twice. A demo that works only when everyone clicks once is not ready to learn from real customers.
A mobile app is a decision, not a milestone
A responsive web application may be enough when the core task happens through a link. A mobile application deserves its place when device capabilities or repeated use change the experience. List those needs before choosing an iOS and Android build.
The same applies to AI. If the first customer only needs to book a service, an assistant may be a later improvement. If interpreting a document is the product’s central job, evaluation belongs in the first release. Architecture follows the task.
Make the handover part of the scope
Agree who owns the domain, repository, hosting and payment account. Include a simple export, a backup procedure and a named route for reporting failures. Someone must be able to operate the product on Monday after the launch.
Write the first release as a short acceptance story with observable outcomes. Then keep a separate list of ideas for later. You can build more once customers show which part is worth extending.
Before you start
- Name the first customer and the complete task they must finish.
- Test permissions, interrupted payment and duplicate submission.
- Agree access to the code, accounts and operational documentation.
Editorial note. Examples illustrate a decision or a test; they are not client results.