The 31% customer, the bespoke EDI feed, and a Product Goal nobody is funding
Your company sells dispatch software to regional freight carriers. The Product Goal agreed six months ago: 'a dispatcher can re-plan a disrupted route in under 90 seconds.' Twelve discovery interviews with mid-market carriers keep naming the same blocker - they will not switch without a public API for their own TMS integrations. Meanwhile your largest customer, 31% of ARR with renewal in seven weeks, says it will not renew unless you build multi-currency invoicing and a bespoke EDI 214 feed. Only 4 of your 130 customers bill in more than one currency. The CEO's instruction to you is: 'Keep them. Do whatever it takes.' The team is nine Developers on two-week Sprints; the next two Sprints are already committed to the re-planning work. The API exists only as a two-year-old epic nobody has refined. Sales has already told the customer it is 'definitely in the next release'.
1. How do you decide whether the customer's request jumps the backlog? Show your analysis, not just your conclusion.
Read the worked answer
First, split the request - it is two different things wearing one coat.
- Multi-currency invoicing is generalisable. It serves 4 of 130 customers today, but the large-carrier segment you are moving toward is exactly where it appears. It is a must-be quality element for that segment, not a delighter.
- A bespoke EDI 214 feed serves one customer and creates a permanent maintenance obligation in a format that is not your product. That is not a feature; it is a custom integration with a lifetime cost.
Second, weigh cost of delay. Twelve interviews name the public API as the switching blocker for the segment the Product Goal targets. The API is the highest-cost-of-delay item you have evidence for. The renewal is high-cost, high-certainty and short-fuse. Both can be true; that is what makes this a judgement call rather than a lookup.
Third, test alternatives before accepting the premise. The EDI 214 is a shipment-status feed. A public API plus an integration partner may satisfy it at a fraction of the lifetime cost - and it is the same API the segment is asking for. Explore: a partner-built connector, a paid custom integration funded by the account, or a contractual commitment from a third party.
Fourth, know which decision is yours. You order the Product Backlog. Pricing, contract terms and accepting the loss of 31% of ARR are management decisions, and they need the analysis above, not a unilateral call from you. Present three options with consequences rather than a verdict.
2. Sales has promised the customer it is 'in the next release', and the renewal is in seven weeks. What do you do about the promise and the relationship?
Read the worked answer
Correct the record, then rebuild it deliberately.
- Talk to the customer directly, with account management present. Not to contradict Sales in public, but because the Product Owner is the person who can actually discuss what is possible and when. A renewal conversation built on a promise nobody can keep is worse than an honest conversation seven weeks out.
- Probe the need behind the ask. Ask what breaks today without the EDI 214 feed and what the multi-currency requirement is really solving - settlement accuracy, carrier reconciliation, or a finance-team workaround. Requirements stated as solutions often have cheaper satisfiers, and this is exactly where a bespoke feed turns into a configurable export plus an API.
- Offer a legitimate commitment. A written statement of intent with a date range, contingent on the ordering decision, plus a short-term manual workaround and a paid pilot for the custom integration. That is something you can defend in the Sprint Review.
- Fix the pattern, not just the incident. Publish the Product Backlog and the current forecast where Sales can see them, and agree that release commitments come from you. Stakeholders who cannot see the queue will invent one.
Model the values. Openness about what is and is not committed, courage to have the conversation with the largest account, and respect for Sales' pressure without letting it become the ordering mechanism.
3. The CEO overrules you and orders the bespoke EDI feed into the next Sprint. What do you do?
Read the worked answer
Accept the constraint, control the damage, keep the consequences visible.
- The CEO can set business priorities; the Sprint Goal is still negotiated by the Scrum Team. You cannot let a directive become a Sprint Goal the Developers have not agreed to. Bring it to Sprint Planning as a high-priority backlog item, and agree with the Developers a coherent Sprint Goal that the work actually serves - or explicitly re-plan what the next two Sprints were committed to.
- Be explicit about what is displaced. The re-planning work the team committed to slips; the Product Goal slips with it; the API - your best-evidenced segment bet - moves further out. Write that down and put it in front of the CEO and the steering group, with dates.
- Quarantine the bespoke work. Describe it as a customer-specific integration with acceptance criteria, and consider a separately funded workstream or a distinct area of the Product Backlog so it does not silently re-prioritise the core product every Sprint. Charge the account for the lifetime maintenance, or at least cost it.
- Either revise the Product Goal or defend it. If one customer's integration now outranks 're-plan a disrupted route in 90 seconds', the Product Goal is no longer true and should be changed deliberately. A Product Goal that survives only on paper is worse than none.
- Instrument it. Track the maintenance hours the feed consumes over the next two quarters and bring the data to the next renewal conversation. That is how a one-off becomes a decision rather than a precedent.