The Feature Fallacy
Why shipping more isn't helping your users, and what to do instead.
If you measure progress by how many features ship, you'll eventually ship yourself into irrelevance.
In healthcare, and increasingly across every SaaS category, the teams that win aren't the ones with the longest release notes. They're the ones with the shortest path to a meaningful outcome.
This isn't anti-shipping. It's pro value density: the ratio of outcome created to effort required. When value density goes up, adoption, retention, and trust follow. When it goes down, your backlog grows faster than your business.
Three invisible taxes you're probably paying
- Context-switch tax. Every new feature branches the mental model, for users and for teams. Users pay with cognitive load; teams pay with QA, docs, analytics events, and support scripts. The more branches, the slower everything gets.
- Adoption tax. Features don't adopt themselves. They need activation points, enablement, and discoverability. "Shipping" without an adoption path is just inventory.
- Quality tax. More surface area means more edge cases. In regulated spaces like healthcare, quality debt compounds with safety and compliance risk. It's quiet, until it isn't.
A better north star: outcome-first, evidence-backed, minimally sufficient
I use a simple loop that travels well across domains:
- Outcome-first: Define the end state in observable terms (for example, "Reduce median prescription time from 4:30 to 2:00").
- Evidence-backed: Tie the bet to a falsifiable hypothesis and minimum viable measurement plan.
- Minimally sufficient: Ship the smallest intervention that can move the outcome for a narrow segment. Then scale.
Think OEM: Outcome → Evidence → Minimum.
What to do this quarter
- Replace roadmaps with bet maps. "We believe doing X for Y segment will drive Z outcome." Add confidence, leading indicators, and kill criteria. Review monthly. Kill or double down based on signal, not opinions.
- Segment before you scale. Design for one high-value workflow first (for example, "charge nurse during shift change"). Optimize locally, then generalize. Cleaner UX, clearer causal signal.
- Default to workflow, not widgets. Ask, "What steps disappear?" not "What screens can we add?" Inline actions, automation hooks, and smart defaults tend to beat net-new features.
- Measure the path, not the page. Instrument end-to-end: start rate, completion rate, time-to-complete, drop-offs. Report "time-to-outcome" like you report uptime. Latency that matters is the user's time-to-value.
- Design for reversibility. Feature flags, shadow modes, opt-in cohorts. Make wrong bets cheap and reversible; make irreversible bets rare and deliberate.
A quick example (healthcare, but universal)
Problem: Clinicians were abandoning an Orders flow at 38% completion. The instinct: build "Orders 2.0" with templates and bulk actions.
The OEM approach:
- Outcome: Raise completion to 70%, cut median time from 3:10 to 1:45.
- Evidence: Replays and path analysis showed friction on patient context switching and code search.
- Minimum: Auto-attach patient context, pre-populate three likely order codes by unit and shift, add keyboard-first quick search.
Result (6 weeks): 74% completion, 1:41 median time, zero net-new "features." Massive value density.
How Product and Engineering win together
- Product: ruthlessly prioritize the fewest interventions that move the outcome. Own problem definition and kill criteria.
- Engineering: collapse time-to-learning. Instrument the path, ship behind flags, and treat reliability, latency and observability as user value, not plumbing.
- Ritual: a weekly Outcomes Review. What did we learn? What can we ship next week to learn faster?
The courage to delete
Create a quarterly decommission list. Remove underused features, consolidate patterns, and redesign flows that require explanation. Celebrate deletion with the same fanfare as launches.
The ask
If you're shipping a lot but moving little, run OEM on a single critical path this month. Define the outcome, gather minimal evidence, ship the smallest intervention, and measure the path. Send me your before and after, and I'll share the best anonymized examples.
