A good PM can clearly articulate what is to be build and why. In my experience, the why is often completely lacking. Zero research. Shady A/B tests with unclear conclusions. Pretty much the "why" is often somebody deep down in the business emailing a random idea. And it seemed cool and people want to please people rather than dismiss them.
With a clear and simple goal and why, if you have half-decent engaged engineers, they can now think along on how to best achieve the goal. This could refine the feature itself, its visual design, anything. The idea that product people have monopoly knowledge on product is ridiculous.
So with a clear and hardened idea you build it. Then we come to the other part that PMs never seem to engage in: feedback.
Did it work? Did anybody use the feature at all? Was the goal met? Did we get user feedback? Often lacking as engineers are to focus on the new sprint.
Engineers can't grow or feel product ownership if they're so far removed from its real world impact.
And as for my second trigger: don't "negotiate" technical debt. The idea that it's negotiable is why it won't get done, so make a stand and remove room for negotiation. It very much is in your power to do so.
I'm sure I'll sound like a jerk because this exact idea is taken as gospel: I still 100% disagree, though.
It is a bit incomprehensible to me. How could a non-technical person decide what is to be built? It would be like a farmer deciding which crops to plant — without knowing the critical details of the soil, the seasons, or the local environment.
IMHO, the role of a PM is three things:
1. Collaborate with Engineering and Design (as well as other relevant folks, like PMM) to collect, filter, and synthesize raw customer data. Together, turn it into a clear statement of the problem to be solved. If the PM needs to be fed some "leadership" kool-aid, then, sure — tell them it's their job to make sure the collaboration happens.
2. Build absolutely bulletproof reasoning around why this problem is the most important one to solve now. Maintain and update that reasoning as the data, the vision, and the solution all evolve. (This is the "value risk," in some modern product lingo.)
3. Continuously rally every internal stakeholder around that reasoning, and clear obstacles in the way of a successful business outcome. (This is the "viability risk.")
I think we actually mostly agree with each other. Your point about having a proper feedback loop — based on real data, rather than politicking and optics — is absolutely gold (and sadly rarely done).
Giving a PM sole ownership (or even "leadership") over the what to build piece, though, is a subtly slippery slope. Down that path lies the inflation of ego, the end of equal collaboration amongst the Product Trio, and the eventual snuffing out of psychological safety as everyone else checks out and stops feeling any real ownership in the product.
> How could a non-technical person decide what is to be built?
Agreed. My somewhat controversial position is that the rise to power of product management has ruined silicon valley. We now have non-technical PMs making decisions about technical details and prioritizations they are not qualified to have an opinion on. This leads to endless technical debt, security vulnerabilities, scalability problems, fragile systems, etc.
It used to be that PMs brought in requirements from actual customers and provided reasoned direction on where the product should go given what customers wanted and the competitive landscape. This was taken as a strong signal by engineering but ultimately it was engineering leadership that decided how to fit it into the roadmap along with all the other factors mentioned above (sane architecture, security, scalability, etc).
Today in most organizations, these other factors have no seat in the table and we only have PMs managing jira sprint stories, with the inevitable outcome of lousy products.
In your farmer analogy, you totally omitted that you need to consider market demand. That’s why you’re growing things in the first place. That’s not a technical decision, and totally is something the PM should understand.
Just because a PM makes "the decision" doesn't mean this should not be informed by the engineers. Consensus is not needed, but accountability and buy-in of all involved is essential.
Just because engineers are "informed" doesn't mean they get to make "the decision" (or indeed that they are the most suitable agents to do so in terms of goals and incentives).
It's harder that it seems to figure out what to do - because many orgs don't give PMs enough time to focus on that part of the job. Mostly because research can be weeks of no outcomes - just research research research. Most product managers know they don't know the market as well as they should and they face enormous pressure to "get things done".
Another issue is the lack of political capital. Very often a product "owner" doesn't own much at all. Some may have reasonable decision power but it's constantly undermined by powerful other stakeholders.
The problem often starts from the very top. Say a CEO tells the business to grow revenue by 20%.
The business/markets then come up with terrible ideas to do that. Aggressive, cutting corners, user-hostile, but likely to work in the short term.
Then they ask the PM to implement it. You can't stop it at this point.
Yup. Honestly at many companies the CEO is the only real decision maker and everyone else is just execution. No matter what their title says.
To your point on stakeholders - most PMs are just trying their best to balance the 35 different constraints/ideas thrown at them by the 5 or 6 most important stakeholders all while appearing upbeat and happy because the PM is supposed to be Miss/Mr/Mrs Positivity.
A good PM can clearly articulate what is to be build and why. In my experience, the why is often completely lacking. Zero research. Shady A/B tests with unclear conclusions. Pretty much the "why" is often somebody deep down in the business emailing a random idea. And it seemed cool and people want to please people rather than dismiss them.
With a clear and simple goal and why, if you have half-decent engaged engineers, they can now think along on how to best achieve the goal. This could refine the feature itself, its visual design, anything. The idea that product people have monopoly knowledge on product is ridiculous.
So with a clear and hardened idea you build it. Then we come to the other part that PMs never seem to engage in: feedback.
Did it work? Did anybody use the feature at all? Was the goal met? Did we get user feedback? Often lacking as engineers are to focus on the new sprint.
Engineers can't grow or feel product ownership if they're so far removed from its real world impact.
And as for my second trigger: don't "negotiate" technical debt. The idea that it's negotiable is why it won't get done, so make a stand and remove room for negotiation. It very much is in your power to do so.