26 days until #mtpcon London, the world’s best product conference
Book now
From Waterfall to Agile: A Product Manager Transition "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 2 February 2016 True Agile, Product Management Role, Product Owner, Role Expectations, Waterfall, Mind the Product Mind the Product Ltd 1779 Waterfall to Agile - juggling different things Product Management 7.116

From Waterfall to Agile: A Product Manager Transition

A few weeks back, Martin Eriksson reviewed the history of Product Management and explained how the discipline was born in the FMCG manufacturing industry. At the time, the process for creating products was similar to the Waterfall project management model we’re familiar with because the development, testing, production and market distribution of physical goods is expensive and slow. Everything has (or at least had) to be planned and spec-ed out in detail in an attempt to prevent mistakes and costly changes later in the process.

Software Development and Waterfall

This same Waterfall model was later adopted for software product development as a familiar working model. The process made sense in a world where getting users to test and validate your product and delivering updates where both hard and expensive activities. Hence a lot of emphasis was put on spec-ing out every detail of the product, planning development and ensuring the quality of the product before release. Multi-year release cycles weren’t uncommon.

In Waterfall, the Product Managers initially spends most of their time doing market research and talking to the different stakeholders to capture the requirements. They document those requirements in a long, detailed product specification document that is handed over to the development team for implementation. Then, during the implementation phase the Product Manager has time to work out the details of the go-to-market strategy: marketing message, pricing, distribution channels, etc.

Agile Becomes Popular

In the late 90s, the growth of the Internet unlocked a new way to deliver software: Application Service Providers (ASP), which ultimately evolved to Software as a Service (SaaS) a few years later. This new delivery channel changed completely the landscape: updates to the product could be delivered rapidly, and user feedback captured immediately. This allowed for a much more efficient way to build software that would quickly adapt to market needs.

Agile and lean project management principles spread quickly across organizations delivering software directly over the Internet.

The introduction of these new project management principles has had a very important impact in the role of Product Management. While the goals remain the same, the way to achieve those goals has evolved significantly and organizations have been working hard to figure out how to organize the Product Management function to ensure the success of the products they build.

My Experience Adopting Agile

I have spent the last five years doing product management for an enterprise software application. When I joined back in 2011 we started the transition from Waterfall to Agile by borrowing some concepts from SCRUM, like the sprints and the Product Owner role. While you may be surprised that we were still using a Waterfall process not that long ago, keep in mind that, because of security concerns, many IT organizations in the enterprise world only started to accept storing their data outside the confines of their firewall 3-4 years ago. On top of that, they were unwilling to install, test and validate new releases often (as that was perceived as expensive), so we didn’t have such a big incentive to move to Agile!

In our own journey from Waterfall to Agile, our Product Management function has evolved through three different configurations. Below, I share my experience of the pros and cons and the impact in the product development process of each of them. It is also worth mentioning that the size of the company increased fourfold in the same period of time and, while we have some teams that work in an office, most of us work remotely from each other.

1. The Super Product Manager

I was the first Product Manager to join the company. Initially my role consisted mainly of the following tasks:

  1. Talking to customers about problems and features.
  2. Managing the Product Roadmap.
  3. Writing specifications.
  4. Occasionally supporting engineering during the development in case there were questions.
  5. Working with marketing to define messaging, launch campaigns, perform product presentations in webinars and trade shows and write sales enablement documentation (data sheets, PowerPoint presentations, etc.).
  6. Providing support in the sales cycle.

It was a very broad and challenging role with many responsibilities, and it was difficult to do everything well.

The Cons

With the change towards an Agile methodology, the Product Management responsibilities initially grew even further to cater for the required involvement in the development process. In particular, there was a continuous cycle of prioritizing the backlog, selecting what to do in the next sprint, writing user stories, clarifying requirements during development, etc., which all consumed a lot of my time. At some point I was even very involved in scheduling and tracking engineering work.

So basically, I found myself being tasked with even more things to manage than I had before!

The Pros

The change in the process brought some positive outcomes too. I was now spending more time with the engineering team, which helped us build more alignment – a common understanding of the product we were building and why we were building it. The new process also allowed us to adapt faster to new requirements and new market needs, which made us more competitive and fueled our growth. We released a new version every month while the competition was by and large still releasing a new version of their products only every 12 to 18 months.

