Comment by stickfigure | Hacker News Reader

Comment by stickfigure | Hacker News Reader

This is atrocious advice. It's basically "give the product managing responsibility to engineers". The PM in this scenario is basically relegated to the "I have people skills!" role from Office Space.

I think Pivotal nailed this one:

* PM's don't code. The job of the PM is to look at the product from the customer perspective and direct the team to change the product in a way that delivers business value.

* Chores (refactorings, architecture changes, etc; any story that isn't visible to a csutomer) aren't pointed. Engineers can put them in the backlog and work on them, but it will slow down velocity. That's the system working as intended.

The problem with engineers dominating the PM is that engineers will be tempted to pick features that they enjoy working on, not necessarily what moves the business needle. Can engineers do PM work, especially on small teams with highly technical products? Of course, and the best engineers are product-minded. But understanding the customer is a full time job.

I think a lot of HN is poisoned by working on products for other techies, like databases and development tools. Most software in the wild runs lines of business. Tell me how your engineers are going to PM a medical billing system, or a financial planner, or the DMV website. It's not impossible - but the talented developer who already has domain knowledge is elusive and you can't afford them anyway.

> It's basically "give the product managing responsibility to engineers".

It's really not going that far. It is critical of the notion that someone without software engineering chops can dictate an appropriate ordering of sub-jobs. That's a legitimate position to take, and we observe it in practice regularly.

It's also in a very specific context, Scrum, and it's talking about these rigidly defined roles. It doesn't really make sense to discuss it outside of this context, because Scrum puts itself in a precarious position. The #1 rule of Scrum, literally, is "A Product Owner orders the work for a complex problem into a Product Backlog." This is what the author is going after. And, there can be no absolutely no deviation, because "The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum."

That sounds fine? The Pivotal process is equally rigid about the backlog order.

But the important distinction - and if you've never worked with a Pivotal team you might not realize it - is that the pointed stories in the backlog are all customer-facing. They represent business priorities. The PM absolutely defines the business priorities.

Pointed stories are not created in a vacuum; the PM works with the tech leads to define reasonable features. And pointing is done by the engineers.

Also, nothing stops the eng team from adding (unpointed) chores to the backlog and working on them! But there's a velocity cost and that can affect delivery dates. There's negotiation involved.

If the PM is micromanaging engineering tasks, you're doing it wrong. The process requires a good PM.

Thr current Scrum guide also defines two separate backlogs: sprint and product.

> It is critical of the notion that someone without software engineering chops can dictate an appropriate ordering of sub-jobs

This is the exact issue. And people talk past it all the time.

Product designs the specs for a set of changes & proposes a timeline. Engineering breaks that down, perhaps the two sides negotiate on the timeline. Beyond that, Product should generally stay out of the day to day. "I want sub-sub-sub-widget-X first" discussions are what lead to the tension that we see here.

I have worked with so-called “product minded” engineers who 1) do nothing, 2) do what they want, or 3) try to tell product how to do their job. It is dysfunction at its finest.

I'm struggling with this a bit. At a certain point it feels you get pushed in this direction. So many other non-engineers have ideas/promises... and being the one who provides the eggs, incentives are not great.

For those curious about the Pivotal Labs product innovation process, check out this guide. In my opinion, it's the best end-to-end guide on how it all works together.

It's a product of 20+ years of iteration & weekly retrospectives - and was used to coach clients on how to collaborate as a team and build high quality products. Definitely download it, and review from time to time - many gold nuggets.

https://tanzu.vmware.com/content/white-papers/vmware-tanzu-l...

(Used to work at Pivotal)

Reply on news.ycombinator.com