Member-only story
The product management “process”—waterfall vs agile teams
In part fourteen of this series, I want to help you understand how Product Management can differ on two types of teams: Waterfall and Agile teams. Here is the previous post from this series.
“Coming together is a beginning, staying together is progress, and working together is success” — Henry Ford (Source).
It’s a distinction that all product managers should understand — it can significantly affect your growth, trajectory, responsibilities, and satisfaction as a PM. There are great lessons to be learned from both Waterfall and Agile.
1. Why the Waterfall vs Agile Distinction is Very Important for PMs:
Knowing the difference between Waterfall and Agile teams will have a huge impact in your role as a Product Manager. From my experience, both are equally valuable methodologies: there are pros and cons to each. Teams usually fall into either bucket — or they take a mix of principles from each. The best teams are flexible to adapting. There are important distinctions between Waterfall teams and Agile teams.
Having overseen the transition from a Waterfall to an Agile environment, I have seen how the Product Management role can evolve and change over time. Understanding the difference between these two processes is absolutely critical to know — because it affects your growth, your responsibilities, your interactions in your day to day job, your goals, and more.
Knowing the difference between Waterfall and Agile environments will help you gain context into what you can focus on. As an early PM, it’s valuable to be a generalist. Your goal is to learn as much as possible about the product management function and role. As you get more senior, that’s when you may want to specialize in certain aspects of the role. This is where it’s critical to know the difference. It will help you understand what your day to day work will entail. It’s important to remember that teams can be highly adaptable. There’s no right or wrong way to define a culture or team by its methodology. What works well for one team may not work well for another team.
