Weeknotes #157
Why do we have a product management function?
I had intended to have a few conversations this week to understand why people in other teams think we have a product function, but I didn’t get the opportunity (for that, read I didn’t make the opportunities).
My answer is: “The role of product management is to balance risk mitigation with exploring and exploiting opportunities to create and capture value for the organisation and it’s customers.”
I think there are six interesting elements in that statement. Breaking it down a bit:
- Risk – the biggest is building the wrong thing for the wrong market at the wrong time. Product Managers mitigate this risk through market and customer research, testing and validation, etc.
- Opportunity – there are always other problems to solve, other markets to enter, other customer segments. Product Managers explore these looking for
- Customer – creating value for people through solving their problems.
- Organisation – capturing value in return for solving customer problems.
- Balance – change is constant, so the balancing is an ongoing effort to achieve product/market fit.
- Value – is the outcome. The sweet spot of maximum value is the optimum outcome.
I think the parts most people would struggle with are the risk and opportunity. I think they’re likely to misunderstand what risks there are to a business that a product function could have any affect on, until perhaps we say that one of the biggest risks to an organisation is not capturing value from its customers. That very quickly leads to no organisation.
Finding the right balance of mitigating risks and exploring opportunities leads to the sweet spot of maximum value creation. A PM that is too risk averse and waits for 100% certainty before making a move or doesn’t explore opportunities to move into new customer segments won’t find the sweet spot of maximum value. Similarly, a PM that is too focused on exploring new opportunities and doesn’t spend enough time on risk avoidance activities such as market research is also unlikely to achieve maximum value. The balancing of mitigating risk and exploring opportunity is at the core of what a Product Manager does, and as no other department does this, is why we need a product management function.
Measures and motivations
I spent some time with one of the Product Managers from a different team working through our understanding of why our performance measures don’t work as well as we’d like in driving the right kinds of behaviours.
We agreed that in a fast moving competitive marketplace its impossible to set meaningful goals in January and still have them be the right goals any time after that. That means, we need a performance measurement process that allows/encourages/forces regular course correction through feedback loops. An OKR-type system could do this but part of the problem is that our PDR system has fixed annually-set goals and as this is the system that drives bonuses it’ll alwats be the measures that people default to.
The only way I can see of using two systems effectively is to have them solve two separate problems. PDR’s can be a measure of personal performance over the year, and OKR’s can be used to measure and drive the products we manage. It’s twice as much work to administer (even more if we get the feedback loops and course corrections working properly) but arguably they are two jobs that need to be done.
The fire control problem
Also known as ‘How to hit a moving target’, this is about how to approach solving complex problems in dynamic situations, where the goal you want to reach keeps moving. It underpins the OKR vs. PDR thing above because we recognise that it’s impossible to set static goals far ahead of time and expect to reach them (which is the PDR approach), and so we need a different approach to actually and truly measure our progress.
This approach requires accepting that we can broadly agree what we want to achieve but that the definition of that goal will only become clearer the closer we get, that the goal is very likely to move whilst we are chasing it, and that there may never be an end point where we can say we have achieved it because it just keeps moving.
Working on this way requires a realistic assessment of the situation, and keeping that assessment up to date as the situation changes. It requires regular measurement of your progress, feedback loops, and course correcting activities to keep you pointing at the target.
The metaphor I use when talking about this is firing a missile at an aeroplane. If you fire your missile in a straight line at where the plane is now you’ll miss because it will have moved by the time to missile gets there (this is building something without paying attention to market and means you never get product / market fit because competitors got there first, for example). If you try to predict where the aeroplane will be at some point in the future you can fire your missile at that point and have a slim chance of hitting it, depending on how good you are at predicting the future (this is the big upfront planning approach, the waterfall approach that agile reacts against). If instead, you fire your missile in the general direction of the aeroplane and when it reaches a certain point you check where the aeroplane is now and change direction towards it, fly on for a bit and then do the same, and keep repeating this until you hit the plane and blow it up. I’ve been searching for a nicer metaphor but I can’t find one that fits as well.
The funniest conversation I had about this was with someone who said that the market we are in doesn’t move very fast. I asked how they were measuring change in the market and pointed out that just because you aren’t aware of it doesn’t mean it isn’t happening.
This week’s product ideas
I had two ideas for products this week:
Horizon scanner – A tool for senior managers to keep up to date with how things happening in adjacent industries might affect their industry.
Policy generator – A tool for small businesses to submit information about their organisation which is used to generate policies (health and safety, cyber security, etc.) that conform to best practice, current legislation and regulation, and of course the current standard.
I’ve set myself the challenge of coming up with and submitting to our labs team one idea a week. I’m not sure how long I’ll be able to keep it up but I’m already working on a couple of ideas around hyper-specificity and access control for next couple of weeks.
These ideas serve a few purposes; they help me to learn about how the organisation works as new ideas always challenge the status quo (part of that perimeter testing I’ve been thinking about), and they build towards my understanding of how to innovate every part of the standards development and commercialization process, which ultimately is about how to move from a pipeline business model to a platform (although it’s nothing to do with my role it’s an interesting problem to solve conceptually).
Duplication of work
The whole team is working on a new product. Some feature definition work has previously been done and recorded in one system. But we didn’t know that. So, more recently we started from scratch and began defining features in a different system. Soon we’ll have to do a copy-and-paste exercise between the two systems to get to a single source for our feature definitions. I think it might be easy to regard doing this as a waste of time, but I don’t it is. I think its an editing opportunity, a chance to check our understanding and add any knew knowledge.
In a complex product you have to keep going back over the same things from different points of view to help integrate new knowledge.
Next week I’m looking forward to…
A meeting with project managers about project managers.
I think we all recognise that managing all the projects in the way that we do isn’t working very well and that we need to try to improve it. There is a lack of visibility, which seems to be due to all communication being funneled through the project managers and them tracking project status on a spreadsheet, which results in no one really knowing what’s happening, people not being involved, and things being missed. The only communication tools we have is two status update meetings a week and occasional emails.
We put the project managers in a difficult position of being this funnel, where on one side they have people demanding answers to questions they can’t answer, and on the other side they have people providing answers they can’t communicate. We don’t give them the authority to manage budgets or the availability of the offshore development team, and yet we expect them to be able to give reliable schedules for multiple complex projects that other teams can use to plan their work. It’s like some weird sit-com about how not to manage projects in a modern world.
So I’m going to suggest that we decentralise communication to remove the pinch point of relying on the projects managers, and shift the project managers focus from being about coordinating the flow of information on each project to helping everyone see the big picture of all the projects together. We need to elevate their role, take it up a level (see above), reduce the need for administrative effort and give them greater responsibility for coordinating how the projects run. Their objective shouldn’t be the usual project manage stuff about ‘on time, on budget, in scope’ because they aren’t given control over any of those things.