AI Makes It Easier to Do Work You Shouldn't Be Doing

AI makes it easy to do work you shouldn't. While you're doing someone else’s job, who is doing yours?

I recently read a post about a product manager whose customer wanted a new field added to a screen. Development was overloaded. The change seemed simple. So rather than wait for engineering, the product manager used AI to pull the code, add the field, and push the change into production.

Problem solved.

Or was it?

I have two questions.

• Was this product manager qualified to make the change?

• What was the product manager supposed to be doing instead?

These questions matter more every month, because AI now makes it possible for almost anyone to do work that used to require specialized skill. A product manager can write code. A developer can create positioning. A product marketer can build a prototype. A salesperson can generate a requirements document. An executive can produce a roadmap.

And they can all do it before lunch.

That sounds tremendously productive.

But I'm not convinced.

Never take down a fence until you know why it's there

One of my favorite maxims is referred to as “Chesterton's fence.”

But somebody put it there. Until you understand why, removing it isn't progress; it's ignorance.

Organizations are full of fences. We have developers, designers, product managers, product marketers, salespeople, security teams, operations, and finance. Some of those boundaries are dumb. Some are historical accidents. Some should absolutely come down.

But before you tear one down, understand why it's there.

The developer doesn't just type code into a computer. The developer understands the architecture, the dependencies, the testing requirements, the coding standards, the security implications, and the technical debt that's already accumulated in that module.

The designer doesn't just make screens look nice. The designer understands interaction patterns, accessibility requirements, consistency, user behavior, and the design system that keeps forty screens from looking like forty different products.

AI gives us access to some of their capabilities. It does not give us their experience or their judgment.

And that's the danger. AI can make you just competent enough to be dangerous.

Nothing is ever just a fifteen-minute project

The customer wanted a field. Fine.

Where is the data stored? Who can edit it? Who can see it? Is it included in exports? Does it show up in reports? Which reports? Is it exposed through the API? Does it contain personally identifiable information? Does it need to be audited? What happens during an upgrade? Does the mobile app need it? Is there validation? What happens to the existing records that don't have a value?

Here's the question I like even better: why does the customer want the field in the first place?

That's the product management question.

Maybe the customer has surfaced a real market problem, and dozens of other customers have the same issue. Or maybe somebody wants a place to store their dog's birthday.

We don't know. Because nobody asked.

The product manager in this story was probably praised for being responsive. The customer was happy. Engineering wasn't interrupted. The change shipped in a day. Everybody wins.

Until they don't. Every workaround has a lifecycle. Somebody eventually owns it, maintains it, supports it, documents it, secures it, explains it, fixes it, or rips it out.

AI makes the first fifteen minutes almost free. It doesn't make anything that follows free.

The real cost is opportunity cost

There's a second problem that bothers me more. While the product manager was writing code, who was doing product management?

This is what organizations routinely ignore when they celebrate their heroic product managers. A product manager cleans up the backlog in Jira — great initiative. A product manager writes the sales deck because marketing is swamped — team player. A product manager runs regression tests because engineering is behind — whatever it takes. A product manager uses AI to implement a customer request because developers are busy — look how productive.

And this really isn’t a new problem. It was here long before AI was a thing.

Product managers prototype screens because their team doesn’t include a designer. Product managers create slides because marketing is busy with other programs. Product managers answer RFPs because there isn’t enough product knowledge in sales engineering.

Pretty soon the product manager is doing everyone's job except their own.

But here’s the interesting question: If you're doing their job, who's doing yours?

Or this one: How many departments are hiding their headcount in product management?

Product management has always been vulnerable to this, because so much of the work is invisible. Nobody notices the customer conversation you didn't have. The market trend you didn't investigate. The competitor you didn't evaluate. The assumption you didn't validate. The business case you didn't challenge.

But everybody notices that the field appeared on the screen Tuesday afternoon.

Activity is visible. Learning usually isn't. And AI makes activity spectacularly easy to produce.

AI is valuable when it helps product management understand markets, customers, problems, evidence, alternatives, and business implications. It becomes dangerous when it makes it easier for product managers to generate more stuff—features, code, designs, marketing campaigns, sales decks—without improving the underlying product decision.

AI changes the economics of building

For most of our history, building things was expensive. We had limited development capacity, limited design capacity, limited everything. Those constraints were frustrating, but they forced choices.

Now code is cheaper. Prototypes are cheaper. Designs, content, research summaries, campaign copy — all cheaper. That's genuinely good news.

But the cost of producing things is falling much faster than our ability to decide which things are worth producing. That's the gap product leaders should be worried about.

When production gets cheap, evidence, prioritization, market understanding, and judgment don't matter less. They matter more.

Use AI to reduce the cost of learning before you use it to reduce the cost of building.

Analyze customer feedback. Find patterns across support tickets and win/loss notes. Explore alternatives. Challenge your own assumptions. Examine competitors. Model the business implications. Prepare sharper questions for your next customer conversation.

And yes, sometimes a product manager should use AI to build a prototype. If the purpose is to put something in front of a customer tomorrow and find out whether an assumption holds, that is product management. The artifact isn't the point. The learning is.

With AI, we have so many new ways to increase the speed of learning.

Before you tear down the fence

I'm not arguing that product managers should stay in their lane. Great product teams collaborate, cross boundaries, and help each other, and new tools inevitably reshape roles and responsibilities.

But capability is not the same as responsibility.

Roles and responsibilities are still important. However, the lines between roles are not walls; they are more like curbs. Just step over the line thoughtfully.

Ask yourself:

• Should I cross this boundary?

• Am I qualified to do this work?

• Who will own, support, and maintain what I create?

• And what am I not doing while I'm doing this?

AI gives us an astonishing new ability to create things. Let's make sure it doesn't just make us extraordinarily efficient at doing work we shouldn't be doing — and building things we never should have built.