Feature creep isn't a discipline problem. It's a process design flaw: backlogs, roadmaps, and sprint reviews are all built to answer “what should we add?” and almost none of them ask “what should we remove?” ERIC (Eliminate, Reduce, Increase, Create) is a four-move framework from Haja J Deen's Build the Right Thing that gives subtraction equal weight with addition, turning “what not to build” into a weekly decision instead of an annual clean-up crisis.
Why “Improve” Quietly Means “Add”
Ask a team to improve a proposition and watch what happens: they list things to build. Addition feels like progress because it's visible and creates artefacts, a new screen, a new setting, a new integration. Removal feels like loss, even when the thing being removed is costing you clarity, maintenance, and onboarding time every single week.
This bias shows up in the tooling too. Product analytics platforms and roadmap software are overwhelmingly built around backlog intake and prioritization scoring, not deprecation tracking. There is no default “sunset” column in Jira. Nobody builds a dashboard for what you stopped doing.
Deen's point is that improvement is not synonymous with adding features. Eliminating and reducing can sharpen the customer journey, lower operating complexity, and, crucially, make the product's actual advantage legible again. A smaller, sharper product is often a stronger competitive position than a broader, muddier one. This is the same logic behind P8's decide-layer approach for founders: the constraint most teams face isn't a shortage of information, it's a shortage of a defensible answer to what to do about it, in either direction, build or kill.
The Four Moves of ERIC
ERIC asks four questions about your proposition, and it deliberately gives the first two equal weight to the last two:
- Eliminate, what can you remove entirely? Which features, steps, or options exist only because they once seemed like a good idea? Removing them reclaims focus and shrinks the surface you have to maintain and explain.
- Reduce, what can you shrink below the industry's default? Where are you over-serving, more configuration, more steps, more edge-case handling than your target customer actually values?
- Increase, what should you push above the industry standard because it's genuinely differentiating for your customer?
- Create, what should exist that no one in the category offers yet?
Most teams jump straight to Increase and Create. The strategic edge usually hides in Eliminate and Reduce, because everyone else is ignoring them too.
This isn't unique to product management. A comparable logic underpins the ERIC compilation of implementation strategies used in health services research, where removing or de-implementing an ineffective practice is treated as a distinct, equally rigorous strategy alongside adopting a new one, not an afterthought to it.
The ERIC Decision Canvas
Run every proposed or existing feature through this canvas. Give the top row as much weight as the bottom.
ELIMINATE What to remove entirely, and what it frees up.
| REDUCE What to shrink below the norm, and where we're over-serving.
|
INCREASE What to push above the standard because it differentiates.
| CREATE What to introduce that the category lacks.
|
Keeping the four fields on one page, at equal size, is the whole trick. The moment Eliminate and Reduce get a smaller box or a footnote, the canvas has quietly become an add-more list again.
Questions That Qualify a Stop
A stop decision needs the same rigour as a build decision, otherwise it's just a hunch dressed as strategy. Before you eliminate or reduce something, answer:
- Evidence and confidence, what tells you this isn't pulling its weight? Usage data, support load, onboarding drop-off? How confident are you, and what would change your mind?
- Customer journey, where does this sit in the journey, and for whom? Removing a power-user feature and removing a first-run step are very different risks.
- Strategic fit, does this support where you've chosen to compete, or is it a leftover from a direction you've since left?
- Reversibility, if you remove it and you're wrong, how expensive is it to bring back? Cheap-to-reverse removals can move faster.
These four map directly onto the “one thing to stop” slot in the Monday product briefing, ERIC is how you find the stop; the briefing is where you commit to it. P8's own glossary defines the Monday Brief as a short, ranked list traced back to what a customer actually said, the same evidentiary bar this canvas asks you to clear before you remove something, not just before you add it.
Subtraction as a Weekly Habit
The distinctive framing, “what not to build,” is worth protecting precisely because it's rare. It travels well, it starts arguments in the right way, and it earns attention even when the search volume for “feature prioritisation” is bigger. But the real payoff is operational: when subtraction has a standing slot in your weekly ritual, feature creep stops being an annual clean-up crisis and becomes a Tuesday.
This connects back to the root discipline in how to decide what to build next: a decision brief with no “alternatives considered, including stopping” field isn't really deciding, it's just approving.
Want one evidence-backed stop recommendation to start with, instead of auditing the whole backlog yourself? Ask P8 for your first brief.
This article adapts the ERIC framework and customer value map from Build the Right Thing (Amazon listing) by Haja J Deen and reinterprets them for weekly product decisions. Product capabilities described reflect P8's current approach, not a guarantee of specific features.
