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:
- Talking to customers about problems and features.
- Managing the Product Roadmap.
- Writing specifications.
- Occasionally supporting engineering during the development in case there were questions.
- 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.).
- 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