Resolving Conflicting #1 Priorities—An Answer on Quora

Posting another answer I posted to a question on Quora about resolving conflicting #1 priorities.

The Question

What are good ways to resolve conflicting “#1 priorities”? This is an open-ended question intended to spur discussion, I have no particular conflicts that need resolving at the moment.

My Answer

I find a few ways to interpret this question: that the priorities conflict because you cannot do both at the same time, that they conflict because the output of each is mutually exclusive, or that they conflict for political reasons. I assume you’re talking about the first, but please let us know if not.

This three step process may be helpful to resolve time/resource based conflict:

  • Reexamine both priorities to make sure they truly are priorities
  • Look for a solution that can make a partial headway on both
  • If all else fails, do some priority calculus

I’ll discuss each below while attempting to keep the tips/techniques generic to any type of “priority.” I use “solution” as a generic term for whatever the priority is (be it taking some action, adding some feature, selling to some particular client, etc.).

RE-EXAMINE THE PRIORITY OF EACH

This first step is a heuristic designed to save time. These basic questions, applied to each solution, hopefully help you arrive at a decision quickly:

  • Ask yourself “what would happen if we don’t do this?
  • Are we solving a core problem, or working on context?
  • What problem is being solved (prioritize problems over solutions)?
  • How many customers/users does this solution benefit?
  • Does the solution fit into your products strategic vision?
  • Does the solution fit into your organizations strategic vision?
  • How well does the solution fit into the roadmap in terms of timing?
  • Are other high priority items in the backlog complemented either solution?

LOOK FOR A SOLUTION TO MAKE PARTIAL PROGRESS ON BOTH

If the initial step to re-examine each priority does not turn up a clear winer and loser, consider looking for a way to make a little bit of progress on each.

If you’re solutions are somewhat related, I suggest conferring with the team. Two heads are better than one, and they might come up with a “3rd way” that resolves the conflict by meeting a little bit of both needs, or even better by finding a solution which is mutually reinforcing. You never know what the brilliant minds around you are capable of.

If the solutions are not at all related, you can still realize some benefit. First, you’ll have to reduce scope for each, which is usually a good practice anyway. Having an aggressive constraint really helps to trim the fat (less useful parts) from your solution.

Second, through the course of working on each solution, you’ll probably learn more about their relative priority. One of them may turn out to be less important than you thought. Sometimes this realizing just happens naturally in the course of development.

Third, by releasing a partial solution, you increase the chance that you’ll get feedback on the direction your taking, which could turn out to be great or completely wrong. The feedback may change the priority, solution, or both. What’s being described in these three benefits is basically the iterative development process.

DO SOME HEAVY DUTY PRIORITY CALCULUS

Finally, if you don’t find any obvious difference in priority and do not find it advantageous to implement a partial solution for each (or the solutions are already at the lowest level of scope), then it may be time to turn to a more in-depth analysis. One such method is a prioritization matrix.

There are a few different types of prioritization matrixes. One type assigns features into quadrants. If you’re solutions end up in different quadrants, the decision would probably be easy. Otherwise, you may look into another common type of matrix which compares items by assigning numerical scores on a number of factors. Recognizing that priorities differ depending who you’re talking to, prioritization factors are often categorized by function (i.e. for sales, customer impact, etc.). The factors are weighted, the value of which depends on you, your organization, and what stage of development your product is currently in.

When compiling a feature matrix I find it helpful score items yourself for the first round. Then, get feedback from others as to why they think it should be higher or lower. The resulting conversation can uncover a lot of assumptions.

A nice feature about numerical scores is that they make it a little easier to compare line items. You might ask, “You say this should be a 4, but is it truly as important as this other item which is also a 4?” Be careful, however, as feature matrixes discussions can have a tendency to get overcomplicated. “Well, yes this is a 4 too, but only if that other item gets completed, because this item is pointless without it,” for example. Just remember that it’s ok to make assumptions and move on. The prioritization matrix should be a living document that is updated periodically.

The bottom line is that doing some kind of structured analysis, such as using a feature matrix, can help objectify the decision in order to unstuck yourself. Additionally it can be good for situations in which the decision for priority is politically charged.

ONE LAST (IMPORTANT) THING

If you’re the product manager, then in the end you need to make a decision. Go with your gut instinct if an objective analysis does not turn up a clear winner, or if the impact of the decision is sufficiently small as to be unworthy of conducting the analysis in the first place.

NOTES

Posted via email from byte plight | Comment »