Agile and its blindspots and prototyping your way out of ’em

I’ve tried to work totally in lock-step with the team (following advice from Agile proponents) but after reflecting on that, I don’t think even the developers I’m working with want that. It’s perhaps a theoretical proposition that either I’ve misinterpreted, or maybe it’s only good for specific team/s.

Anyways, prototyping ahead of the team and refining is something I’m going to return to. Agile purists – sorry! I tried.

https://www.axure.com/blog/the-pitfalls-of-agile-and-how-we-got-here
https://www.axure.com/blog/avoiding-the-pitfalls-of-agile-with-high-fidelity-prototyping

Fundamentally, most of this could be fixed by PMs not prioritizing features on a backlog, but instead, clearly communicating the metrics, user needs, and company goals to the team, and then working collaboratively to figure out the best options.

https://www.usersknow.com/blog/2019/10/8/product-team-mistakes-part-2-selecting-estimating-and-prioritizing-features

I think this is really key to a productive (and enjoyable and effective) working relationship between PMs and designers. The best collaborations I’ve experienced have supported these ways of framing the work. Then we all (there are more than designers and PMs who should define what is to be be built) can work together.

Another good way of thinking about the above statement is outcomes, not output. Unfortunately output feels (and looks like) progress.