We Kept Trying to Plan Everything

We started with a vibe-coded prototype and wanted to turn it into a product. It was tempting to look at what was already on the screen and start planning everything it would take to finish it.

One: trying to plan the whole product

We broke the prototype down into modules, defined personas, and tried to work through what each part of the product needed to do. We wanted to go the full way, from the people who would use it to the work needed to build it.

It was too much. We used AI to help write the documentation, and the docs became long and difficult to read. Generating another section was easy. Understanding the plan we were asking everyone to follow was getting harder. We eventually put together guidance on AI-assisted documentation, but the immediate problem was that we were trying to describe too much before we had learned enough.

The planning itself was monthly: set a goal for the month, then check in halfway through. Our product docs and our plans lived in Notion. That arrangement worked reasonably well for a while. We had something to aim at and a point in the middle of the month to see how we were doing.

Two: two weeks, with the work in GitHub

Then we started working towards onboarding our design partners and got access to real data. Things were very different from the tidy world of the prototype. We needed to find out whether what we were building worked with what our partners actually had, and we needed those answers sooner than the end of the month.

We moved to two-week planning cycles. That gave us a more frequent point to check what we had learned and adjust the next piece of work. The monthly plan had helped us get started; working with real data gave us a reason to shorten it.

We also started questioning where the plan lived. The product docs and planning were in Notion, but the engineering work happened in GitHub. We were maintaining a picture of the work in one place while doing it in another.

There was no shortage of project-planning tools we could have chosen. I didn't want us to boil the ocean finding one. The engineers liked GitHub. They already tracked their work there and spent their day there. It made sense to bring planning closer to that work.

So we started using GitHub Projects, with milestones and goals inside them. Product documentation stayed in Notion. We moved the delivery plan to where the engineers would use it, without asking everyone to adopt another tool.

That did not automatically make the board reliable. Goals still needed to connect to the work, and someone had to keep them current. I also built a dashboard only I opened, which was a reminder that another view of the work could not make people maintain the information behind it. But the reason for using GitHub was sound: the plan belonged close to the work it was supposed to guide.

Three: trying to plan three months to launch

Once we had our design partners, we started preparing for a public launch. We wanted to work out the whole three months leading up to it. After shortening the cycle to learn from real data, we were back to trying to plan a long stretch in detail.

It was painful. There were meetings, plans, and more meetings to work through the plans. We ended up with three iterations of the goals before we had something useful.

The first came from the founders, again with AI helping us write them. We then took them to the engineers, and the next version became too technical. By the time I worked through the third version, I was trying to balance the intent from the founders with what the engineers knew it would take, and make the goals describe outcomes.

I needed to be able to read a goal and understand what would be different when it was finished. The technical work mattered, but listing it did not explain the result we were committing to. Equally, a goal from the founders needed enough grounding for an engineer to question it and work out how to deliver it. I was trying to get both into the same description.

Trying to settle the whole three months that way failed. We spent too much time working on the plan, and the goals still needed repeated rewriting. In a retro, someone wrote, “I find planning confusing”. It got more votes than any other suggestion for improvement. By then I could hardly be surprised.

Four: agree the direction, then shape the next goals

We still work towards projects that run for two or three months. The change is how much we expect to decide at the start. We agree the outcomes we want, group the goals into milestones, and choose what deserves attention next. We don't need a finished specification for every goal before we can have that conversation.

A proposed goal can start with a clear title and the milestone it belongs to. Listing it is not a promise to deliver it. In monthly planning, we review priorities, overlaps and dependencies, then select the next goals to shape. Detailed solution discussions happen afterwards, with the people responsible for that goal.

That is where the Owner and Sponsor roles help. The Sponsor brings the customer context, the intended outcome and the questions we need to answer. The Owner works through the approach with them and takes responsibility for delivery. They are different people, and they shape the goal together. Changes to scope go back to the Sponsor.

They agree the requirements, boundaries, approach and what a finished result would look like. The description can be a few lines when the goal is simple. A more complicated goal needs enough detail for the people doing it to agree what they are taking on. We no longer ask a room full of people to finish all of that during the planning meeting.

Once the written plan and dependencies are agreed, the goal is ready for the backlog. It can start when its Owner has capacity, without waiting for another meeting. Each Owner can have at most three goals in progress. The GitHub project tracks milestones and goals; it does not need to contain every daily task. Those goals do need to stay current.

The meetings have a clearer purpose too. Stand-ups three times a week cover progress, blockers and decisions. A weekly all-hands gives people a place to demo shipped work and discuss milestone progress. Monthly planning chooses priorities and the next goals to shape. Monthly direction no longer means writing a detailed month of work in advance.

This gives me a more useful way to help when someone is stuck. We can look at the outcome they are trying to deliver and the decision they need, then bring in the Sponsor or another owner. The latest rules are still new. What we have now is an agreed way to reach those decisions without making every engineer wait for me or another planning session.

What I would start with now

If I were doing this again, I would keep the monthly direction, the shorter validation cycle and the plan close to the engineering work. I would also bring the founder and engineer into shaping the same goal from the beginning. We spent too much time passing different versions of the plan between them.

This is the planning framework I would start with:

1. Agree the outcome for the next stage. For the next two or three months, name the customer or business outcome and the constraints that matter. Keep later goals as short proposals. A prototype is enough to start asking what needs validating; it is a weak basis for specifying every module of the finished product.

2. Choose the next goals, then shape them together. Use monthly planning to agree priorities, dependencies and what can wait. Work through the selected goals afterwards with the people responsible for them. The person bringing customer context and the engineer delivering the result need to reach the same understanding before the work starts.

3. Make ownership and the next decision clear. Give the goal an Owner for delivery and a Sponsor for product context and scope. These are responsibilities people on the team take on. Keep active work small enough that they can follow it through; our limit of three goals in progress per Owner is a ceiling, not a target.

4. Check against reality within two weeks. That is where I would start for a team onboarding its first customers, and sooner when a question can be answered sooner. Bring real data, a customer response or a working result to an existing check-in or demo. Decide whether to continue, change the approach or stop. A longer goal can still produce something useful to examine along the way.

5. Keep one current view of delivery. GitHub suited us because the engineers already worked there. I would choose wherever the team actually maintains its work, keep outcomes, owners and blockers visible, and link to supporting context. When a priority changes, update that view and agree what gets delayed or dropped.

For a goal we are about to shape, I would use a short starting template:

• Outcome: Who should be able to do what?
• Why now: Why does this deserve attention ahead of the other goals?
• Evidence: What would show us that it works, and which assumptions need checking?
• Owner and Sponsor: Who owns delivery, and who supplies the context and agrees scope?
• Boundaries: What is included, excluded or dependent on other work?
• Next check: When will we look at the result and decide what happens next?

I would fill that in with the person doing the work, adding detail where a real question needs it. The monthly goal helped us focus; the shorter cycle gave us more chances to validate. We are trying the newer shaping and ownership rules to make those decisions easier. I would start there before adding another planning tool, document or meeting.

A few useful reads

• Martin Fowler, The New Methodology. The adaptive-versus-predictive distinction is the clearest statement I know of why a plan written at the start of the month stops being true.
• Henrik Kniberg, Making sense of MVP. The skateboard-to-car picture everyone has seen, with the reasoning underneath it.
• Addy Osmani, The 70% problem. Honest about where AI-assisted building actually saves time and where it does not, which is the question any estimate now has to answer.