[goldcd]

Sorry, definitely wasn't saying "hide projects from devs"

As PdO I see my job (and also that of my partner Dev Manager) as sheltering dev from the shit churning shit above and my sole purpose as providing backlog/semi-coherent guidance. My downward job is to make sure every 2 weeks some contiguous stories get created and I sign off on their completion on the way back up - and if my requests match what I get back, I have the joy of absorbing any corporate wrath. I'm a "shit-umbrella"

Positive part of the job is when something hits me I can't deflect, I can cash in a few of my 'hopefully not-a-cunt' credits from the team, explain why I'm changing backlog mid-sprint, throw myself at their mercy, explain the issue etc etc - and collectively provide a better result than'agile' could officially provide.

[ec109685]

I still think you’ve set things up so that the direction for the whole team almost exclusively has to come from you.

If you could share this responsibility with the team so they know the context and outcomes desired by the business, you’ll have a larger pool of good ideas, including from folks who deeply know the code and push the roadmap from that perspective.

E.g. creating a holistic thinking environment: https://headheartbrain.com/resources/creating-a-thinking-env...

[goldcd]

On the bi-weekly sprint planning - yes. From what's actually on the backlog - definitely not.

Opportunity Team meetings (or stakeholder chats - lead devs, architects, support peeps etc) always cover the general direction we want to go and are where the ideas for the backlog come from.

Example of easy benefit is if we have two things we want the product to do - this is where you learn what the options are and more importantly the rough costs/impacts. If something's going to cost 10x as much and require refactoring, I suddenly decide I don't want it as much as the other option.

Can also come up from mid-sprint from dev. (Real example) I had a US to add a new button. Dev noticed there was an internal 'button framework' already in place (as somebody had some a good job in the distant past). She asked if I could add a new US for next sprint to continue this work, so she could extend this framework and allow us to publish it. i.e. Focus on adding new controls to the config tool, and then delivering on the original US with a bit of config. I had no idea this untapped potential even existed - but for 2 weeks effort of one person, my product now has a configurable UI. Lost count of the number of issues where a customer query can now be answered with - Just add a new button/tab/menu (and then over time it's been easy to add contextual controls, make more tokens available to the target builder etc etc)

"Technical Debt" is often mentioned (hidden cost of a hacked together mess, increasing the cost of the next feature to be piled on top). What's satisfying are the "Technical Assets" like this - not just for me as I get a better product, but for the dev who can take pride in building something elegant and knowing this feature is theirs.

[arcbyte]

Your job as a product owner, as it relates to developers, is to be the customer so we dont have to waste time in phone tag. That meana you have to get inside the customers head and figure out what they want better than they know it and to take accountability when the team built what you thought the customer wanted but you fucked it up.

[ec109685]

Why should that responsibility solely come from the product manager? Are devs incapable of their own good ideas if given a chance to understand the customer as well?

The product manager should be the overall decider, but the best products do not germinate out of a single person’s head.

[yodon]

The person you're responding to is not advocating that ideas are the responsibility of the PM, nor are they saying the PM should be the overall decider.

They are saying the PM is responsible for collecting information from the customer and bringing that information to the team in an efficient manner so the team can make decisions based on that information.

If the PM brings incorrect or inadequate information, the resulting product will be poor because the team will have made its decisions on the basis of that poor information.

[nickforr]

How does the PM know better than devs about whether or not they’re bringing the right information and not inadvertently summarising something incorrectly that’s technically important? Gatekeepers are generally inefficient longer-term.

[arcbyte]

You're attributing gatekeeping to the wrong place here. The customer is the gate and the customer's unavailability is keeping the gate shut.

The PO reduces that inadvertent gatekeeping by being always available with customer insights so the devs don't twiddle their thumbs or worse, build thr wrong thing, because they were guessing what the customer wanted in the absence of actually talking to them.

The PO reduces gatekeeping because they are an always available customer.

[goldcd]

Yes - also there are many customers. PdO is a weighted amalgamation of them all.

[geertj]

> Why should that responsibility solely come from the product manager?

It should not, but the PM is accountable. GP put it nicely, effective PMs know better what customers want than customers themselves. This keeps iterations fast as PMs can immediately answer questions on trade offs instead of going back to the customers (who don’t know).

[mavelikara]

> effective PMs know better what customers want than customers themselves.

Please don't attribute superhuman skills to any particular team member.

For modern products valuable enough to be worth building deliberately, nobody knows what the market wants.

The team has hypothesises which they validate with software releases. The PM is accountable for these experiments.

Also, the use of the word "effective" in the quoted sentence is a setup for a No True Scotsman.

[geertj]

I am speaking from experience, and no, I am not superhuman. As a PM it is quite common to understand customers (meaning, customer use cases) better than they understand them themselves. The domain is complex, and customers try to find solutions just like the PM. But, as a PM you have the benefit of talking to many customers so you see common patterns and can often see the ‘problem behind the problem’.

I did not say that a PM will understand any customer issue, and yes sometimes new research is needed, which is expensive and time consuming.

I do not see the link to the true Scotsman argument as in my view my description of a PM is not mythical or heroic but quite common at least in my area.

[mavelikara]

> The domain is complex, and customers try to find solutions just like the PM. But, as a PM you have the benefit of talking to many customers so you see common patterns and can often see the ‘problem behind the problem’.

I agree to most of this. The team - by virtue of building and operating the software product catering for many customers - can often understand the customer usecases and solution better than any one customer. But it is the team, as a whole, where this expertise resides. Not one member of the team who happens to have a particular role and title.

> I do not see the link to the true Scotsman argument

By adding the word "effective" in:

> effective PMs know better what customers want than customers themselves.

you seemed to imply that any counterexample of a PM who is not doing this as not a true effective PM, and hence, not worth discussing.

[arcbyte]

The problem isn't arbitrarily keeping the customer away from the devs and replacing them with a PO. The problem is the customer is fucking busy doing business and supporting two other software initiatives. They don't have time. The devs can never get their hands on the customers time in enough quantity to be truly effective.

The PO is an always available customer.

And here's the wonderful thing about agile - if you happen to have an always available customer, you don't need a product owner