4 ms·

Too much fluff. Keep it simple. A good PM can clearly articulate what is to be build and why. In my experience, the why is often completely lacking. Zero resea

by fleddr 4y ago

Too much fluff. Keep it simple. 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.

danielmarkbruce 4y ago
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".
- fleddr 4y ago
  Those are fair counter points. 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.
  - danielmarkbruce 4y ago
    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.
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 ago
  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.
  - q7xvh97o2pDhNrh 4y ago
    Sure, 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.

by fleddr 4y ago

danielmarkbruce 4y ago

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".

fleddr 4y ago
Those are fair counter points. 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.
- danielmarkbruce 4y ago
  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.

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 ago
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.
- q7xvh97o2pDhNrh 4y ago
  Sure, 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.