Deciding which features to build and how to prioritise them is tough when resources are scarce. However, it is a key question every start-up needs to be able to solve when building a minimum viable product (MVP).
And as an early-stage start-up, one of the challenges you face is the lack of abundant data or customer feedback. You will typically have a gut feeling about what you need to build, but you don’t have user data to support your hunch.
So, how do you decide what your minimum viable product (MVP) should look like? What features it should have, and how you should prioritise them?
However, to make these critical product decisions, you must answer these fundamental questions:
Why are you building your product? How are you building your product?
Answering these questions will help you determine your MVP, the product features you need, and how to prioritise them.
This article will examine start-ups’ unique product management challenges when answering these questions.
Let’s dive in and see how to solve these challenges!
Defining Your Minimum Viable Product (MVP)
Why am I building my business? What problem do I want to solve?
According to CB Insights, one of the main reasons start-ups fail is because there is no market need for the product they built.
So, choosing what to build as an MVP is probably the most important decision a start-up must make.
In his book Start with Why, Simon Sinek presents the idea of his Golden Circle.
The idea is that finding the purpose of your business will, in turn, allow you to use your market knowledge and understanding of what users will value to figure out the “how” and the “what” of your product features and product-market fit.
The “why” gives you the big picture regarding your product strategy and company goals, which gives you a compass by which you can decide on the product you need and the merits of the features you will build.
So, as a founder, especially a non-technical founder, the most important thing you bring to the table is the ability to answer the question of “why”.
A good example is the start-up ekko, whose “why” is that they want to help build an environmentally sustainable future.
Coming from a financial background, the founders were able to leverage their market knowledge to answer their “why” by creating Fintech products that enable people to track and offset their carbon footprint easily.
| 💡 Expert Insight:
“If you’re building out an MVP or a PoC, you should always ask yourself if what you are building is solving your “Why” – your reason for existing! Matt Sutcliffe – Product Manager at MOHARA |
How do I build an MVP that solves my “why”?
Once you know the why of your business, you need to figure out how you will make it happen.
This is where having a venture studio like MOHARA as a build partner can really help. We have developed eight different product lenses through which to look at how to build a specific product, i.e. how to create a minimum viable product that achieves the product-market fit identified in your “why”.
This allows us to help our partners plan and prioritise the different product aspects and decide on the product’s design, ultimately informing how to prioritise features.
Let’s have a high-level look at the eight product lenses.
👓 1. UX / UI
People spend a lot of time on a product’s user interface (UI) and user experience (UX), which is understandable, as it is the most visible part of a product.
However, it matters a lot that you build the right level of UI/UX for your specific business. For example, if you are building a specialised business-to-business (B2B) application, having the best-in-class UI is unnecessary.
On the other hand, a business-to-consumer (B2C) application needs more focus on UI/UX, as you’re building for a larger number of users.
👓 2. Identify your business model
Understanding your business model is critical, as different business models have different needs. A B2B software-as-a-service (SaaS) product targeted at a specific industry has different priorities than an online marketplace which connects buyers and sellers on a large scale.
👓 3. Stage of business
No matter the stage of your business, you will have a limited budget and time constraints.
However, these constraints are even more severe for a pre-revenue start-up. This means it is crucial to ensure you can build a viable MVP within them.
At MOHARA, we have developed a golden equation to help reduce uncertainty and risk when determining what is possible to build as an MVP.
This may look complicated, but essentially, it states that the total value you receive from your customers (CLTV) needs to be higher than what it costs you to acquire them (CTA), serve them (CTS), and build your product (CTB).
To calculate these costs, you need to make certain assumptions, which will need to be validated and considered when budgeting for your build costs.
For example, if you are building a B2B application, you need to understand your CTA might be higher due to the long sales cycles in B2B sales.
This higher CTA affects how much you can spend on your build. For example, you might need to build an MVP that focuses on delivering the core functionality well but perhaps sacrifices having the best-looking UI.
👓 4. Data
Another key element to understand when deciding how to build your product is your data.
How is your data created? Who can read the data, and what data can they read? How will the data be updated? And how and by who can the data be deleted?
You must also understand how much data you will generate, as this impacts data storage decisions. For example, if you are generating a large amount of data, you will need to implement architecture at the start to allow your product to scale in the future.
👓 5. Stack and infrastructure
These are the more technical questions about your tech stack and software architecture.
Some things to consider include:
- What resources are available to you?
- How quickly do you need to get to market?
- What level of scalability do you need?
👓 6. Elements
When deciding how to build your product, it is very important to be aware of the elements that can be bought rather than built.
For example, if your product requires a payment gateway, you don’t need to build one yourself.
Using an off-the-shelf one like Stripe or Lemon Squeezy will be much cheaper.
| 💡 Expert Insight:
“Buy over build (where possible and within reason). Often founders spend months building something that could be bought and validated in a week or so. Rather buy a feature or subscribe to SaaS products that will allow product validation sooner”. Leo Thesen – Senior Software Engineer & SA Leader at MOHARA |
👓 7. Fitness functions
Your fitness functions determine whether your product works how it is supposed to.
They include:
- Code quality
- Resiliency testing
- Observability testing
- Performance testing
- Compliance standards
- Security code analysis
- Operability standards
You need to determine the importance of each of these when deciding how to build your product.
For example, if you are a business operating in the healthcare space, it is critically important that you comply with all legislation, so you will have to prioritise compliance standards when building your MVP.
👓 8. Users
Finally, we get to users.
We use this as the last lens, as all of the previous lenses should push you to the most important one: building a product that solves a problem or creates an outcome for your users.
It is crucial to understand your different types of users and ensure the product will work for all of them.
For example, if you are building a social media platform, you can’t only optimise it for the people using it to create social content; you also need to ensure that advertisers can efficiently use it to sell to your users.
What does my MVP look like? How do I come up with its list of features?
Traditionally, most product development methodologies focus on gathering data and the ability to get customer feedback to validate your product assumptions.
Whilst this is not a bad approach, it poses a problem for early-stage start-ups, as they are typically creating innovative products.
These products do not exist yet, so they don’t have users; they also solve a perceived problem in the market, so they have inherent uncertainty.
This doesn’t mean start-ups should ignore customer feedback and data, but rather that an extra element needs to be added.
The gut feel of the founders
Gut feel isn’t just a guess, it comes from the market knowledge of the founders, their understanding of the problems their target users have, and the reason why they are building their business.
This is supplemented by data and the design thinking of the product lenses to determine what the minimum viable product looks like, how it will be built, and what features it will have.
However, the emphasis is really on the minimum in the minimum viable product, as it informs all further feature prioritisation decisions.
| 💡 Expert Insight:
“With start-ups, we’re essentially looking at 0-1 Builds – coming from a problem to a product in the market. We don’t have data to prioritise when building a proof of concept (POC) or MVP. You’d normally do this through user testing, whether through A-B testing & automation or user interviews with a select group of your customers. But, what you do have, is a way of understanding what is actually the core of your product and the problem it’s solving – so instead of just looking at your features, you’re looking at the product as an entire unit and the unit is made of features When building a zero to 1 MVP, your most important decision is actually what NOT to include. You should constantly ask yourself whether this is needed to solve the problem. Can I take it out and still solve the problem?” Sasha Benjamin – Product Manager at MOHARA |
Applying this method of looking at the product as a whole, and then asking what features are absolutely necessary to solve the problem it is setting out to solve, will allow you to determine the list of features you need.
Once you have that list of product features, you must prioritize them to create your product roadmap, which will allow you to build and deliver your MVP within budget and on time.
Product Feature Prioritisation Frameworks for MVPs
Once you have a list of the features you want to build for your MVP, you need to rank them in order of importance to determine your product roadmap.
A useful tool to do this is a feature prioritisation framework.
Given that we want to remain focused on building features needed to solve the problem the MVP is setting out to address, the best feature prioritisation frameworks to use allow our product managers to prioritise those core features on the product roadmap.
Let’s look at two frameworks that can help us do this.
📑 MoSCoW Feature Prioritisation Framework
The MoSCoW method works by grouping features into four categories, with the categories going from highest to lowest priority. This enables all stakeholders to be on the same page regarding the features that will be built.
The categories are:
🔹 Must-have
These are the non-negotiable features at the core of the product – without them, your product won’t function and cannot be launched.
This means they have the highest priority and are the most time-sensitive.
🔹 Should-have
These product features are important but are less time-sensitive, so they receive a lower priority.
🔹 Could-have
These product features are not essential for the MVP, so they are not time-sensitive. They will potentially add value to the product but do not affect the ability of the MVP to solve its core problem, so they have the lowest priority.
🔹 Won’t-have (this time)
These product features are the least critical and will not be considered during the current build cycle. They can be set aside for future releases.
Pros of using the MoSCoW feature prioritisation framework:
- It is a framework that is easy to understand for non-technical stakeholders, ensuring that the engineering team and founders are on the same page about product features.
- It is intuitive and makes communicating priorities to product teams easy.
- It strongly focuses on resource allocation by grouping features into higher and lower-priority categories.
Cons of using the MoSCoW feature prioritisation framework:
- You need to ensure that you do not overestimate the number of features in the must-have bucket.
- It might require further prioritisation to prioritise product features within each category.
📑 RICE Feature Prioritisation Framework
The RICE method is a popular feature prioritisation framework that allows you to assign a score, called the RICE score, to each feature based on the impact that feature will have on a specific product goal.
You can then prioritise the product features based on their assigned score.
When building an MVP, the product goal for measuring impact should be to provide a solution that delivers business value to end users.
| 💡 Expert Insight:
“Prioritisation is often about delivering business value to the end user. What is the process that actually brings in cash for the business? The faster you can get to bring in revenue, the better”. Nick Solly – Chief Technical Officer at MOHARA |
The RICE scoring system works as follows:
🔹 Reach
How many users/customers will this feature impact within a given time period?
🔹 Impact
Using a numerical score, typically 1 to 5, to determine this feature’s impact.
🔹 Confidence
Apply a percentage score to your confidence level that your assessment of reach and impact is correct.
🔹 Effort
How much effort is required to deliver this feature? This can be quantified in different ways, but no matter how it is quantified, it needs to be assigned a numerical value (typically 1 to 5).
The final score is calculated using the following formula:
The product roadmap is created by prioritising features from the highest to the lowest RICE score.
Pros of using the RICE feature prioritisation framework
- Feature requests must be SMART (specific, measurable, attainable, relevant, and time-based) to assign a RICE score to them.
- Assigning a confidence score allows you to take into account uncertainty.
Cons of using the RICE feature prioritisation framework
- It relies on data you sometimes do not have access to as a start-up, forcing you to make educated guesses about what will provide customer satisfaction.
- It doesn’t take dependencies into account, which means that if a feature is dependent on others, it will need to be deprioritised even though it has a high RICE score.
It is important to remember that these frameworks are useful tools, but they will not enable you to create a finalised product roadmap that you won’t ever need to revisit.
According to Nick Solly, MOHARA’s CTO, “Feature prioritisation needs to be an ongoing activity, it never stops”.
How MOHARA Can Help with Feature Prioritization
We’re a product venture studio with over ten years of experience developing software solutions.
We really understand what goes into building a successful MVP for a start-up. By applying our in-depth software product development knowledge, we can help you answer the questions of how to build your product, what exactly you need to build, and how you should prioritise your product features during that build.
We have helped more than 30 pioneering start-up ventures build successful products, and our combined experience can be leveraged at every level of your software product development process.
Partnering with MOHARA isn’t just hiring a software development agency; it brings on board an invested co-founding partner who can manage all the responsibilities usually handed over to a tech co-founder – from product ideation to execution.
We have helped more than 30 pioneering start-up ventures build successful products, and we bring a combined experience that you can leverage at the executive level.
And, with our sweat equity model, we provide a cost-effective build solution for cash-strapped start-up founders.
Why not contact us today to learn more about the MOHARA way and how we can turn your ideas into reality?
Let’s be pioneers together!
