Target condition: describe what solved looks like

A fix can fail for a boring reason: nobody wrote down what "fixed" means. A target condition is a short, concrete description of what solved looks like, set before you start changing things. This guide shows you how to write one, how it differs from a goal, and how to keep the gap between where you are and where you want to be visible while you work. You will leave with a template and examples you can copy today.

What a target condition is and why it comes before the fix

A target condition describes a future state you can observe. It says how things will work, measured or checked in a way you could confirm in a few minutes. It does not say how you will get there.

The Lean Enterprise Institute's page on problem solving describes it as "identifying and closing gaps between current and target conditions," and says the problem, the target condition and the causes should be based on verifiable facts, not assumptions. It also treats a plan as a theory of what will address the cause, which you then test.

It comes first because a fix without a target has no finish line. You try something, it feels a little better, and you move on. Two weeks later the problem is back and you cannot tell whether your fix did anything. With a target written down, every attempt gets judged against the same line. Either the state you described is true, or it is not.

Writing it first also slows you down in a useful way. It is tempting to jump to solutions. Describing the end state forces you to look at the problem long enough to understand it.

Target condition vs. goal vs. current condition: the key differences

These three terms get mixed up, so here they are side by side.

• Current condition: how things actually work right now, with numbers or observations. "Invoices are paid 45 days after sending, on average."
• Target condition: how things should work at a set point in the near future, described just as concretely. "By the end of next month, the average invoice is paid within 30 days."
• Goal: the broader direction or reason. "Healthier cash flow." A goal can stay vague because it points the way. A target condition cannot.

The gap between current and target is the actual problem you are working on. The goal tells you why the gap matters. If you only have a goal, you have a wish. If you only have a current condition, you have a complaint. You need both ends of the gap.

How to describe what solved looks like: a step-by-step template

Use this sequence. It takes about ten minutes.

1. Write the current condition in one sentence. Use a number, a count, or an observation someone else could repeat. "I start studying at 10 p.m. and stop after 40 minutes."
2. Name what you will observe when it is solved. Ask: if a stranger watched for a day, what would they see? "I start at 7 p.m. and finish a 90 minute session four nights a week."
3. Add a date. A target with no date drifts. Pick something close enough that you will check it.
4. Add how you will check. A calendar log, a spreadsheet column, a weekly count. If you cannot say how you would check it, the target is still too vague.
5. Strip out the method. If your sentence contains "by using" or "by switching to," cut that part. Methods are solutions, and they go somewhere else.
6. Read it aloud. Could two people disagree about whether it is true? If yes, tighten the wording.

The finished template reads like this: "By [date], [observable state], checked by [method]. Currently: [current state]."

Target condition examples for work, teams, and personal projects

Work

Current: "Support replies take two days on average." Target: "By 1 December, 80 percent of support emails get a first reply within 24 hours, checked from the inbox report every Friday."

Teams

Current: "Weekly meetings run 75 minutes and end without decisions." Target: "By the end of the quarter, the weekly meeting ends in 45 minutes with every open item either decided or assigned an owner, recorded in the meeting notes."

Personal projects

Current: "I reread notes the night before exams and blank on pathway questions." Target: "Two weeks before the exam, I can draw each major pathway from memory with no more than one error, tested every Sunday."

Notice what is missing from all three: any mention of software, scripts, flashcards, or new rules. Those come later, as solutions you try against the target.

Common mistakes that make a target condition vague or untestable

• Feelings instead of observations. "The team feels less stressed" cannot be checked. "No one works past 7 p.m. more than once a week" can.
• Hiding a solution inside the target. "We use a new ticket system" is a method. If you adopt it and replies are still slow, you met the target and kept the problem.
• No current condition. Without a starting number, you cannot tell how big the gap is or whether you moved.
• A target years away. Distant targets are goals in disguise. You will not check them until it is too late to learn.
• Too many measures. Five numbers means five arguments about which one counts. One or two is enough.

Mapping the gap between current and target condition with a problem graph

A target condition is only useful if you keep looking at it while you try things. A to-do list can bury it. This is where Problem Graph fits: it is a personal problem and solution journal drawn as a map, so the problem, your attempts, and their outcomes sit on one screen.

Here is a worked example using the invoice problem.

1. Write the gap as the problem line. One line is enough, so make it carry both ends: Invoices paid in 45 days, target 30 days by 30 Nov. Put it in the work lane and press Enter. It lands on the graph right away.
2. Attach solutions as ideas. "Send invoice the same day work ends." "Add a reminder email at day 21." "Offer a small early payment discount." Each one is a solution node attached to the problem.
3. Mark what you are trying. Pick one or two and mark them as the ones you are trying. Leave the rest as ideas.
4. Record the outcome against your target. When you check at month end, mark each attempt as worked, partly, or failed. "Same day invoicing" might move the average to 38 days. That is partly, not worked, because your target said 30.
5. Link related problems. If you notice late payments tie to a separate problem, say "Scope changes not written down," link the two. You can link across lanes too, so a work problem can connect to a personal one like sleep or workload. Patterns show up on a map that a list hides.

The invoice example on the graph. A made-up business, not a real user or result.

The target is what keeps step four honest. Without it, 38 days would feel like a win. With it, you know you are partway there and need another attempt. A failed solution also stays on the map as failed, which is exactly what you or anyone else needs to know before trying it again.

When you run out of ideas, you can ask the app for suggestions. The AI proposes new solutions grounded in what worked for others on similar problems. Treat each one as a proposal to test against your target, not as an answer.

For team targets, mark the problem as a main node and share it into a private network. You create the network, give the invite code to the people involved, and they see the main node along with its solutions, outcomes, and requirements. Anyone with the code can join, so give it only to the people you mean. Your other problems stay private, which is the default.

Frequently asked questions

How specific should a target condition be?

Specific enough that two people would agree on whether it is true after a quick check. That usually means one number or observable behavior, a date, and a way to verify it.

How far out should a target condition be set?

Close enough that you will actually check it, often one week to three months. Longer horizons belong to the goal, with a series of nearer target conditions along the way.

Can a target condition change once work starts?

Yes, if you learn the original target was wrong, such as finding the current condition was measured badly. Write the new target down and note why it changed, rather than quietly moving the line to match your results.

Who should agree on the target condition before changes begin?

Everyone who will do the work or live with the result. Talking to them one at a time before the group meeting helps, an approach described in our post on nemawashi, getting agreement before you change something.

Get started

Pick one problem that has been nagging you. Write the current condition and the target condition in a single line, with a date. Then attach the first solution you will try and decide now how you will check the outcome.

You can open the app and press "Load example set" to see how problems, solutions, and outcomes look on the map before you add your own. It runs in your web browser and works on your phone.

Try Problem Graph: it is free, and you can look around the public network without an account. Write one problem down in a line and attach the first thing you will try.