By Friday afternoon, the evidence can be strong enough to cancel a feature while the organisation still withholds the authority to cancel it. When the person closest to the customer must schedule a meeting so someone farther from the evidence can make the call, the roadmap preserves hierarchy at the expense of runway.
Ama, an invented composite of product leads I have worked alongside, is sitting in a small meeting room in Accra at 4:18 p.m. Her laptop is open to a feature brief covered in comments. Beside it sits a paper cup of coffee she stopped drinking an hour ago.
The proposed feature would let customers build custom approval paths inside a procurement product. Ama has spent the week reviewing support conversations and watching customer calls. The pattern is awkward but clear: customers are struggling with incomplete supplier records before they ever reach the approval stage. Two prospects sounded interested in custom approvals. Neither had agreed to pay for them.
Engineering is due to start on Monday.
Ama knows what the evidence says. Cancel the feature, fix the supplier record problem, and keep the team’s limited build time focused on the point where customers are already getting stuck. Yet the roadmap gives her no clean way to make that decision. Her official next step is to arrange a meeting with the founder, engineering lead and commercial lead.
If the meeting slips, the feature begins. Once it begins, stopping it will look like wasted engineering work rather than avoided product work.
The evidence was ready before the organisation was
Ama’s case has three parts.
First, the current problem appears earlier in the customer journey. A buyer cannot benefit from flexible approval paths when the supplier information entering those paths cannot be trusted.
Second, the feature request carries weak commercial weight. Interest during a sales call can mean curiosity, politeness or a genuine buying condition. Ama has no commitment that separates one from the others.
Third, building the feature creates a cost beyond engineering time. It gives sales another capability to demonstrate, support another workflow to explain, and product another surface to maintain. A feature can survive long after the reason for building it has disappeared.
This resembles the trust problem in Ama’s incomplete supplier record. The visible request sits downstream. The actual weakness begins earlier.
Ama does not need another research task. She needs decision rights that match the work she has already done.
Scheduling the meeting can become a hidden veto
Teams often say product people own the roadmap. The verbs inside the process reveal something else.
Ama may gather evidence, write the recommendation and schedule the review. The founder may approve, reject or postpone. That makes Ama responsible for the quality of the decision while leaving the decision itself elsewhere.
There are sensible reasons to reserve some calls for founders. A feature may affect a signed contract, a regulated workflow, a major positioning change or a commitment that keeps the company alive. Limited runway makes those consequences sharper.
The problem begins when every cancellation receives executive treatment. Continuing becomes the default because code can start without a meeting, while stopping requires calendars to align. Delay quietly votes for the feature.
By 5 p.m., Ama has sent the invitation. One required person cannot attend before engineering begins. The bad ending remains live: developers could spend the first part of the week creating a system no customer has committed to use, while the proven supplier-record problem waits.
She adds a temporary note to the roadmap: “Do not start pending decision.” That sentence buys time. It does not solve the authority gap.
Decision rights need boundaries, evidence and a clock
I would give Ama authority to stop this feature within defined limits.
She can cancel or pause work when the request has no contractual commitment, no regulatory consequence, no demonstrated willingness to pay, and no dependency already promised to a customer. She must attach the evidence and record what would cause the decision to be reconsidered.
Escalation remains necessary when stopping the work threatens revenue already committed, changes the company’s market direction, or creates a material obligation elsewhere. Those are company decisions. A poorly supported feature is a product decision.
The process also needs a clock. If an executive review is required, work should remain paused until the review happens. Otherwise, the organisation rewards attendance problems with engineering expenditure.
This is the same discipline behind protecting a roadmap from attractive distractions. Kofi’s decision to reject work that pulled the product off course shows the commercial side of that tension in why he turned down a derailing contract. Ama faces the internal version: nobody has signed the distraction, but momentum may fund it anyway.
Monday should reflect Friday’s evidence
On Monday morning, Ama changes the feature card from “Ready for development” to “Stopped: insufficient customer evidence.” The engineering lead moves the first task back to the supplier-record problem. The founder reviews Ama’s note later and leaves the decision in place.
The important change is smaller than a reorganisation. Ama now has a written boundary she can use next time. She does not need permission to prevent unsupported work from starting. She needs to show her reasoning, preserve the evidence and escalate only when the consequences cross an agreed line.
Before the next roadmap review, inspect the verbs assigned to the person closest to the customer. If they can research, recommend and arrange, but cannot stop, their ownership ends exactly where runway starts to move.
Comments
No comments yet.