Imagine this: you come back from a week-long vacation and work through your backlog of emails. One of them stands out. It’s from your supervisor, describing a new project from an internal customer you’ve never worked with before. A scoping meeting has been set for that afternoon.
You walk in. The customer doesn’t waste any time. His organization can’t do their job. It’s taking three times longer than the budget allows. His team has trouble performing even the basic parts of their work. The error rate exceeds 25%. He wants a new training program — something comprehensive, something that will teach his people how to do their jobs efficiently and effectively and get that error rate down.
He’s already decided what the solution is. He came in with a conclusion.
Here’s the question you need to ask before you agree to anything: What does success look like to you?
Not “what training do you need?” Not “what topics should we cover?” Not “what format do you want?” Those questions accept the premise that training is already the right answer. This one doesn’t.
Why That Question Changes Everything
When you ask someone what success looks like, you force them to define the outcome they actually care about — not the solution they’ve already decided on. And the answer almost always reveals something the original request was hiding.
In this scenario, the customer says success looks like his team completing tasks in the time the budget allows, with an error rate under 5%. That’s a measurable outcome. That’s something you can actually design toward. And more importantly, it opens the door to the question that needs to follow immediately: how do we know the problem is a knowledge or skill gap?
Because here’s what the customer hasn’t told you yet: why is it taking three times too long? Why is the error rate at 25%? He has a conclusion — his team doesn’t know how to do their jobs — but he doesn’t have evidence for it. And “my team is performing poorly” is not the same thing as “my team needs training.”
There are a dozen reasons a team might be underperforming that have nothing to do with knowledge or skill. The process they’re following might be broken. The tools they’re using might be inadequate. The documentation might be outdated, missing, or written by someone who assumed the reader already knew what they were doing. There might be a staffing shortage that means everyone is operating at capacity before they’ve finished onboarding. There might be a systemic issue upstream that sends bad inputs into their workflow and guarantees errors on the other end regardless of how skilled the person handling it is.
Training cannot fix any of those things. A new course on how to do the job will not repair a broken process, replace a missing tool, or staff a team that is already stretched past its limits. What it will do is consume weeks of development time, hours of your team’s time, and a training budget — and then, when the error rate stays at 25%, someone will say the training didn’t work.
The training didn’t fail. It was never the right solution.
What “What Does Success Look Like” Actually Does
That one question reframes the entire conversation. Instead of starting with a solution and working backward to justify it, you’re starting with an outcome and working forward to find what will actually achieve it.
It also signals something important to the client: you are not an order-taker. You are a professional who is trying to solve their actual problem, not just build what they asked for. Most clients, once they understand that distinction, appreciate it. A few will push back — they came in with a solution and they want someone to execute it. That’s a conversation worth having directly rather than just complying.
When you get the answer to what success looks like, the next question is straightforward: what do we know about why the gap exists? Not what do we assume — what do we actually know? That’s where the needs analysis begins. Not with a course outline, not with a storyboard, not with a list of learning objectives. With evidence.
In this scenario, a proper analysis might reveal that the team actually knows how to do the job — they’ve done it before, they can describe the process accurately, and the errors aren’t random. They cluster around one specific step in the workflow where the documentation is ambiguous and the tool they’re using behaves inconsistently. That’s not a training problem. That’s a documentation and tool problem that a job aid and an IT ticket will solve faster and cheaper than any course ever could.
Or it might reveal that there genuinely is a knowledge gap — that the team is newer than the customer implied, that the onboarding process was compressed, and that several critical steps were never formally taught. In that case, training is the right answer. But now you’re building it with clear outcomes, clear evidence, and a clear definition of what success looks like when you’re done.
The Question Is Simple. The Discipline to Ask It Is Not.
It is easier to just take the project. Say yes, schedule the kickoff, start on the storyboard. The customer is happy, your calendar is full, and everyone moves forward with the comfortable illusion that something is being done.
The problem is that something being done and the right thing being done are not the same thing. And when the training ships and the error rate doesn’t move, the question that follows is rarely “did we solve the right problem?” It’s “why didn’t the training work?” — and that’s a much harder conversation to have after the fact than before it.
Ask what success looks like. Ask it in every scoping meeting, for every project, from every client. Ask it before you open a new Storyline file, before you write a single learning objective, before you agree on a timeline or a budget. Ask it as if the answer matters — because it does.
The answer will tell you whether you’re about to build something that solves a real problem, or something that makes a client feel like a problem is being addressed. Those are not the same thing, and only one of them is worth your time.