The Best Product Management Methodology: Agile vs Waterfall vs Lean

As a Product Manager, it’s likely that you are familiar with terms such as “Lean”, “Agile” and “Waterfall”, but what is the difference between each of these product management methodologies and how can you choose the best one for your product and team? We take a look in detail at why product management methodologies matter and how they differ from one another.

Why does the product management methodology matter?

Although you might think of product management as a relatively new discipline, product management methodologies have been around for quite some time, and can be traced back as far as the 1970s!

As you can imagine, product management methodologies have really evolved, particularly over the past 20 years or so, with the rise of new technologies and ways of working.

Product methodology really matters in a world where companies are competing to discover and deliver the most valuable product that solves their customers’ problems in the best ways possible and take that share of the market.

In a world where new software and iterations of your product can be released every minute of the day rather than once a year (think: Microsoft’s annual release of the Encarta CD-Rom!), it’s important to ensure that the product management methodology you choose to use is fit for purpose.

4 main product management methodologies

There are many product management methodologies out there so let’s take a look in a bit more detail about what is involved with each of those:

Waterfall

You may not have heard of American Computer Scientist Winston W. Royce, but it is commonly noted (although possibly mistakenly) that his paper “Managing the development of large software systems” published in 1970 was responsible for the Waterfall methodology as we know it today.

Originally Royce envisioned the methodology as containing the following steps:

1. 1. Systems requirements
   2. Software requirements
   3. Analysis
   4. Program design
   5. Coding
   6. Testing
   7. Operation

As you can imagine, in the 1970s they didn’t have the luxury of being able to iterate on their work as the rise of the digital era was yet to happen, so each stage of development had a distinct purpose and had to happen in sequence. There is also nothing in this list about customer needs, problems, opportunities, or collaboration!

A more “modern” version of the Waterfall methodology can be seen as having the following steps, again each handled in sequence with a ‘hand-off’ and often rooted in project management rather than product management:

1. 1. Ideas
   2. Business case
   3. Roadmap
   4. Product requirements
   5. Design
   6. Build
   7. Test
   8. Deploy

Unfortunately, this “top-down” approach does not leave much room for customer needs to be considered (although there may be a one-off exercise of considering them as part of “Requirements”), collaboration or experimentation to happen which means that there is a high risk of delivering a product that your audience doesn’t find valuable or will not use. This is because it’s a linear process and once each stage has passed, there isn’t room to go back and make changes. The goal in Waterfall is to deliver products on time and to budget, not to focus on outcomes and customer value, which is where the methodology often falls down.

Agile

Fast forward 30 years and the digital revolution is in full swing, and with it, the need for a new way of working. In 2001, around the time of the dot-com boom, 7 software developers defined the “Manifesto for Agile Software Development” and the Agile methodology was born.

There are 12 principles in the agile manifesto in total and in combination they guide teams to increase responsiveness to change, productivity and efficiency:

1. 1. Customer satisfaction by early and continuous delivery of valuable software.
   2. Welcome changing requirements, even in late development.
   3. Deliver working software frequently (weeks rather than months)
   4. Close, daily cooperation between business people and developers
   5. Projects are built around motivated individuals, who should be trusted
   6. A face-to-face conversation is the best form of communication (co-location)
   7. Working software is the primary measure of progress
   8. Sustainable development, able to maintain a constant pace
   9. Continuous attention to technical excellence and good design
   10. Simplicity—the art of maximizing the amount of work not done—is essential
   11. Best architectures, requirements, and designs emerge from self-organizing teams
   12. Regularly, the team reflects on how to become more effective and adjusts accordingly

The agile principles are where we really start to see the beginnings of collaboration as a key way of working and the ability to iterate on products come to the forefront of product development. The concept of self-reflection as a team also makes an appearance here as does the mention of customer satisfaction, something notably missing from the Waterfall methodology.
Kanban and Scrum are two frameworks you may be familiar with that have arisen as part of agile product management:

Kanban

Favored by some cross-functional teams for its fluidity, Kanban operates on the basis of limiting work in progress and Kanban boards often take the form of 3 columns: “To-do”, “In progress” and “Done”. There is less focus on the work being time-bound (unlike 2-week sprints in Scrum) and more focus on maximising efficiency in the team’s work.

Scrum

Still part of Agile thinking but quite different from Kanban (and a bit less fluid) Scrum teams commit to delivering set pieces of working software through “sprints”, which often last a period of 2 weeks. Team members adopt a number of different roles (such as Scrum Master) in this framework and there is a focus on ceremonies such as retrospectives (to ensure time to reflect on how the team can improve) and planning (to agree on the goals and work to be undertaken in the coming sprint).

Lean

A name you may be more familiar with is Eric Ries. His book Lean Start-Up, published in 2011, put a lot of emphasis on the need for customer-focused discovery and experimentation, in a way that perhaps hadn’t been seen before.

The Lean methodology has its origins in physical product development – namely the Toyota Production System (TPS) which focussed on reducing waste (hence the name “Lean”), improving processes and encouraging innovation.

The TPS is grounded in 2 main concepts:

1. Just in time – “Making only what is needed, only when it is needed, and only in the amount that is needed”
2. Jidoka – Autonomation – “Automation with a human touch” – a way to discover process abnormalities, stop your workflow to prevent quality issues, quickly fix identified issues and identify and remove the root cause of any process problem to ensure a continuous flow of work

