A startup planning an approval tool hears three requests: make the form easier, stop invoices sitting in an inbox, and keep an audit trail. They sound like one project. They may be three different problems.
Product development starts by finding out which problem matters, who has it, and what a first release needs to do. The rest of the work follows from those answers. Skip them and a team can ship a polished product that leaves the delay, confusion, or manual work exactly where it was.
The seven stages of startup product development
The product development process takes an idea through decisions about the problem, the first release, and what happens after launch. A small startup may move between stages in a few days. Treat them as questions to answer, not gates that must be passed once.
- Frame the problem: name the user, the task, and what goes wrong today.
- Research and validate: check whether the problem happens often enough to solve.
- Define the concept: choose the user and the outcome the product should improve.
- Test the risky parts: use a prototype, manual trial, or technical experiment.
- Build the first useful version: make the core job work from start to finish.
- Launch and support it: release to users who can help you see what breaks.
- Improve from evidence: fix the biggest repeated problem, then measure the result.
The stages overlap. A prototype may expose a new constraint, sending the team back to research. That is progress if it changes a decision before the team has spent months building the wrong thing.
Find the problem before you choose the product
Talk to people who deal with the problem. Ask them to walk through the last time it happened: what started the task, where they got stuck, what they did next, and who else got involved. If you can, watch them do the work. A workaround tells you more than a general opinion about an app idea.
In the approval example, entering an invoice may be quick. The delay starts when a manager is away and nobody knows who can approve it. A cleaner form would not fix that. Routing the request to a backup approver might.
Write a short problem statement that names the user, the situation, and the consequence. For example: “Finance coordinators at small companies cannot tell who should approve an invoice when the usual approver is away, so payments stall while they chase people.” Keep it as a hypothesis. The next conversations should test it, not defend it.
Move on when you can describe the current process, the people affected, and why they might change their behavior. If those answers are vague, adding features will not make the product idea clearer.
Test the riskiest assumption
Asking people whether they like an idea is an easy test to run and a poor one to trust. People are generous about products they do not have to adopt. Ask about what they did the last time the problem came up, or put a small version of the proposed workflow in front of them.
Choose the assumption most likely to sink the project. Maybe a coordinator will not change how they submit invoices. Maybe managers will ignore delegated approvals. Maybe the accounting integration is harder than expected. Each needs a different test.
A clickable prototype can show whether someone understands the approval flow. A manual trial can show whether a backup approver responds. A short technical spike can check whether the accounting system exposes the data you need. None requires the full product.
Decide in advance what result would change your mind. If coordinators still chase approvals in chat, the new workflow has not solved the problem, even if they praise the design. The result may be to build, change the approach, or stop. Any of those answers can save time and money.
Scope an MVP around one complete job
A minimum viable product (MVP) is a first version that lets a defined group complete a useful job and gives the team evidence for the next decision. “Minimum” keeps the scope narrow. “Viable” means the important path works well enough for someone to rely on it.
Trace one user's job from beginning to end. For an approval tool, that could mean submitting an invoice, finding the right approver, recording a decision, and telling the coordinator what happened. If a missing step sends everyone back to email, the workflow is not complete.
Sort proposed features into three groups: needed to finish the job, uncertain enough to test, and safe to leave for later. Write down what the first version will not do. This gives founders, designers, and engineers a way to push back when the feature list starts growing.
Some requirements cannot be traded away for speed. An approval product may need clear permissions, dependable records, and a way to recover from mistakes. The right quality bar depends on the product and the data it handles. A narrow release can still be carefully built.
Sometimes an MVP is not the next step. A prototype, a manual service, or another round of research may answer the question with less effort.
Build in short cycles, but know what you are learning
Sprint-based product development can help a small team make progress without pretending every requirement is known upfront. Each cycle should have a small outcome, a working change or test, and a review where the team decides what to do next. A sprint is a decision point, not a promise to ship a fixed list of features.
Build one usable slice, put it in front of the right person, and adjust it before expanding the workflow. Test the awkward cases too: the approver is away, an invoice is missing a field, or someone submits the same item twice. Those moments often reveal more than the ideal path.
Keep a roadmap as a record of priorities and open questions, not a contract to deliver every feature on a date. Product, design, and engineering should make scope and quality calls together. A simple screen can hide difficult data rules; a tidy technical design can still confuse a new user. Catch those problems while the release is small.
Launch a version you can support
“It works on our machines” is not a launch plan. Before people depend on the product, walk through the main task and likely mistakes with the people who will support it.
Check permissions, data handling, empty states, error messages, integrations, and what users should do when something fails. Choose an owner for support requests. Track enough usage and errors to tell whether people finish the core job and where they get stuck.
A pilot or early-access release can help when the workflow is new or support capacity is limited. A wider launch makes sense when the core job has been tested and the team can respond if it fails. Tell early users what the first version is meant to do and how to report a problem.
Let feedback choose the next change
After launch, requests tend to arrive as solutions: “Add a dashboard” or “Send more notifications.” Ask what happened before the request. A dashboard may mean people cannot find the status of one invoice. More notifications may mean the current ones reach the wrong person.
Compare what users say with what they do. Read support messages, watch someone complete the task, and look at a few measures tied to the original problem. For the approval tool, that might be completed approvals, requests that get stuck, and manual follow-ups. Skip numbers that do not help make a decision.
Pick the repeated problem that matters most, then decide how you will know the change worked. The answer may be a new feature, clearer wording, a different workflow, or a repair to something already shipped. Product development continues while people rely on the product; launch gives you better evidence, not a reason to stop paying attention.
A practical way to start this week
Write down one user, one task they need to finish, and the workaround they use now. Talk to three people who have done that task recently. Ask about the last time, not an imagined future product. List the assumptions you are making and choose one to test.
Before building, make sure the team can name the user, the problem, the evidence behind it, the first outcome, what is out of scope, who makes the decision, and the next test. If you cannot, spend the week learning instead of adding to the backlog.
The Hey Labs helps teams make those decisions and carry them through design, engineering, launch, and ongoing care. If you are shaping a product and want to talk through the messy version, book a 20-minute call.
Frequently asked questions
How long does startup product development take?
There is no standard timeline. A prototype may answer one question quickly. A product with integrations, sensitive data, or complex operations needs more work before release. Estimate after you have defined the user, the core job, and the main risks.
What is the difference between a prototype and an MVP?
A prototype tests an idea or an interaction and may not be working software. An MVP is a usable first version that completes a valuable job for a defined group and can be supported while the team learns from it.
When should a startup change direction?
Change direction when repeated evidence shows the problem is less urgent than expected, the proposed workflow does not improve it, or adoption costs more than the benefit. Compare the results with the assumptions you wrote down before the test, not one enthusiastic comment or one disappointing demo.
What are the seven stages of product development?
Frame the problem, research and validate it, define the concept, test the risky parts, build the first useful version, launch and support it, then improve it using evidence from real use. A startup may revisit earlier stages as it learns.