Some common patterns for prioritization

Everybody loves shortcuts

Intro

Last week I shared some thoughts around prioritization rubrics and how to talk about them in a focusing way. Today I’ll share recurrent patterns that cover may well chosen priorities. These let you shift your mental spotlight to each and ensure you’ve checked the usual suspects. Otherwise you’re prone to being the butt of that old joke about looking for your keys under the convenient streetlight¹.

The one weird trick for your priority rubric

The thing to prioritize is the bottleneck of your system. Where might that be? You can (and should) read the many valuable works of Theory of Constraints (TOC) to help out here. Starting with The Goal, It’s Not Luck, Isn’t it obvious, Goldratt’s Rules of Flow, and more serious (and painfully dense) works such as The Theory of Constraints Handbook. I’ll wait…

Oh, you don’t have time? fair enough, I’ll try to hit some highlights. But they’re all really worth it².

A constraint is what (or who) limits the system from producing more of the goodness you care about. You’ll recognize it because having more capacity at that constraint will result in a lot more of the thing that’s your core goal. Typically, there are components/stages in a system where you might think it would be good to have more capacity. If it’s not the constraint then you can prove to yourself it wouldn’t give you a similar lift in terms of your core outputs.³

It’s especially important that one internalizes that capacity added outside of a system’s bottleneck isn’t super useful. Our natural instinct in a distributed enterprise is to focus on our own efficiency as the top priority. Teams responsible for individual work areas left to their own will almost always work to create more local efficiency in there area. But this is pretty similar to looking for your keys only where there’s light.

Choosing your priority rubric well provides signally across groups what’s truly, truly important. Giving permission and clarity that say, even if your team is responsible for better prediction of clothes to send to people, if the constraint is actual inventory then their most important work should be in anything that assists the team doing inventory selection and placement.

The usual suspects of prioritization

There are a lot of different things one could prioritize. This section provides a little shorthand of are some commonly useful things to prioritize. I’m not saying these are the only things - but once you’re confident in these usual suspects you can bend the rules in specific cases. Mostly though your priorities should focus effort on;

1. Things that make customers happier

2. Things that make these future happy customers aware your product exists

3. Things that make your staff better at driving throughput related to (1) and/or (2). Making the staff more satisfied and more creative is included in this.

Any of these can have positive additions (new feature/change that increases throughout or something customer needs) or positive subtractions (removal of defects in current system that makes your product suck at times).

The phrase “things that” is intentional. Setting priorities on inputs to success that you control is a lot better than focusing on the outputs you want. Regardless of whatever The Secret says.

Once you choose which category you’re in then it’s time to get as specific as possible. There are some examples in the next section below that arguably sounds like an output. Try to figure out what input drives that a result you care about and use that as the priority. Sometimes there’s a bit of gray here. Keep working on reducing it. But don’t obsess to the point of being completely blocked. If you get stuck maybe take a break and take a walk or re-read my bit on goal setting.

Common categories of things to set priorities on

There are patterns in most things, and even if there aren’t our human brains will decide there are anyway. At the risk of falling into that bias I’ll suggest that there are a finite number of prioritization categories⁴. At least in terms of business results. Some top examples of controllable priorities include; reduction of defects, accelerators of throughput/innovation, customer experience, cycle time, and waste/costs.

I’ve expanded on this somewhat below with bullet points representing prioritization categories, and then some examples of each. Most are based in real world experiences so please ask for more details in the comments if it would be helpful.

• Reducing defects - Defects being something that you want to have less of. These could be poor experiences for customers, software failures, manufacturing defects etc. Just a few of examples⁵;

  • inputs to reducing bad customer experiences. Examples include; reducing -order defects, time to publish new prices, late shipments, and unresolved customer service contacts.

  • Rolled back deployments - ie; moments where you deployed software that didn’t quite work right

  • Percent purchase orders handled with zero human touches (no need to correct defects manually before the order arrives on the receive dock).

  • Latency issues that results in customers not staying and shopping.

  • System uptime: defects in availability. Including improved mean time on alarming.

• Throughput: These are priorities to increase the amount of high quality things you produce in a given period of time. That’s a broad statement with some examples below;

  • Amount of work your dev team gets done. I cover this in my reframing of technical debt as a production throughput problem.

  • Issues with your business pipeline. Warning: some of these are more outputs than inputs. In such cases fixing the output could definitely be a clear objective, but you almost certainly need to dig deeper to find the inputs that will drive change - and make those goals and priorities for focus.

    • Top of funnel acquisition numbers/quality

    • Poor conversion (due to expectation mismatch, poor results/value, etc)

    • Thrash - customers not returning/cancelling due to dissatisfaction. The reasons for the dissatisfaction are likely the input defects you want to reduce.

  • Increasing yield of some existing process

    • higher desirable in-stock rate

    • Inputs that drive better return on ad spend.

    • Higher rate of leads that result in a trial, higher number of trials that lead to a paid subscriber.

  • Other things that make your processes more effective/impactful

    • Moving from human to automated decisions. For example percentage of decisions that use an algorithmic input (merchandising)

    • Improving prediction accuracy. For example when you are bidding on something, or dependent on forecasting.⁶

    • More productive time building or otherwise creating value now or in the future. For example reducing the time developers spend responding to internal queries or keeping the lights on.

    • Some constructive engagement metric/feature that results in more daily/monthly usage.⁷