Ries also popularized a concept called the “Five Whys” – a technique used to find the underlying causes or roots of a customer problem – originally created by Sakichi Toyoda as part of the Toyota Manufacturing process evolution.

The Lean methodology focuses heavily on the importance of product discovery – in particular customer research in the form of direct interviews, identifying a minimum viable product followed by quick testing and iterations to minimize waste in the development process.

Some of the principles that sit behind the Lean Methodology are:

1. Validated learning – a real focus on experimentation with the goal of quickly validating your ideas
2. Innovation accounting – a focus on measuring progress and prioritizing work
3. Build–Measure–Learn – turning ideas into products, measuring how customers respond, and learning whether to pivot or persevere – this should be a continuous loop of learning and iterating

Dual Track Agile

Around 2012, product gurus Marty Cagan and Jeff Patton coined the phrase “Dual Track Agile” after reading a paper on “Adapting Usability Investigations For Agile-Centred Design” by Desirée Sy. This methodology is also sometimes referred to as “Continuous Discovery and Delivery”.

In Dual Track Agile a team has two “tracks” of work – one where your team is figuring out what the right thing to build is (product discovery) and one where they are actually building it (product delivery). These two tracks happen concurrently and are continuous in nature with the product discovery track continuously feeding the product delivery one.

This product methodology really takes in all of the learnings and evolution of product management of the past 50 years to ensure that product delivery and discovery get their fair weighting when it comes to creating valuable digital products.

It can be argued that product teams who use Dual Track Agile are much more likely to deliver valuable products to customers because the methodology encourages only validated product ideas to reach their backlogs, which will ultimately result in only products, features and functionality being released that customers value and care about.

Splitting the work across two parallel tracks (one for discovery and one for delivery) also means that teams have a higher chance of getting a product or feature right with users within the first set of iterations rather than having to repeat a linear process many times. This can result in speedier development and release cycles with less wasted time and resources.

Product management methodology comparison table

We have discussed each of the main product management methodologies in detail above, let’s take a look at them all at a glance:

Which is the best product management methodology?

There are many views on this but from my personal experience I would have to say Dual Track Agile. Of course continuous discovery and delivery can work in conjunction with elements of some of the other methodologies such as Agile and Lean but the nature of Dual Track Agile is that it is a continuous process of learning, iteration, experimentation, collaboration and delivering value to customers. There is also a heavy emphasis on collaboration across disciplines, right from the get-go. For example: a Product Manager, Lead Developer and Lead Product Designer should be part of the product discovery process at a minimum, and ideally other team members and stakeholders are brought in at key moments to participate. The key to Dual Track Agile is that it’s iterative and cyclical as opposed to linear and finite.

Waterfall concentrates very heavily on delivery and lacks the key stages of discovery necessary to deeply understand core customer needs and find the very best solution for those needs. It is often focussed on a single solution (normally one that has come from someone senior in the business!) and the lack of collaboration in each of the stages leaves a lot to be desired as information and work is passed from one team to another. Writing business cases can be considered a waste of time when it’s your job as a product team to get out there and solve customer problems in the right way (that’s not to say that product recommendations shouldn’t be articulated, however, as long as they’re based on validation!).

Many implementations of “pure” Agile are too heavily focussed on delivery and not enough on discovery and customer value, which misses the mark. Sometimes Scrum can be implemented in such a way that product teams end up drowning in-process and measured on their velocity and volume of work delivered, rather than on the value they are adding.

Lean comes close to hitting the mark with its lightweight approach to testing and experimentation and a heavy focus on customer needs and solving for those. Lean and Agile can work well in conjunction with one another if set up in the right way.
Companies will often try to mandate a particular methodology but in my experience teams work best when they find what works for them.

Are product management methodologies and product development methodologies the same?

A lot of this comes down to semantics – managing your product and developing your product can be considered very similar things. Managing your product should encompass developing and iterating on it, as well as sunsetting it if it’s no longer providing value as part of the product lifecycle.

New product development and existing product management methodologies are very similar (product discovery/product delivery), possibly with the exception of the initial discovery phase for a brand new product where you are looking for a product-market fit and demand, whereas an existing product may already have this but customer value will still need to be added continuously to keep your user base active and engaged!

How to choose the best product development methodology for you

No matter which product development methodology you choose, your ways of working should always include the following considerations:

• Have you articulated your outcomes and what success looks like?
• How deeply do you understand your customers and their needs?
• Have you spent time identifying the right problems to solve for them?
• Have you explored the opportunity space to see if these are problems worth solving?
• Have you spent time brainstorming multiple solutions to these problems?
• Have you prototyped and tested those potential solutions with customers?
• Are you working collaboratively with your stakeholders?
• Have you taken the time to test the “4 big risks” (value, usability, feasibility and business viability?)
• Have you found a product-market fit or an MVP that works?
• Are you continuously learning about your customers and measuring how your product is performing?
• Is your team continuously improving their ways of working?

It’s best not to be too caught up in process and methodology and try to focus on the things that matter (the list above!). Of course methodology can be helpful in putting a bit of process in place where necessary but you shouldn’t feel too bound by it, or worse, add too many processes in place of collaboration or other key ways of working.

Key takeaways

Hopefully you have learnt something about product management methodologies here and how they have evolved over time. Focussing on customer needs and finding the best solutions for those through experimentation and collaboration are always key in product management – so ensuring that your methodology incorporates those things will remain important in this digital age. Remembering not to be too caught up with process and to keep things flexible and iterative is also important! Whichever way you choose to work, we wish you success!