Excellent historical perspective on how we ended up with applications filled with annoying interruptions and notifications. It's been done indeed one step at a time and lead to poor UX really.

This is a good overview of what the Staff Engineer can be. There's of course a lot of variation depending on time, priorities and the culture of the organisation.

The definition of ready can be a big help avoiding too many questions about stories as they are implemented. They should be clear before hand.

This is a very good resource on the different ways to split user stories.

This is a good introduction to what product management really entails.

For technical tasks, the user stories common structure (the "Connextra format") is not adequate. We can indeed take inspiration from other long forgotten agile approaches for alternatives. I particularly like this one, and it works for user stories as well in my opinion.

There's a balance to strike on quality. Too much or too little and you won't be able to progress towards the user needs.

I wonder what the whole series will give. Anyway I very much agree with this first post. Too often projects have a single product manager and that's a problem.

I wouldn't frame it as always superior (I'd argue the article falls a bit in this trap). Still this can sometimes be an alternative to driving everything purely on project mode. Some organizations would benefit from such a change of perspective other less so.

I don't think it's always unfolding exactly like this but there's some truth to that. Most projects see a "let's rewrite it in X" phase, this is rarely the best outcome.

I think this is still one of the best distilled explanation of product ownership. It's also interesting for the other parties on an agile project.

There's often confusion as to where the management responsibilities are in agile teams. This little rambling does a good job pointing it out and giving an idea of how management happens inside and around teams.

Interesting thinking around a portfolio of activities. You can prioritise differently within it to manage quality vs speed of delivery over time.

Nice tricks to say no when people push to get something in a product. 😉

Struggling with making your first technical roadmap? Driving it from measurable problems is a good first step.

A good reminder of what agile is about from the product management perspective. If you can regularly demo your work you ensure a feeling of progress.

Excellent piece which shows why React (or Angular) is almost always a bad choice and that you'd be better off banking on the underlying web platform. It leads to better user experience full stop. The article also goes in great length debunking the claims which keep React dominant.

A bit biased toward stable product teams only. Still, there are good tips which are more widely applicable here. This gives a good idea of the management of a distributed team of remote workers.

This is accurate in my opinion. Engineering and product teams need to properly negotiate, otherwise quality will suffer.

Interesting guidelines idea to help teams manage the priorities themselves. It's written in the context of a product manager but I think it is lightweight and generic enough to apply in other contexts.