The quickest way to waste a month is to start sketching screens before you've named the constraint, the bottleneck, and the behaviour you're trying to change. AI makes this worse because it creates the illusion that the hard part is the model. It isn't. The hard part is deciding what job the application is actually being hired to do.
Write down the pain in operational language
I want teams to describe the problem in terms of time lost, revenue missed, errors repeated, or decisions delayed. Not in product language. Not 'we need a dashboard'. Usually the real problem is something like: sales notes live in six places, nobody trusts the numbers, and decisions get made off stale information.
A framework beats a feature list
Once the pain is named, the framework gets simple: input, decision, action, outcome. What information enters the system, what decision needs to happen, what action should follow, and what business result proves it worked. That sequence is far more useful than a vague backlog full of shiny ideas.
Build the shortest path to a changed behaviour
The first version should exist to change one behaviour decisively. If the app cannot make one thing faster, clearer, safer, or more accountable in the first session, it is too broad. Every useful product I have shipped started by being aggressively specific.