Part 2 — You're Running a Project. Your Customer Bought an Outcome.
Ask most post-sale teams how the implementation went and you'll get a project answer. On time. In scope. All milestones closed. Customer signed off.
Then the renewal comes around and the customer isn't sure what they got.
This is the most common mistake in post-sale, and it's easy to miss because nothing went wrong. The project succeeded. The outcome never showed up.
Two different definitions of "done"
A project is done when the work is delivered. Environments configured, users provisioned, integrations live, training complete.
An outcome is done when something changed in the customer's business. Cases closed faster. Fewer trucks rolled. A report that used to take a week now takes an hour.
Your plan tracks the first one. Your customer's boss asks about the second one.
That gap is where renewals get decided. A deployment your team is proud of can still leave the customer unable to answer the only question that matters internally: was this worth it?
Why we default to the project: Because the project is the part we control.
Tasks, dates, and owners are concrete. We can staff them, report on them, and close them. The outcome depends on the customer's process, their people, and their willingness to change how they work — none of which appears on a Gantt chart.
So we optimize what we can see. The deployment becomes the goal instead of the vehicle, and a launch date quietly replaces a business result.
The question that changes the route, Early in every engagement, ask this and keep asking it:
"Six months from now, what has to be true for you to tell your leadership this was worth it?"
Then listen for three things:
The metric they'll be judged on. Not "better visibility" — the actual number, and where it sits today.
Who has to believe it. The person who will ask them to justify the spend. What has to change in how their team works. The behavior shift the outcome depends on, and who owns it on their side.
If you can't get specific answers, you don't yet have an outcome. You have a deployment with optimism attached.
Run the project inside the outcome You don't stop running projects. You subordinate them.
Write the outcome at the top of the plan, with a baseline number and a target. Every workstream ties back to it or gets cut. Sequence for first value, not for completeness. Get one team to a real result early rather than every team to a configured state at once. Add the customer's milestones to your plan — their internal review, their budget cycle, the board update where your impact gets mentioned or doesn't. Track evidence, not just status. By the time you reach the renewal conversation, the proof should already exist, in their numbers, not in your slides. Define go-live as value achieved. If "live" means logins are working, you've just declared victory at the starting line. The check that costs you nothing Look at your largest active implementation and try to state its outcome in one sentence with a number in it.
If you can't — or if three people on the account would say it differently — your route is aimed at the wrong destination, and you still have time to fix it.
The project is how you get there. It was never where you were going.
Next in the series: the team that bought you often isn't the team that renews you — and what to do about it before the renewal is on the line.
Want to see where your route breaks? Take the free 2-minute assessment, then book a full post-sale assessment with our team. Lets help you fix it.