The Verdict

In my experience, this configuration works fine for startups or small teams. however, at our scale, it soon became clear it was too much for a single person to do. Something had to give and this is how we decided to split responsibilities between a market-facing Product Manager and a team-facing Product Owner.

2. The Odd Couple: Product Manager and Product Owner

We looked for advice from industry experts on agile practices to see how they had resolved our “Super Product Manager” problem. This led us to discover the Scaled Agile Framework Extension (SAFe) which distinguishes between the role of Product Manager and Product Owner. Using SaFE as an inspiration, we divided the roles in the following way:

Product Manager (PM) Product Owner (PO)
Market / customer facing Product team facing
Owns vision, roadmap, go-to-market Owns release plans, product quality
Provides prioritized high level feature backlog to the Product Owner Provides prioritized user story backlog to the product team
Defines feature acceptance criteria Defines user story acceptance tests

The Pros

This configuration allows the PM to spend most of their time in the market, defining the product and market strategy. It delegates the more tactical work to the Product Owner, who is also the one that represents product management and the user in front of the product development team.

For this configuration we selected a more business-oriented person for the PM role, and more technical-oriented person for the PO role.

The Cons

We soon realized this set up had two main drawbacks: conflicts in priorities, and lack of team alignment with the product strategy.

The conflicts in priorities arose because there wasn’t a single owner of the backlog, and the PM and the PO weren’t in perfect alignment in terms of strategy. What happened is that while the high level features (or “epics”) were prioritized based on business value, the more tactical work that was added to the backlog by the team wasn’t because the PO didn’t interact directly with the market. This included things like smaller improvements to existing features, which in some cases weren’t the top priority for our customers even if they made logical sense.

The lack of alignment between the PM and the PO, and the indirect communication between the PM and the product team also led to a disconnect in the vision and understanding of the real business value of the features being implemented. Moreover, it created confusion inside the organization because there wasn’t a single “owner” of the product. Depending on the type of issue, questions or requests would need to be addressed to the PM or the PO, which led to even more misunderstandings and even less alignment in the priorities.

The Verdict

Given those problems, exacerbated by the remote work set up, we ended up giving all the prioritization responsibilities to one single person and transitioning to the configuration we are using today…

3. The Dynamic Duo: Product Manager and Product Marketing Manager

When we decided to merge the Product Manager and Product Owner roles back into one single person we obviously couldn’t go back to step 1, and so we still had to hand over some of the responsibilities. We decided to introduce the Product Marketing Manager role:

Product Manager (PM) Product Marketing Manager (PMM)
Brings market knowledge to the product Brings the product to the market
Owns product strategy Owns go-to-market strategy
Defines requirements Develops sales tools
Manages backlog priorities and the release plan Manages the product launch plan

The Pros

This configuration has allowed us to centralize the ownership of priorities in the PM, and also give that person time to talk to the product team to sell the vision and business value of the different features being built. This translates overall into a better understanding of the market and the users by the product team. We have also found that alignment between the PM and the PMM has been much easier to achieve. I suspect this is because of two reasons.

First, the alignment only needs to be reached at the vision and roadmap level, which doesn’t require as much frequent communication as the more tactical daily work inside the development team. The two usually only need a one hour call per week to stay on the same page. And second, both speak the same business language and rely on very similar market information to make decisions. Actually, they both often share market and user research information.

As an added benefit, this configuration has proven well-suited to supporting our move to a Design Thinking approach to finding problems and discovering the best solutions. The PM can now easily bring together users and team members to collaborate to build better products.

The Cons

We haven’t encountered any major drawbacks thus far, but I can see problems arising if the separation of duties between Product Marketing and Product Management aren’t clearly defined, or if there is strong disagreement on the product strategy defined by the PM. In that scenario, the PMM may be messaging the product to a market that it is not designed to serve well.

The Verdict… so far

This is were we are in our journey. I am sure we will refine the current Product Management configuration as we learn and discover ways to improve the way we build products.

What Product Management configuration are you using currently? What is working, not working for you? Let’s start a conversation in the comments.

Comments 7

Good article. As a product manager I have been struggling a bit with a third role – the product designer. Within the last few years this third role has emerged out of UX design as a contributor in researching and designing a set of features that are lowest risk / highest value for any given release.

