• Project planning is hard.

• Planning AI / software projects is harder (“you’re inventing the future!”)

• Planning AI / software projects as an early stage startup is near-impossible

But to be a successful early-stage AI / software startup you simply have to get exceptionally good at prioritizing, planning and shipping projects. It’s the only way; without it, many fail.

A few months ago I wrote about The Founder’s Paradox - this quantum state about starting a business where you’re both hyperfocused on your vision, while also completely open to new, better, shiny alternatives.

Turns out that philosophy breaks down pretty quickly when you’re staring at 47 half-finished products, your lead engineer is asking ‘so… what are we building this month?’, and your customers / investors are pounding their fists on the table demanding to know when the dark mode toggle they’ve been asking about for months will be ready.

We learned this the hard way at Uptrends. We talked to customers, we shipped stuff, but we lacked the right processes in between to make it all make sense. The result? Lots of jumping from shiny object to the next, a bonafide Github graveyard of abandoned pulls, and deadlines chronically missed.

After selling Uptrends and starting Babbl Labs, launching an MVP built on deeper AI tech for clients with higher stakes and product requirements, we’ve realized we’d need to get more serious about our project management skillz if we wanted to succeed.

Below is the project planning framework we’ve implemented, to help us decide what to build, how to build it, and ensure we get it done. Much of which has been borrowed shamelessly from other smart people (highlighted below) and adapted through trial and error. Hopefully it can save another early-stage entrepreneur some time down the road:

How We Plan Projects at Our Startup

The post-MVP project planning process can be summed up into three phases:

1. Prioritizing (placing bets)

2. Planning (shaping them)

3. Building (shipping them)

1. Quarterly Bets: Selecting What Matters

Every 90 days we hold a 3 hour team-wide roadmapping meeting, we call it our Quarterly Roadmapper (very original I know)¹

Throughout the quarter we all dump our ideas into a Github project board - new features and revenue streams, customer complaints and tech debt, random midnight inspirations, it all goes in there. By the time we hit our Quarterly Roadmapper there’s usually about 20-30 items starting back at us.

The temptation of course is to try and do them all (Don’t do that).

Instead the key is to force ourselves to pick 5-7 bets. We rate each idea on a simple formula: Impact x Urgency / Effort = Priority

It’s not a perfect science; we put them into a little Eisenhower Matrix and do this for relatively.³ Then the real magic is in the questions we force ourselves to answer:

• Does this problem actually matter to customers?

• Is this the right time? (sometimes waiting a quarter reveals higher/lower scores)

• Do we have the right ppl available? (like when that ML feature sounds great but your ML engineer is in the process of finishing their PhD)

In short: curate a list of 20-30 ideas over time, score them in terms of priority, triage with these questions, and land on 5-7 that are worth tackling (the rest should be avoided). Once the cream has risen to the top, we move onto shaping them:

2. Shaping the Work (Fixed Time, Variable Scope)

Next comes actually planning each project. Based on our priority/urgency/effort scores, each project gets a time budget - not a feature list. We try to work in ~6 week cycles with hard stops (few exceptions). This helps avoid the “just one more week to add this critical feature” scope creep.²

Before anyone writes a line of code, we ‘shape’ the work:

• Set the appetite: How much time are we willing to invest? 2 weeks? 6 weeks?

• Write the outline: What problem are we solving? key components? approach?

• Identify rabbit holes: Where could we get stuck? What AREN’T we doing?

• Assign ownership: one person owns each project (no committees)

What we explicitly don’t do:

• Open-ended refactors (“just make it better bro”)

• Redesigns with out a clear, obvious problem to solve

• Anything described as a ‘quick fix’ (they never are)

We learned this lesson hard when we spent 3 extra months building out our MVP data pipeline and adding new features / refactoring on the fly. What starts innocently as a 2 week ‘clean things up’ turns quickly into missed deadlines if you aren’t careful.

3. Building Into Reality (Shape → Ship)

Once you’ve got the shape worked out and w'e’re ready to start building, we follow a few guidelines to keep ourselves honest:⁴

Build Vertically First - try to get one complete slice working end-to-end before building horizontally. Ex: for our recent API build out, that meant one endpoint fully functional with auth / rate limits / monitoring before adding the other 10.

The Three Buckets - for each project’s jobs-to-be-done there are a few levels of granularity:

• Scopes: meaningful chunks of work (mapping the ‘regions’ of a project)

• Tasks: deconstructed bite-sized chunks of a scope (ex: password reset flow)

• Chowder: overflow catch-all for tasks that don’t fit into a scope

The Hill Concept - another Shape Up steal. They key to remember when building is that you will never know all of the moving parts up front. There are uncertainties when you are ‘inventing’ - things that you’ll learn along the way. It’s helpful to think of every piece of work as having essentially two phases:

• Uphill: You’re figuring it out, still lots of uncertainty

• Downhill: You know what to do (all the key parts), now just execution

Knowing which phase you’re in changes everything; it makes keeping track of progress much easier. Uphill work needs exploration, downhill needs focus and momentum.

Must Have’s vs Nice to Have’s - finally, it’s important when scoping out your tasks to distinguish between essentials vs nice additions. Do this religiously. When time runs short (as it often does), we ship must-haves only. If there’s extra time, you can add nice to haves

It’s About the System, Not Perfection

At the end of the day, there are many project management frameworks. But every business is different (focus, stage, size, etc.). We’ve borrowed and adapted our current framework from EOS and Shape Up, but we don’t follow them perfectly. Someday we may even switch to something else.

The point is not to be perfect. The point is having a system of priority and execution.

Before implementing this, we were a classical startup cliche - build frantically in every direction, miss the deadline, burn out. The hope with this system instead is to maintain focus and ship consistently (be prolific!). Ultimately, the team knows what we’re working on and why. And our customers get what we promised them.

Is it perfect? No; the point is to avoid perfection - perfection and production are always at odds. We still occasionally chase shiny objects (I try to think of this as a 70/20/10 for our main customer types, more on this in another post later). But we ship. Consistently. and In the startup world, momentum is everything.

Our Toolkit:

For anybody looking to implement something similar:

• GitHub Projects for task tracking (simple is better)

• 2.5-hour quarterly planning sessions (book them in advance)

• 10-minute daily standups (actually keep them to 10 minutes)

• 30-minute weekly team meetings (review the hills)

The Main Thing: If you take nothing else from this, take this: pick a system, any system, and stick with it for at least two quarters. The system matters less than having one.

Because at the end of the day, the best product roadmap is the one that actually ships products.

Peace,
Ramsey

1  This is mostly borrowed from the EOS Quarterly Meeting, with a few twists

2  This is pretty directly from Basecamp’s Shape Up methodology, a gamechanger

3  Borrowed from Sahil Bloom’s The 5 Types of Wealth chapter on Time mgmt

4  Also pretty much directly from Basecamp’s Shape Up Methodology ^