Monday, September 7

Just because something became easy to build doesn’t mean it’s a necessary feature | XPLORED

Monday, September 7

Just because something became easy to build doesn’t mean it’s a necessary feature

Just because something became easy to build doesn’t mean it’s a necessary feature — Image source: Medium · Kristine Breum

1. Implementation cost and the total cost of a product are different

Even if AI reduces development time, that does not make the decision to add a feature any cheaper.

In the past, limited development resources served as an opportunity to review whether a feature was necessary.
If implementation shrinks to a matter of hours, the several days spent on user research may feel expensive instead.

2. Hidden costs accumulate after launch

The development time for a single feature makes it hard to explain the burden a product will take on.

Costs include not only maintenance, but also user inconvenience, support and training, and loss of trust.
- Such burdens are spread across multiple people and over time, making it difficult to trace the cause.
In the study cited by the original article, faster initial development did not lead to benefits in subsequent maintenance.

3. Faster improvement does not validate the original assumption

Once a feature exists, it is easy to focus on improving its completeness rather than re-asking whether it is needed.

Even if conversion rates or usability improve, the wrongly defined problem may remain.
Once users begin to rely on a feature, removing it also creates new costs.
- Something that was easy to add is not necessarily easy to roll back.

4. Criteria for choosing what not to build

As implementation becomes faster, deciding what to build becomes more important.

Repeating imperfect judgments quickly causes even small burdens to accumulate into product-wide complexity.
Just as execution speed increases, time is also needed to examine problems and assumptions.

XPLORED View

When reviewing the value of a feature, it is worth placing the post-launch burden next to the development estimate.

Good times to read

When the suggestion “it can be built quickly, so let’s add it” keeps coming up
When you keep improving a product, but it becomes more and more complex

Takeaway points

Look at user and operational burdens alongside implementation time
Distinguish between questions that improve a feature and questions that verify whether the feature is necessary