Feature factories

It's Monday morning and the product owner is focusing the meeting on adding new stories to the backlog: "let's include an advanced filter for the monthly summaries; we'll integrate orders with the new CRM and build a customizable dashboard." María, a senior developer, comments:

—And what we saw last week, that 70% of users abandon their purchase during the verification process?

—We'll get to that next quarter, otherwise we won't move forward.

This is a common situation: measuring progress by the features shipped, without paying attention to or understanding the real needs of users. The slide from "agile company" to "feature factory" is not intentional. It arises from the good intention of increasing deliveries to the client and demonstrating the team's capability, but the problem is that it shifts the measure of success from "problems solved" to "features delivered." This mindset is based on the traditional way of understanding productivity, which has measured success by the number of units produced. When the same logic is applied to products and services based on knowledge, a team that adds ten new features seems more productive than another that, in the same time, perfects a single critical experience, even though it generates ten times more value.

Warning signs:

• Retrospectives focus more on times and velocity than on the value delivered.
• There is no connection between business metrics and product decisions.
• In refinement and prioritization decisions for features, the key question is not "why?"

The point is not to fall into analysis paralysis, stunting the product's scope, but to ensure that features are aligned with the company's product strategy and connected to the real needs of the client; because, yes, it is true that besides the client's needs there are market pressures and expectations from all stakeholders. To deal with the interests that circumstances add to those of the client, a useful framework is to classify initiatives into three groups: parity features (those necessary to compete), differentiating features (those that set us apart), and experimental features (for solving problems).

The key is not to consider them equally. Don't spend the same effort copying what the competition does as on deeply understanding our unique users. The proposal is to achieve a balance between differentiating, experimental, and parity features, which is most appropriate for the product in its environment. Analyze, in the answer to "why?" for each feature, what role they play: solving a problem and strategic reasons.