Building a minimum viable product (MVP) is one of the first milestones in every founder’s startup journey, so which product development approach to take in creating one is a critical question that you, as a founder, need to answer.
Once you start looking into software product development, you will come across the following two types of product development methodologies.
💻 Waterfall product development
💻 Agile product development
Both have pros and cons, but nowadays the consensus seems to be that you should always use an agile development approach, because waterfall development is deemed as being too rigid for the rapidly changing world of modern software development.
In many cases this is true, but it is also the case that a pure agile product development approach is not the right fit for every project, either.
In this article, we take an in-depth look at the waterfall and agile product development processes to illustrate where they respectively work best.
If you are a non-technical founder, we also show why it will better serve you to follow a hybrid approach – the so-called wagile product development approach that combines the best elements of both methodologies.
Let’s dive in and look at why that is the case.
Waterfall Product Development Defined
The most important feature of the waterfall methodology is that it is sequential.
This means that the product requirements are defined up front, and implementation happens in discrete phases.
Each phase consists of specific activities that need to be completed, documented, and approved before work can start on the next phase.
Although initially intended as a software product development model, the waterfall methodology is also used when developing other products – for example, in construction.
Building a bridge is a helpful example to illustrate how the waterfall approach works.
Let’s say you must build a bridge from one side of a river to the other within 12 months.
Following the waterfall approach, you might spend two months planning. You will define what is required, design the bridge, and plan the steps to complete in order to deliver a working bridge.
You might then spend another month sourcing your vendors and building supplies.
Once everything is in place, you will spend the next eight months building the bridge sequentially, starting from each side of the river.
The last month will be spent testing the bridge, i.e., checking that the two sides join correctly and that it can carry the required loads before you open it to the public.
You can’t release a project like this in phases, since you can’t, for example, have people testing the unfinished bridge and falling off it.
Phases of the waterfall methodology
From our bridge example, we can see that the waterfall method consists of the following six phases:
- Requirements analysis.
- Design.
- Implementation.
- Testing.
- Deployment.
- Maintenance.
Typically a stage gate review will be conducted at the end of each phase to decide whether the project can proceed to the next phase.
There is usually also a requirement for meticulous documentation during each phase.
Advantages of the waterfall methodology
🔹 Clear expectations regarding requirements, timeline, and budget are set from the start.
🔹 It is easily understood, and there are identifiable milestones.
🔹 Clear progress can be seen at every stage of the process.
🔹 Ideal for projects with well-defined requirements and low complexity.
Disadvantages of the waterfall methodology
🔸 Its rigid structure and limited opportunity to gather user feedback make it inflexible to changes in requirements or customer needs.
🔸 Since testing only happens after the product has been built, it can have significant cost implications if testing reveals that changes or revisions are needed.
When should you use the waterfall methodology?
You should generally use the waterfall methodology, or a hybrid approach incorporating the structured, sequential process of the waterfall methodology, if any of the following applies to your project:
- You have strict budget constraints.
- You have strict time constraints.
- You don’t need customers to be involved during project development.
- You can’t involve customers during project development because you don’t yet have access to them.
Agile Product Development Defined
The main difference between the agile product development methodology and the waterfall product development methodology is that the agile method is iterative rather than just sequential.
This means that the agile product development process is divided into iterations of short periodic timeframes, often called sprints, that usually last between one and four weeks.
However, rather than being a defined phase of the project, each sprint is, in effect, a small complete project executed by an agile development team. This team develops a working product or feature that can be delivered to customers and stakeholders for testing.
The customer feedback to each sprint is incorporated into the next so that each sprint builds upon the previous one.
This means that you typically start with an idea and roadmap of the MVP you want and what you believe users value, but you don’t have a predefined way of getting there.
Instead, your final product is defined by a continuous and incremental process of development based on the cycles of release and customer feedback.
The agile methodology initially came about as a response by 17 software developers to what they saw as the inflexibility of the waterfall model.
They released the Manifesto for Agile Software Development in 2001, setting out their philosophy with four simple statements:
💠 Individuals and interactions over processes and tools.
💠 Working software over comprehensive documentation.
💠 Customer collaboration over contract negotiation.
💠 Responding to change over following a plan.
These statements were then further refined into 12 agile principles.
The agile manifesto and the agile principles make it clear that what is valued within agile product development and agile product management is flexibility, collaboration, and responsiveness to changes in requirements based on customer feedback.
Advantages of the agile methodology
🔹 Allowing agile teams to adjust their priorities and tailor the product according to customer feedback after each sprint enables a high degree of flexibility.
🔹 Continuous testing throughout the agile project development process reduces risk by identifying problems early and enabling the development team to solve them before they become significant issues.
🔹 Customer feedback allows you to validate your assumptions and ensure that your product adds value to the customer.
Disadvantages of the agile methodology
🔸 Because adjustment to change is prioritised, you have less predictability over the cost and timeline of the project.
🔸 Lack of initial and long-term planning increases the risk of the project falling behind schedule or losing direction.
🔸 The customer feedback requirement means you need access to customers willing to test portions or unfinished versions of your product after each sprint cycle to give you feedback.
When should you use the agile methodology?
You can use the agile software development methodology if the following applies to your project.
- You have a general idea of what users will value, but you need to validate your assumptions to ensure product-market fit.
- You don’t have strict time or budget constraints to finish building your MVP.
- You have access to a customer base willing to test and provide feedback on multiple versions or phases of a product throughout the development process.
Why a Pure Agile Product Development Approach Is Not Always the Best Fit for Non-technical Founders
As a non-technical early-stage startup founder, you face two constraints that make it challenging to develop a minimum viable product using the agile software development process.
Your first constraint is resources, i.e., limited capital and time.
Because you cannot build the product yourself, you must hire a development team or engage a product development agency to develop your minimum viable product.
However, you typically have a very fixed budget – coming either from your funds or investor-provided seed capital – to build a working product and get it into the hands of the user.
This means that you need to be able to have strict control over the budget of your project, which is very difficult in the iterative build-measure-learn world of agile product development.
Your second constraint is getting access to a significant customer base of end users who can test and provide feedback during the agile product development process.
If you are at the seed stage, you need to prove to your investors that you can build a product, but since you don’t yet have a minimum viable product, you typically don’t yet have customers who can test it.
You can, of course, test internally, and you might have a few potential customers to put your unfinished product in front of. Still, typically you won’t have a large enough customer pool to be able to validate your product assumptions properly.
And even if you did, budget constraints may mean that you cannot deviate significantly from your initial assumptions and product requirements.
A Better Way: Wagile Product Development
Just because the agile product development approach isn’t a good fit for a non-technical founder doesn’t mean you are forced to take the waterfall product development approach instead.
As we have seen, both the agile and waterfall approaches have advantages and disadvantages. Ideally, you would want to combine the two to optimally gain from their advantages to your project and minimise their disadvantages.
Arguably the most important thing you bring to the table as a non-technical founder is knowledge of your market and your ability to make informed assumptions about what customers within it will find valuable.
Having this knowledge means you should have a good idea of what your minimum viable product needs to deliver to achieve a product-market fit.
This means you can apply the waterfall approach to project planning, setting out an end goal with precise requirements and milestones, as well as determining your budget and timeline.
However, to minimise the risk of only testing at the end of the project and to increase flexibility and adaptability to the limited feedback you can get, you should break your development process into short sprints.
You will also want to define a deliverable to be tested after each sprint.
This will typically not be a finished or usable product, but you can, for example, define specific product features that can be delivered and tested at the end of a sprint.
This enables you to make small changes and adjustments, if necessary, during the product development process, whilst still staying within your predefined timeline and budget.
It also means you are continuously reviewing and ensuring you are on track to deliver your MVP at the end of the software product development process.
We call this a wagile software product development process.
Choosing the Right Partner
A critical caveat to the wagile process is that you need the right partner to help you execute it.
Again, this is due to your constraints as a non-technical founder.
As mentioned, what you bring to the table is your knowledge of the market for which you want to build a product, enabling you to know what your MVP should look like and deliver.
However, because you are not necessarily an expert in software development, you won’t know exactly what is possible, how long it will take, or how much it will cost, and you might want to build a product with too many features.
Many software development agencies won’t give you any feedback or advice, and they simply execute what you tell them to do, which may result in you going over budget without a working product.
For this reason, you need a partner that will push back on features and help you build an MVP that is the best version possible, given what you want to achieve is within your budget and timeline.
How MOHARA Can Help You Build a Successful Product
We’re a product venture studio with over ten years of experience developing software solutions.
We can help you to build a minimum viable product using a wagile approach and we provide expert guidance on product strategy to deliver solutions that translate into results – within budget and on time!
Partnering with MOHARA isn’t just hiring a software development agency; it brings on board an invested co-founding partner who can manage all of the responsibilities usually handed over to a tech co-founder – from product ideation to execution.
We have helped more than 15 pioneering startup 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 startup founders.
Get in touch with us today to learn more about the MOHARA way and how we can turn your ideas into reality.
Let’s be pioneers together!
