Justification is not Prioritization
There’s this tendency in organizations that are just getting wind of this whole Product Management thing to want to use product management to affirm their already-held beliefs.
I see justification happen in two forms: massaging and gaming.
Let’s explore these a bit.
Massaging the system
Someone decides that it’s time to start really prioritizing things, so they make a prioritization matrix of some sort and then massage the weights of the inputs until their pet projects end up at the top.
To be fair, every system needs a little bit of massaging, especially when getting set up first.
The problem arises when there is no space for really using the system, and it’s really just a reflection of what a certain individual’s pet projects are (that individual is the person who is dictating the massaging – not necessarily a certain role in the company).
When the system is massaged more than just very occasionally, that’s a big sign that it’s not really being used for its intended purpose; instead, it’s being used to justify certain projects.
Gaming the system
This happens when someone understands how the prioritization system works, so they take a pet project and gather more information to support why that project should get priority.
This can be either with a structured system like a prioritization matrix, or an unstructured system where project ideas are floated and then justified.
The issue with this is that the justification that’s gathered might be factual, but it’s potentially low-impact. Gathering justification for a pet project looks like:
“Hey customer, do you want this?”
“Sales team – have people asked for this?”
“CS – have customers requested this?”
Or worse – “Hey you, people definitely want this thing, right?”
To be clear, these questions aren’t bad questions to be asking per se. The problem with these questions are the context. When you’re justifying why something should get built, you’re ignoring more important questions. You’re ignoring business needs, you’re subverting real experimentation, you’re asking for validation.
And then you’re plugging that misleading information into your prioritization matrix or waving it in front of other stakeholders saying, “See! People want this!” Which, of course they do. I want free candy bars to appear in my pantry every day. But that doesn’t solve my real life problems.
Not all things can be considered in a prioritization matrix. Sometimes bets are made based on gut feel. That’s all wiggle room that should exist in any company’s prioritization scheme.
What shouldn’t exist is the ability/desire to massage or game the system so that it hides the ambiguity. When you do that, you’re breaking the system such that it can’t be trusted at all.
It’s okay to say, “I know our prioritization scheme doesn’t agree with me, but I think we should work on this project because this is an ambiguous bet I think we should make.”
It’s not okay to say, “Hey look at that, if we change the way things are prioritized periodically, it always spits out the things I want to work on! It’s so reliable!”
Justification in either direction is a mis-step that undermines product management. Do yourself and your team a favor and avoid it at all costs – but keep ambiguity and product bets an open conversation.