Problem and Solution Slides: Show the Customer’s Work Before and After

The strongest problem-and-solution slide does not begin with the problem. It begins with the work.

Not “operations are inefficient.” A task. Someone, on some trigger, trying to reach a result. The slide earns its comparison by showing how that work currently gets done — workarounds included — and then naming the one step your product changes. Everything else stays in place.

The example below is fictional. It is a teaching illustration, not a customer case, and it makes no claim about how common this workflow is or how much faster anything becomes.

Start with a task someone is trying to complete

A coordinator at a mid-sized company receives an equipment request from a project lead. The trigger is a project phase that needs a specific machine for a specific window. The coordinator is responsible for the answer. The result the project lead needs is simple: a confirmed booking, or a clear no, with enough lead time to plan around it.

That is bounded enough to draw. A broad complaint — "scheduling is chaotic" — gives you nothing to compare later. A task gives you a before and an after.

Decide where the account comes from, and say so on the slide or in your notes. If you observed this workflow with a real customer, you can put their actual steps on the page, with their permission and their details. If you are illustrating, label it as an illustration, as this one is. A real observed task grounds one slide about one organization. It does not establish that every organization works this way. Keep your language at the scale of your evidence.

Show why the existing process is reasonable enough to exist

The coordinator opens the request, checks a shared calendar, and messages the equipment owner: is the machine free for this window? Sometimes the calendar and the owner disagree, because the owner knows about a maintenance slot that never made it onto the calendar. Sometimes the owner is out, and the coordinator waits. When the answer comes back, the coordinator replies to the project lead and updates the calendar entry so the next request reflects reality.

Nobody designed this to be bad. The calendar gives everyone a shared view. The owner's confirmation exists because the owner is the only person who knows the machine's real condition. The coordinator's reply to the project lead keeps one person accountable for the answer.

This is what April Dunford's positioning advice treats as the alternative your explanation has to account for — not just a competing product, but the customer's existing way of handling the problem (Positioning and Competition). The current manual process is not an absence waiting to be filled. It is a system someone built out of the tools they had.

Find the friction inside that system rather than around it. A shared calendar is not a problem by itself. Neither is the gap between the calendar and what the owner actually knows — the record and reality can drift apart, so someone has to ask, and that double-check stays in the after version. The friction the tool will address is narrower: the request arrives in one place and the bookings sit in another, so the coordinator carries the window between them by hand before there is anything to ask the owner. That lookup is the step a comparison can later change. "Manual process" as a phrase tells the reader nothing they can judge.

Place the product inside the same workflow

The proposed tool centralizes the request and the current booking record into one place. A project lead submits a request; the coordinator sees it alongside the existing bookings; the record and the request now live together.

What the tool does not do, in this fictional depiction, is remove the equipment owner's approval. The owner still confirms. The maintenance slot still gets resolved by a conversation, because the tool's booking record only knows what someone has entered, and the owner still knows things the record does not.

So the intervention is precise: the coordinator no longer has to reconcile two sources by hand before asking the owner, because the request and the booking record are in the same view. The owner's confirmation, the coordinator's reply to the project lead, and the update that keeps the record honest all remain.

If you skip the owner's approval to make the after look cleaner, you have not simplified the workflow. You have misrepresented it, and a reader who knows the operation will notice. Say plainly what your product does today versus what it is proposed to do, and describe actions a reader could watch happen rather than benefits you have not measured.

Make the comparison answer a reader question

Now the two versions, side by side. Same request, same window, same people.

Before:

1. Project lead sends a request to the coordinator.
2. Coordinator checks the shared calendar for the window.
3. Coordinator messages the equipment owner to confirm.
4. Owner checks the machine's real condition and replies.
5. Coordinator replies to the project lead.
6. Coordinator updates the calendar entry.

After (proposed):

1. Project lead submits the request through the tool, which shows current bookings.
2. Coordinator sees the request beside the booking record and messages the owner to confirm.
3. Owner checks the machine's real condition and replies.
4. Coordinator marks the booking and replies to the project lead.

Steps 3 and 4 in the before become steps 2 and 3 in the after, unchanged in substance. The other before steps fold into their neighbours rather than vanishing. Checking the shared calendar stops being a step of its own: in the after, the booking record arrives in view beside the request, so there is nothing separate to open. Before steps 5 and 6 become after step 4, one step instead of two, because the reply and the record now sit in the same place. The coordinator still marks the booking — the update has been relocated, not absorbed. Nor has the tool absorbed the owner. It introduces one new requirement: the project lead now submits through the tool instead of sending a message, which is itself a change someone has to adopt.

That last point is the qualification the slide must carry. Every proposed change adds something, even when it removes something else. If the after column is all subtraction, the reader has grounds to distrust it.

One page works here because the lists share a shape and a reader can run their eye down the numbers. If the before had three exceptions and the after had two, or if the two processes diverged for a stretch, a paired view would become a puzzle. Split them across two pages, keep the same labels and the same level of detail, and let each page be readable on its own. The format follows the comparison's needs; the labels don't dictate a fixed number of slides.

What remains, and what you are asking the reader to believe

After the change, the equipment owner still confirms every booking. The exception that sent the coordinator to the owner — a maintenance slot the record did not know about — still sends the coordinator to the owner. That conversation is not friction to be eliminated; it is where the record gets corrected. A tool that erased it would be a tool that quietly decided the record is always right.

What changed is where the coordinator looks first, and where the booking record lives. One separate lookup gone, one record update moved into the same view, one new submission habit attached. The reader can now judge it: does that trade — one new submission habit against one fewer separate lookup for the coordinator — look worth it in their own operation?

That is the question the slide should leave open. Not "isn't this better," but "is this the step you would change." A reader who can answer that has understood your product's place in the work. Anything larger — the market, the transformation, the end of scheduling problems — is a claim the comparison has not yet earned.

Frequently asked questions

Where should a problem-and-solution slide begin?

It should begin with the work: a task someone performs on a trigger to reach a result. A broad complaint like operations are inefficient gives nothing to compare later, while a bounded task gives a before and an after.

Why show the existing process as reasonable?

The current process is a system built from available tools, not an absence waiting to be filled. A shared calendar and the owner’s confirmation exist for reasons; the friction to address should be narrow, such as a lookup carried by hand, not manual process in general.

What should the after column preserve?

It should keep the equipment owner’s approval, the exception that corrects the record, and the move that marks the booking. Every proposed change adds something too, such as a new submission habit, so an after column that is all subtraction gives the reader grounds to distrust it.

When should the comparison be split across two pages?

If the before has three exceptions and the after has two, or if the processes diverge for a stretch, a paired view becomes a puzzle. Split them, keep the same labels and same level of detail, and let each page be readable on its own.

What should the slide ask the reader to judge?

It should leave open whether the trade is worth it in their own operation: is this the step they would change? Larger claims about the market or transformation are not earned by the comparison. The slide should also label whether the workflow is observed or an illustration.

Further reading

• Explain an Approved Product Change to the People Who Must Work With It — After the comparison is accepted, this shows how to announce the switch to the people who must work with it, keeping fixed choices separate from open arrangements.
• Choose a Product Difference the Buyer Can Actually Use — When the one changed step needs a sharper claim, this separates capability, task, comparison and consequence so the difference rests on conditions you can actually name.