# How do you determine which features belong in a first version? [Home](https://3bird.nl/)/How do you determine which features belong in a first version? # How do you determine which features belong in a first version? The functionalities that belong in a first version are those features without which your product cannot deliver its core value to the end user. Everything that comes after is an addition. A good first version, also known as an MVP (Minimum Viable Product), solves one problem, for one target audience, as simply as possible. The questions below help you draw that line clearly. ## What criteria determine whether a feature belongs in an MVP? A feature belongs in an MVP if it directly contributes to solving the core problem of your target audience. The best way to test this is by asking yourself three questions: **Can the user achieve their goal without this feature? Does it solve a proven pain point? And is it necessary to collect feedback that helps your product move forward?** If the answer to all three is no, the feature does not belong in it. In practice, you can evaluate every potential feature against three criteria: - **Necessity:** Is the product usable without this feature? - **Validation value:** Does the feature provide information that helps you decide on the next step? - **Build cost:** Does the investment outweigh the direct value for the user? Features that score on all three belong in the first version. Features that only score on one criterion are planned for a later iteration. This framework prevents you from investing time in *software development* of features that nobody will miss at launch. ## How do you distinguish core functionality from extras? Core functionality is everything that gives the product its reason for existence. Extras are features that improve the experience but do not carry the product. You make the distinction by going back to the central user question: **what must someone be able to do to be satisfied after first use?** That is your core. Everything that would be nice after that is an extra. A useful method is dividing your feature list into three groups: - **Must-have:** Without this feature, the product does not work for the user. - **Should-have:** Useful and desired, but the product is usable without it. - **Nice-to-have:** Great if it’s there, but not a priority for version one. Only the must-haves belong in your first version. This sounds simple, but in practice should-haves are regularly labeled as must-haves, because teams are too close to the product. For each doubtful case, ask yourself: *what happens if we leave this out?* If the answer is “not much,” then leave it out. ## What are common mistakes when putting together a first version? The most common mistake is **scope creep**: the first version gradually grows into a full product, causing the launch to be delayed indefinitely. Other common mistakes include building features based on assumptions rather than user research, and prioritizing technically interesting solutions over what users actually need. Recognizable pitfalls at a glance: - Adding features “just in case,” without evidence that users need them - Investing too early in scalability while the core product has not yet been validated - No clear definition of what “done” means for version one - Making decisions based on internal opinions rather than user feedback - Pursuing perfection where a working version is sufficient The common thread in all these mistakes is that teams run too far ahead of what users want. A first version is a hypothesis, not a final product. Treat it as such. ## How do you involve stakeholders in prioritizing functionalities? You involve stakeholders in prioritization by organizing a structured session in which everyone makes their assumptions explicit and then tests them against user needs. Without structure, prioritization conversations quickly become a discussion of opinions. **With the right approach, you turn opinions into well-founded choices.** Effective ways to do this: - **MoSCoW session:** Have stakeholders individually categorize features as Must, Should, Could, or Won’t, and then discuss the differences. - **Impact vs. effort matrix:** Plot features against their expected value for the user and the required build time. - **Centering user stories:** Link each feature to a concrete user scenario, so that discussions focus on the user rather than internal interests. Also make sure that someone has final responsibility for the prioritization. A product owner or *software development partner* with experience in these kinds of projects can fulfill that role. Without a clear decision-maker, prioritization conversations keep going in circles. ## When is a first version good enough to launch? A first version is good enough to launch when it fully and reliably executes the core functionality, and when you can use it to collect actionable feedback from real users. **Good enough does not mean flawless or complete — it means the product delivers on its promise to the target audience.** Use this checklist to assess whether you are ready: - The user can achieve their main goal without assistance - There are no critical errors that block usage - You have a way to collect feedback after launch - The product is secure enough for the data it processes - Your team is ready to respond quickly to issues after launch What you do not need for a launch: a perfect user experience, all planned features, or a fully developed design. Those come in subsequent versions. Launching is itself also a way of learning. ## How 3Bird helps build a strong first version Determining the right scope for a first version is exactly where many teams get stuck. Building too much costs time and money. Building too little results in a product nobody uses. We help you find that balance, from the first prioritization session to launch. What we concretely do for you: - **Scope definition:** We help you draw up a clear must-have list based on your target audience and business goals - **Custom development:** Our team builds exactly what is needed, without unnecessary complexity - **Guidance from a fractional CTO:** A Dutch technical lead oversees the development process and keeps the focus on your core functionality - **Flexible scaling up and down:** After launch, we scale along with the pace of your growth Our team of experienced developers works from **€25 per hour** and supports a wide range of technologies, from React and Flutter to Java and .NET. Whether you need a web application, mobile app, or complex backend solution, we make sure your first version is rock solid. **Get in touch via [contact@3bird.nl](mailto:contact@3bird.nl) or call +(31)75-7993038 and tell us what you want to build.** ## Ready to Get Started? Talk to us about your project and find the right 3Bird solution. [Contact Us Today](https://3bird.nl/contact/) --- Book a free 30-minute consultation: https://calendly.com/3-bird/3bird-oscar-30-minuten-meet Email: contact@3bird.nl | Phone: +31757993038