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.

Good idea on how product managers should behave to facilitate requirements handling. I wish more of them would do this.

He is spot on again. The scope is what will allow to create flexibility in a fixed price project. This is what leads to the necessity to work incrementally.

Nice way to keep in check how and why behavior changes as the requests from various stakeholders come in.

This is an interesting framing of the question. We often talk about the scope, but how thorough are we when handling it? Should we even be that thorough? Might make some of the trade offs more explicit.

A bit long and a couple of mistakes when pointing out the flaws of story points. Still, it's definitely a worthwhile read. Quite a lot of the criticism of story points is warranted and the proposed approach based on queue theory is welcome. This is stuff you can find in Kanban like approaches and mature XP.

This is indeed a good way to classify events probability in requirements. It definitely impacts how you handle them in software.

This is definitely an ambiguous term. You need to know where stand the people employing it in order to figure out the exact meaning of "root cause".