Sean’s voice crackled through the loudspeaker: “Can you hear me?”
“Yes”, muttered the director.
“Look Stacy, no one’s more upset than us. We’re in a tough situation, I know.
The launch should’ve happened a month ago. Everyone’s been working non-stop.”
“Then why didn’t it?” she interrupted.
Sean continued.
“This was supposed to be a quick experiment. Two sprints max.”
“I know!” Stacy’s frustration carried over as if he were in the room.
“But then we needed CRM integration. Product wanted customizable widgets. Compliance had a pile of checks. Engineering guidelines changed mid-stream… And when I tried reducing scope, nothing could be cut from the MVP.
We must decide what’s more important. Either it’s an experiment with rough edges, or it’s a sure bet that we build properly. Moving the goalposts constantly helps nobody.”
—-
Most of us have experienced this conversation.
When everything is a priority, nothing is.
Time is finite. Demand always exceeds capacity. Teams without power to triage effectively won’t be able to deliver—the classic tragedy of the commons.
Some leaders try to avoid the costs of hard choices by saying yes to everything. But this is just kicking the can down the road. Sooner or later, the non-decision will trigger a crisis.
“Passion for excellence”, “Customer first”, “Bias for action”.
Fine principles, but without ruthless prioritization they are nothing more than hollow words, worthless when facing a hard choice.
And in unstructured environments, they become tools of control; swords hanging constantly above people’s heads.
“Bring me a rock—no, not that one.”
For a principle to have value, it must carry a cost:
– User happiness over technical convenience.
– System stability over delivery speed.
Only when these choices are consciously made, and written down, they become useful.
To do this, start by examining your constraints: budget, time, talent, compliance adherence. Anything that you can’t easily get more of.
Which resource is most scarce?
This scarcity is your guide for prioritizing.
Compliment this by understanding what stakeholders actually need (yes, including those “pesky” end users).
What is more important for them?
Finally, consider the classes of deliverables.
Should they all treated equally?
Are there any that can tolerate compromises in the above?
For example:
– Does every experimental feature require the same rigorous test coverage as your core platform?
– Does that quick experiment truly warrant the same legal scrutiny as your flagship product?
– Should the rarely used feature have the same polish as the app’s main flows?
We get in situations like the above, when we assume the answer is “yes” to all such questions.
To avoid it, you must be willing to sacrifice some things for what matters.
It’s simple but not easy. That’s how you get real principles.
references
Photo by bady abbas on Unsplash
Leave a Reply