Agile Product Manager?
I’ve often seen jobs advertising for an agile product manager, and it drives me nuts! What is an agile product manager? For me it indicates a profound misunderstanding by businesses of the role that Product has to play. In this post we’re going to explore the relationship between Product and Engineering; how the product process differs from the engineering process; and how that impacts how we work with them.
The Product-Engineering trap
I’ve been guilty of focusing on the number of stories that I’ve completed because that felt like an achievement. It is, in a manner of speaking but it isn’t my achievement as a Product Manager, it’s engineering’s achievement. The measurement of Product Management should be based around the product process of delivering value: have I found an unmet need and what am I doing about it? How is a feature/product that we released performing and are the metrics improving? The problem is that often the metrics of a product or feature are not immediate, and take time to resolve into concrete results. So in the meantime, what do we do? We get busy and report engineering outcomes in the interim. Over time, that becomes our default mindset: to report engineering metrics.
Product process vs Engineering process
The product process and the engineering process have very different goals and very different metrics. Product processes focus on delivering customer value, essentially the WHAT and the WHY of a product. How we measure that value is primarily through the P/L. Engineering processes on the other hand focus on efficiency, the HOW if you will.
The engineering process is all about building efficiency. If you examine the metrics that it upholds, you’ll notice a similar theme – how units of work are delivered.
We shouldn’t be measuring product teams by the number of stories they’ve written; how much activity they are doing; or by how many features they’ve released. Rather, they should be measured in accordance to the metrics that align with clearly defined Customer Value KPIs. From experience as a Product Manager at eBay, I am well aware of the pressure of having to deliver something, anything in a release cycle as a means of proving that we’re doing our jobs.
Engineering is a stakeholder
We often think about product and engineering being closely intertwined. Reporting lines, org structures and engagement levels confuse the issue, but I’d argue that there is no overlap between product and engineering. Yes, we spend a large portion of our time with engineering however they remain a stakeholder and very much distinct from product. Once we are comfortable with this separation, we can disentangle ourselves from engineering processes.
Now I’m certainly not suggesting that we are ignorant of how engineering works – the better we understand it, the more empowered we are to influence it. What I am saying is that as Product people, we should be looking at what the right customer value to deliver is and not getting our hands dirty in the day to day process of building feature that enables that value.
There is no such thing as an agile product manager, just product managers who know about agile processes. A strong product manager will be able to work with any engineering process because they have determined that their function and value is delivered through different means and measures. Consequently, it is important that Product must take ownership of its processes and not use engineering processes as a proxy because of the reportable nature of it. We must be disciplined in reporting on how our product processes are delivering customer value, rather than engineering’s executional activities, which is a much richer and more interesting story.