Why I dropped PRDs for ShapeUp

I attended a CTO Gathering put on by nDeva last week. Pierre Bergamin gave a talk called “Pizza and Tokens” (https://cto-gathering-deck.pages.dev). He made a point that really resonated with me: “The bottleneck is no longer coding. It’s decision clarity. Small mission-clear teams win”.

Code stopped being the hard part

I think that code stopped being the hard part. It’s surprisingly easy to ship features nowadays. The hard part is choosing which features to ship.

I’ve seen large teams die because they couldn’t make decisions about what to build and what to ship to their customers. This was apparent at a previous startup I worked at. We couldn’t get a clear idea of what we were building and it kept us from shipping for ages. I also see this when thinking about the book Team Topologies. Having teams be super clear about what they are doing makes things much easier to deliver.

My first answer was Product Requirement Documents

When AI started coming properly into my life, I started leaning heavily into spec-driven development. Writing PRDs to then ship the code. This meant that we could get clear on what we were building before we started. You can write product requirement documents surprisingly easily with AI, because it can guess at what features you might want in your product. You probably also want the same non-functional requirements as everyone else: reliability, security and performance. PRDs are filled with boilerplate language and basically just capture a shopping list of features. It’s an easy way to align on what is and isn’t in scope.

PRDs assume you already know the answer

One thing I’ve noticed about this, though, is that we aren’t always super clear when we write the PRD. We don’t know what we don’t know until we start building it. Not every feature is as important as every other feature. The PRD boilerplate would hide what was actually important to the customer and what was just a nice-to-have. I tried a great deal to improve the PRD to capture only what we absolutely needed, but even then we couldn’t anticipate that building a specific integration would take 3 months longer than we expected. Often, we had a deadline of 1 month to ship and we hadn’t even gotten halfway through the document. This meant that the PRD would drag on, deadlines would be missed and we wouldn’t be shipping anything. Even if we have all that “clarity”, we still weren’t shipping fast.

ShapeUp splits decision clarity in two

I’ve moved away from this idea of using spec-driven development and moved to a new method. It’s called ShapeUp. I actually found out about it from Claude while trying to improve my PRD process. ShapeUp was designed by the guys who built Basecamp. You can read their book here: https://basecamp.com/shapeup.

The idea around ShapeUp is that you try your best to get the clarity to the team before you start, but you also give the responsibility back to the team who is building to decide the scope. Even when you ship something, the only way to get actual clarity from your users is to ship it to them. ShapeUp helps with this because time is fixed and you will always be learning from your users every time you ship a new feature. This allows you to still ship on time, even if the scope isn’t exactly what you predicted before you started building.

The work to decide what to do upfront is still there. It’s called “Shaping” and it’s a really in-depth process where the CTO and CEO constantly try and get decision clarity for the team before they start building.

The reason I like ShapeUp so much is that it gives me a “hands on the wheel” ability to still do the work to get decision clarity, but also allows the team to decide things while they are building.

What this looks like for me

I’m not dogmatic about completely following the exact formula they wrote in the book. We aren’t doing cooldowns, and we are only on a 4-week cycle. The main ideas of “fixed timeframe, variable scope” and “shape before you build” are really where I’m starting to see us get better as a team. We have a dedicated person to make sure the software engineers scope hammer (cut scope) to meet their deadline, and we also have an end-of-cycle demo before shipping to our customers. We took a long time to get the first brief out the door, but I expect we’ll get faster at shaping in the next few cycles. I’m still getting the method in place, but I can already see the benefits from the Shaping process alone. Watch this space for how this all unfolds.

The shaping work is still on us

Surprisingly, AI isn’t heavily used in the Shaping process yet. It’s great at writing what we think, but we still need to go into the design process and actually think about what we are shaping. There’s not a lot of boilerplate it can write for us in a pitch. It’s all meat. AI can’t make product decisions for us either. Maybe it will spot patterns with our customer calls in the future, or might be able to distill key insights about what our customers want, but right now the real bottleneck is the shaping and getting aligned on what to put in the pitch.

My take

You should use ShapeUp instead of spec-driven development if you want great decision clarity, and you also want to consistently be shipping each cycle.