What a Product Manager does

Last year I took an unexpected pivot and have spent most of the time since working as a Product Manager. While I’ve had a couple of minor side gigs in that time I think my consulting life is gone, I see myself continuing on as a Product Manager. While I enjoyed my years consulting its also great to be consistently working on one thing, delivering product to real customers.

Now feels like a good time to reflect on just what I’ve been doing as a Product Manager and how I make sense of this world now.

A little background

Now I’ve been a Product Manager before, I dabbled in managing a product manager when I was still coding and then trod the common path from engineer to Product Manager via an MBA. I even did training with Pragmatic Marketing in the USA.

As a result my flavour of agile has always been heavy on the product side and I frequently found myself asked to coach product manager, owners, BAs and founders. I often describe this as “the demand side” or “what question.”

A lot of my writing a lot of it clearly falls into the product space: Business Patterns for Software Developers (how I wish I had called this book Strategy Patterns for Software Products), Continuous Digital, Project Myopia (which didn’t talk about products and simply said “projects are wrong”) and of course The Art of Agile Product Ownership.

Product Owner or Product Manager?

Somewhere along the line I kind of fell out with the product manager community part of this is because I refuse the distinction between Product Owner and Product Manager. I’ve observed Product Managers who look down on Product Owners and see them as some kind of charlatans. Now granted, Product Owner as defined by Scrum is a pale imitation of a Product Manager role but both roles have, or at least should have, the Product at heart. Both roles are concerned with the demand side and should be value oriented.

Now the two roles are really badly named but the a bigger problem is the way companies interpreted by corporations is completely messed up but unfortunately I can’t fix that. Often there are two roles but I would call them Tactical Product Manager and Strategic Product Manager (more on that in The Art of Agile Product Ownership).

While most of my year has been spent as a Strategic Product Manager one can never get too far away from the day-to-day. Without a Tactical to partner with I’ve taken a lot of that on but I haven’t written a single user story or prioritised a backlog. I’ve been driving work through OKRs which means I’ve been much more strategic.

Strategy

Now as a Strategic Product Manager it is not just a case of writing a strategy, giving in to everyone and putting my feet up. Delivering a strategy means living the strategy, it means repeating it, and repeating it, it means letting it into every decision, it means calling out decisions which you (and others) make which don’t fit the strategy, and it means coping with problems which arise so they don’t disrupt the strategy.

For example, one of my early strategy decisions was to develop a small product and expand it. Having made that decision I had to fight for it and explain to people that building small didn’t prevent us “going large” later. That mean finding the language and metaphor to explain that decision. It meant socialising it, getting key people to understand my logic and agreeing. That meant repeating it, it meant reassuring people we weren’t walking away from the large product and it mean prioritising decision to deliver the small.

One of the other teams in the organisation kept implying that my product was going to be much bigger than it needed to be. I had to keep correcting them, saying “In the first instance we are building a small product, we may do that large stuff later but right now we are going small.”

In fact, I’ve made lots of decisions along the line to not doing something. To put a problem in a box and label it later.

Yes I listened, yes I took on other concerns, but once I’d made a decision the team and I had to live that decision. When we’ve had problems, fires, and need to react those decisions have to align with the strategy. Rather than saying “This is an emergency we need to go bin the strategy for a week” it means saying “Our strategy tells us to deal with the emergency by doing this.” A crisis is an opportunity if you handle it right.

Business value

Most of the business value for the product had been identified before I arrived. But I still worked over where the product added value, I needed to make it my own. And on many occasions in reasoning, and thinking strategy, I’ve taken myself back to first principles: “What is the value this product is delivering? And to who?”

That has been especially true of the second product I’ve been involved with. That product has been troubled. It is a “business enabler”, it doesn’t so much deliver the value itself as support teams who are delivering value. With this product I regularly find myself going back to “how does this deliver benefit?” Unfortunately I find the business side too forgiving here, I wish they would join me in looking at business benefit and querying work was being suggested. Too many people hear that the work is both strategic and technical and switch off, they then trust the techies.

The client organization is paranoid about delivering the right thing. Knowing the value in both cases, having a strategy, and giving a consistent message in all cases both furthered the case and saved time. I didn’t need to go back to basics everytime.

Guilt, or just imposter syndrome?

In fact, if you ask me “Describe in one sentence what you have been doing as a product manager” I’d probably reply “Forming and promoting the strategic vision.” That sounds pompous, so let me try again: “Agreeing the outcome and keeping the focus.”

I do feel like a charlatan product manager: normally when I read Marty Cagan’s posts. Don’t get me wrong, I’m a big fan of Marty Cagan’s work and his posts. I agree with almost everything Marty says but measured to his standard of product management I’m a fraud.

I don’t spend my every possible hour meeting customers. Actually the product I’ve been managing is largely internal so very few users are “customers.” I pretty much know all the customers. And those facts add to my charlatan feel.

I don’t agonise about Product Design – its not irrelevant but in our environment its not a high priority. So again, is this really product management?

I do encourage agile style working, I do work with an outsourced team. The client likes the idea of a product operating model but they can’t give up their project habits so it is full of compromises and dysfunctions.

In short I just don’t feel I live in the same product world as Marty. Maybe I should be considered a project or programme manager but the client considers me a product manager.

(Actually, every time Marty complains about agile coaches who try to coach product people I feel guilty too.)

OKRs

One of the attractions of working with this client was OKRs. When I joined they were starting OKR adoption. As such I had one of the first to teams using OKRs. While my OKR execution may not have been perfect, and while the organisation has been a long way from perfect I have had success.

My backlog free approach has worked great: OKRs are set quarterly, we review them in most planning sessions, work is direct work towards the OKRs and the team write their own tickets for things to do. There are no user stories and the only backlog we have is work we simply haven’t got to yet. (Although even just a tew dozen items in the backlog, in progress or blocked we get duplicates!)

Problem solving team

Part of my success with the OKRs has been respecting my main delivery team as Problem Solvers. The OKRs describe the problems and parameters of the solution and the team can work out how to solve it.

The second product team I was working with things didn’t go so well here. This was a different supplier and it seems the culture here was less problem solving and more doing what was asked. Which mean a) the asks had to be more detailed and specific, b) it was more time consuming and c) they were more easily distracted and blown off course.

Conclusion and next

So there you go, there are some thoughts on life and challenges as a product manager. This is the way I find the Product Manager role. Personally, I don’t think this is much like it is in the books (and conferences) – with the possible exceptions of The Art of Product Ownership. But does this make me less of a Product Manager? Does it mean I should have a different title?

And now… the main project is coming to an end. I expect to stay with the same client so if you want like to tempt me to be your Product Manager get in touch fast!