While observing startups across tech build and ship at increasingly absurd speeds, I keep returning to a line from Jurassic Park:

“Your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.” — Dr. Ian Malcolm

That quote hits differently now that the answer to “can we build it?” is almost always yes. AI has completely changed the economics of building software: a feature can go from “maybe” to a live part of the product before the assumption behind it has been properly challenged.

Today, the hard part is understanding what that one more thing does to the product as a whole.

One feature leads to another, then another, until the product has a lot of functionality but nobody can clearly explain how all of it fits together.

This is AI Product Slop, or simply Product Slop: when features make sense on their own, but the product stops making sense as a whole.

When speed erodes coherence

Product Slop rarely starts with a bad idea. The trouble begins when shipping speed becomes the dominant measure of progress.

A referral program could help with growth. A points system could increase engagement. An AI assistant could help users find information. A social feed could build community. Each one sounds reasonable on its own.

There’s also a temptation to turn every promising product into an “everything app”. If users like one thing, why not give them ten more? But the products people come back to usually have a clear reason to exist. They do one thing, or a small number of things, extremely well. You know what they’re for.

Focus creates that clarity. Every new feature has to compete for attention with the thing that made the product useful in the first place.

Jira and Linear are a good example. Jira grew into an extremely flexible product with customizable workflows, fields, permissions, and thousands of integrations. Linear took a more opinionated approach to how software teams work, and even says there are Jira features it has deliberately chosen not to pursue. It didn’t need to match Jira feature-for-feature to become compelling. Focus became part of the product.

(This is a tangent, but I think another competitor will eventually take on Linear for the exact same reason they took on Jira. Feature creep gets the best of us.)

And that is the broader pattern. Each addition can be useful on its own while the product becomes harder to understand as a whole. Zoom out and suddenly you have five competing priorities, several disconnected journeys, and no clear sense of what users are supposed to care about.

That is the trap. The faster you add things, the easier it becomes to lose sight of what they’re doing to the product as a whole.

Product Slop often comes with Visual Slop

Both forms of slop come from the same pressure to move quickly, even though they appear at different layers of the experience.

Visual AI Slop is the obvious stuff: generic styling, synthetic language, predictable layouts, awkward typography, and interfaces with no real visual point of view. The product feels like a first-pass AI output because, in many cases, it is.

The problem is that users see all of this before they understand the value of the product. When everything looks and sounds like the same AI-generated template, it becomes harder to stand out, harder to feel memorable, and harder to signal that real care went into what you built. In products that involve money, identity, or risk, those details can also affect whether someone trusts the product enough to keep going.

Fortunately, this surface is easier to repair and recognize. Stronger brand direction, clearer language, design QA, and a coherent design system can improve visual quality relatively quickly. Many Design Skills already repair that system across typography, layout, color, and more. Jakub Krehel’s Better Interface Skills, Paul Bakaus’s Impeccable Styles, and Emil Kowalski’s Skills are great examples.

Product Slop is buried deeper. It lives in the feature set, information architecture, onboarding, feedback, risk controls, core loop, and overall journey. Fixing it may require removing features, combining flows, changing priorities, or rebuilding parts of the product.

A visual refresh can make an incoherent product look more polished without making it easier to use.

Why coherence matters

At some point, the product technically works. The wallet connects, the transaction executes, the data appears, and the feature behaves as expected. That’s usually the moment a team starts to feel done.

But functional is a milestone. It isn’t a finished product.

The product still has to make sense as an experience. Users need to understand what to do, what is happening, what matters, and what they should expect next. Sometimes how the product delivers value matters just as much as the value itself.

That means answering a few basic questions: Can users tell what to do next? Do they understand what is happening? Do they know when they have won? Can they recover when something goes wrong?

There is no universal answer. A trading app, social platform, game, and developer tool each need different forms of clarity, feedback, trust, tension, and reward. The right decision depends on the product, the user, and the moment.

That is why product design is so difficult.

In finance and crypto, the stakes are even higher. Users are being asked to connect wallets, sign transactions, and move money. The technology can work perfectly, but the experience still has to make people feel confident enough to continue.

Good product design helps people understand what’s happening, reach value faster, and feel confident enough to return.

How do we mitigate Product Slop?

Product Slop is a judgment problem, so the repair has to begin before another feature reaches production.

Product judgment needs to come back into the process before the team starts building. Step back from the feature, look at the whole journey, and ask what adding it actually does to the product.

Does it strengthen the core journey? Does it make the product better at what people already come here to do? Does it introduce another competing priority? Does it make an existing behavior clearer? Does it create something new the user now has to understand? Does the added complexity earn its place?

Stop judging every feature on its own. Look at what it does to the whole product.

I wrote A Developer’s Guide to Product Design as the practical follow-up to this essay. It shows developers how to protect a product’s coherence as it grows: defining the problem behind each addition, exploring alternatives, mapping the journey, testing the riskiest assumptions, and deciding where craft belongs.

This is also why I built the Product Judgement Skills: four Skills that bring product judgment back into the loop.

  • Compass maps the product journey and helps you see where the experience breaks down.
  • Focal clarifies what each screen needs to communicate and what users should focus on.
  • Flywheel examines what gives people a reason to come back.
  • Soul helps you decide where the experience should stay Expected, become Elevated, or feel Net-new.

Point them at your designs, product requirements, or codebase before you commit to a path. They’ll help you explore alternatives, protect the main journey, and spend craft where it matters. The final judgment is still yours.

What this means for the tech industry

Product Slop is happening across the tech industry. Early teams need rapid experimentation. They have to ship, learn, and figure out what users actually value. Some roughness is inevitable, and I don’t think every early product needs to arrive fully polished.

The opportunity is to preserve that speed while becoming much more deliberate about what earns its place in the product.

As software becomes easier to produce, shipping another feature becomes the easy part. The difficult work is deciding what belongs, how each addition changes the rest of the experience, which moments deserve more care, where familiar patterns are useful, and which ideas should never make it into the product.

AI has made “could” cheap. We can build almost anything, and we can build it faster than ever.

The question worth spending more time on is the one Ian Malcolm asked decades ago:

Should we?

Dr. Ian Malcolm: Your scientists were so preoccupied with whether or not they could that they didn’t stop to think if they should.