A customer has been promised a launch date. Engineering needs time to fix a technical issue. The backlog has ten requested features, and everyone has a different view of what “ready” means.
I have seen versions of this situation throughout my work on enterprise applications and e-commerce platforms. The mistake is to begin by arguing about which of the ten features is most important. I begin with a simpler question:
What does the customer actually need to do on launch day?
At Position2, I worked with clients to understand how they operated, map their current processes, and turn those needs into product requirements. I also led teams making technical design and release decisions. That meant I had to see both sides: the customer needed progress, and engineering needed enough room to deliver software that would work.
When a client asked for a broad set of use cases at launch, we would go through the actual workflow. Which use cases would people use immediately? Which were needed before another process could begin? Which could follow a few days later without disrupting the operation?
That conversation often changed the shape of the release. A request for “everything by Friday” became a clear first release, followed by a dated plan for the remaining work.
Four questions behind the decision
I use four questions. They draw on familiar prioritization ideas such as RICE and cost of delay, but they are prompts for a conversation, not a score that makes the decision for us.
1. Who is affected if we wait?
A feature used by everyone on day one is different from one needed by a small group next month. Reach matters, but so does when people need it.
2. What happens if it is missing?
Will orders stop, revenue be delayed, or a team need a manual workaround? This is where the cost of delay becomes real. Sometimes an apparently small integration matters more than a visible feature because the business cannot operate without it.
3. How sure are we?
Are we prioritizing a demonstrated customer need or an assumption? RICE includes confidence for a reason. A supported estimate deserves more weight than a persuasive story with little evidence.
4. What must be true for a safe release?
Engineering effort is not just the time to write code. It includes integration work, testing, security, monitoring, and the ability to recover if something fails. Those are part of the product commitment.
I then put the work into three groups: what is essential for the first release, what can follow on an agreed date, and what needs more discovery. The important part is to make the trade-off visible. Everyone should understand what is included, what is deferred, why, and who will communicate the decision.
A date needs a plan behind it
Prioritization is sometimes described as “saying no.” In my experience, it is often about getting specific enough to say yes to the right scope.
That still requires discipline. If a date has already been promised, the product and engineering leader should confirm what the team can safely deliver. The customer-facing team should then communicate the plan clearly. A smaller release only works when it solves the customer’s immediate problem and nobody is surprised by what remains.
The same thinking applies to technical debt. If an engineering issue could put a core workflow or the release at risk, it cannot be pushed aside simply because a feature has a customer name attached to it. Equally, “we need more time” should lead to a clear explanation of the risk, the options, and the decision.
A framework can help organize the evidence. It cannot replace the conversation with the customer, the judgment of the engineering team, or accountability for the outcome.
The question I return to is: What must work on day one, and what are we prepared to stand behind?
