As any professional cat herder knows, once you’ve mastered the art there really isn’t much of a challenge anymore. For an increased level of difficulty you need to replace those cats with headless chickens, mind you only ones with infinite stamina else the herding will come to a bit of a premature end when they … well, drop dead …
Product management is almost, but not quite, entirely unlike herding headless chickens (with apologies to Douglas Adams), but before I clarify I’m going to pause right here for a disclaimer:
To all past, present and future colleagues and even more importantly to all past, present and future stakeholders; I’m not calling you headless chickens, relax, would never dream of it, NEVER … I’m just giving a bit of color to a situation that basically exists everywhere.
Phew! OK, with that off my chest how exactly does the chicken thing relate to anything in the product management space at all? Well if you ponder it a bit you might think of things like multiple chickens, each having their own goals / agenda with little regard for, or even knowledge of, what the other chickens may be up to. Seeing as they’re headless, they likely don’t see very far into the future either. There are some excellent exceptions though, which makes the metaphor a bit shaky so here’s where I’ll abandon it and bring it back to stakeholders.
Common challenges one faces when dealing with multiple senior stakeholders include:
- each stakeholder having their own ideas of what is best for the product, driven by their experience and insights which vary wildly in terms of the data backing it
- some stakeholders have a more vested interest or severe bias to overcome, maybe it is their pet project
- some stakeholders just have more authority and will be heard regardless
The way to address this is to reach common ground, and I don’t mean just magically reaching some consensus that leaves everyone equally disappointed. You need a tool, a way to objectively express the different priorities and compare them to each other in quantifiable business value terms. Your tool doesn’t make any decisions, it represents an agreed way to measure things, which means by default if anyone disagrees with what it says either the tool (not referring to the one who dares to disagree, really, the tool you’ve created) needs to be changed by agreement, or the exception needs to be properly motivated.
As an example, if your business usually prioritizes items for the client or stakeholder that shouts the loudest, then design your tool like that.
Give the “one who shouts loudest” a higher weighting in your formula, why not? If that is the reality then quantify it, you’ll very quickly discover whether others agree or disagree that it should be the official approach. Of course it sounds inherently wrong, it is wrong, but don’t hesitate to point out the reality.
Sometimes all it takes for others to see the mistake is to voice it. Just like paying off your debt with more debt, or betting bigger on your next wager to recover your losses, “he/she who shouts loudest” is a very common situation that everyone instinctively knows is a bad idea. So point it out, quantify it and have the debate about how your tool should really measure business value, congratulations you’ve just overcome a big challenge many product managers face.
I’ll potentially discuss a more comprehensive example of such a tool another time, there are less real world examples out there than you might imagine which means most people are rolling their own and not leveraging the experience of others much.
For now just remember you can quantify anything, make the conversation about how business value should be quantified rather than what should be prioritized, else you’ll soon end up feeling like a headless chicken yourself.