Everyone Can Build Now. Product Discipline Has to Catch Up.

AI has made it dramatically easier for almost anyone inside a company to build software. That's a good thing. People closest to a problem can test ideas themselves instead of waiting six months for a spot on the engineering roadmap.

But building software and making good product decisions are still different skills.

For most of software's history, engineering capacity was scarce. That scarcity forced companies to answer hard questions before anything got built. 

• Is this problem important?

• Does it affect enough customers?

• What happens to the rest of the system if we change this?

• Who's going to maintain it?

The process was slow and often frustrating. But it imposed discipline. Now a prototype can become a product before anyone realizes a product decision has even been made.

The code got cheap. The complexity didn't.

Small Decisions Create System-Wide Consequences

Most bad product decisions don't look bad in isolation. They usually solve a real problem for a real person.

A salesperson wants one more custom field. Ops needs an exception to the standard workflow. A customer asks for a slightly different version of an existing feature. Each request is reasonable. Each change is easy enough to build.

Then the fields stop meaning the same thing across teams. Reporting gets unreliable. Workflows accumulate exceptions nobody remembers the reason for. New hires spend their first month learning which parts of the system are real and which are historical debris.

Locally rational decisions add up to a globally incoherent product.

We saw this at LeagueSide, where we ran a marketplace connecting brands with local sports organizations, with a heavy operational layer of thousands of organizations, sponsorship campaigns, and making sure brands actually got what they paid for.

Most of our product decisions came down to metrics like increasing sales velocity, close rate, average deal size, and how many organizations one person could manage. A feature either moved one of those, or it didn't get built.

I'd love to say that was disciplined product thinking. It wasn't. Engineering time was expensive enough that we couldn't afford to skip the conversation.

It bought us time to figure out whether we were solving a recurring problem or building permanent complexity around a temporary inconvenience.

Democratized Building Needs Shared Product Principles

The answer isn't recreating the old approval bureaucracy. The opportunity is to distribute product judgment alongside the tools, not to slow everyone back down.

Before a prototype becomes part of the product, it's worth being able to answer five questions:

1. What repeated problem are we solving? A recurring pattern deserves a system. A one-off request may just deserve a workaround.

2. What outcome should change? Feature → changed behavior → customer result → business result. If you can't fill in the middle, you've probably built a capability and called it a product.

3. What else does this touch? Data, reporting, permissions, the next person who has to build on top of this.

4. Are we extending the system or creating an exception? Exceptions happen. They should at least be priced as exceptions, not quietly absorbed.

5. Who owns this after it ships? Someone has to maintain it, measure it, and decide when it should change or go away.

AI lowered the cost of producing software. It didn't lower the cost of being wrong.

Homework: Run This on One Thing

Pick one AI-enabled feature shipped in the last ninety days. Run it through the five questions. Most land in one of four places: keep experimenting (promising, needs evidence), productize (the outcome moved, give it an owner), revise (real problem, wrong solution), or retire (never moved the needle). A feature doesn't get to survive just because it's cheap enough to ignore.

The Product Role Is Becoming More Important

As building gets more distributed, product people will spend less time guarding the roadmap and more time spreading judgment through the company. Helping people tell recurring problems from isolated requests, and see the downstream effects before they ship.

The next evolution of product leadership isn't controlling who gets to build. It's teaching the organization how to build thoughtfully.

I'm taking on a small number of consulting, advising, and executive coaching clients each quarter. Reply to this email if you're working through a product, team, or operating challenge.