Start With the Requirements, Not the Tool

Some of the most valuable work I've done is requirements gathering: sitting with people, learning what a system actually needs to do, writing it down before anyone shops for software. The order matters. Requirements first, tool second. Teams that shop first end up bending their work around whatever they bought.

AI adoption is running this backwards everywhere I look.

A team hears about a tool, buys it, and then hunts for problems to point it at. Six months later they're maintaining an expensive solution in search of a problem — and the actual needs, the ones a requirements session would have surfaced in a week, are still unmet.

Don't automate chaos. And don't shop before you know what you're shopping for.

Start where my systems work always started: what decision are we trying to improve? What does good look like? What are the constraints — the data, the rules, the people affected? Write that down first. Then evaluate tools against it.

Requirements first, tool second. It's slower for a week and faster for years.

I explain frameworks; I don't give legal counsel.