The fastest way to waste a quarter is to start from a capability. Somebody demos a tool, the room gets excited, and the next four weeks go into finding a problem worthy of it. The work looks productive and produces nothing.
I try to run it the other way. Start from the experience that is broken, describe it in the user's own words, and only then ask what the smallest thing is that would fix it. The size of the problem sets the size of the solution you're allowed to buy.
A big problem — order rejections nobody can interpret, hitting thousands of users on a volatile day — can justify a new vendor contract, a schema change, months of engineering. That's a fair trade. A small problem doesn't deserve an hour of engineering time, let alone an AI copilot bolted onto it.
The temptation is enormous right now, because AI makes every problem look like it has an elegant solution. Most of them have a boring one: a clearer label, a default changed, a screen removed.
Working backwards also changes who you talk to first. Start from the tech and your first conversation is with an architect. Start from the problem and it's with support — and support already knows the answer, because they've been repeating it in tickets for months.
The order matters more than the rigour. A rough problem statement written before the solution beats a beautiful one written afterwards to justify what you had already decided to build.