It is easy to look at a busy backlog and think, “We are making serious progress.” Add a filter, create an endpoint, move a button, build an export. I enjoy the sense of order too; closing tidy boxes feels good. Sometimes every box closes and the customer’s problem stays exactly where it was.
“Manage problems, not features” does not mean that I dislike building things. It means holding back the urge to decide the answer for five minutes and becoming curious about what is actually broken. Those five minutes can prevent weeks of very organized work in the wrong direction.
Where does a feature request come from?
When a stakeholder says “we need a Remote Start button,” the sentence is usually a signal packaged as a solution. The underlying problem can be different: users cannot find an existing action, charger state arrives late, authorization fails, or operations needs a controlled way to trigger a process remotely.
If the button goes directly into the backlog, we attempt to cover all of those possibilities with the same implementation. The first move is not to reject the request. I note the button and ask a few curious questions instead: Why do we need it, who gets stuck, and what happens today?
I look for the following parts in a useful problem statement:
- Who experiences the problem?
- At which step of the journey?
- How frequently and at what scale?
- What is the user or operational impact?
- Which log, SQL query, interview, or support ticket supports it?
- Which metric should change if the problem is solved?
When those questions are unanswered, we have a hypothesis rather than a confirmed problem. A hypothesis is still useful; it simply should not be planned as a fact.
How Jira becomes a feature factory
Feature-shaped work is easy to estimate and report. “The button is complete” is a clear status. “Reduce charging-start failures” spans multiple teams and unknowns. Organizations reduce that discomfort by planning outputs rather than outcomes.
The roadmap becomes a shopping list and the sprint report becomes a count of closed tickets. Everyone gets tired, the system grows, and when the customer metric stays flat we add another feature. It may be the most orderly way to work very hard without moving.
One problem has several classes of solution
Once the problem is clear, the answer is not always more software:
- Existing copy or UI hierarchy may change.
- Data quality can be repaired.
- An operational process can be simplified.
- An unused feature can be removed.
- Monitoring or support flow can improve.
- Sometimes doing nothing is the correct decision.
Each option should be compared through cost, risk, reversibility, and expected effect. A small reversible experiment may produce more learning than a large feature.
Acceptance criteria should protect the outcome
When acceptance criteria describe only UI or API behavior, the team can build exactly what was requested without solving the problem. Strong criteria have two layers:
- Product outcome: Which user or operational behavior should improve?
- Delivery safety: Which edge cases, permissions, monitoring, and rollback conditions must be protected?
“The button is visible” is a delivery condition. “A user in an eligible state can complete the action, an ineligible user receives an understandable result, and failures are measured” protects the problem space more effectively.
Learning after release
The ticket can close when the feature ships; the problem is not closed yet. The team must revisit the metric, segments, and side effects selected in advance. If the outcome does not improve, either the solution was weak or the problem definition was wrong. Both conclusions create useful information.
I am not trying to build a perfect discovery ceremony. Sometimes changing a ticket title from “build this screen” to “why does this user stop here?” is enough to change the conversation. It is a small wording change, but the team remembers which answer it is looking for. I get to manage curiosity again, not only a list of things to ship.