How good are you as a Product Manager?
Being a Product Manager is mostly a game of mental models. Mental models about development, about your product, about the needs and requirements of your customers, of your stakeholders, of prioritisation…
Personally, I like to express my mental models as or using equations when I can, even if the variables are hard to measure or incalculable, because it helps me be very clear and explicit about what I’m optimising for. One thing I’ve been thinking a lot about recently is how do I know if I’m good at my job. That has lead me down some interesting mental rabbit holes.
For what it’s worth, I’m starting here with the assumption that the primary output of a product owner is a decision or an opinion. I can definitely see that being argued another way, but bear with me.
The most obvious way of measuring the value of a PM is directly — how successful is their product? The job of a PM is to optimise value of a particular product, product suite, or feature. Obviously exactly what that looks like depends on the specific company and role, but let’s go with it for now.
Although that’s a good start, I think it’s incomplete. Something that’s universally true (but not universally recognised) is that the quality of inputs and the quality of outputs are varyingly correlated depending on the situation. Something like the value of a product is only slightly correlated with the Product person working with it. There is a huge number of inputs that lead to the output of a product; the engineering team, the product landscape, even the timing of trying to bring it to market (Google Glass, anyone?) That’s further muddied by the potentially very long time that can elapse between a PM making a decision, and the full effect of that decision becoming apparent.
Let’s try isolate some of those variables.
First, we’re going to have our PM work as normal for some long amount of time. Then, we remove them from the team altogether for the same long amount of time. For the sake of argument, let’s say we send them on an all expenses paid vacation to the Swiss Alps. In both cases, we figure out the total value the team is delivering, and the difference between the two values is the impact the PM was having on the team.
Our equation becomes thus.
Again, there’s some issues with this. For one thing, you need to send your PM to the Swiss Alps for six months or so. For another, it assumes the issues the team or product is facing over the second time period are the same issues the team or product are facing over the second period, which probably isn’t true at all. It also has the same issue as the first idea, in that the time that can elapse between a PM making a decision and the time the impacts of that decisions are fully realised can be very long. Take, for instance, the decision to take on some aspect of technical debt in order to deliver a feature. The time before the cost of that technical debt is really understood could be months or even years, where as the benefits of taking it on might be evident in weeks or months.
This brings us to our final idea, and our final equation (at least for now.) Although ultimately a PM should produce a valuable product, the feedback loop on how they’re doing needs to be much faster than that, which means we have to skip product value altogether — we need to optimise the immediate outputs of the PM. As I said earlier, I am assuming that is decisions, but in this instance you can substitute any other discrete output.
Let’s say some things about decisions.
- Decisions have different impacts. Some decisions have a big impact, others have a much smaller impact.
- Decisions take different amounts of time to make — some decisions can be made more or less completely on the fly, others take hours, days, or weeks of thought and experimentation.
- There is a limit on how much time you are willing to spend making decisions (I.e. you can’t simply make all the decisions)
That makes our equation thus.
To unpack that — your value as a PM is the sum of the value of your decisions, normalised by how long those decisions take to make. We’re not looking to maximise the number of decisions we make, and we’re not even looking to maximise the quality of every single decision. We’re looking to maximise the overall quality of our output.
I think this suggests some important things. Firstly, it suggests there’s a sensible point at which you should stop trying to make a perfect decision. That point varies depending on the impact of the specific decision, but the longer it takes you to make that decision, the less valuable of a use of your time it becomes. Realistically, there’s probably some sort of exponential distribution at play here, but even if we assume nothing about the distribution we can see that the time needed to make a decision is potentially unbounded (we could take forever if we wanted to) but that even a “perfect” decision (whatever that means) has a limited up side.
Secondly, it’s a reasonably stark reminder that not only do we, as product people, need to prioritise backlogs and epics and roadmaps, but also need to prioritise our own time. Personally, I estimate that if I were to take the full amount of time to do everything that crossed my desk, I’d be working something in the order of 80 hours per week. The fact I’m choosing to set T to 40 hours (and most people will be setting it between 35 and 50 hours) means there’s a lot of these things that are either going to go undone, or not done as well as they could be. This model makes it increasingly obvious to me that choosing which things to spend that 40 hours on is critical.
Finally, it tells us we don’t need to get every decision right. On average we need to get most decisions right, and we should probably get the biggest, most impactful ones right, but the odd swing and miss is acceptable in the scheme of things.
(If you were actually calculating these values, you wouldn’t be able to compare between the different equations because they’re not dimensionally consistent, but like I said, the purpose here isn’t to actually calculate the value, but rather to guide my effort day to day.)
As I said right at the top of this post, I’m not suggesting we try to actually measure the value of the impact of each decision we make, and thusly calculate our own value down to some dollar figure. I suspect that would be a painful and ultimately fruitless endeavour. I do think it’s a useful mental model to bear in mind when planning my time, or deciding when something is good enough, though, even as a heuristic — to remind myself to ask “Is continuing down this route the best use of my time? What’s the trade off I’m making here, what else could I be doing?”
I hope this exploration of my mental model of value of Product Managers, or potentially any knowledge worker, has been some combination of interesting, insightful, and amusing. If you’ve used a similar model before, or if you want to bounce ideas around about it, I’d love to hear from you.
