Three asks are almost never three requirements
A list of features arriving from an account under strain is a compressed account of something else, and the first job is decompression. Each item was written by someone with a problem, and the feature is their guess at a solution. Until you know the problem you cannot judge whether the ask is the only route to it, and you certainly cannot decide what a no would cost.
So take each one and work backwards to the business outcome and the person who owns it. What can they not do today. What are they doing instead, and what does that cost them in time, error rate, or headcount. Who inside their organisation is unhappy about it, and is that person the same one who signs the renewal. That last question matters more than candidates expect: a request that came from a frustrated analyst and a request that came from the sponsor's own board commitment look identical in a ticket and are entirely different commercial facts.
Two of the three usually change shape under this treatment. One turns out to be satisfiable with configuration, a report, or a piece of work on the customer's side that nobody had thought of. One turns out to be a preference — a workflow they liked in a previous tool — which is real but survivable. And one is genuinely blocking a funded outcome, which is the one you should spend your credibility on.
| The ask as written | The outcome behind it | What it really is |
|---|
| Bulk edit in the UI | Month-end corrections finished inside the close window | Solvable now via the API and a script |
| Custom approval chains | Auditor demands two named approvers per change | Genuine blocker with a compliance deadline |
| Dark mode in the console | The previous tool had it and people liked it | Preference, no business consequence |
Putting it in that shape is also the most persuasive single artefact you can hand a product manager, because it converts an angry list into three separately decidable items with evidence attached.
Going to product without spending the revenue number
The temptation is to walk in with the contract value and the renewal date and let those do the arguing. It works occasionally and it degrades quickly, because a team that has been moved by account size once expects the same lever next quarter, and every other customer-facing colleague has learned to pull it too. Roadmaps steered entirely by whoever is loudest at renewal serve nobody, including the accounts doing the shouting, since those are the same roadmaps that never ship anything hard.
What travels better is evidence about the shape of the problem. How many other accounts have asked for this, and how similar were their versions of it. Whether the request is a segment characteristic — regulated industries needing dual approval is a market fact, not one customer's taste. What the workaround costs in support load and in professional services hours. Whether the absence of the capability was already visible in lost deals. Bring the renewal risk as one input among those, stated once, plainly, and then let the case stand on its merits.
Ask product a precise question, too. Not "can we build this" but "is this in the plan, could it be, or is it a no", and if it could be, what would have to move and who owns that trade. Vague asks receive vague answers, and a vague answer is the thing you cannot use.
The honest no, and why it is worth more than a maybe
Sometimes the answer is that the feature is not coming — not this year, and possibly never, because it contradicts the product's direction or serves a segment the company has decided not to chase. Delivering that is the part of the job most candidates avoid, and the avoidance is what actually loses accounts. A maybe left open until renewal removes the customer's ability to plan. They cannot buy a point solution, cannot brief their auditor, cannot resource a workaround, and they eventually discover the truth at the worst possible moment and conclude they were managed rather than told.
A no has four parts, and the missing one is nearly always the third.
1. The decision, unhedged.
"Custom approval chains are not on the roadmap for the next twelve months.
I asked directly and I want you to have the real answer rather than a maybe."
2. The reason, at the level you are allowed to give.
"The team is committed to the permissions rework through Q3, and this
depends on it. Building it before that lands would mean building it twice."
3. What you will do instead, with a named owner and a date.
"Two of your three are addressable now. I will have the bulk-correction
script working against your sandbox by the 14th, and I have asked for the
approval-log export you can hand your auditor as an interim control."
4. What happens if the situation changes, and when you will next speak.
"If the permissions work lands early I will tell you the week it does.
Either way we review this together in January, before your notice window."
The third part is what converts a no into something a customer can act on. Without it you have delivered bad news and left; with it you have delivered bad news and a plan, which is what a supplier is for. And the fourth part matters because the credibility you are protecting is not this conversation's, it is next year's.
Do not go around your own product organisation
Two failure modes destroy trust internally, and interviewers listen for both. The first is committing on product's behalf — a date, a quarter, even a hopeful "I think that is coming soon" — because when it slips, the customer's complaint is not that the feature is late but that you misled them, and you cannot recover from that with a second explanation. The second is the reverse: relaying product's answer verbatim with no interpretation, which leaves the customer to conclude their supplier has nobody thinking about their business.
The position to hold is that you own the customer's understanding of the situation and product owns the plan. You can be completely transparent about what you know and completely disciplined about what you do not promise, and doing both at once is precisely the skill being tested.
What separates a strong answer here
Weak answers optimise for keeping the conversation pleasant, which in practice means deferring the hard sentence and hoping the roadmap changes. Strong answers accept that the account may leave and still tell the truth on a timeline that lets the customer act — and they say clearly which of the three asks they judged worth fighting for internally, and why the other two were not. An interviewer is watching for whether you can hold a commercial risk and an honest position in the same hand, because that is the whole of the job at this level.
A dated no lets a customer plan around you; an undated maybe only lets them discover, later, that you knew.
© 2026 Preptima. Originally published at preptima.com (opens in a new tab).