The papercut trap: Why AI-native products still need a hair-on-fire problem

I have two product beliefs I’ve held for years.

#1: the easiest route to a differentiated product people love is clarity on a narrow ICP. Small enough to win, big enough to matter.

#2: build around a hair-on-fire problem. It’s just much easier to sell something people already want than to educate them on what you think they should want.

“Small enough to win” especially matters when you’re running a PLG motion without a marketing or sales team - which is exactly what Wave is doing. When everything is carried by word of mouth, you need your ICP to be a tight-knit group of people who actually talk to each other. DevOps engineers at a meetup, complaining about the same terminal frustrations. The more tight-knit your audience, the faster word travels.

It’s been pretty easy to rehash these beliefs when consulting startups from the outside. Then I joined in a hands on capacity at Wave Terminal - an AI-native, open-source terminal - and abandoned both of them along the way. Whoops.

• The ICP drift

• The 10000 papercuts temptation

• What I found when I looked at successful AI-native companie

• The diagnostic: do your papercuts add up to a holistic hair-on-fire problem?

We started focused. DevOps engineers - people who live in the terminal. I ran an Outcome-Driven Innovation (ODI) process to understand their jobs-to-be-done, their unmet needs, their workflow.

Then we drifted.

The team building Wave were developers (who also did DevOps tasks - small startup life). They were dogfooding the product and naturally shaped it around their own needs. Dogfooding is powerful, but dangerous when the team isn’t the target audience.

Then the Claude Code boom happened. All of a sudden, the terminal wasn’t a niche DevOps tool anymore - it was becoming a mass market product. Our potential audience jumped from 27 million developers worldwide to 150 million product builders. I was personally part of the distraction. I’m an excited Claude Code user, and I saw enormous potential in broadening.

So we switched. DevOps to developers to “product builders”.

But here, we faced the same problem as with developers: The primary home for most (non devops) builders is the IDE, not the terminal.

We ended up looking at:

- Where do we have the most knowledge? (DevOps!)

- Who lives in the terminal? (DevOps!)

- Where do our strengths lie (persistent sessions across terminal sessions & an agent that can look across remote machines) (DevOps!)

Back to DevOps/SRE.

Every ICP switch was expensive. New JTBD to understand. New hair-on-fire problems to identify. New positioning. New messaging. Features built and thrown away. Luckily, the team builds superfast.

I can frame this experience as either “a lot of waste” or “we learned fast based on real user behavior data”. Probably both are true.

More importantly, I swayed from my hair-on-fire belief.

Quick primer on what I mean by that. Sequoia Capital describes three PMF archetypes you can build a product around:

• Hair on fire. A problem people actively feel and can name. They’re already looking for a solution. You feel market pull - the least education required.

• Hard fact of life. A problem people *know* about but have accepted as unsolvable. They won’t bring it up in interviews because they’ve stopped expecting better. Think: non-technical PMs accepting they’d always need developers to build software - until Lovable showed them otherwise.

• Future vision. A product built around a world that doesn’t exist yet. The iPhone. Nobody was asking for a touchscreen computer in their pocket.

I’ve always gravitated toward hair-on-fire. You just feel the pull. Less “educating the market”, faster adoption.

But at Wave, I started questioning that instinct. The thinking went like this: AI is exceptionally good at solving context-rich, low-complexity tasks. Which is exactly what most papercuts are. Before AI, automating these was often impossible or too expensive - they required human-like understanding of nuance that traditional software couldn’t handle. But LLMs can.

So why not build a product around solving a thousand little problems, rather than one big holistic one?

The Amazon analogy is seductive: Products a little cheaper, delivery a little faster, support a little nicer. Everything just slightly better, and in aggregate: a massively compelling proposition.

There was also a defensive argument. Hair-on-fire problems in DevOps? They’re already being solved 100 times over by competitors. And now people can easily code their own solutions with

So we tried it. We solved a lot of little problems. We built the (disparate) features our users were asking for in our Discord channel.

And in user test after user test, meetup after meetup, shadowing session after shadowing session, literally 80% of DevOps engineers told me the same thing:

“OK, but what problem does this solve for me?”

I couldn’t answer that question in a compelling way. Painful.

I started wondering: is anyone actually succeeding with the pure papercut approach? I ran a comparison across the most successful AI-native companies.

The finding: hair-on-fire is still the choice for most. Nothing new under the sun here.

We got thrown off by Cursor. At first glance it looks like a thousand papercuts: autocomplete here, generate a function there, multi-line edits, refactoring suggestions. Lots of small things. So a 1000 papercuts product works, doesn’t it?

But if you look closer, together, they all roll up into one clear, holistic problem: *I want to build robust software faster*. The papercuts are the delivery mechanism. The hair-on-fire problem is the positioning.

Notion AI is the same pattern. Summarize this, draft that, auto-fill a database property, search across your tools. A thousand small AI features. But they all serve the holistic problem Notion was already solving: one workspace for your team’s knowledge and collaboration. The AI just makes that core promise work better.

Even the product that *looks* most like a pure papercut play isn’t one. Every successful example I found has a holistic problem underneath.

If you’re building an AI-native product right now - especially if you’re pre-PMF (Product-Market Fit) - you’re probably feeling the same temptation we did. AI can solve so many things. Every user test reveals five more things you could fix. The product keeps expanding because it easily can.

Here’s the one sentence that would have saved us months:

“[ICP] uses [product] to [one holistic outcome]”

If you can’t fill that in clearly, your papercuts aren’t aggregating into a product. You can feel that quite quickly when you put your product in front of users.

Wave is at 5,000 DAU now, growing organically through pure word of mouth. No marketing team, no sales team. We’re going back to what we’re best at: persistent sessions and AI-powered visibility across remote infrastructure. One audience, one holistic problem.