July 1, 2021

Lesson 3: Priorities

Lesson 3: Priorities

Isn’t it ironic that the chapter on priorities isn’t ordered at the top of the chapter list? Especially since I set this chapter to a ranking of “critical”.

But obviously all the other chapters are critical too. Damn. How am I supposed to decide which comes first?

Well let’s put it this way. If making decisions that impact the livelihood of everyone in the organization based on little or no information makes you queasy, expect to be puking a lot...

...I visit the bathroom to yak at least twice daily.

“Yuk. I don’t remember eating that. Welp. Back to work.”

As gross as it sounds, this is your job: to prioritize chaos and vomit things into existence…

…it ain’t easy.

Prioritization is to Product Management what dung is to the Dung Beetle. It’s a shitty part of who we are.

We know this because the canonical record contained within the holy Agile institution known as “Mountain Goat Software” states, and I quote, “A Product Manager’s responsibility is to blah blah blah blah blah.” And then there’s some rambling on about the Product Manager’s duty to decide the future of the business in its entirety and if things don’t work out it’s his or her fault…

…on a disappointing side note, there is virtually no information about Mountain Goats at Mountain Goat Software, which would make the site infinitely more valuable.

Clearly no one would willingly volunteer for the blah blah blah part, which explains why most Product Managers have no idea how they got there or who they even are.

“An Italian Fisherman found my body at sea with 2 bullets in my back," a Product Manager recounts his career story. "I had a mysterious key to a lockbox and inside was an application for a job in Product Management.”

“Hmmm," his coworker responds suspiciously. "That sounds an awful lot like the opening scene to Bourne Identity.”

Let’s be real. No one wants this life. Well. Almost no one.

If you are a man or woman with the sole desire of weaseling your way into power, then maybe this prioritizing responsibility sounds enticing. Or hell, if you are a weasel with the sole purpose of becoming a man or woman, anything is possible in today’s society…

…Elizabeth Holmes is probably working on a rodent-to-human prototype as we speak…

…I should invest.


But if you are like most, neither a megalomaniac or a weasel or any combination of the two, then you likely tremble in the face of this Goliath task to prioritize a tech company’s initiatives. It’s one of the weightiest jobs known to humankind…

…just below Navy Seal and just above the guy delivering your Amazon Prime order.

“All we want you to do is take all the feedback from every voice in the market and whittle it down to 3 validated items. Engineers will fail to deliver 2 of them, and everyone’s livelihood is riding on what’s left. Good luck.”

“Uh. Can I get my orientation packet first?”

…it ain’t easy.

The work of prioritizing is done in what is commonly known as the backlog. I think they first called it a backlog because it’s quite literally as burdensome as a log on your back.

“Dude, why are you coming to work with that log on your back?” some co-worker said. “Just let it go.”

“It’s my job to convey the backlog,” the PM said. “I can’t just let it go!”

You have to admit that the backlog is a much funnier word when pictured as a literal log on your back, like the lyrics to one of my favorite songs.

What rolls down stairs
Alone or in pairs,
And over your neighbor's dog?
What's great for a snack,
And fits on your back?
It's log, log, log

It's log, it's log,
It's big, it's heavy, it's wood.
It's log, it's log, it's better than bad, it's good. "

Everyone wants a log
You're gonna love it, log
Come on and get your log
Everyone needs a log
Log log log

But not everyone treats the backlog so flippantly. Although it’s really just a fancy word for a list, Agile Masters, Scrum Coaches, and Mountain Goats try to pretend it’s much more than that, going as far as calling it an artifact, as if it were excavated from a Mayan ruin.

“Behold this perplexing artifact which appears to be a simple list of things,” some archaeologist says as he dusts off a tablet of ancient engravings. “I wonder what it was used for? Perhaps we shall call it THE BACKLOG!”

To be fair I’m sure the Mayans had a backlog of sorts, but you certainly didn’t want to be on the implementation team for one of their stories:

As the god of harvest, I need a human sacrifice, so the lowly villagers can grow crops.

“Who wants this story with a subtask of ‘sacrifice yourself’?” said the Mayan Scrum Master. “Any takers? C'mon. We're a self-organizing team.”

Unfortunately as the experts get more entrenched, the product backlog gets more complicated. What started as a simple to-do list has become a twisted mind maze, the kind where you’re being chased through the snow by an ax-wielding Jack Nicholson…

…the ax in this reference is obviously the rigor of sprint ceremonies.

“Heeeeeere’s Sprint Planning!”

Yep. We’ve all been there. Any of us who have been doing this long enough has had that horrifying feeling on a Monday morning:

“Oh no. Sprint Planning is today. I had 2 weeks to prepare for this, and I mistakenly spent the entire time visiting with customers and discovering market needs. We all know there’s no time for that!”

You then spend 30 minutes cramming some made up garbage into the backlog so engineers can stay busy for a scrum interval.

“Phew. That bought me a couple weeks.”

In many organizations who call themselves Agile, the product backlog has become an entire institutionalized system of coldly calculated WSJF scores, absent of any product whatsoever….

…not to mention passion, life, or joy.

So to add a little fun (if your company allows laughter) copy and paste the following phrase into a text-to-speech reader. https://ttsreader.com/.

“I am the backlog. I live in a world called Jira. If you implement my items in sequential order then I will output something that gets your customers turnt. At least, I think that’s the word all the cool kids are saying these days.”

One thing we can all agree on is that the backlog has an enchanting allure to it. It possesses a bewitching, hypnotic effect.

Whenever a customer or key stakeholder brings up an item that has a snowball’s chance in hell of getting developed, we can utter the magical phrase, “I’ll put it in the backlog”.

And just like that, instant appeasement.

There’s no need to mention that the item is so deep in Jira’s bowels that you’d have to descend into its 9 circles of hell to find it.

There’s no need to mention that the item is so irrelevant that it now exists next to a list of people you want to date in the office.

There’s no need to mention that the primary purpose of a backlog is to fill it with useless items you are never going to get to…


And so now that you know your backlog is likely full of senseless garbage that not even Marty Mcfly’s Delorean could use as fuel, what are Product Managers to do with it?

Hmmm. Would it be shocking to say you let it go? Take the log off your back? After all, it’s just a list, people. Stop trying to turn it into an artifact. Instead, try doing your job: define outcomes, create a list of things you could possibly do, and use it to collaborate with some cool people who care.

Looking back on every successful product I’ve been lucky enough to be involved with, I honestly can’t remember the process, or tools, or backlog organization. What I do remember are the people that learned what the market needed and beat all odds to create something amazing.

I promise there’s no such thing as the perfect sequence of stories, conjured up in that isolated vacuum you call your mind, that is going to output anything that could resemble the word “innovation”.

It’s a team effort, and the people on the team have to care about the product they are building.

So what’s the lesson:

The lesson is that done right, prioritizing the backlog, as it is so called, is just a common sense thing that naturally happens. It starts with a Product and outcomes and then you go from there. With this kind of dumbed down common sense logic, the most important thing is that “the product should create the backlog, not the other way around”…

…now there’s a quotable phrase you can tweet to your social empire.

What I’m really hoping by writing this article is that someday, after you’ve created some really great and meaningful products that resonate with real people, you’ll dust off your old process-driven backlogs and exclaim like the Mayan archeologist did, “Behold this perplexing artifact. I wonder what it was used for.”