Skip to content

Published 3 min read

Launch smaller. Finish the customer journey.

A useful first release should let one kind of customer finish one important job. How I would choose the scope, handle manual work and decide what comes next.

NT Founder, Pitstop Technologies

Two people cross the finish line in a small blue cart while an enormous unfinished cart remains behind.

I like ambitious products. I also like getting something useful into people's hands before the enthusiasm disappears into a six-month feature list.

Those two things can work together. My starting point is to choose a smaller promise and deliver it properly. A first release should give someone a reason to use it, a way to finish what they came for and a clear understanding of what happens next.

That sounds obvious until the launch checklist contains a dashboard, a referral programme and three account types, while nobody has decided who answers the first enquiry.

Illustrative garage enquiry

One small promise. Every step delivered.

Customer

01Request a service

Vehicle + issue + preferred date

Submit the request
02Receive a receipt

“We have your request.”

Garage team

03Review the request

A named person checks capacity and replies.

Agree the appointment
04Confirm the arrangement

The customer now has an agreed date.

The handover between lanes is part of the product. Receipt ≠ confirmed appointment.

A preferred date is not a booked appointment. The human handover belongs in the first release.

Choose the job before choosing the features

Imagine a garage that wants customers to request a service online. This is a hypothetical example, but the decision is familiar: build a complete workshop platform now, or start with a useful booking enquiry?

For the first version, the customer might describe the vehicle and problem, choose preferred dates and receive confirmation that the garage has their request. The garage needs enough information to respond, somewhere reliable to find the request and a way to agree the appointment.

That is a coherent first release. The date is a preference until somebody confirms it; the wording must say so. Calling the same form “instant booking” would create a promise the operation cannot keep.

A points scheme, customer app and automatic parts ordering can wait. Protecting customer information, handling a failed submission and making the form usable on a phone cannot.

Manual work can be an intentional part of the product

There is nothing embarrassing about a person reviewing a request. For a new service, that conversation may be how you discover which details matter and which assumptions were wrong.

The important part is designing the handover. Who receives the request? What happens when they are away? Can they distinguish a new enquiry from one already answered? What does the customer see if no appointment is available?

If those answers live only in someone's memory, the first version is fragile. A small internal queue and a clear process may be more valuable than another impressive screen.

I would also agree when the manual step needs revisiting. Perhaps the owner starts spending too much time copying the same information between tools. That gives us a specific automation problem to solve, with a process we already understand.

Define “finished” in customer language

A developer can finish a form component while the business still cannot receive enquiries. That is why I want acceptance criteria to describe an outcome.

For our garage example: a customer can send a request from their phone, see an accurate confirmation, and have it appear once in the garage's queue. A failed submission keeps their answers. Staff can find the information they need to respond.

We should walk through that together before launch, including failure cases. We should also decide who checks the first real requests and how to disable a broken feature without losing the information already collected.

A small scope makes those details easier to finish. It does not make them optional.

Measure the uncertainty you actually have

The first question might be whether people understand the service. It might be whether they trust the price, can complete the form or accept the available appointment times. Each uncertainty suggests a different next step.

I would look at where people stop, read the enquiries and ask customers what was unclear. Where analytics are appropriate, collect only the information needed for that question and handle consent properly. A page-view total on its own cannot tell us why somebody left.

The next release should follow what we learn. Sometimes that means software. Sometimes it means a clearer explanation, a different offer or a faster reply from the business.

If you want to launch quickly, bring the big idea. Then let's identify the smallest version that delivers a useful result all the way through. Tell me what your first customer needs to achieve, and we can work out what belongs in that first release.

A useful next step, for your business.

Tell us what your website needs to do. We’ll help define the scope, responsibilities and next step.

Calls are in English, with Romanian support on request.