Why AI Probably Won't Help Your Team Ship More Product

Imagine you work in an office 5 days a week. (Maybe you do, or once did and can remember what it's like.)

Further imagine you have a morning routine you follow pretty much every day to get yourself ready and to get to work by 9am.

Morning Routine

• 7:30 Alarm goes off - you hit 'snooze' and check your favourite apps on your phone. (9 min)
• 7:39 Get up, shower, get dressed, do hair, etc. (21 min)
• 8:00 You cook yourself a full breakfast worthy of Skylar White and eat it (30 min)
• 8:30 Walk to the train station. (5 min)
• 8:35 Take the commuter train which stops right at your office building. (20 min)
• 8:55 Walk to your desk and start your day. (5 min)

One day you see an advertisement for the "AI Breakfast Bot 2000", a robot that will cook any breakfast its owner could want. You realize you can have it make your breakfast while you're getting ready and cut your 30 min breakfast time down to just the 10 or so minutes it takes to eat. This is great because it's the longest single step in the whole routine so it's bound to make some serious improvements to the overall process.

You set the bot to start cooking at 7:10am and now your routine looks like this:

Morning Routine (Now With AI!)

• 7:30 Alarm goes off - you hit 'snooze' and check your favourite apps on your phone. (9 min)
• 7:39 Get up, shower, get dressed, do hair, etc. (21 min)
• {Robot is making breakfast here}
• 8:00 Eat your robot-cooked breakfast (10 min)
• 8:10 Walk to the train station. (5 min)
• 8:15 Arrive at the train station
• 8:35 Catch the commuter train which stops right at your office building. (20 min)
• 8:55 Walk to your desk and start your day. (5 min)

How'd we do?

So… how’d we do? You still arrive at 9:00. You optimized the longest step but ignored the real constraint: the train only comes at :05 and :35. Arriving earlier doesn’t help. To get ahead, you’d need to adjust other parts of the routine to catch the 8:05 train instead.

What's this got to do with product development?

Every product development team I've been a part of has one thing in common: more product ideas than capacity to build it. Leaders often think: if we could just build faster we can ship more of massive backlog.

AI coding tools now have Product Managers, Engineering Managers, and Execs salivating at the promise of a step-change in developer productivity. The assumption is that faster coding ➡️ faster backlog burn-down ➡️ more product shipped.

But chances are that's just the same as the breakfast robot. You're making one step faster out of many, but you may not be addressing the true constraints of the system.

Let's be Generous

I think it's fair to say that at this point we don't really know if these tools are going to have a positive impact on productivity or not. Early signs are saying 'no' but I think the jury is still out on what the full impact will be and this will be true for a while still.

Let's be generous and optimistic and assume that some gains will be available or will become available in the nearish term as the tools get better and we get better at understanding what they're good at and how to use them.

Building a feature is more than just coding it.

Every feature has some kind of life cycle. Regardless of your specific methodology you're probably following some sort of path that looks like:

• Ideate
• Design
• Code
• Test
• Refine
• Release

(Hopefully with some loops and iterations in there somewhere)

In bigger orgs the the early stages probably involve a lot of cross-functional work around resource planning and allocation, prioritization, scoping to get alignment from many departments and execs around what you're building and why. The later stages likewise probably involve a lot of cross-department collaboration to get things like marketing collateral, sales enablement, and support team training figured out before you can launch a new feature.

At every stage constraints lurk. Like the train schedule in our earlier example. AI tools might be able to help with some of them too, but in order to achieve the goal of "more features out the door through the magic of AI productivity" you really need to understand where those constraints lie. Optimizing any part of the process that doesn't improve throughput at the biggest constraint cannot produce an improvement in the end-to-end time. Just like arriving early for a train doesn't get you to work any earlier.

This is counter-intuitive

The "Code" & "Test" steps are generally the longest, most expensive part of the feature development life cycle so one would be forgiven for automatically assuming that an optimization here would obviously improve the end-to-end time for the whole feature. That's not always the case though!

The insidious bottlenecks can hide anywhere:

• Mid-project on a big pricing and packaging change you find an edge case you didn't think of that would impact existing customers.
  • You need input from the CRO but they just left on vacation and their second-in-command is afraid to make a decision.
  • You escalate to the CEO and they punt to the next exec meeting in a week.
• Your Security team needs to sign off on the new service you're deploying as part of your feature but they're midway through the SOC2 audit and don't have anyone who can get to it for a couple of weeks.
• Your feature is shipping via a third party app store and you've been rejected from their review process with little explanation.

It doesn't take many of those to eat up the gains you might have gotten from Claude writing your unit tests for you.

Some of those constraints were the result of a surprise, and while I've never seen a project that didn't have a few of those, the bottlenecks can just as easily be built right in to your process. Here are some real ones from my career to date:

• Product Marketing demands n days/weeks of lead time before anything can ship to customers, even small UI changes.
• Support Team requires training on every feature before it's released to the customer.
• The founder-CEO wants a final review of any change to the user interface of the entire product.

Your specific constraints, reader, might not be on that short list at all, but they exist, and writing code faster isn't going to solve them.

How to find them

Most leaders already have a gut feel for where bottlenecks are. But beware, the worst ones are 'wait states'. They don't look like work because nothing is happening, you're just waiting for someone to decide something or to otherwise unblock you.

The Fix: instrument your process like you instrument code. Start logging key events:

• Idea Proposed
• Added to roadmap
• Design fleshed out
• Kickoff meeting
• Coding begins.
• Dev Complete
• Beta
• Marketing Launch
• General Availability

Start by simply measuring the elapsed time in days between each step. If possible, measure how much time you spend waiting in each phase.

Value-Stream Mapping is a great way to map out your whole process and see where bottlenecks lurk.

The Takeaway

Don't be fooled: writing the code faster won't magically unlock more product. Even if AI assistants really light the afterburner on your team's code output, any gains can be squandered if the constraints live elsewhere.

Engineering leaders should be careful to educate their stakeholders and everyone involved in leading Product Development efforts should periodically instrument and review their processes to find the hidden bottlenecks that are the truly slowing down their output.

Optimizing at the constraint is what helps your team ship more. Anything else is just faster breakfast.

Image Credit:
"Robot Chef" by Sam Howzit is licensed under CC BY 2.0.