The interface is usually downstream of the real problem.
A feature request is often the final translation of a messier operational problem. Good product work starts by reversing that translation.
A business rarely experiences a problem in the same language that a product team receives it. By the time a request reaches a designer, the problem has usually been translated several times: an operational frustration becomes a management preference, the preference becomes a requirement, and the requirement becomes a feature request.
The feature can be correct and still solve the wrong thing.
Imagine an appointment-based business asking for same-day bookings to be blocked. The requirement sounds clear. A developer can implement it perfectly. But the quality of the product decision depends on what created the request in the first place.
Perhaps practitioners are not always onsite. Unexpected bookings create staffing problems, so the business wants protection. But on some days a practitioner is already available and would happily accept additional work. A permanent block removes the operational risk by also removing legitimate revenue.
The better question is not “How do we block same-day bookings?” It is “How do we protect practitioners from unpredictable demand while preserving optional capacity?” That question produces a different system: a default notice period, a practitioner-controlled same-day switch, eligible slots that appear only when capacity exists, and a normal booking experience for the customer.
The interface arrives last.
None of this is particularly impressive as code. The important work happened before the interface: identifying the constraint, separating the default rule from the exception, deciding who should control the exception, and making sure the customer does not have to understand the operational complexity behind it.
This is why I think product design is often less about adding screens and more about correcting translations. The feature request is evidence. It is not always the problem.
A useful sequence is: symptom, context, constraint, behaviour, rule, then interface. Starting at the interface makes a product team efficient at producing answers. Starting at the constraint makes it more likely that the answer is worth producing.
The most valuable product decision may therefore look almost disappointingly simple when it reaches production. Simplicity at the surface is often the result of complexity being resolved earlier, where the customer never has to see it.