How to Run Discovery and Delivery as One Person

How to run discovery and delivery as one person: give discovery a protected share of your time, keep it on its own list with its own clock, write down when an idea graduates to building, and check both streams monthly. Protection beats method.

How to run discovery and delivery as one person

Start with the bad news. You can't do this by feel.

If discovery is something you do when you have time, you won't do it. There is never time. That isn't a temporary condition that clears after the next release. It's permanent. Something more urgent always turns up, and building always looks more urgent than learning.

So the whole job is protection. The method is the easy part. Four decisions made once, then a monthly look at whether they held.

Most people who give this up gave it up because one of those decisions was never made. Not because the practice failed. Because it never had walls.

Decision one: both tracks are yours, permanently

Ignore what team-based advice says about handoffs. You don't have a research group to hand anything to.

What you have is a quieter version of the same problem. You tell yourself discovery comes after the building is done. The building is never done. So discovery never starts, and you've recreated a split team inside one head, with one half permanently unemployed.

Say it out loud once: neither track stops for the other. Silly? Perhaps. It works anyway, because the version of you at ten o'clock on a Thursday needs something to point at.

Free guide · 21 pagesDiscovery and delivery, one person.The Dual-Track Playbook: how to keep discovering while you keep building.Get the free guide →

Decision two: put assumptions in discovery, features in building

Keep two lists. This is the cheapest structural move you can make.

Discovery items are questions or risks. "Will people complete setup without help?" "Does anyone want this at a price?" Build items are things that already earned their evidence. "Build the new onboarding" belongs on the second list, and only after the first list gave it a pass.

Why separate? Because a discovery list full of pre-decided features is a build list with a slower approval process. It produces exactly the confirmations you went looking for. Start from the risk, never from the thing you already want to build.

Separate lists also fix a smaller problem. Discovery items on a task list look overdue all the time, because they run on a different clock. Some resolve in an evening, some take a month. Put them in the same list as build tasks and you'll feel like you're failing at them. You aren't. They're behaving normally.

Decision three: protect a share of your time and name it

Pick a share. The number matters less than the fact that it exists.

Then plan around it, write it in the calendar, and decide in advance what happens when you feel behind. Because you will. That moment is the real test. The discovery block will be the first thing you want to sacrifice, which is exactly why the rule has to exist before the moment arrives.

Notice the last row. Protection works in both directions. Discovery also needs a limit, because it always feels responsible to learn a little more. Timebox every question before you start, a few days or a week, and make a decision at the end. Even if the decision is "I still don't know, and here is the one thing I'll test next."

Decision four: the rule for graduating

You need a clear answer to one question. When have I learned enough to build?

Without an answer, one of two things happens. Everything graduates, and the discovery track becomes a formality. Or nothing does, and you pile up well-researched ideas that never ship.

Write the rule down. Not because it's complicated, but because in the moment you'll be arguing with yourself, and the version of you that wants to build usually wins. If you never defined what validated means, the bar quietly moves to wherever your wish already was.

When something does graduate, it moves across with four lines. What you assumed. What you tested. What you found. What's still uncertain, and what outcome you expect. That's not a specification. It's a note to the person who'll build it in three weeks, who is you, and who will have forgotten why.

What discovery and delivery look like on a Monday

Open two lists. The first holds questions. Pick the one that would hurt most if you were wrong, and book the smallest test that could change your mind. Give it a date.

The second holds work that already earned its place. Pick from the top and build.

Somewhere in the week, talk to a couple of real people who match the customer you want. Not whoever is easiest to reach. Write four lines afterwards: what you asked, what you did, what you found, what you decided. That's the entire machine. It takes minutes to maintain and it is the only memory a one-person business has.

You'll feel slower for about a month. After that you'll notice you've stopped building things you'd have regretted.

Free assessmentHow trapped are you, really?Take the Corporate Suffocation Index, the free solopreneur readiness assessment.Take the assessment →

Keep the build side fed without rushing the learning

Here's a practical tension. Building needs a steady supply of validated work. Discovery can't deliver on a schedule, because questions don't resolve on demand.

The answer is a small buffer. Enough validated work queued that you're never stuck waiting. Not so much that you're approving things just to fill the queue.

When the buffer runs dry, what do you do? Not lower the bar. That turns the whole thing back into a feature factory with extra ceremony. Pick up maintenance or an improvement you already know is good. Boring, honest, and it keeps the standard where you set it.

Watch for starvation, monthly

Each track can starve the other, and neither announces it.

Discovery starves when build pressure absorbs everything. The symptom is a list of items with no evidence behind them and no answer to what outcome they serve.

Building starves when discovery gets precious about certainty. The symptom is shipping slowing while the notes pile up.

Both are gradual. Both feel perfectly reasonable at every single step. So don't rely on feel. Once a month, ask two questions: what did discovery decide, and what did I ship? Two months in a row blank on either side is your signal.

If it's discovery that's blank, you've probably been drifting back into building only. The cheapest fix is to find the one risk that scares you most. That's what finding your riskiest assumption is for. If it's building that's blank, check whether you're learning or hiding. Conversations are more comfortable than shipping, and that preference is a trap pointed straight at you.

Do not turn the boundary into a ritual

One last failure, and it's a sneaky one.

The handoff gains a template. Then a checklist. Then a process. Soon dual track is a waterfall with new vocabulary, performed by one person for an audience of nobody.

Keep the boundary light. Four lines and a decision. If graduating an item takes longer than running a small test, the process has become the point, and you'll quietly drop it within two months.

Free guide · 21 pagesDiscovery and delivery, one person.The Dual-Track Playbook: how to keep discovering while you keep building.Get the free guide →

Close the loop after you ship

The cycle isn't over when something ships. Check whether the outcome you predicted actually moved, on a date you set in advance.

This is the step almost nobody does, and it's the one that builds your judgment. Skip it and you never learn whether your calls are any good. That's the difference between ten years of experience and one year repeated ten times.

Once a cycle, spend half an hour on the reasoning rather than the output. Which assumptions were wrong? Where were you overconfident? Which tests changed a decision, and which were theatre? We cover that review properly in how to review what you shipped.

Free assessmentHow trapped are you, really?Take the Corporate Suffocation Index, the free solopreneur readiness assessment.Take the assessment →

Frequently asked questions

How much time should discovery get?

Name a share and protect it. The right number matters less than having one that's written down and defended when you feel behind. Unprotected time is unallocated time, and it goes to whatever feels most urgent.

Should discovery items sit on my build list?

No. They run on a different clock, so they look permanently overdue next to build tasks. Keep a separate list of questions and risks, and keep features off it.

What if I run out of validated work to build?

Take maintenance or a known improvement. Don't lower the bar to fill the queue, because that rebuilds the feature factory you were trying to leave.

How do I know discovery and delivery are slipping?

Ask what discovery decided and what you shipped. Two consecutive months blank on either side means that track is starving and your discovery and delivery balance has slipped.

The full method, with the checklists, is in The Dual-Track Playbook, a free 21-page playbook.