5 ms·
> clearly articulate what is to be build 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 bi
by q7xvh97o2pDhNrh 4y ago
> clearly articulate what is to be build
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.
- adeelk93 4y agoIn 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.
- q7xvh97o2pDhNrh 4y agoSure, that's totally reasonable. The PM can bring those constraints to the table; the Engineer brings other constraints from their perspective; and the Designer brings even more. Then they work together to creatively explore the problem space and converge on a solution together.
- jjav 4y ago> 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.
- tpoacher 4y agoJust 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).