In the startups I've worked at, where they start hiring in product people, the point in time that normally happens it that critical t0 point. Basically, where the innovation will have to slow down, because you need to stop thinking about just coding the solution but start on the build pipelines, tests, infra, support, analytics, feedback loops... And yes, you can think of these things on day one, but it is that point, t0, where you need to actually have those things defined (even if it's simply a wikipage that has"No" written on it). And that is the point of bringing in a PM.
The worst PMs I've worked for aren't the ones who stifle innovation. The worst are the ones who encourage it to increase the feature factory appearance to make their own CVs look good. The best ones gather and present the data to inform the decision that the team has to make.
But in terms of power, yes there needs to be an emphasis on them being facilitators of the conversation and not the decision-makers. As Devs (QA, DevOps, SRE etc) we need to make sure that it isn't a one sided decision and learn to argue without undermining or name-calling.
+1 on this. People forget product development is a collaborative process. If a PM is just chucking work over a fence, they’re not a PM. They can’t be doing their job effectively if they’re not spending as much time with developers as with customers.
Well, Section 28 happened here in the UK in the 80's, and that was targetting teachers (and local councils) that didn't toe the central government's homophobic agenda.
I recall working on a project a few years ago that had it in place. The end client was a hundred year old company, with bricks and mortar stores, that needed a boring, stable solution that had several key features. They would take only the older version that we built for the escrow, so that if things went sour they had a workign solution that they would have the source-code for that could be given to another company.
On the one hand it was a pain to work towards, as the requirements had little immediate value (new features needed lengthy documentation, lots of features had to be stripped out, long (manual) test checklists, etc) but on the other hand, it got you thinking about how to build software that would need to last longer than the company you're in. Made me realise that feature creep/bloat was what was holding the product back, not the Next Big Thing(tm).
