Product planning
Planning a first version that earns a second
An MVP is the smallest version of a product that can tell you whether the idea is worth continuing. The work here is planning, not engineering: choosing what to leave out, then holding that line when someone asks for one more feature.
What an MVP is and is not
Two failure modes show up again and again, and both come from the same confusion about what the first release is for.
Not a demo
A demo is built to convince. It runs on curated data, skips the awkward states, and answers no question about how people behave once the room empties. Teams that ship a demo learn what stakeholders think, not what users do.
Not half a product
The other extreme is building the whole thing before anyone touches it. By the time the roadmap is delivered, the assumption underneath it has gone untested for months, and the cost of changing direction has grown with every feature.
A working version with the least scope
An MVP is a working version that real users can use for its core purpose, built with the smallest scope that makes that possible. A booking MVP lets someone book. It may not carry loyalty points, referrals, or an admin analytics suite — those can arrive later, once you know the core task is worth completing. The difference is not ambition. It is what the first release is allowed to teach you.
Write the problem in one paragraph before you write a single feature. If a request does not answer that paragraph, it belongs in a later version by default.
Writing the problem statement
Before features, write down the problem in one paragraph: who has it, what they do today instead, and why that is unsatisfactory. This sounds trivial and is frequently skipped. It is also the single most useful document in the project.
A clear problem statement is what lets you reject feature requests later without arguing about taste. The conversation stops being about who has the louder voice and becomes a simple test: does this address the problem we agreed on?
What the paragraph needs to contain
- The person or role who runs into the problem, described plainly.
- The workaround they use today — a spreadsheet, a phone call, a paper form.
- Why that workaround is unsatisfactory, in terms of time, errors, or missed information.
- What would have to be true for you to call the first release a success.
Deciding what goes in the first release
A practical method is to list every feature you can imagine, then mark each one as required for the core task, useful but not required, or unrelated. Only the first group ships. For the second group, note the order you would add them. This list becomes both your roadmap and your defence against scope creep.
Required
Everything the user must be able to do for the product to serve its core purpose. If you remove one of these, the release stops being usable at all.
Ships in version one.
Useful, not required
Features that improve the experience for people already using the product, or that reduce manual work behind the scenes. Valuable, but not what you are trying to learn first.
Write them down in the order you would add them. This is the roadmap.
Unrelated
Ideas that do not address the problem statement you wrote. They may be good ideas for a different product. They do not belong in this one, and keeping them on the list only muddies the decision.
Set them aside without deleting them.
In Singapore's business context, integrations are often the surprise here. A CRM, an accounting tool, or a payment provider can add weeks to a build if it was not scoped from the start, and the delay usually appears late, when the feature is already promised.
API integration and third-party dependencies
Many first versions depend on outside systems. API integration can be the difference between a four-week build and a four-month one, depending on how well documented the other side is and whether you control access to it.
Test access early. If a provider needs approval, sandbox credentials, or a signed contract, start that process before development begins, not during. A dependency you cannot reach in a test environment is not a dependency yet — it is a hope.
What to confirm before the build starts
-
Access
Sandbox credentials, an account you own, and a named person on the other side who answers questions.
-
Documentation
Current reference material, sample responses, and a clear picture of what happens when a call fails.
-
Commercial terms
Whether usage is billed, whether there is a contract to sign, and what the review or approval process looks like.
-
A fallback
What the product does if the outside service is unavailable, and who the user contacts when it is.
Choosing a stack you can maintain
For a first version, the stack should be boring and well supported. Boring means other people have already hit the problems you are about to hit, and the answers are findable. Ask what happens at version three, not version one — that is when the constraint you accepted at the start shows up as cost.
| Pattern | Suits | Where it strains |
|---|---|---|
| Managed backend with a cross-platform mobile front end | One team shipping the same product to iOS and Android without maintaining two codebases. | Features that need deep access to device hardware or unusual background behaviour. |
| Web application with a content management system | Products where non-technical staff edit copy, listings, or pages regularly. | Highly custom interfaces where the editor fights the layout on every change. |
| Low-code build | Standard workflows, modest volume, and a short path to a usable first release. | Once requirements get unusual, the platform becomes the limit rather than the shortcut. |
| Custom web build from scratch | Products whose core value is the interface itself and cannot be assembled from existing parts. | Teams without ongoing development capacity to maintain and extend it. |
None of these is wrong. The question is which one you can still change in a year, and whether anyone on your side can read the code when the original developer moves on.
Timeline expectations
An MVP timeline depends on scope, how many integrations are involved, and how quickly decisions get made. Decision latency is the most underrated factor. A project waiting on approvals is not progressing, no matter how fast the developers are.
Build in time for review cycles and content, and expect the first version to take longer than the optimistic estimate. That is normal, and planning for it is cheaper than explaining it later.
Where the time actually goes
- Scope
- How many of the required features survive contact with the problem statement. A tight list shortens everything downstream.
- Integrations
- Each outside system brings its own approval process, test environment, and quirks. Three integrations is not three times one integration.
- Decisions
- Who signs off on design, copy, and pricing, and how long that takes. Slow sign-off delays a build that is otherwise ready to ship.
- Content
- Real copy, images, and product data arriving on time. Empty screens hold up testing more often than unfinished code does.
Measuring whether it worked
Define what you are trying to learn before launch. It might be whether users complete the core task, whether they come back, or whether a specific workflow saves time. Pick a small number of measures and look at them consistently for a set period.
Worth watching
Completion of the core task, return visits from the same people, and whether a step that used to need a phone call now happens on its own.
Weak signals
Total downloads, page views, and time on site. They move for reasons that have nothing to do with whether the product is doing its job.
How long to look
A fixed window agreed before launch. Deciding the review date afterwards turns the numbers into a negotiation instead of a finding.
Planning the next iteration
An MVP is the start of a sequence. After the first release, use what you learned to plan the next version, adding the features you deferred and fixing what real usage exposed. Keep the same discipline: a short list, a clear problem, and a decision about what not to build.
Products that iterate this way tend to stay maintainable. Products that grow by accumulation tend to become expensive to change, because nobody can say which parts are still carrying their weight.
A short list to carry into version two
- Fix the first thing that stopped people completing the core task.
- Add the highest-value deferred feature — the top of the useful list, not the loudest request.
- Decide what you are deliberately not building this round, and write the reason down.
- Set the review date before the work starts, so the next decision has a deadline.
Questions we get about scoping
Short answers to the things teams ask most often before a first release is agreed. If your situation is not covered here, the contact page is the fastest route to a reply.
ViewCircuit Digital, 71 Robinson Road, #14-01, Singapore 068895. Monday to Friday, 9:00 AM – 6:00 PM.
How do we know the scope is small enough?
If you can describe the core task in one sentence and every required feature maps to it, the scope is probably right. If you need a paragraph to justify a feature, it belongs on the deferred list.
What if a stakeholder insists on a deferred feature?
Ask what it replaces. Adding work without removing work moves the launch date rather than the value. If nothing can be removed, the honest answer is that the timeline changes, and that should be a decision made openly.
Should the first release be mobile, web, or both?
Start where the core task happens. If people will use it while standing in a queue, mobile comes first. If they will use it at a desk with a spreadsheet open, a web application is the shorter path. The comparison of app approaches covers this in more detail.
How much should we plan before writing code?
Enough to agree on the problem, the required list, and the integration access. Beyond that, more planning documents rarely change the outcome. Real usage is a better teacher than another workshop.
What happens after the review window closes?
You decide whether to continue, adjust the scope, or stop. All three are legitimate outcomes, and the point of running a first version this way is to reach that decision with evidence rather than opinion.
Ready to scope your first version?
If you have a problem statement and a rough idea of what the core task is, the next step is a conversation about what belongs in version one. Bring the feature list you already have — even a long one — and we can work through which items are required, which are useful, and which belong somewhere else entirely.
Where to go next
- See how websites are built
- Native, cross-platform and hybrid apps
- Working with a development partner
- Accessibility and performance
Prefer to write first? Email [email protected] or call +65 6211 3173 during working hours.