Always. I’ve been practicing this for 10 years, most of which I’ve been working as a consultant building custom software for internal business processes, as well as customer-facing software for clients’ users. My typical process looks something like this when a feature/change request or random idea is asked for—which almost always comes in along the lines of, “Can we get X added in that does Y and looks like Z?”:

1. I never say yes to any request immediately. I always tell a client, “Anything is possible that doesn’t violate the laws of physics, but let’s dig into this more.”

2. Ask what they’re trying to accomplish. What problem are they trying to solve? What mistake are they trying to prevent? What is the end goal? I ask questions until I can explain back to the customer what they’re really wanting to do and why.

3. I then push back on why I think we should not do what they’re asking for in the way they’re asking for it. Not in an asshole way, but I do challenge their request, its utility, the value it will bring the business/customers/employees, etc. When doing this, I always spend time on educating them on the tech behind the scenes, potential pitfalls, how adding something (especially if it’s visible to people) will make it nearly impossible to ever remove it once users get used to it, when they’re asking for something that would be more effort the way they’re asking for it to be done than it’s worth when it’s trying to solve for a rare edge case, etc.

4. After explaining the problems with their idea as given by non-experts, I start suggesting other ways we could accomplish their goals--using a simpler UX, or even no UX at all--relying on the ability to automate things if we have enough information, hiding all the complexities of a given business process behind a single button once we have the right info to intelligently take action.

5. I give a couple of recommendations for potential ways forward that solve the real problem in a way I’ll enjoy building it out. I spend time explaining what I see as the benefits & trade-offs with my suggestions for solving their problems, as well as how long the options should take. I try to always include at least one option that is as simple and quick-to-build as possible (internal MVP approach), and one option that has more bells and whistles (when relevant/appropriate). Then I let them make the choice.

Following this pattern has pretty much never failed me. What feels best about it is when I see clients actually learn how their software works when I’m working for them. I love it when they remember the discussions we’ve had, internalized it, and recall it when we talk 6 months later about their new idea. Over time, their ideas improve because their understanding of how their software works improves. They also become increasingly invested in our working relationship as their trust in my concern for solving their problems—and not just doing their bidding—increases.

Never shy away from challenging your customers’ ideas—but always do it in a respectful manner that gets to the heart of their real problems and educates them along the way. They’ll appreciate it, and will keep coming to you for more. I don’t think this is unique to being a consultant, either—the same sort of process can be followed with direct users of your own product.