Prioritizing Prioritization for Product Designers
A question that I often get asked when my students hit Module 12 of my Object-Oriented UX Masterclass is:
“Shouldn’t the Prioritization Round come before the detailed work of the Requirements Round? Why not do all the trimming first, and then focus the detailed work on what’s left over?”
Valid.
This question comes up after the series of deep dive activities that make up the mind-melting Requirements Round of the ORCA Process (and if you aren’t familiar with the ORCA Process, you might want to back up to this 10-minute article first).
During the official second round, we go deep — it’s actually a ton of writing.
During the O (objects) of the Requirements Round, we write an Object Guide, which is a structured, hyped-up glossary of objects.
During the R (relationships) of the Requirements Round, we examine all of our nested objects through the lens of My Cat Saving Fire Department. That’s a mnemonic (duh) for mechanics, cardinality, sort, filter, and dependency.
During the C (calls-to-action) of the Requirements Round, we expand our Discovery CTA Matrix to create object-oriented user stories by articulating the why and when for each CTA.
And finally, during the A (attributes) of the Requirements Round, we add attributes to our objects: documenting if an attribute is required, its data source, any conditional logic, privacy and permissions, and more.
It’s a lot of work. Valuable, rigorous work that saves so much time in the long run — but when you are in the thick of it, it can be overwhelming, especially when you are new to the ORCA Process.
And then comes the Prioritization Round.
Objects are eliminated, offloaded, combined, or downgraded to metadata. This creates a chain reaction:
No object, no nested objects for that object.
No object, no CTAs on that object.
And of course, no object, no attributes for that object.
Os, Rs, Cs, and As (along with all those detailed requirements) are either moved to a future phase, flagged for research validation, or eliminated altogether. What’s left is a simple system that will provide a solid foundation for future growth (not a patchwork, guessed-at set of “features”).
Gloriously, the Object Map and CTA Matrix shrinks down to a manageable short-term scope for design and development.
OOUXers typically love this part of the process. Except for the fact that sometimes as much as two-thirds of all that hard Requirements Round work gets put on the chopping block. Err, filtered out.
So I get it. Why not prioritize first and then only run the remaining Os, Rs, Cs, and As, through the rigor of the Requirements Round? It’s a totally fair argument.
The ORCA purist in me answers with this:
You need to get the best possible understanding of the things you are prioritizing before you prioritize them. If you prioritize first, you will inevitably be doing it with less insight than you would be if you’d first gone through the pain — er, preparation — of the Requirements Round.
But then there is the realist in me who knows what a struggle it can be getting a single day of OOUX Discovery on a teams’ schedule.
And when I look at how I actually teach and practice the ORCA Process, I often flip Prioritization and Requirements Rounds. In my Advanced OOUX Workshops, we focus on Discovery activities, then we go through a quick round of Prioritization so that we can end the day with sketching. We don’t even touch the advanced moves in Requirements until day 2.
When constructing my one-week ORCA Sprint Outline, only a few Requirements Round activities made the cut. Prioritization (all the “Survivor” activities) on the other hand is a keystone part of every day. (Here’s the ORCA Sprint Outline in Notion and here’s the podcast episode where I explain it.)
And while working on the millionth iteration of the ORCA Handbook (coming sooooooon!), I decided to move up the Prioritization Round. Part 2 became Part 3. Part 3 became Part 2. This created more editing work and delayed our launch of this awesome eBook even more — but it helped us create a more succinct book! Focusing the Requirements techniques on fewer objects helped keep the book under 200 pages.
So here’s the deal. If you don’t have a ton of time, you need to invest significant time in chipping away everything that doesn’t look like your most focused solution.
“It is easy. You just chip away the stone that doesn’t look like David.”
-allegedly Michelangelo on his process.
So your ORCA process might actually look like this:
Or even like this:
Yes, ORCA is a tried and true meat grinder of a process. The canonical version will always place the Requirements Round before the Prioritization Round. That’s how it will continue to be taught in the OOUX Masterclass and I will continue to push you and my clients to make time and space for this deep work. You’ll save time in the long run and build better products if you carry the clarity of the Requirements Round with you into Prioritization and design.
But the best processes are flexible and remixable. They provide value even when used just a little and/or out of “order.”
ORCA has an out-of-the-box configuration that you can reference if you are stuck asking “what do we do next?” But you know your project, timeline, team, and budget better than the ORCA Process. If you are pressed for time, bring Prioritization forward. If you are a beginner, just focus on the Discovery Round and sketching — and, seriously, leave the rest. But whatever you do, please keep your objects on blue, your metadata on pink, your core content on yellow, and your CTAs on green! K, thx!
Let me know in the comments — how have you remixed the ORCA process?
