The 2013 book The ONE Thing contains a fascinating product management insight from a very unlikely place: The origins of the word priority.
Doesn’t sound like a big deal, does it? But if you can reinterpret the word from how you’re almost certainly using it today to how its fourteenth-century creators defined it, you might find that this simple step can profoundly improve your product roadmaps, your relationships with the various teams involved in your product development, and ultimately your ability to deliver a great product to the market.
That’s a big claim, I know. But I hope you’ll stick with me for a few more minutes. I really think there’s something to this idea of reimagining the concept of priority, something that can help your products, your company, and your career as a product manager.
First, priority’s original definition.
In The ONE Thing, author Gary Keller (he’s the co-founder of real estate giant Keller Williams) explains that priority actually comes from the Latin word “prior,” which means “first”. Not “important”, or “valuable”, or any of our newer interpretations of priority. For about 500 years, the word simply meant first. So if something mattered the most, it was deemed the priority, or first on the list.
Keller goes on to explain that since the twentieth century we’ve effectively demoted priority to mean anything that matters. This is also why it’s only in the last 100 years or so that we’ve introduced the plural — priorities. That simply wouldn’t have made sense in the original context of the word. After all, many things can matter at the same time, but only one thing can be first.
Ironically, as the book then points out, when we want to recapture the original meaning of priority today, to refer literally to the first thing on a list, we have to add words in front of it like “highest”, “top” or “first.”
So, how can the fact that we’ve diluted the original meaning of priority help you?
Can Your Product Roadmap Really Have 11 Items Marked “Highest Priority?”
As a product manager, you are no doubt under regular pressure from many groups (sales, executives, investors, customers) for more. More features. More revenue. More releases. More evidence. More feedback. More users.
The natural tendency for most product managers in these situations is to “prioritize” more of the items on their lists, to move ever-more features and stories and surveys and QA-testing sessions and bug fixes into the Priority 1 bucket.
Tweet This:
“You can’t have seven items in your queue, or on your product roadmap, that all need to be done first.”
But you can’t have seven items in your queue, or on your product roadmap, that all need to be done first. When you do this, when you throw a bunch of items into your Priority 1 bucket, you undermine your product development efforts in several ways.
3 Problems with Having More Than a Single Task at a Time Listed as Top Priority
1. You create a lot of stress among your developers, which undermines their work.
When you load up your roadmap with multiple “Priority 1” items, you offer no way for your developers to identify a hierarchy of importance within that list, to distinguish your
real Priority 1 from the other, next Priority 1 tasks. As a result, you risk putting your development team in what might feel to them like an impossible position.
That’s likely to create stress among your developers because they will always be looking at a bunch of initiatives they know they can’t tackle at the same time, and certainly not at the pace you seem to be expecting from them because you’ve marked all of those tasks as top priorities. No matter what they do, they’ll reason, they will be disappointing you.
2. You undermine your own credibility with your team.
Really? Seventeen Priority 1 tasks to complete in the next thirty days?
When you jam a bunch of initiatives into the Priority 1 category, anyone on your team who understands how development actually works is going to view that as a wish list, not a plan — a best-case scenario that’s not likely to happen.
And that can eventually erode your credibility as the strategic lead for your product, because if your Priority 1 doesn’t really mean first up on your to-do list, then your Priority 2 items similarly aren’t really next-up projects but rather things to get to later.
And Priority 3? Forget about it! Who’s going to believe that stuff will ever get done?
3. You undermine the value of your product roadmap.
Unrealistically cramming many items into what should be a single-item list — Priority 1 — can have the eventual effect of devaluing your product roadmap altogether, both among your team and even for yourself.
That’s because the various groups who view it (sales, management, development) will learn not to trust what’s on it. Moreover, you yourself will come to think of your roadmap not as a well-thought-out strategic plan with realistic timelines, but rather a dumping ground for anything that matters.
All of which is to say that when you violate the true meaning of priority — a dedicated focus on the first thing on the list — you risk eventually undermining the value of perhaps the most important strategic document you have as a product manager, your product roadmap.
The Solution: Return to the Original “Priority” — a Laser-Like Focus on The One Most Important Task, and Then the One After That
This misinterpretation of priority plays out in product teams every day. The product manager tells her development team, “Please start on any of these ‘Priority 1’ items.” The development lead responds by asking, “Which one should we begin first?” And the product manager answers, “Really doesn’t matter. Just pick one.”
What’s happening here is that the product manager is failing to actually prioritize, to determine which item on her list — if she could have only one — she would consider the most important, the priority.
The solution, then, is to start thinking about the concept of priority like those fourteenth-century Latin speakers defined it. Build your strategic plan by placing a laser-like focus on one task at a time, the most strategically important task on your list. Only after completing that task will you then move on to the next most strategically important item — the new priority.
This will be a difficult shift in approach. You will be tempted to add just one (or three or six) more items to that Priority 1 bucket. They will all seem important, after all.
But just as marking every incoming email message “Urgent” won’t mean you’ll read them all any faster, placing all of your important tasks onto a top-priority list won’t make your team complete them all any sooner. In fact, doing so will only create the very real problems I’ve described above.
Tweet This:
“Placing all of your important tasks onto a top-priority list won’t make you complete them all any sooner.”
The best way to get to deliver the strongest product possible, in the shortest time possible, is to help your team focus strategically on the single most important item on their agenda, to the exclusion of every other distraction, until they’re done with it and ready for the next most important item.
Start with the Right Product Roadmap Software
This need for a laser focus always on The ONE Thing, as that great book describes it, is also a reason to have a smart way to filter all of your wish lists — into your long-term nice-to-haves, your immediate backlog, and your product roadmap.
This way you can always easily filter all of this data and focus only on what’s pertinent to the moment or to the team or audience you’re working with.
This is why when you develop your roadmap in Excel or PowerPoint, you will always be at a disadvantage because you’ll always be throwing every task and idea that comes up onto the same document. And that document will quickly become too cumbersome and complicated to provide any real, quick-glance strategic value.
For this reason, you’ll want to use native product roadmap software, a platform that lets you easily view the high-priority stuff, and to just as easily shift views to display only the details that matter — such as your next Priority 1 item — to the audience that needs to see it.
