Prioritizing with a Scarcity Mindset
How my boss introduced me to the re-org stress-test
Was I about to get re-org’d? My manager had just asked me if I would still prioritize this project if I knew my team was about to get re-org’d to focus on something new.
At first it shocked me - he’s my manager - what org changes are executives conjuring up? But this wasn’t a threat, it was more of a mantra: “Prioritize your features like you’re about to get re-org’d”.
My manager was introducing a mindset of building with urgency and clarity. Scarcity of time, of resources and of certainty sharpens focus. It forces you to choose what really matters. And re-orgs aren’t the only source of scarcity. Budget freezes, layoffs and roadmap resets all create moments where priorities get rewritten overnight.
👋 Hey, I’m Alex. I write Shipping on Fridays to explore the craft of how great products get built and what we can learn from the people behind them. I publish 1–2x a month, and every post is meant to be fun, useful, and a little unexpected; from design sprints to sailing races to holiday chaos. If you’re into learning, product or design, this is for you.
A new edge to my prioritization framework
As a PM I already knew I should be consistently prioritizing the work that hits the trifecta of:
Solving the deepest customer problem
Generating the greatest business impact
Costing the least effort
But this re-org framing added a sharp edge: what if you only get to ship one more thing that impacts your OKR? What would it be?
Wait, isn’t this just a scare tactic?
At first, it felt like one: my manager threatening a re-org to force prioritization.
But the truth is, every team has finite resources. And in tech, priorities can shift fast - and sometimes without any warning. To make the most progress against our OKRs, we need to stay ruthlessly focused on the highest impact work and stress-test our roadmaps to keep ourselves honest. Realistically, as PMs, we rarely know when our teams will be pulled in a new direction.
Tell me about a time…
This mantra of scarcity prioritization sunk in a few months ago. My manager and I were reviewing a large new feature that I had broken down into small iterations.
The first iteration was an analytics widget to give customer admins an easy way to understand their platform utilization. My hypothesis: by making it easy for admins to see their utilization, Admins will invite employees at a faster rate.
I excitedly explained that the team would build this fast, delivering incremental, but immediate value to customers even as the next phase of the project was in development.
My manager listened, leaned back and asked me that simple question: “does it pass the re-org test?”
We grabbed a whiteboard and ran a quick RICE analysis: Reach, Impact, Confidence, Effort. This framework is great when you need to strip away emotional attachment and compare ideas apples-to-apples.
We compared the analytics widget to phase two of the project: Access Review, a feature designed to give admins confidence in who had access to what. This was a much bigger blocker to activation and something customers told us kept them up at night. It also was higher effort.
As we talked through the project phases and scored them, it became obvious that the core difference was their potential impact. While it would be fast, my proposed first phase wasn’t going to be very impactful. In contrast, the next phase of the project, Access Review, was directly aimed at increasing customer admin confidence to invite their employees to our platform. Access Review directly hit at the core customer problem - confidence, while the Utilization Widget didn’t actually solve anything for customers.
If we were going to be re-org’d Access Review was the project we should work on. Imagine if we launched the Utilization Widget and then stopped working on Activation? We wouldn’t have actually solved any customer problems.
Lessons Learned:
Push yourself and your team to adopt a scarcity mindset. What would you ship if you could only ship one more thing to impact your goals?
Give those “quick win” projects extra scrutiny. Are they actually wins that will move your core success metric? Or just easy vanity work?
Use frameworks like RICE to strip away bias and make confident calls.
Post Script:
Glad we asked the hard questions. Turns out, it really was our last project focusing on Activation 😉