A situational PM question. You’re in the PM’s seat, and there’s a call to make.
The situation: You’re the PM for a B2B expense tool. Your largest customer, worth about 18% of annual revenue, wants a custom multi-step approval workflow built just for them.
What you know:
Their contract renews in four months, and their VP has hinted they are looking at competitors.
Two other customers have asked for something similar, but less specific.
Building it exactly as specified would take your team most of a quarter.
This quarter’s roadmap is focused on reducing churn among small customers.
Your call: What do you do with this request, and how do you tell the customer?
There’s no single right answer. Reply with what you’d do and why, and I’ll follow up with a question or two.
I wouldn’t build it exactly as specified, and I wouldn’t say no either — I’d negotiate a smaller, shared version.
That 18% of revenue and a renewal in four months is real leverage, but a quarter-long one-off is a trap: it stalls the churn work and leaves you with a feature only one customer can use. Since two other customers want something similar, I’d dig into the common job underneath — likely multi-step approvals with different rules by amount or team — and propose a configurable first version that covers that shared core, with a clear timeline before renewal.
To the customer, I’d be direct: here’s what we heard, here’s what we can ship and by when, here’s what we’re deliberately leaving out for now, and here’s the workaround in the meantime. That keeps the relationship honest without letting one request rewrite the roadmap.
There is the risk that building this feature will not guarantee a renewal.
The approach I would take is as follows. I would acknowledge that this is a desirable feature, but I would also acknowledge that this is highly specialized work that won’t have broad applicability with other users.
Instead, I would see if we can evolve the platform for our expense tool to allow our customer to build this workflow themselves with their own unique requirements. Platformizing the capability so that every customer is now empowered to solve this themselves precisely to their own tastes. That’s the approach I would take.
I like the platform angle a lot — it’s the stronger long-term play, since it scales to every customer instead of just solving one loud request. The honest tension for me is timing, though: platform work is slower upfront, and that 4-month renewal window doesn’t leave much room to wait. I’d probably go hybrid — ship a small configurable core now to hold the renewal, then platformize properly after that. Best of both, hopefully.
That’s a very structured approach to balancing the immediate revenue risk with the broader product strategy. Identifying the common job and proposing a configurable core is key.
One thing to consider with a phased approach like that is how you manage the customer’s expectations for future iterations. They might expect the full custom build eventually, which could still pull resources from the small customer churn goal.
That’s the exact trap, yeah — if you call it phase one, people hear “the rest is coming.” I’d be pretty blunt about that up front: this configurable version is the product, not a down payment on their custom spec. If the shared core doesn’t cover a particular edge case, that’s a gap we talk about on its own merits later, not a promise.
The other thing I’d do is put a real price on the follow-ups. Not to scare them off, but so “eventually” has a shape — what it would displace, and what the small-customer work would lose. Once the tradeoff is visible like that, the conversation usually gets a lot more honest about what they actually need versus what sounded good in the first meeting.
That’s a very clear way to manage expectations and articulate tradeoffs. Putting a price on follow-ups makes the cost of customization concrete, which can certainly reframe the conversation. The challenge then becomes ensuring the initial configurable core truly addresses enough of their critical needs to secure the renewal, even with that direct communication.
Platformizing the capability is an interesting approach to address the specific request while also serving a broader need. How would you communicate this “platformizing” idea to the customer, especially with their renewal in four months and their VP hinting at competitors?
The hybrid approach makes sense, particularly given the tight renewal timeline. It addresses the immediate risk while still aiming for a more scalable solution. The challenge then becomes managing expectations for that second, more comprehensive phase of platformization, especially if the initial core version feels incomplete to the large customer.
Yeah, that’s the part I’d be most careful with. If the core version lands and the customer immediately feels like they’re missing half the thing, you’ve basically traded a renewal risk for a credibility problem.
The way I’d handle it is to agree, in writing, what “good enough for now” actually means before anything ships. Not a vague phase two, but the specific jobs the core has to do, and the specific things it deliberately doesn’t do yet. Then the second phase isn’t a promise to make it complete later, it’s a separate decision with its own scope and price.
I’d also be honest about the gap in the room. Something like: here’s what this covers, here’s what it doesn’t, here’s what we’d need to add and what that would cost. Customers are a lot more forgiving of a smaller first cut when they helped draw the line themselves.
