Draw a sharp line around a problem by asking where it shows up and where it doesn't.
Is / Is Not is a two-column table. On the left you record what, where, when and to whom the problem is happening. On the right you record the closest things, places, times and people where it could be happening, but isn't. That second column is the clever part. Most of us describe problems only by their symptoms, never by their limits.
Comparing the columns does two jobs. For a fault or a complaint, it points toward the cause: whatever is special about the “is” side, and missing from the “is not” side, is your best clue. For a project, it sets the scope: what you will work on, and what you deliberately won't.
Use it when something is going wrong and nobody knows why, when a problem seems to be “everywhere”, or when a project's scope keeps growing and you need to agree on what's in and what's out.
Library Wi-Fi: the clue lives in the contrast. Only the back room, only at lunch, only when it's full.
What exactly has the problem, and what similar thing doesn't?
Where does it show up, and where nearby could it show up but doesn't?
When does it happen, and when could it happen but doesn't?
Who experiences it, and who in a similar position doesn't?
How big is it, how many are affected, and is it growing?
What is true of everything on the “is” side, and missing from the “is not” side?
Describing what a problem isn't feels odd at first. It's also one of the fastest ways to stop guessing.
A problem that appears in one room but not the next, or on one shift but not another, is telling you something. The boundary between “is” and “is not” is exactly where the cause tends to be found.
A true explanation has to account for both columns. If a suspected cause would also affect the “is not” side, it's probably wrong. That saves you from expensive fixes based on a hunch.
Facts laid out in two columns are hard to argue with. Instead of debating whose fault it is, people work from a shared, neutral picture of exactly what is happening.
Writing down what you won't tackle is as useful as writing down what you will. A clear “is not” list protects a project from growing until nobody can finish it.
Write a short, factual description at the top: “Checkout fails on the app,” not “The app is broken.” Draw two columns below it, headed Is and Is Not.
Record what, where, when, who and how much the problem affects. Be precise, and stick to what you've seen or measured rather than what you suspect.
For each row, name the closest comparison where the problem could happen but doesn't. The nearer the comparison, the more useful it is: the room next door beats a building across town.
For each row, ask what is special about the Is side. Ask, too, what changed on that side around the time the problem began. List every difference and change you find.
Check each possible cause against every row. A true cause explains why the problem is where it is, and why it isn't where it isn't. Cross out any cause that can't do both.
Check the surviving cause with a small, safe test before rolling out a fix. If you're scoping a project instead, the Is column becomes your brief and the Is Not column its limits.
A whiteboard or page split into two columns, whatever facts you can gather and 20–40 minutes. With AI, use the prompt below to build the table together.
Subject: new-user sign-ups for a fitness app. Goal: find the cause before changing anything. Theories on the table: a competitor's launch, the new pricing page, a seasonal dip.
Is: sign-ups on Android. Is not: sign-ups on iPhone or the website, which held steady.
Is: drop-off at the email-confirmation step. Is not: the pricing and profile screens that come before it.
Is: from the 12th onward. Is not: before the 12th. Android version 4.2 went out on the 11th.
Is: brand-new users. Is not: existing Android users logging in, whose numbers are normal.
Is: about 30% fewer completed sign-ups, flat from day one. Is not: a slow, gradual decline.
Only Android, only email confirmation, only since 4.2. The update changed how links open, so confirmation links now land in a browser instead of the app.
A competitor's launch, the pricing page and the season would all have hit iPhone and web sign-ups too, so all three theories were crossed out. A one-day fix to Android link handling brought sign-ups back within a week.
Is / Is Not depends on discipline: precise facts, close comparisons and honest testing of every theory. AI makes a useful partner. It asks for the comparison you forgot, notices when an entry is vague, and checks each suspected cause against every row. You bring the facts and decide what to check next.
Let AI ask for the missing “is not” in each row.
Here's my Is column. For each row, ask me for the closest place, time or group where it could happen but doesn't.
Ask what is unique to the “is” side.
Compare my two columns. List everything that is true of the Is side but not of the Is Not side.
Test each suspected cause against every row.
Test these causes against my table. For each, which rows does it explain and which can't it? [list causes]
Use the same table to agree on what a project will and won't cover.
Help me write an Is / Is Not scope for my project: what's included, and what we're deliberately leaving out.
Describe the problem and what you've observed, then copy the prompt into any AI assistant. In coach mode the AI builds the table with you one row at a time, asks for the closest “is not” in each row, then helps you find the clue and test your theories.
The “Open in” links put the prompt in the web address. If your challenge includes anything sensitive, copy and paste instead.
After the session, click one to copy it, then paste it into the same chat.