Most Feature Requests Are Decisions in Disguise

Listen for the decision behind the request

In enterprise procurement, a request for a new approval step or a new field often means two groups disagree about who owns a choice. Building the feature without settling that disagreement just moves it into the software, where it is harder to see and more expensive to change.

So my first question is rarely "how should this work?". It is "what decision is this trying to make easier, and who is making it today?"

Good products remove decisions, not just steps

It is tempting to measure a product by how much work it automates. I think the better measure is the quality of the decisions it helps people make, and the number of unnecessary decisions it removes altogether. A workflow that asks a user to choose between five options they do not understand has automated nothing.

Governance is a product feature

In regulated environments, rules about who can approve what are not an afterthought. They shape adoption. When governance is designed into the product, users trust it. When it is bolted on, they work around it. Treating policy as part of the user experience, rather than as a constraint on it, changes what gets built.

Design for every customer, learn from each one

Large enterprise deployments are full of specific requests. The work is translating what one customer needs into a decision that improves the platform for every customer, rather than a special case that only one of them will ever use.

Where AI fits

I am now building AI-native enterprise products, and this lens matters even more. A model can read, summarise and suggest. The product still has to be clear about which decisions stay with people, and why.