AI is stopping startups from completing puberty

Puberty is that in-between bit between seed stage and a startup working out what it actually needs to be in order to thrive.

If you've been in a seed or Series A or B startup, or even an early stage product in a larger company, you will likely have seen this. It doesn't happen evenly, across all departments and functions. But gradually, someone gets to: "we need a bit of that big company stuff to get us further. Some structure".

Maybe too many development teams to handle with one board. Maybe you hit your first n customers and you need things like go to market discussions, or even release note reviews. Maybe you're snowed under with bug requests, or feature requests, and the team seem to not be producing anything fast anymore.

So you look around, see frameworks and so on. And you add documents. And processes. Often copy/paste out of some guidance, or based on a previous workplace someone (even you) worked at.

And that seems to be ok, initially. People seem happier. Fewer things are getting missed. So more growth happens... and the moment happens.

Too many documents. Too much for people to handle. And that crisis is important. And it's painful.

The useful crisis AI can prevent

AI can make workarounds cheap enough that startups fail to notice the underlying problem they need to solve to scale.

I've seen this happen with AI-assisted operational work. A team was using an AI agent to make corrections to customer outputs that the (AI) product itself couldn't reliably make.

In that world prior to easy access AI agents and LLMs, those bugs would have been done manually, and the organisation would naturally reach a capacity limit. A conversation starts - "we shouldn't spend this much money and time on these, we should correct the cause or decide this doesn't matter to us".

Except there wasn't a mechanism for those corrections to feed back into the product. So the better the agent got at doing the correction, the less visible the product gap became.

The workaround was no longer painful enough to force anyone to ask why the workaround existed. All the KPIs look lovely. The customer is happy, which is obviously good. But have you learned anything that makes your own product better? Or have you just bought a way of making the evidence disappear?

This becomes even more dangerous when the product itself is AI.

You're no longer necessarily using the customer interaction to make your own AI better.

You're paying someone else's AI to compensate for the bits of yours that aren't working yet.

The correction itself can be incredibly valuable information. It tells you where your product did not understand the real world, and what a person thought the right answer was. If that work is happening in (for example) Claude, but not being tagged, stored or fed back into your own intelligence (be that models or otherwise), you have solved the customer problem for today. You have not necessarily made your product any better for tomorrow.

Add some time, you've gone from producer of capability to consumer of capability.

So if you're a startup whose advantage is supposed to come from your own AI, you should probably notice when that transition is happening.

Our judgement and intuition assume a pre-AI world.

Before this, rising manual work, complaints and delay were signals. They were annoying, but they told you something. You were eventually forced to work out whether to fix the thing, stop doing it, or make a deliberate choice to carry the cost.

So before AI: you'd hit a limit, you'd need to decide "what is actually needed" and work out what is needed to unblock growth or scale (in any area - development, product, marketing, finance, sales, support, customer success, etc).

Now: you can automate the documents and processes with AI agents instead of running out of time. Which is stopping that "what what do we really need" discussion from happening. Why are we patching bugs in this way? Why are we writing two emails to our users rather than one? Should this be handled by changing what we do, or by adding to what we do?

So by doing this, we can help a company sleepwalk past the growing-up conversation. We are eating runway to keep the current shape of the business working, instead of learning what needs to change for it to scale. And we are doing it at a slightly higher rate because of the token bill.

This is because you're not getting the right information or trigger to learn that vital thing that gets you that unique advantage. That pivot. That reframe. That ah-ha moment. That magic combination of things that other products or startups did not work out before you (and often lost!)

How to adjust

That's not to say don't use these tools - that's not the focus of this post. But do realise that they can protect you from what you need to see.

Weirdly, this is "back to the future" almost. Much like people were poring over cloud-provider bills ten years ago because they had lifted all their VMs over without redesigning for cloud hosting properly (yummy containers and all that), we need to do the same for GenAI tooling.

You're looking for AI usage that compensates for a recurring product or organisational failure, and explicitly asking yourself what to do next: eliminate it, productise it, operationalise it as a bounded service, or accept it as a conscious trade-off.

Some practical options on how that looks:

• What does your AI spend profile look like? What is it actually being used for?
• When you talk to people using the tokens, what work is it taking off their hands?
• Who reviews newly automated workflows - and what are they reviewing them for?
• What is the AI making invisible? Is that information getting to the right people?
• Who used to complain constantly and has gone quiet? What silent workaround appeared?
• Is feedback from support, sales and other external-facing teams actually flowing back into the roadmap? (I mean, this is the eternal challenge of product management...)

And most importantly... be aware that your judgement will need calibrating again. "It's quiet, it's probably fine" may not work anymore.