I Plan Every New Product Before I Write a Line of Code. Here's What That Actually Looks Like.
Starting a new product used to mean opening an editor. Now it means a scope doc, a broken-down issue list, and a short list of decisions I've already made. Here's the actual process.
For most of my career, starting a new product meant opening an editor. I'd have an idea, get excited, scaffold a project that night, and figure out the rest as I went. Some of those projects became real products. A lot of them stalled somewhere around week three, when the questions I'd skipped at the start came back all at once.
These days nothing gets a repo until it has a plan. Not a pitch deck, not a fifty-page spec. A short, specific set of documents that answers the questions I used to discover the hard way.
Step One: A Scope Doc That Fits on a Few Pages
The first thing I write is a plain description of what the product is, who it's for, and, most importantly, what it isn't. The "what it isn't" section is usually longer than the rest. Every idea I'm excited about but don't need for a first version goes there, so it's written down and I'm not tempted to sneak it in.
If I can't describe the first version in a few pages, it's too big, and I cut before I start rather than halfway through.
Step Two: Lock the Decisions That Would Otherwise Stall Me
Every product has a handful of decisions that, left open, quietly block everything else: the platform, the business model, the one core interaction the whole thing is built around, what free versus paid looks like. I list them, make a call on each, and mark them as locked.
Locked doesn't mean permanent. It means I'm not going to relitigate it every time I sit down to work. Most of my stalled projects weren't stalled on code. They were stalled on a decision I kept reopening.
Step Three: Break It Into Issues Before Day One
Once the scope and decisions are set, I break the first version into actual tasks, each small enough to finish in a sitting or two, ordered so that every step leaves something working. By the time I write code, I'm not deciding what to build next. I'm just building the next thing on the list.
This is the step that changed the most. Starting with a full issue list means a bad day still produces progress, because I don't need a good idea to make headway, just the next item.
What This Costs, and What It Saves
Planning this way means the first few days of a new product produce no code at all, which still feels wrong to the part of me that wants to start building immediately. But the projects I've planned this way get to a real first version faster than the ones I used to start by coding, because I'm not stopping every few days to figure out what the product actually is.
It also makes it much easier to say no to a new product early. If I can't write a scope doc I believe in, that's usually the most useful thing the planning tells me.
The Bottom Line
The code was never the slow part of starting something new. The slow part was all the questions I hadn't answered yet. Planning first doesn't add time to a new product. It moves the hard thinking to the start, where it's cheapest, instead of spreading it across every week of the build.