4 Musts of Building a New Feature

December 27, 2025

A CTO’s guide to reducing waste, increasing learning, and shipping what matters

As CTOs, we like to believe that building features is a technical problem. If the architecture is clean, the code is solid, and the team is strong, success should follow.

Reality disagrees.

Most failed features don’t fail because of bad code. They fail because we invested heavily before we learned enough. We optimized execution before validating direction. We treated uncertainty as something to be managed later, instead of the core problem to solve first.

Over the years, I’ve learned that successful feature development is less about brilliance and more about discipline. There are a few non-negotiable principles that, when applied consistently, dramatically increase the odds that a feature will deliver real value.

This article outlines a few of those principles.

1. Start With Effort vs. Risk - Not With the Solution#

Every new feature carries two independent dimensions that are often confused: effort and risk.

Effort is the cost we can reasonably estimate upfront:

• Engineering time
• Number of people involved
• Infrastructure changes
• Coordination overhead

Risk, on the other hand, is about uncertainty.

• How “researchy” is this problem?
• How many assumptions are we making?
• How confident are we that this will work - technically and for users?

Both can usually be classified as low, medium, or high.

The mistake many teams make is assuming that high effort automatically implies high risk, or worse, ignoring risk entirely. In practice, risk is what causes effort to explode.

A feature that looks like “medium effort” can quietly turn into a multi-quarter project if the underlying assumptions are wrong.

Before committing to a solution, I insist on explicitly placing the work on an effort–risk matrix:

• Low effort, low risk: execute quickly.
• High effort, low risk: plan carefully, but proceed.
• Low effort, high risk: perfect candidate for experiments.
• High effort, high risk: stop. Break it down or reduce uncertainty first.

This framing forces a critical shift: our first job is not to build, but to learn.

2. Break the Feature Until It Can Be Deployed#

Large features fail in predictable ways. They take too long, hide feedback, and accumulate irreversible decisions.

The antidote is deceptively simple: never build a feature as a single unit.

Instead of asking, “How do we deliver this feature?”, ask:

“What is the smallest version of this that we can deploy to production?”

This is not about cutting corners. It’s about vertical slicing - delivering thin, end-to-end increments that work in the real system.

This step is also iterative with the effort vs. risk assessment. Breaking a feature apart is often how hidden risk reveals itself. What initially looked like a single medium-effort task may turn out to contain a high-risk component that deserves its own experiment, or a low-risk slice that can be shipped immediately.

Each slice should:

• Be deployable on its own
• Reduce uncertainty
• Move the system closer to the final vision

Sometimes the first slice delivers no visible user value. That’s fine. Internal value counts too:

• A backend capability behind a flag
• A new data pipeline with no UI
• A manual workflow that validates demand

If it can’t be deployed, it’s too big.

Breaking work into small components does more than improve delivery speed. It changes how teams think. Progress becomes measurable. Risk becomes localized. Decisions become reversible.

3. Fail Fast, Fail Often - On Purpose#

Failure has a bad reputation in engineering cultures, usually because it arrives late and costs too much.

But failure itself isn’t the problem. Delayed failure is.

When we break features into deployable parts, we unlock the ability to fail early - when failure is cheap and informative.

Failing fast means:

• Shipping before we feel “ready”
• Exposing assumptions to real users
• Letting reality correct our plans

This requires operational discipline:

• Feature flags to control exposure
• Incremental rollouts
• Monitoring from day one

It also requires cultural discipline. Teams must understand that early negative signals are not a sign of incompetence, but a sign that the system is working.

The goal is not to avoid failure. The goal is to maximize learning per unit of effort.

4. Define Measurable KPIs Before You Write Code#

A feature without success metrics is not a feature - it’s a hypothesis.

Before implementation begins, we must be able to answer a simple question:

“How will we know if this worked?”

Good KPIs are:

• Measurable: based on observable data
• Actionable: they inform a decision
• Aligned: they reflect real user or business value

Examples include:

• Adoption rate
• Frequency of use
• Retention impact
• Performance or cost improvements
• Time saved for users

Vanity metrics don’t count. “It feels useful” is not a KPI.

One often-overlooked detail: KPIs are not free. Tracking them requires instrumentation, logging, dashboards, and ongoing maintenance. That effort must be part of the feature’s cost from day one — not an afterthought.

If a metric is important enough to define success, it is important enough to build proper visibility for.

KPIs serve a second, equally important role: they give us permission to stop.

If a feature fails to move its metrics after sufficient iteration, the data gives us cover to deprecate it. This is how organizations avoid accumulating dead weight disguised as progress.

The System Matters More Than Any Feature#

These four principles are not independent. They reinforce each other.

Evaluating effort vs. risk pushes us to reduce uncertainty early. Breaking features into small deployable parts enables fast learning. Failing fast shortens feedback loops. KPIs anchor decisions in reality.

Together, they form a system designed for learning, not heroics.

As CTOs, our real responsibility is not to ship features. It is to build organizations that can discover what to ship - efficiently, repeatedly, and with humility.

In the long run, the teams that win are not the ones that build the most. They are the ones that learn the fastest.