This third role has been troubling me in all sorts of ways, as I am trying to figure out where this role belongs in my overall process.

Here is a slide deck that describes the role more effectively: http://www.slideshare.net/langstonrichardson/experience-design-framework-june-2015-for-slideshare

Slide 20 shows a venn diagram of the different responsibilities between a product owner and product designer, with the first item under product designer’s ownership as “architects product” and second as “studies product users.” Perhaps it’s no surprise that the author of this slide deck is a consultant, much like the controversy around Eric Ries’ Lean Startup, and how it leads people away from determinedly sticking to a problem for the long haul, and getting to know users through thick and thin over the course of many months and years. This is not what startup consultants, nor product design consultants, are paid to do.

The product designers I work with are not consultants, but their practices and methodologies do appear to be born out of design consulting services I am vaguely familiar with.


Even the fact that there’s a table enumerating the diffs between PM and PO makes this article jeopardizing the essence of Product Management itself. In your view a PM talks to customers while a PO (who doesn’t) writes the stories. A PM writes high-level biz requirements and a PO translates them into actionable stories for the team to implement. In my experience as a PM and a consultant, the disconnect inevitably created by the introduction of 2 types of requirements always leads to misaligned expectations typical of Dilbert’s comics. As @arifbobat:disqus correctly pointed out, the 2-people-1-role paradigm should be discarded in favor of a modular and scalable approach, the very same one industry leaders such as Google, FB, Skype, Spotify, etc. use. Is it too much for a Super PM? Then replace her with 2 normal PMs, both of them consistently doing all the things listed in your table. Introducing more labels in the org chart just hides the real problem, which is effectively slicing and dicing the product teams so that they can be working as independently as possible and end-to-end – from customers to code – on the part assigned to them.

Interesting article, a few observations, 1) there’s an implicit assumption that the Org structure of a business shouldn’t change as a result of the move to Agile/Lean approaches and the change in market and demand for digital products and 2) perhaps some consideration should be given to the size and structure of the products themselves
For 1) Other businesses have reshaped their Org to be flatter, lesser hierarchical whilst aligning dependent resources (sales, brand, BI, marketing) under one of many product teams. This works on the basis that for 2) you reshape product teams to be smaller, focussed on independent components of your overall ‘Product’ and are autonomous in their way of working as long as they are aligned to a set of goals/kpis (aka the Spotify, Netflix, Transferwise model). Each team’s goals are then related to the overall product strategy and business goals

Thanks for the comment, @arifbobat:disqus . You are very right about the deep impact in the organization. I would say that the most important ones are cultural rather than organizational, though. You need a very different mindset.

Also, I mostly agree on number 2. We are implementing OKRs to get alignment and giving more freedom to each team. However, giving a lot of autonomy to each team is proving very challenging. It seems some companies are successful at it but for we are struggling with that. Maybe the fact that most of us work remotely is too big of a barrier. Or maybe as we learn how to use OKRs better, alignment will come more naturally.

OKRs is definitely a great approach (very much like the Google/Intel model), something I’ve struggled to encourage organisations to adopt unfortunately. Having said that I do agree that we’re talking cultural and behavioural change here, and that tends to come from the very top (board level). If the leaders at the top are able to empower those below, specifically PMs to develop a vision, strategy and direction for their product you’ll start seeing wider organisational behaviours change through osmosis. Once this happens, and people are more empowered and trusted you’ll start seeing more innovative ideas come to the fore around product strategy, how teams align, what the org needs to do differently etc. OKRs, as you quite rightly point out are a great way to start empowering your org to start thinking differently, as you’re probably finding, this is a slow process as its all about people change. Good luck!

“Talking to the different stakeholders” does not generate requirements. Neither a PM or a PO should be generating requirements. As long as they are, the requirements will oscillate, while the underlying domain being automated doesn’t change at all. Agile is good at noise generation.

Who is responsible for generating requirements then? A dedicated BA documenting them? If so, where do the requirements come? From the market? How are the market expectations converted into requirements then?

Join the community

Sign up for free to share your thoughts

#mtpcon LONDON | 20 OCT 2023

Join world-class product experts for a jam-packed day of inspiring talks and interactive sessions

Book now