• Customer experience examples

  • Reducing things that piss customers off. ie; defects in delivery, expectations, quality, etc. Yeah, there’s overlap in this framework - more on that at the end.

  • Creating more of something good that makes customers successful (especially in B2B cases). For example if you knew this was important to long term success you might prioritize the % of new clients that make their first marketplace sale in 30 days (or completed carrier load for a freight marketplace).

• Costs/Waste: Lowered costs - reduced spend on X. Somewhat self explanatory in a capitalist society.

  • Cost to move a package through your warehouse.

  • Cloud compute spend.

  • More (or higher value) decisions per operational staff member.

  • Less physical waste (say leftover metal in manufacturing).

• Cycle Time - the time to take something from start to finish. Cycle time improvements that are important to your business are dependent on what you produce. This ranges from feature concept to release (software) to more traditional inventory management problems in supply chain⁸, to how long it takes to setup and run an experiment.

• Specific delivery of something by a date - This one in my experience is less frequently truly critical than one would expect. Meaning needing to complete something by an exact target date or else very bad things happen. There are good reasons for launch time to be the constraint; if you’re shipping new software to support sellers for Christmas then getting it done past October 1st is going to be a miss⁹. Similarly, if you’re at Amazon and everyone needs to work together to launch the entire new website in India, then everyone picking their own arbitrary date just ain’t going to cut it. Much of the time you’re better off focusing on overall throughput.

Last words

This could have been a much longer article - but I’d rather give a basic framework and encourage people to reach out on how to match it to their problem than try to write something truly exhaustive.

There’s obvious overlap in the categories above - I didn’t try to make this framework mutually exclusive. For example less defects in your assembly line (parts not meeting spec) means less rework (time cost) and likely less material costs.

One final word of (someone else’s) wisdom. Don’t be fooled by the efficiency trap. Do not indulge the cost accounting problem of measuring whether some resource (person or machine) is being “utilized 100%.” That’s not your goal. If your robot goes from 100% usage to 45% usage and you make more money that’s not a loss. Maybe in this case you might ask yourself if you really needed that expensive robot in this situation. But don’t use the robot every operating minute just because you sunk a bunch of capital on the purchase.¹⁰

My advice in priority setting: Stay focused on overall throughout in the things that make you money now and in the future. Whether that’s money, happy customers or satisfied employees. All those determine success now and in the future. Few other things matter much when it comes to setting priorities to drive focus. Take the answers you’ve found and write goals + a prioritization rubric. Now you’re truly ready to rumble get shit done.

1. The streetlight effect being a cognitive bias where one tends to work on something convenient even if there are more difficult but almost certainly more fruitful ways of approaching a problem. People, and teams tend to do this all the time without realizing.

It’s often illustrated with a story of a drunk looking for their keys far from where they were list because where they chose to look was conveniently illuminated.

2. I’ll admit though that handbook is super daunting and I’ve had limited luck getting into it myself.

3. A famous example from The Goal is the initial believe that a new robotics system that is 10x faster the prior operators is making the company more productive. But since after installing the robot no more widgets were made and sold than before - this claim is dubious. If the robot’s assembly area was the bottleneck to the factory then having more capacity there would help make more money.

4. At least in terms of business priorities. Life is another matter - though it’s probably true here (maybe; primary physical needs, health, family, personal satisfaction/happiness, actions that minimize future regrets.)

5. I’m available to help folks brainstorm types of defects in their specific problem space. Just drop me a line.

6. Non-intuitive tip. Try to not be dependent on forecasting if your business allows it. Often your product or problem can be reframed to me more resilient to lack of forecasting accuracy than one initially thinks.

7. As long as it’s not pathological/damaging. See Instagram or the Youtube video algorithmic rabbit hole of extreme content for possible negative versions of this priority. Worth re-reading my goals article re: having balancing goals if your priority could have negative consequences.

8. An example from my past was how long it took to label a newly uploaded creator video accurately - which drove how long it could be monetizing on a social media platform.

9. Yes, I know it probably needs to ship earlier than October, I’ve been there. But any date I choose is going to be a bit arbitrarily wrong, so I just pulled 10/1 out of the air.

10. Sorry for using the robot efficiency example twice. But it’s just so darn good. Hopefully our future robot overlords will understand I’m not dissing robots. Just dissing thinking too highly of local efficiencies.