Short answer
Find out exactly what was promised and by when, then cut it to the smallest version that keeps the promise. Ship that in pieces, so the customer sees progress every week, and give the work its own stream so the rest of the roadmap keeps moving.
First, find out what was actually promised
“We’ll have SSO” can mean anything from one sign-in button to a full enterprise identity setup. Before anyone writes code, get three things in writing from whoever sold it:
- The exact words. What’s in the contract, the proposal or the email thread.
- The date. Is it a go-live date, a renewal date or just “soon”?
- What done looks like to the customer. Which identity provider they use, who needs to sign in, and what their IT team will check.
A short call with the customer’s technical contact often shrinks the job by half. They usually want one thing working properly, not every option on the market.
Cut it to the smallest version that keeps the promise
Big features sit in a backlog for months because nobody can see where to start. Break them into releases that are useful on their own. Two common examples:
| Release | Single sign-on | Audit logs |
|---|---|---|
| 1 | Sign in through the customer’s own identity provider | Record sign-ins and permission changes |
| 2 | Create user accounts automatically on first sign-in | Show the log to admins in the app |
| 3 | Let an organisation require SSO and turn off passwords | Filter and export the log |
| 4 | Settings screen so customers can set it up themselves | Record changes to key records |
Release 1 alone often satisfies the contract. The rest can follow on the normal roadmap. How to write each piece as a request.
Show progress every week
A customer waiting on a feature is far more patient when they can see it coming. Send a short note each Friday: what shipped, what’s next, and anything you need from them, such as test accounts or a contact in their IT team. Small releases make this easy, because there’s always something real to report.
Don’t pull your best people off the roadmap
The instinct is to put your strongest developer on it until it’s done. That stalls everything else, and the next deal will need something from the roadmap you’ve just paused. Give the sold feature its own stream of work, run one piece at a time until it’s finished, and leave the rest of the team where they are.
Stop it happening again
- Sales can promise a feature, but not a date, without someone technical agreeing it.
- Keep a short “sold, not built” list, and review it in the same meeting as the roadmap.
- Write down what was promised at the time, in the customer’s words.
None of this means saying no to sales. Features that win deals are good features. The aim is to know about them before the contract is signed.
How we help
On a subscription, the sold feature goes into your queue, broken into releases that ship one after another, with senior review on each. Our track works on it while your team stays on the roadmap, and you can show the customer real progress every week. How we work with stretched CTOs.
Questions
How long does single sign-on take to build?
It depends on the product and what was promised. A first release that lets one customer sign in through their own identity provider is often a matter of days to a couple of weeks. The full set of options takes longer, which is why we split it up.
Should we tell the customer it will be late?
Tell them early and specifically. A clear plan with weekly releases lands much better than a missed date with no warning.
Can you work on it while our team stays on the roadmap?
Yes. That’s the usual setup: the sold feature goes on our track and your developers keep the roadmap.