Before You Ship Another Feature

Adding a feature feels like progress because the diff gets bigger. Unfortunately, customers do not pay by line count. They care whether a problem becomes easier to solve.

Before extending the product, find the current bottleneck. You may need another capability. You may need a clearer label, a working integration, a faster response, or fewer steps. The last three make terrible announcement threads and excellent products.

Describe the stuck moment

Turn “users want dashboards” into an observable statement: “After processing a batch, bookkeepers cannot see which invoices need review, so they export everything and rebuild a checklist.”

If you don’t know the moment, ask for a recent example or watch someone use the product. Avoid filling the gap with the loudest customer’s proposed solution. Their experience matters; their suggested implementation is one hypothesis.

Write a one-page decision note:

1. Who is affected, and how often?
2. What are they trying to accomplish?
3. Where do they get stuck today?
4. What evidence supports this account?
5. What small change could remove the obstacle?
6. What outcome would tell us it worked?

If you cannot answer the fourth question, you have a research task before you have a feature task.

Compare alternatives that don’t add permanent surface area

A requested CSV export might be right. It might also indicate that the summary is missing a field. A complicated permission system might be necessary for enterprise teams, or it might be solving a sales request from a customer you cannot responsibly support yet.

Consider a manual service, a documentation improvement, a change to defaults, removal of a step, or a limited experiment. Include “do nothing yet” as an option. The point is not to refuse work; it is to avoid building a permanent machine to test a temporary guess.

Every feature creates obligations: error states, support, access control, migration, documentation, and future compatibility. The settings page is not a junk drawer with an infinite warranty.

Example: the dashboard detour

Five users complain that they cannot tell whether an invoice import succeeded. You could build a dashboard with filters and charts. Or you could show a clear completion summary with the number processed, the number needing review, and a direct link to the exceptions.

Ship the summary to a small group first. Observe whether they can answer “Did it work?” and “What should I do next?” without contacting you. Track support questions and successful task completion across the next few uses.

If users still need to compare many batches over time, you now have a clearer case for a dashboard and better evidence about what it should show. You didn’t just delay the larger feature; you improved its specification.

Make the release reversible

Define a review date and the signal you want to see before shipping. For a frequently used workflow, that might be two weeks of task completions. For a long sales cycle, it may be a different interval. Avoid treating the example timeframe as a law of physics.

Keep a way to roll back the interface without losing records. Use migrations carefully; don’t couple a cosmetic change to an irreversible data transformation. Test the main success path and what happens when the external dependency fails.

After release, examine whether the intended people used the change, whether their task became easier, and what new problems appeared. Low usage is not automatically a marketing problem. The feature may be unnecessary, invisible, or badly timed.

The ten-minute preflight

Before starting the next feature, name one real stuck moment, one piece of evidence, one cheaper alternative, one outcome measure, and one rollback path. Then decide what to do.

Sometimes the answer will be “ship the feature.” Great. Sometimes it will be “fix the thing we already shipped.” Also great. Maintaining a useful product is not a failure of imagination.

The roadmap can survive a smaller box. Your customer may finally get through it.