The salary increase covered more than a wider role. It paid for choosing which executive promise the team would break, then carrying that decision into the next meeting.
At 9:18 on her first Monday, Abena sat in a small Accra office with a cold coffee beside her laptop and four coloured labels across the product roadmap. This is an illustrative composite, but the conflict is familiar. Sales had promised a reporting feature to a prospect. Operations needed an internal dashboard before the next delivery cycle. The chief executive wanted an AI assistant ready for a partner demonstration. Engineering had already committed the month to fixing onboarding failures.
By Friday, one of those commitments would have to move. Abena’s new title was Product Operations Lead. Her first real assignment was to decide who would leave the room disappointed.
Four promises cannot share one deadline
Abena had spent the previous year designing interfaces. Her work began after a product decision had enough shape to become a screen: who needed it, what they were trying to do, and which path mattered most.
The roadmap she inherited contained none of that certainty.
Each item looked reasonable in isolation. The sales request could help close revenue. The operations dashboard could reduce manual work. The AI demonstration might create a new partnership. The onboarding repairs could stop new accounts from failing before they reached the product’s useful moment.
The conflict sat between the rows. Each executive had treated a different outcome as fixed, and the roadmap had preserved all four assumptions without forcing anyone to reconcile them.
This happens easily in a small company. A prospect asks for something during a promising call. A founder says, “We should be able to do that.” Someone adds it to the roadmap. Three weeks later, the sentence has hardened into a commitment, even though nobody removed anything else.
A roadmap built this way records organisational pressure. It does not make a product decision.
The role changed when she asked what failure cost
Abena’s design instinct was to clarify the requirements. Her operations responsibility required a harder question: what happens if this does not ship now?
She opened a plain document and gave each request the same four lines:
- Who had received the promise?
- What specific event depended on it?
- What evidence showed the deadline was real?
- What would the team stop doing to deliver it?
The answers changed the order.
The sales feature was attached to an interested prospect, but no signed agreement required it. The operations dashboard would save repeated manual work, although the current process could survive another cycle. The AI demonstration had a fixed meeting, but the partner needed evidence of a credible workflow rather than a finished assistant.
The onboarding failures were already affecting people trying to enter the product. Engineering also understood the fault well enough to repair it without opening a second architecture project.
That made the decision clearer. Keep the onboarding work. Build a narrow demonstration around the existing workflow. Move the reporting feature and dashboard out of the current month.
Clear did not mean comfortable.
The sales lead had already described the reporting feature as upcoming. Operations had planned around the dashboard. The chief executive still wanted the AI concept to feel substantial. Abena had reduced the technical uncertainty while concentrating the political cost on herself.
That was the work hidden inside the promotion.
A decision needs an owner and a consequence
On Thursday afternoon, Abena put one page on the meeting-room screen. It showed the two commitments the team could deliver, the two it would move, and the consequence of each choice.
She avoided a weighted scoring model. Scores can make a disputed assumption look settled. Instead, she wrote the trade plainly: accepting the reporting request would delay an onboarding repair tied to current failures. Expanding the AI demonstration would consume engineering time without proving more about the partner’s demand.
For several seconds, nobody spoke.
The sales lead challenged the moved date. The chief executive asked whether the demonstration would look too limited. Either objection could have returned the team to four priorities and no decision. Abena kept the discussion on consequences: which current commitment should be displaced, and who would tell the affected person?
Nobody proposed removing the onboarding repair.
The roadmap changed before the meeting ended. More importantly, the promises changed with it. Sales would reset the prospect’s expectation. Operations would continue the manual process temporarily. The partner demonstration would show one working path, with the unfinished parts named.
A similar boundary appears when a product designer moves into operations. The useful trial is rarely whether they can maintain a board or run a meeting. It is whether they can expose competing commitments before the team spends scarce runway on all of them. I explored that transition more directly in what a four-week product-operations trial revealed.
The roadmap became a record of choices
On the following Monday, Abena opened the roadmap again. The coloured labels remained, but every active item now had a named decision owner, a displaced alternative, and the next event that could justify reconsideration.
The document looked less ambitious. It was also more honest.
That honesty matters in a startup with limited runway. Two credible requests can pull one team toward two different products, especially when each request comes with a plausible commercial story. Kojo faced that tension with two signed pilots. The danger begins when plausible stories enter the roadmap as simultaneous obligations.
Abena’s salary increase made sense by the end of that first week. She was no longer being paid mainly to improve the product’s interface. She was being paid to make conflict visible early enough for the company to choose, while there was still time to disappoint someone without disappointing everyone.
Before your next roadmap meeting, take the top three items and write down what each one displaces. If nobody can name the displaced work, the decision has not been made yet.
Comments
No comments yet.