With AI tools, it's never been easier to build new features. You can spin up a proof of concept in a weekend and copy a competitor in days. But just because you can build something doesn't mean you should. Over the past decade we've watched founders — especially technical ones — overbuild: shipping feature after feature, then wondering why customers still say the product is too complex or can't find what they need. The trap is thinking adding a feature equals adding value. Every feature you build, you have to sustain: ongoing support, documentation, and keeping it working as you build around it. Complexity compounds. And as building gets easier, experience and distribution matter more — the products that win are the ones that are easier to use, not the ones with the longest feature list.

That's why we built our target feature framework: a simple canvas that forces you to make the argument for a feature before writing a line of code. Eleven sections. Here's how it played out for a real client — a B2B SaaS company that wanted to add an approval workflow because customers asked and competitors had it.

The sections that do the heavy lifting

What is this feature? Write it plainly. Teams are surprised how often they each picture something different. (Here: a structured feedback-and-approval workflow for media assets, built in so customers go from draft to approval in one tool without switching context.)

Problems it solves. The most important section. Name an actual problem customers have today, gathered from talking to them, jobs-to-be-done interviews, and support tickets. If you can't clearly state the problem, stop and gather more data. Adding a feature to a product with real users needs strong evidence — otherwise you're just adding noise. (Testing revealed customers needed the process tailored to their way of working and simple enough not to feel overwhelming.)

Importance. Why now, and what happens if you don't build it? Here it tied to keeping users in the product, more time in-app, lower churn risk, and — by inviting managers and teammates in — expansion revenue and a path up-market.

Target customers. Be specific. This one was for designers and project managers in small-to-midsize agencies — designers gathering feedback, managers wanting status overview.

User flow impact. Map how it changes the existing experience. This is where features go wrong: built, then tucked away where users never look, or disrupting a flow that worked. They realised it had to connect to where assets are created and show per-asset status.

What you tried, and why it didn't work. The client had already shipped commenting and even a full workflow builder that was too complex. Comments were too passive — feedback whenever, no way to approve or change an asset's status. Understanding why the earlier version failed kept them from repeating it.

Success metrics, similar solutions, constraints, and "other." Define how you'll know it worked (adoption rate, time from first draft to final approval). Research what else exists. List constraints — for this client, an eight-week launch window, which forced focus and cut everything non-essential. And note the guardrails: they explicitly did not want to build a full project management system.

You don't need every section filled perfectly to start. But if you can't fill out the first few — the problem, the target customer, a success metric — that's the signal to pause and gather more before you commit. Use it as a discussion tool so product, design, and engineering are aligned, and revisit it after launch to make your next decision better.

If you're overbuilding — low retention, confusing flows, customers who can't find what already exists — that's exactly what we help with. Talk to us.