Here's the situation I was trying to fix.
Twenty posts in, I had a method. Test a workflow against real constraints, measure what changed, document it, and only then decide whether it could become an offer. It worked. But it was scattered across twenty pieces, and I kept meeting people who had the same problem I'd started with: a list of ideas and no filter.
So this is the filter, written down in one place. It's the closing post, and it's meant to be the thing you come back to—the test you run on every future idea, including the ones this site hasn't written about yet.
The Problem This Test Solves
Every idea arrives with the same energy. That's the trap.
A new tool, a new workflow, a new offer idea, a new platform—they all feel promising on the day you find them. The feeling is not a signal. The test exists to convert the feeling into evidence, cheaply, before you spend a month on it.
Three failure modes it's designed to catch:
Building things that never ship. The system gets refined forever and never shown to anyone.
Shipping things that were never tested. The offer gets made before the workflow was proven.
Testing things that don't matter. The workflow gets measured beautifully and produces nothing anyone would pay for.
The test has four gates. Every idea passes through all four. Any gate can end it—and an early ending is a success, not a failure.
The Four Gates
Gate 1: Does It Fix Something Real?
The first gate is the simplest and the one most often skipped.
The test: Can you describe the problem in the words of someone who has it? Not your words—theirs. A real person, describing a real frustration, in a real situation.
If you can't, you don't have a problem yet. You have an interest. Interests are fine; they're just not testable. The first gate converts an interest into a problem statement.
What fails here: ideas that sound useful in the abstract. "AI could help people with X" is not a problem statement. "My colleague spends two hours every Friday cleaning up the report before sending it" is.
What passing looks like: one specific person, one specific task, one specific cost—time, money, or annoyance.
Gate 2: Can You Build the Smallest Version?
The second gate is about scope discipline.
The test: describe the smallest version that would count as a real test. Not the full product. Not the ideal system. The smallest thing that would produce evidence.
For a workflow: the smallest version is one run on real data. For an offer: the smallest version is one conversation with one buyer. For a product: the smallest version is a rough draft someone can react to.
If you can't describe the smallest version, the idea is still too vague. Vagueness is the most common reason ideas die slowly—they never get small enough to test.
What fails here: ideas that require the whole thing to exist before any of it can be evaluated.
What passing looks like: a version you could build in a single session, with a defined output.
Gate 3: Does the Test Change Anything?
The third gate is the one that separates testing from pretending.
The test: before you run it, write down what you'd do differently depending on the outcome. If every possible result leads to the same next step, the test isn't a test—it's a ritual.
For a workflow: if the measurement comes back "saves two hours a week," do you keep it? If it comes back "saves ten minutes and adds maintenance," do you delete it? Both answers have to be pre-written.
For an offer: if one person says they'd pay, what's next? If nobody does, what's next? If the answers are the same, you're not testing—you're collecting reassurance.
What fails here: tests designed to confirm rather than inform.
What passing looks like: a clear, pre-written decision rule for each plausible outcome.
Gate 4: Does It Earn Its Place?
The fourth gate is the ongoing one. It doesn't end at the first test—it recurs.
The test: after the workflow has been running, the offer has been live, or the product has shipped, ask the maintenance question. Does it cost less than it returns—in time, attention, and energy?
This is the gate that keeps the system honest over months, not just weeks. Everything passes in week one. The question is what survives month three.
What fails here: systems that worked initially and now quietly cost more than they return. The meeting notes system that nobody reads. The automation whose maintenance exceeds the task.
What passing looks like: a workflow you'd rebuild if you lost it, an offer you'd make again at the same price, a product that still earns its keep.
How the Gates Interact
The order matters, and it's not arbitrary.
Gate 1 filters for relevance. No real problem, no test.
Gate 2 filters for scope. No smallest version, no test.
Gate 3 filters for honesty. No decision rule, no test.
Gate 4 filters for durability. No earning its place, no keep.
You can fail at any gate and the right move is to stop—not to push harder. An idea that fails Gate 1 isn't a bad idea; it's just not ready. An idea that fails Gate 2 needs more definition, not more effort. An idea that fails Gate 3 will produce noise, not information. An idea that fails Gate 4 isn't a failure—it's a completed experiment with a negative result, which is the most useful kind.
Applying the Test to the Twenty Posts
The test isn't theoretical. It's the shape of everything on this site. A few examples:
The Friday report workflow. Gate 1: a real recurring task with a real cost. Gate 2: one run on real data. Gate 3: keep if it saves more than it maintains, delete if not. Gate 4: still running, still saving.
The inbox triage system. Gate 1: a real decision cost. Gate 2: three layers, built in stages. Gate 3: the decision rule was written before the test. Gate 4: failed—the full system cost more than it returned, and was cut back to the parts that earned their place. That post is a Gate 4 failure reported honestly, and it's more useful than a success story.
The resume rebuild. Gate 1: a real problem with a real deadline. Gate 2: three bullets, not a full rewrite. Gate 3: the decision rule was "keep if defensible in an interview." Gate 4: the method is still in use.
The two-hour Saturday test. Gates 1 through 3 applied to the idea of an offer, in two hours, with a decision rule written in advance.
Every post is one of these four gates, run on one idea. The site is the test, applied repeatedly.
What Still Needs You
The parts of the test that can't be automated:
Writing the problem in someone else's words. Only you can know whether you're describing a real frustration or a projected one. The model can help you draft; it can't tell you if it's true.
Choosing the smallest version. Deciding what counts as a real test is a judgment about your own standards. Too small and it proves nothing; too large and it never happens.
Writing the decision rule honestly. This is the hardest part, because it means pre-committing to a result you might not like. The model can suggest decision rules; only you can mean them.
Running the Gate 4 check on schedule. The durability question is the one that gets skipped, because it asks you to admit something you built isn't working. That's a human discipline, not a process.
Stopping. Every gate ends with the option to stop. Taking it, early and without drama, is the skill the whole test is designed to teach.
The model can help you draft, build, and measure. You decide what's real, what's small enough, what you'd do differently, and what deserves to stay.
The One-Idea Version
If you have an idea right now:
Gate 1: Write the problem in the words of the person who has it. One sentence. If you can't, stop.
Gate 2: Write the smallest version that would count as a test. One session. If you can't, stop.
Gate 3: Write what you'd do differently for each plausible outcome. If the answer is the same for all of them, stop.
Gate 4: Set a date—two weeks, a month—to ask whether it's earning its place. Write the question down now.
Four sentences. One idea. The test doesn't tell you whether the idea is good. It tells you whether it's testable, cheaply, before you spend a month on it.
The Closing
This site started with a claim: better work first, more options next. Twenty posts later, the claim holds, and it's narrower than it sounds.
Better work first means the job you have is the test environment, not the problem. Every workflow starts there, under real constraints—a full-time job, a family, limited energy—and proves itself before it's recommended.
More options next means the offer comes after the proof, not before. A tested workflow can become a service, a package, a template. It only earns the right to be sold if it earned its place first.
And the closing line—make the workflow earn its place—is the whole test in five words. It's the filter for every future idea, the standard for every system already running, and the reason this site deletes as much as it publishes.
The workflow isn't the goal. The judgment about which workflows deserve to stay is the goal. That judgment is yours, and now you have a test for it.
Better work first. More options next.
Make the workflow earn its place.
No feedback yet — submit the first.