This message was deleted.

Pragmatic advice that has helped me in the past 🙂 1. Establish a time boundary for prioritisation (aim for longer at first) 2. Push for a very lightweight PRD or project document Then use the above as leverage to push for better problem definitions. You’ll get better over time at defining the specifications and can grow them and make the process more sophisticated if you need. Go simple at first. At my previous company, this meant implementing a variation of Shape Up. Six week iterations, proposals were in markdown in a repo. Repo flow helped adoption of the process, developers like GitHub, and they like enforcing standards, combine the two and voila! Discussions on where investments would be placed were held weekly. This cadence, visibility and push towards defining the problems on paper helped. Oh, and also, be patient and kind to yourself. Impact and change on this stuff takes time and progress can come in waves.

in technology teams there's always very strong tendency to speak solutions and not the problems. I would start with exactly naming the problem, user need, business outcome, value and/or opportunity. If the stakeholders start with solution, ask why they need that, what user needs will be address, what business value will be delivered and with that you will eventually get to opportunities that should be prioritized. Every solution exists to address some problem, if the problem is irrelevant, solution is irrelevant as well, how do you know that problem is irrelevant if it is not even stated? Be perseverant, no one is going to challenge this approach 🙂 I tried it with very positive feedback although it was new to everybody