← Back to Blog
product managementaiproduct discoverystrategy

The fine line between good product and slop

By Jay Nathan, Jonathan Huhn|
Tangled dark lines on the left straightening into smooth orange lines on the right

Beyond The Click · Vol. 40 · August 20, 2026

For decades, engineering capacity set the ceiling on every product roadmap. You could have fifty ideas but only build three of them. It was a blessing disguised as a constraint, because it forced you to choose. But AI has now removed that constraint almost entirely.

Coding is a natural use case for AI, and any product org refusing to use it is just being negligent. Last year, Satya Nadella claimed that 30% of the code in Microsoft’s repos is AI-written. This year, Sundar Pichai put AI at 75% of Google’s new code. And Y Combinator reported that a quarter of its winter 2025 startups had codebases that were 95% AI-generated.

But when one engineer suddenly produces as much code as five, teams can turn into output factories, building everything they possibly can. It might be “sloppier” than it was before, but it gets perceived as productivity because “look at how many features we can ship now.”

Welcome to Beyond The Click by Balboa. Today we’re covering how to keep an enterprise product development engine scaling sustainably instead of devolving into pure vibe-coding, including:

  1. Re-elect the governor 🎩
  2. Enforce the user validation gate 🏰
  3. Link every build to a business outcome 🔗
  4. Don’t “girl-math” the tokens 📊
  5. Remember that software was never the hard part 💪

Let’s dive in.

Re-elect the governor 🎩

The old capacity constraint was a natural governor on the infinite flow of ideas. To a lot of leadership teams, removing it feels like a dream come true, because engineering could never build things fast enough and that was always framed as a problem. Now the machine can build features faster than you can think of them.

And that’s why prioritization has to become an explicit step that someone on your team owns. You CAN build anything, but you still SHOULDN’T build everything. Keep filtering the fifty ideas down to three, on purpose this time, before building.

Enforce the user validation gate 🏰

Code is one ingredient of a product, but it was never the whole recipe. Increasing velocity answers none of the questions that decide whether a feature is even worthwhile, namely:

  1. Is it valuable?
  2. Is it usable?
  3. Is it feasible?
  4. Is it viable?
  5. Is it what customers want and will pay for?

Product discovery and end-user validation are gates that no feature should ever skip, no matter how quickly it can be built. A feature that ships in a day without passing those gates spends the next several months in iteration, refinement, and bug fixes. And then you’ve lost the whole speed advantage anyway.

Social media posts from tech leaders about how much of their code is AI-written
It’s now cool to brag about how much of your codebase is AI. But does “cool” = “good”?

Link every build to a business outcome 🔗

Every build should point at a revenue, retention, or renewal number before the work starts. If a feature can’t plausibly move one of those, then you ask why it’s on the roadmap at all.

10x code without a proportional uplift in revenue, retention, or renewals is just added cost, and much of what gets built this year will generate very little revenue six months from now. When that bill comes due, someone in the boardroom will ask why the company spent all that money on tokens. No company is in the business of writing code.

Don’t “girl-math” the tokens 📊

Business leaders intuitively grasp the cost of people. We know what to expect from a $200K engineer, and we know how to budget for a $300K one. But almost nobody has that mental model for tokens yet, which is what makes them so easy to burn.

Plenty of teams have skipped hiring five new engineers only to unintentionally burn five people’s worth of comp in AI tokens. Do the math on what a token actually costs your team before the CFO does it for you, and budget for that spend the way you’d budget for a new hire.

Remember that software was never the hard part 💪

Developing software was never the hardest part of building a successful product. The hard parts are discovery, validation, UI and UX, onboarding, adoption, and land and expand. These steps aren’t going away, but the technology has tricked a lot of smart leaders into forgetting that.

AI accelerates whatever product discipline you already have. If you’ve already set up the guardrails to build good product, you’ll now build good product faster. If you haven’t, you’ll build slop faster. There is no shortcut. 👍