Scrum's “Product Owner” Problem

https://rethinkingsoftware.substack.com/p/scrums-product-owner-problem

by rbanffy • 2 years ago

92 133 2 years ago

rethinkingsoftware.substack.com

Former PM/PO and my best experiences were when the engineers had final authority on how it works, but I had final say on what it does

figassis• 2 years ago

I don't think it would make sense any other way. When doing rituals like refinement and sprint planning, POs want features but have no idea how they interact with what's already there, or how integrations are implemented, or how things are optimized. Simple features might be very complex to change for example, often because product itself asked to make something that does not scale for the sake of velocity, and now wants to build on top of that.

There should be a conversation, engineers should inform POs about risks, alternatives, workarounds, etc. Sometimes POs are just not aware that there is a much better way to do X.

piva00• 2 years ago

SWE here with experience on product development through a few startups earlier in my life, working on larger orgs later.

I wouldn't choose any other way. As a SWE I can have my opinions about the product, I can build a business case for what I see might be gaps in the offering and try to sell it but I'd still very much need the PO/PM to take the job of fleshing that out to users'/product's needs and defining the "what" better than I can.

A well-oiled product team is invaluable, there's very few things I hate more in this career than working with an incompetent product manager, everyone else's lives become extremely difficult if a PM is not doing a good job.

falcor84• 2 years ago

An apt analogy for the proper relationship between product and engineering is a restaurant.
Engineers are the chefs in the back...

I can't help but feel that this betrays a misunderstanding of both Product work and restaurant kitchens. As I see it, while in some restaurants everyone may be called "chef", there is only one "Chef" (with a capital C) who is really in charge of the menu. While everyone benefits from being informed and their input should be respected, if everyone in the kitchen were to make independent menu decisions, it would be anarchy. Same with tech projects, there is a strong benefit to having a singular vision of "what" we are about to release - and the inverse, to avoid scope creep.

I have seen cases where a power-hungry incompetent product owner sets up "mushroom management", but I don't see how having everyone constantly making their own independent product decisions would make things better. As another comment here said, product owners should have authority of the what, while offering engineers and designers information and full flexibility on the how.

To bring it back to the author's analogy - "Too many cooks spoil the broth".

EDIT: minor copy-editing

hexfish• 2 years ago

Please don't confuse anarchy with chaos.

smolder• 2 years ago

Anarchy in this case seems like a good choice of word to me, at least. No single leader, no single direction.

NeoTar• 2 years ago

Please don’t impose your solely political definition on others; anarchy meaning disorder (i.e. chaos) is a well attested meaning of the term.

anarchy: absence of order : DISORDER

https://www.merriam-webster.com/dictionary/anarchy

anarchy: Confusion in general; disorder.

https://en.wiktionary.org/wiki/anarchy

anarchy: confusion and disorder

https://www.dictionary.com/browse/anarchy

rightbyte• 2 years ago

if everyone in the kitchen were to make independent menu decisions, it would be anarchy

If a committee of chefs were to make menu decisions, it would be anarchy.

specialp• 2 years ago

The difference in the kitchen analogy is the Chef comes from a background in cooking food and was once a kitchen cook. Many in product are completely non technical. In this case the kitchen cooks and minor chefs will be told to cook dishes out of season, and do impractical things. I view product and engineering as a complementary resource not one directing the other what to do. Often times "what" is dictated by "how" in software development

grvdrm• 2 years ago

What’s the floor for non-technical? Not professional engineer but know some SQL? Or much lower?

stickfigure2• 2 years ago

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.

rubyfan2• 2 years ago

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.

bravetraveler• 2 years ago

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.

ibejoeb3• 2 years ago

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

stickfigure2• 2 years ago

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.

jghn2• 2 years ago

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.

dv35z• 2 years ago

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)

cjcenizal• 2 years ago

I think this is a valid approach, but success is contingent on working with product-minded engineers [0]. I consider myself to be one, so I'm a fan of this approach. There are also many engineers who aren't product-minded, and they might prefer working in a culture where their job is to focus on execution.

[0] https://blog.pragmaticengineer.com/the-product-minded-engine...

ibejoeb3• 2 years ago

Agreed. In that situation (following tfa's language) the product owner must either be an architect or be besties with one. A hoard of relatively unskilled laborers is not going to produce a cogent product otherwise. Then, what are you left with? The architect is leading the charge.

It's also good to take a step back and recall that all of these prescriptive, brand-name models for making software are, in fact, products in and of themselves. Their purported aim is to improve software, but what they really do is sell books, conference tickets, and consulting services.

Kalanos• 2 years ago

The product role is far too broad. It's absurd. The more experience I get in both product and engineering leads me to believe that product should be a scout out ahead of the team, identifying the most valuable things to build. Product people should spend more time with customers and internal stakeholders. Implementation below the epic level should be handled by the engineering team.

https://docs.google.com/drawings/d/1-6iUUbfFp3UFK24_OymF7ciX...

rubyfan2• 2 years ago

I was expecting it to address the common practice of product owners often not owning business outcomes.

Also would have loved to see mention of the hijinks that goes on around half-ass features often in conjunction with the abuse of the term MVP.

jt2190• 2 years ago

Edit: removed repost of article text.

I did not pay attention that this was hosted on substack so I reposted the text here when I got a load time of greater than one minute.

ahepp• 2 years ago

Are you saying HN broke substack?

ListeningPie• 2 years ago

I've also been thinking in a kitchen analogy to get management onboard to freeing up the tools used by engineers. There is a push to unify and breakdown silos, which is great, but in the eyes of management it also means using the same IDEs, the same OS, the same AIs etc.

My kitchen analogy is that the tools the engineers use are like the chefs kitchen knives, as long as the dish (code quality) is the same, engineers should be supported in choosing the tools that serve them best and the end results presented goes through a final pass (code review).

Back to the article, I disagree engineers should make the menu, it's not there job to know what the customer wants or to set prices. The engineers cook, the menu would be the maitre'd with the restaurant owner that decides (Yes, in a restaurant the head chef makes the menu and here the analogy breaks down.)

joezydeco• 2 years ago

Wasn't Agile supposed to bring the customer closer to the developers?

The menu is set, the diner complains about the price or the choice of side dishes, the chef iterates.

I don't see a lot of customer feedback in any of these PO loops, I'm witnessing it first-hand in my company. There's nothing Agile in this process anymore.

cjfd• 2 years ago

This is a complete straw man. It is completely normal for developers to ask all of the listed 'banned' questions to the product owner.

b800h• 2 years ago

Agree. The central premise of the blog piece is mistaken.

imwillofficial2• 2 years ago

I disagree with this premise entirely.

A product owner is the conductor of the symphony.

Unless you have a team of experienced senior engineers, the engineers will lack the perspective and wisdom to make the proper choices.

ibejoeb3• 2 years ago

Surely you've worked with a product owner who's invoked one of those "I'm not technical, but..."

I don't know of any working conductors out there who predicate their directions by "I'm not very musically inclined, but..."

imwillofficial2• 2 years ago

I have been fortunate to only work with technical product owners, or ones wise enough to listen to the more technical when deciding a path forward.

heisenbit• 2 years ago

Often there is not so much work for PO as many projects are not dealing with something new but a slight variation of existing functionality. In contrast to this just reinventing the wheel on a newer stack requires many architectural, tactical and technical decisions. The role of the architect has been relegated to ‚the team‘ and is parceled into user stories chopped into sprints. Without balancing mechanisms for product and technical leadership we will continue to produce random quality under consistent high pain.

zsellera• 2 years ago

The same essential skills make a great PO/business analyst as a great engineer: the ability to think in abstract terms and the ability to debug.

When successful POs write a book or something, they present the best-practices. They don't share the most important wisdom though: there are pretty smart to start with... Applying their practices without the ability to think does not work, and it's not something one can pick up on the go.

Nothing comes from nothing.

fatfox• 2 years ago

To me, this recurring narrative of product versus engineering is both tiresome and misguided.

In well-run companies, commercial, product, and engineering teams are aligned - overused as the term may be. Any misalignment points to fundamental flaws in company culture. In my experience, this misalignment is what causes so much pain in high-growth companies that introduce managerial roles to a previously founder-led culture - not the product owner role as such.

It's counterproductive to stereotype POs as overbearing taskmasters, or to cast engineers as creators of beautiful but useless code. Such perceptions, if prevalent within a company, should be the primary issue to address. There's certainly features that POs don't enjoy working on but they have to - same for engineers (think about all those compliance features).

I believe POs can serve as a vital bridge between commercial and engineering departments. They clarify how features add customer value, explain business objectives behind projects and help decide what's next on the roadmap. Additionally, they help maintain focus by minimising abrupt directional shifts in the roadmap that could waste resources. And they can weigh in on decisions when they see that engineering teams are already strained by other projects or any business-as-usual work.

In that way, everyone is be enabled to do their best work and the PO is not reduced to the cookie cutter version the author portrays in the article.

ungreased06755• 2 years ago

I have to disagree with the central argument, which is to give engineers more product management responsibilities. A way I’ve handled priorities as a PM is by setting the order of the backlog. At sprint planning, the team collectively decides what to pull off the backlog, and it doesn’t have to be the top stories that add up to our expected points goal. If the team goes diving to the bottom of the list for a bunch of trivial stories, then that sparks a conversation about why we have different priorities. Product owner isn’t a dictator, but they are ultimately responsible for the product.

Ideally, I want engineers focused on building, not taking discovery meetings with potential customers, messing around in Figma, projecting financials, writing ads, or any other role. I think some engineers like the side quests because they’re fun. In the kitchen analogy, we need cooks to do boring stuff like chop 100 onions and make dinner rolls. If everyone in the kitchen had to do market research at other restaurants, pick up ingredients from local farms, and test new menu concepts, the place would be out of business in short order.

Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.

calflegal• 2 years ago

Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.

This is so good and yet so painful.

grecy• 2 years ago

It’s all good though, because with experience the spray gunners can move towards being Picasso.

nick3443• 2 years ago

Having dealt with some truly awful run & gun painters, it's visceral.

meiraleal• 2 years ago

Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.

Led by one wannabe Picasso that never painted their whole life.

leetrout• 2 years ago

Funny how that works, innit?

jghn2• 2 years ago

I think these debates wind up missing the middle zone, partially because there's not a one size fits all in terms of teams and scope relative to a company. Specifically the issue I've found is that while I agree Product needs to be steering the ship, that Product Representatives find their way too far down the hierarchy.

Or another way of looking at it: On a typical team one often finds a PO, Scrum Master, and a Tech Lead. The PO reports upwards to a broader PM. The TL reports upwards to a broader EM. I'd contend those are 3 people filling the duties of what should be 1 or 2 people's worth of duties.

Imagine there's a PM at a company responsible for some portion of a/the product. And suppose there are 3 dev teams working towards it. In my mind there should be a PM for that product, detailing the what and (idealized) when. They're the ones talking to customers, coordinating with other PMs in the company, etc.

But their involvement with engineering should end at the sprint level. Instead what I've found is there's often a lower level "PO" who attends daily standups, will debate micro-level prioritization (do this before that), etc. And to me this really should be at the team/team lead level to decide. What's more, I've pretty much *never* seen this "PO" persona do any outward facing customer work - they're almost always just representatives of the broader PM organization.

As an engineer and engineering lead who has complained about product, *this* is what I'm complaining about. You're 100% correct that I don't want to be deep diving into the product side of the fence. But I'm usually in tune well enough that I don't need 2-3 layers of Product Bureaucracy between my team and the people who are doing said deep dive.

evrydayhustling• 2 years ago

The underlying problem is how this essay uses the word "own", which is as dictation. In almost any context, ownership should primarily about responsibility for the outcome, with the minimum authority necessary to coordinate work towards that outcome. People who are good at owning things will push most decisions to people closer to each sub-problem, while giving an overall framework that keeps everyone rowing in the same direction. For Product, that manifests as a roadmap with high level prioritization, but plenty of room for engineers to tweak scope or ordering to take on targets of opportunity.

Kinrany2• 2 years ago

Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.

This doesn't add anything to the rest of the comment, does it? It insults the developers with the implication that they think they're so good when they aren't. When the problem being discussed has nothing to do with how good they are in the first place.

alwa2• 2 years ago

To me it doesn’t seem to speak at all to “how good” anybody is, just to the nature of the work the job demands.

A fine artist will paint a better portrait, but they might not be the right hire to get a housing development painted and shipped (so to speak).

The fine artist may be less good at house painting than the tradesman, the tradesman may be less good at portraiture than the fine artist.

There’s always the possibility that somebody could be good at both, but they’re orthogonal: both dip something in paint, but that’s where the similarities end.

ungreased06755• 2 years ago

It’s not insulting. Engineers are smart and like to solve wickedly difficult problems. But sometimes that’s not what’s needed.

Let’s say I need a web form that puts user inputs into a database. Picasso goes to a cabin in the woods for two weeks to architect something that handles every edge case and is absolutely elegant. House painter knocks out something acceptable in an afternoon and works on something for paying customers the rest of time. There’s a time and place for both, but a lot of software development honestly just needs painters.

randomdata5• 2 years ago

I have to disagree with the central argument, which is to give engineers more product management responsibilities

How is it disagreeable? Scrum is a formalization of Agile, which is literally about eliminating management by giving engineers control over the project. They are intrinsically linked. It doesn't make sense otherwise.

The Twelve Principles, is pretty clear that you need special people to make Agile work; that it's not for everyone. Your assessment that you don't want to go down that road is going to be true in the vast majorly of cases, and nothing in the literature disagrees with that. However, in those cases you wouldn't be using Scrum in the first place. It is clearly the wrong tool for the job if you are going to retain managers.

awill88• 2 years ago

The article and commenter are talking about a single management role, Product. You say “retain managers” — plural. You’re putting words in their mouth.

They had something like Extreme Programming, and it was not a good time from what I heard. If you want to live in la la land of coding for a profitable business, well, sorry to break it to you, but a cohort of smart people need to be led. Notice I said led, not managed.

Also, the role is called Product Owner not Product Manager, I would imagine that was a conscious choice. If a PO feels like a manager, that’s what’s wrong. And maybe why that could be is the engineering team’s fault for having an insatiable need to.. control all aspects of their day-to-day. However, it’s a business at the end of the day, not a coding playground.

The article is basically suggesting POs shouldn’t control the backlog because engineers know better (essentially). Sounds like they’ve had a bad experience and want to vent about it. Fine, but it’s an immature take imho.

I am an engineer myself and I think it’s insulting to the people who have to take the work that engineers do (or fail to do because they want to experiment) and cross the divide and tell the business that the work you’ve done is worth everyone’s salary.

I don’t want to control the backlog with a bunch of other knuckleheads, thanks.

Izkata3• 2 years ago

Scrum is a formalization of Agile

Scrum is one kind of Agile. Kanban is another. I think I remember there being a third, but not sure about that.

vault_• 2 years ago

Where this breaks down, as I've experienced at least, is that the product management side maintains basically zero awareness of the production constraints engineers are working within. If you've built out a painting production line around spray guns and beige, that has knock-on effects as to what results are attainable. A PM asking for polka-dots next sprint is throwing into question the entire body of practice, but this happens with extreme frequency in software.

Spivak• 2 years ago

This I think is a broader problem of a certain personality of "idea guys" that lie about requirements, often without being aware of it, and it being our problem as engineers to read their minds and be two steps ahead of them.

Director: "We need a factory that's tooled around manufacturing boxes of cookies with blue frosting. We don't need any other colors, just blue frosting!"

Junior Engineer: "He's going to come back in two days and ask for red frosting. Better make sure it can do any color."

Mid Level Engineer: "He's going to come back in a week and ask us for multi-color boxes. Better make sure it can do any combination of colors in each box."

Senior Engineer: "He's going to have the big idea to add sprinkles, writing, and branch out into eclairs. Better make sure the factory is extensible and can retool itself per-batch to make each box to-order."

The worst part about this is you can see where uncertainty leads to over-engineering and consequences if your psychic senses are off. This is where a good PM steps in and forces folks like this into a roadmap on a long-enough time-scale that you can see the mid-level's design is all we'll need. And if you still want eclairs we can talk about that in 2026.

ricardobeat2• 2 years ago

Ideally, I want engineers focused on building, not taking discovery meetings with potential customers, messing around in Figma, projecting financials, writing ads, or any other role

This is a very short-sighted view and one of the reasons a lot of engineers hate their jobs today - even though they might say they “just want to code”.

Software engineering is ultimately about building things for people (or machines), so the more distance you put between the engineering and the end goal, the worse outcome you get. You can definitely have specialized functions like marketing, copy-writing, design, but they all work together in a multi-disciplinary team, understand what they are building and why so that they have shared knowledge and goals.

On that strawman argument, nobody expects developers to routinely do client meetings or financial projections, though they should be able to delve into that if it will help build a better product. To continue your analogy, in great kitchens everyone knows the dishes they are making, the whole menu, get to taste it, and can probably take any other station if required.

bluefirebrand5• 2 years ago

Ideally, I want engineers focused on building, not taking discovery meetings with potential customers, messing around in Figma, projecting financials, writing ads, or any other role.

Maybe engineers shouldn't be bothering writing ads, or projecting financials

But if you want good builders, they should absolutely be in contact with the clients and building mockups (which you describe as messing around in Figma)

Assembly line style development where devs just churn through endless tickets is fine for junior devs but cannot be what your senior and principal devs are doing.

bluGill5• 2 years ago

There are many different engineers with many different interests. Some senior engineers should be talking to clients, but some should in no way be allowed to talk to them. Some senior engineers get there by knowing the client. Some get there by make the code "better". Some get there by creating tools everyone else uses. Some get there by digging into the really hard problems. Some get there by mentoring others. Some get there by figuring out the big picture and building an architecture that works better. Some get there by figuring out priorities and getting the real important stuff done. Some get there by writing ads, projecting financials, messing with Figma. I'm sure there is more that I can't think of now.

There is nothing wrong with anything on the above list. Depending on your situation some will be more important than others. It is not possible for one person to do everything in the above list well, though often you need to do more than one. Some of them are better done by departments - but if an engineer is interested does it matter (sometimes it does, sometimes it doesn't). Your junior engineers should be thinking about what they like and what is needed - then positioning themselves to their future senior role.

The only really bad thing is when a mid level engineer is so good at something that you don't realize how important they are and so don't promote them to senior much less principal. (bad because when they leave that you didn't promote them is a sign to others you don't care about that and so the juniors didn't study it to become a backup - if you really don't care then you should be talking to that person about their waste of time side activity)

MarkMarine3• 2 years ago

I hear that you want to be empowered, but you want the people around you not to be.

Understanding why you think your role should be empowered (ultimately responsible for the product) and the benefits it brings is _exactly_ why the people around you should be empowered as well.

It sounds to me like you’ve never been in the software businesses where true creation is happening and you’re in the world of pseudo contractors or explicit contractor arrangements. All I can say is there is a much better world, you should change your attitude and hustle to get there.

bitwize• 2 years ago

Programmers should not be empowered to perform roles for which they are an ill fit. In general, programmers are detailists who speak the language of the computer; they do not have a big-picture perspective nor do they understand the problem in business terms. Their social skills are very often lacking, and they are prone to arrogance. In a high-functioning information systems organization, the programmer's job is one of simple translation from specifications into code; those specifications will have been produced via stepwise refinement by systems analysts who do understand the business and the people within it.

See the late Tim Bryce's Theory P essay: https://www.phmainstreet.com/mba/ss050117.pdf and note that he uses the exact same "artists vs. house painters" analogy. Before his retirement Tim had been managing large software projects since before much of Hackernews was born, and had forgotten more than most internet commenters know about what it takes to manage a successful project.

The "software businesses where true creation is happening" are few and far between -- Apple, maybe Google at its peak, and a handful of others. They are run by geniuses, typically from top-tier schools like MIT and Stanford. They are not the typical software organization. The typical software organization produces the software that keeps civilization humming -- and doing that is a proven, teachable, scientific process. Lately we've seen many organizations that should be doing this instead cosplaying as a bunch of genius disruptors, but they have nowhere near the brainpower to actually pull it off, and the world has gone to hell in a handbasket as a result.

015a3• 2 years ago

Second, 100%. That's exactly what I'm reading as well, its why POs/PMs get a bad rep, its representative of the worst POs/PMs I've worked with, and frankly it is virally toxic.

If you view your product development as a factory floor, your product will be a mass manufactured cookie cutter widget. That's how it works, and it does work for, say, cars. But the software business isn't like the car business. Its startlingly winner takes all. Atlassian builds a better, more efficient widget factory than you do for tasking software, and they eat the tasking software market, and they shoot tendrils out into other markets, and soon your business is dead.

ubercore• 2 years ago

I really can't stress how unpleasant working in the world you describes sounds to me, as a developer. Through my career, so much work could have been avoided or improved if developers were in more discovery meetings, messing around in Figma, etc.

Senior people should be expected to bring an engineer's perspective to these tasks, and mentor junior engineers in the process to bring them up to that level.

dijksterhuis• 2 years ago

Product owner isn’t a dictator, but they are ultimately responsible for the product.

they are accountable for the product.

when there’s a problem, they’re the ones who take the schtick for it.

engineers are responsible for the product.

they are the ones who fix the problem the product owner is getting schtick for.

accountability always goes up, responsibility always goes down.

this may seem like a nitpick. but it’s an important nitpick.

because the more accountable someone is made for something they care about, the more invested they are in making it succeed.

a lot of engineers care very deeply about the things they are making.

ungreased06755• 2 years ago

You are correct. That’s what I meant but the wording should have been more precise.

brightball• 2 years ago

One of the things that attracted me to SAFe (I know, a lot of folks have had bad experiences, hear me out) was the dual backlog. Most places I know where SAFe went sideways did not use this and IMO it's one of the key selling points to the whole system.

Essentially, there's the Program Backlog which is managed by Product and the rest of the business. And the Solution Backlog, which is managed and prioritized entirely by the tech teams. Going into a PI, the goal is to allocate capacity to both and typically that is a 70-30 balance but it ensure that the teams can prioritize anything they believe is important without having to bother convincing the non-technical side of the company.

https://v5.scaledagileframework.com/program-and-solution-bac...

Unfortunately where Scrum, SAFe and most other things go wrong is not the system itself. It's leadership trying to enforce a command and control structure to remove decision making from people closest to the problems.

intelVISA2• 2 years ago

I think this comment should be framed as a solid example of why you shouldn't have non-tech people manage tech teams. Feudal mindset that doesn't represent development outside of bottom tier tech companies.

Then again... engineers like to think themselves Super Smart(tm) yet forget who's paid to do all the fun sidequests while ya'll stuck "chopping onions" for those 'dumb' Product Lords.

bsoles• 2 years ago

Most software businesses don’t need a bunch of Picassos, they need house painters with spray guns and buckets of off-white.

Oh, so the product owner is Picasso here and the software engineers a bunch of painters? What a load of condescending bullshit!

In the kitchen analogy, we need cooks to do boring stuff like chop 100 onions and make dinner rolls.

And programming is the boring stuff in this analogy? This is why the software engineers think that product owners, scrum masters, and the like are bunch of idiots, who don't know what they are talking about.

And why should engineers not mess with Figma? The designers and product owners, in all their creative wisdom, ask for unimplementable, inaccessible, unnecessarily time consuming BS all the time without any understanding of what goes in software design, architecture, and implementation. Then they complain about missed deadlines, blown budgets, etc. And then we end up with stupid stuff like Scrum because engineers can't be trusted to self-organize their development process. Perhaps product owners should come off from their high horse and learn to be proper team members?

tootie• 2 years ago

Gave up after one sentence. Product owners do not have sole control over the product backlog.

supergeek133• 2 years ago

Whenever you see one of these "it's product" or "it's engineers" all I can think of is "someone has more business context or knowledge than the others"

The best teams I've ever worked on as a product manager/owner is where we have shared context. These problems described here are minimal. In those teams I could provide technical input to engineers, and engineers gave me "consumer facing" suggestions on features.

I've believed for a long time that lack of business/use context drives a lot of these issues.

Take for instance I currently work at an IoT company, and if I'm working with engineers who have no idea what a thermostat does/how it works other than "makes it hotter or colder" then we have much more difficulty building shared understanding of a feature request.

I also know this because 10 years ago that was my simple understanding of a thermostat... so it was much harder for me to understand why we were doing certain things.

josefrichter• 2 years ago

This sounds more like a complaint about broken communication in a team. While I'm not crazy about Scrum, this doesn't seem to be its systemic failure.

robertclaus• 2 years ago

This definitely resonates with me as an EM at a fast moving startup. I would much rather have a mediocre product that addresses a real need than a perfect product nobody needs. That means my PMs generally need to focus more on understanding the users and the market (and getting everyone on the same page for that vision), not the implementation details.

Our PMs quickly sort issues into very broad priority buckets to save time, and engineering picks work according to those. If the PM on my team is spending 10 hours a week prioritizing issues that's 10 hours of user research, competitive research, and user acceptance testing we're missing.

mumblemumble• 2 years ago

The central premise of the article seems to me to be a likely misunderstanding of the problem. I would bet that a Scrum Product Owner who uses a "command and control" leadership style and doesn't know how to properly delegate authority would be doing the same under any other development framework, too.

In general I'm a big fan of the "single wringable neck" principle. I've seen it put to great effect in the hands of a skilled leader, in both Scrum and non-Scrum teams. Better yet, when the leader isn't managing things well, it also leaves no question that they're the one who needs to figure out how to set things straight. Same goes for their delegates.

And for the ICs it makes collaboration easier - and therefore, ironically, enables them to work more autonomously. When everyone unambiguously knows what they're in charge of and what the team's big-picture objectives are, they have everything they need to independently figure out how best to make it happen. And it's also a lot easier to figure out who to talk to when they need to call attention to a problem.

I've seen a lot less luck with shared authority and informal delegation. On the best of days, it turns decisionmaking into an unnecessarily political process. More likely, the team will settle into an informal consensus process that typically operates as "rule by the obdurate" in practice. And when things get tough, the leaders will tend to slide into unproductive bickering that all but precludes actually fixing the problem.

Favorite readings that touch on this kind of thing: The Tyranny of Structurelessness by Jo Freeman, and Turn the Ship Around! by David Marquet.

sevensor2• 2 years ago

As far as I can tell, almost nobody, whether engineers, product owners, sales people, or sometimes even executives, has a firm grasp on how a company creates value for its customers. Sometimes this is because the company destroys value instead and everybody’s trying not to know it. But even at productive companies that should be proud of their products and services, most people can’t explain how the business works.

This is bad. If you know why you’re making money, it’s a lot easier to make the right decision.

m_rpn2• 2 years ago

That's probably only true for most coffee bean subscription SaaS startups, but the world is full of pretty normal business, in which pretty standard engineers and other professionals work, that make money in a streamlined and predictable way but who's story doesn't make it to HN unfortunately.

sevensor2• 2 years ago

I wish that were the case. I’ve spent a good chunk of my career in the “Real Engineer” widget making world, and it’s that experience I’m speaking of here. Even in the semiconductor industry, most people just kept their heads down and never connected their work to the customer, never even thought about what kind of device the chips were going into.

joe8756438• 2 years ago

It’s true that some companies will place a PO in order to establish a hierarchy over a scrum team. But that’s not a scrum problem, it’s an organization problem.

In a reasonable team theres a dialog between product and engineering that establishes direction and priority.

ricardobeat2• 2 years ago

It’s a little funny to read this since this is exactly how Scrum was meant to be.

The PO prioritizes tasks, but coming up with stories and breaking them down into actionable bits is a team responsibility, based on the PO’s input and product requirements.

This was subverted into PM roles that exert control over the backlog once Scrum made it into enterprise.

lucasyvas• 2 years ago

The respected and socially competent engineer should always fulfill the traditional PO obligations. I believe the buzzword for this is Product Engineer, even though that’s roughly what agile was supposed to be to begin with…

The problem with this is somewhat real though and it’s that companies do not prioritize this capability set over the “traditional” ones where the engineer never has to talk to a customer. Given that anyone that codes is at least probably lightly on the Autism spectrum, and you end up with only a subset that can successfully do both roles.

bluefirebrand5• 2 years ago

The respected and socially competent engineer should always fulfill the traditional PO obligations

This is sort of the problem isn't it? You have a significant portion of people in business who believe that engineers are not socially competent by nature, and another significant portion that simply does not respect engineers in the slightest, instead treating them like an assembly line

There's probably a large overlap between the two groups, but it's not a circular venn diagram

I can't be the only person who has encountered dismissive comments from departments outside of R&D, or from managers higher up the food chain, about engineers ability or value

I mean a lot of companies treat engineers as fungible assets, as if the only value we provide is slinging code and any engineer could do that

beryilma2• 2 years ago

Given that anyone that codes is at least probably lightly on the Autism spectrum

What?!

mindaslab• 2 years ago

Scrum is the problem.

tartieret2• 2 years ago

I used Scrum with my teams for about 1.5 year, and tried hard to adjust the framework. Then we switched to Kanban, which matches much better the realities of an innovative and B2B product.

The main benefit of scrum is that it forces stakeholders to discuss goals and priorities.

But the framework itself has flaws in its philosophy. The Scrum book is adamant that the results of a sprint should be a user facing change, which doesn't always aligned with the "path of most value generated" that an organization should follow. For instance my team is working right now on transitioning our data storage system to a different offering in Azure as the type of PostgreSQL service we use is being retired. That's a non user facing but imperative change. Similarly, as our products are getting mature we work on both incremental improvements and longer term (6-12 months) ML/AI projects which are discussed with our clients. Our product manager has to be involved with those too and sometimes prioritize engineering work related to them. Scrum simply ignore this reality of operational tasks, and medium/long term value generation

pseudosavant2• 2 years ago

I'd say Scrum is more about creating business value than user facing change. It is the business that consistently doesn't value long term value generation, not the process.

tartieret2• 2 years ago

Yes, the goal is to generate business value. But Scrum requires to do this in small increments, and these increments have to be exposed to stakeholders. As per the Scrum guide (https://scrumguides.org/scrum-guide.html#increment):

"In order to provide value, the Increment must be usable."

So this conflicts with the fact that business value can be generated (or protected, in the case of maintenance/upgrade of a system) without generating immediately "usable" changes. Or said otherwise, a high value change may requires a succession of non-usable changes over many "sprints", and Scrum doesn't account for that.

wnmurphy• 2 years ago

This is actually really simple to solve: product articulates the problem, engineering designs the solution.

When product tries to design the solution, tosses it over the fence, and engineers who don't know any better just implement it, you end up with a codebase that consists of parts duct-taped onto the side of other parts. Over time this compounds the cost of future development.

When you let engineering design the solution, they design for reuse, with the lightest touch. This decreases the cost of future development by keeping the codebase maintainable, understandable, unsurprising, simple, etc.

If your user stories from product contain implementation details, you need to guide the discussion back to the actual problem that needs to be solved.

fmbb2• 2 years ago

Not only is this easy to solve, Scrum is one solution. Like this is the core of what it attempts to solve.

pseudosavant2• 2 years ago

Right off the bat I can see where they are going astray.

In Scrum, Product Owners have sole authority over the Product Backlog; they control what to build and when to build it.

True, POs have authority over the Product Backlog. Guess what they don't have authority over? The Sprint Backlog - you know, where things actually get made, not just talked about. A PO actually has zero _authority_ over the Scrum team at all.

mattxxx• 2 years ago

The article opens with:

In Scrum, Product Owners have sole authority over the Product Backlog; they control what to build and when to build it. Engineers are merely ticket-takers, implementing one instruction after another.

I think this immediately starts the article off in the wrong place. An Engineer that is a "ticket-taker" is relegating themselves to that role; they have more agency than that.

If you're able to cogently explain why something needs to done, and are additionally weighing product value while doing that, you will be heard. Stakeholders are not the problem here.

theptip• 2 years ago

The Scrum Guide would have you believe there are only two appropriate questions to ask a Product Owner

A lot of people over-interpret rigid hierarchy’s, when Scrum is supposed to be the opposite.

From the actual scrum guide: https://scrumguides.org/scrum-guide.html

The Product Owner is also accountable for effective Product Backlog management… The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

It’s entirely compatible with Scrum for the engineers to sit with customers and come up with backlog items, and the PO to take the role of ensuring backlog quality and reviewing strategic direction of the work items being added by developers.

klez• 2 years ago

Exactly. This article starts with a misunderstanding:

In Scrum, Product Owners have sole authority over the Product Backlog

While, as per your quote (emphasis mine)

The Product Owner is also _accountable_ for effective Product Backlog management… The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains _accountable_.

Meaning they have the final say, not that they decide on their own without any input from the team.

My impression is that OP just had to work with bad POs who didn't understand their role.

fmbb2• 2 years ago

This is not a Product Owner problem, nor a Scrum problem. Get ready for some No True Scotsmanning:

The product backlog is a collection of User Stories. The user story describes a problem and starts out as a placeholder for a discussion in the team to figure out what the problem is and how we can solve it.

The Product Owner prioritizes these problems against eachother. The team members can communicate. Talking is not forbidden, in fact it is encouraged.

JuanTono• 2 years ago

Agree with the post from a practical perspective, the funny part is from a theoretical perspective all the arguments saying “scrum is wrong” will be wrong… since it is an agile framework it will always have the open way to say “the core says this…” which is really dynamic and agile by nature.

Based on my experience, one of the main issues describing the problem in post is associated with ego and management status… a lot of people in those positions feel like they’re better, superior to engineers forgetting exactly that they should be waitresses for engineers… the core issue is the structure, status and power associated to management and business related positions

rc_kas• 2 years ago

Yeah I like this authors line of thinking, on some of my past teams the PM has hurt productivity by making decisions they should not be making.

drc500free• 2 years ago

I agree with a lot of this, but disagree with the final conclusion that Product shouldn't define what is going to be built. Everything listed in TFA is something a good PM and a product-minded engineer collaborate and iterate on. At the end of the day, I think the article is really concluding that "bad Product Managers shouldn't define what is built."

The actual issue with Scrum is that APMs and others who identify as "Product Owners" often aren't trained or equipped to be good at actual product management, because they are focused on a fake set of JIRA-focused responsibilities. A "Product Owner" is really a software development project manager who uses a ticketing system to micro-manage engineering work.

The result is that scrum POs are bad Product Managers. Their role has little to do with understanding user needs, establishing and communicating a vision of a product's philosophy, or assessing the success of a feature once it's out in customer hands.

Scrum ends up wrong on two fronts:

* It has no idea how work is prioritized (much of the actual work of product management), and

* It thinks that "priorities" are a well-ordered list of discrete development tasks rather than features, and assigns much of the engineer's role to the PO.

It's as if Scrum defined a new role called "chief financial owner" who is responsible for making sure the columns are aligned in the annual financial statements, and then the job market was flooded with thousands of people with two years of experience saying "I'm a CFO" and we got hundreds of think pieces about why all these companies were having trouble managing cash.

johnobrien1010• 2 years ago

All the arguments for where to place control over who decides what gets built IMHO are just political power grabs from one constituency or another. Different companies do it differently, and I'm not sure there is one best way. Any time engineering or product or sales or marketing want more power they come up with some reasons why their function should have more control in every company everywhere.

I don't think arguments that any function should always drive can be true, because who is best qualified to make those decisions is based on things like judgement, experience, domain knowledge, and customer understanding.

Instead of saying a specific function should have control, I think empowering the people who have been best a making decisions about scope should do it is the best approach. That can be engineering but that also can be product etc.

emilio1337• 2 years ago

I used to ask all those questions to my product owner. He was so annoyed by that. Almost got fired. Companies I worked for, everything is top down. Always. I gave up asking too much

jrochkind1• 2 years ago

I think it can be a problem when the product owner role is strictly divided from the engineers.

But I've definitely seen it as a problem when the engineers take on product owner role. Engineers should definitely be thinking about user needs and those questions OP lists. But Engineers are too close to the code to be the actual responsible owner of deciding priorities based on user needs, or deciding what user needs take priority or are.

Product owner does need to be in the "kitchen" though -- product owner even in traditional agile scrum is supposed to be on the team every bit as much as the engineers, right? This is supposed to take care of the problem the OP mentions "make decisions in real time", "tight feedback loops, reassess, and make their next move" -- ABSOLUTELY, and agile and scrum as I understand it say the product owner is on the team to make this possible!

Things I think are true, to make things work:

* There absolutely needs to be a product owner who is not an engineer who "owns" user and business needs.

* They need to be on the team

* They should be in constant dialog with the engineers, educating them about user and business needs, and hearing their feedback and suggestions about how the engineers think they can best meet user needs. It should be a conversation engineers are included in, but Product Owner makes the call.

* the product owner (on the team) should not be the ONLY place engineers learn about user and business needs

* In addition to product ownewr responsbiel for "owning" user and business needds, there needs to be a technical lead who "owns" technical needs. (technical debt, efficiency including cost efficiency, etc; also team sanity needs!). In fact deciding what to do next can't be only up to the product owner and busniness/user needs. The time spent needs to be based on a combo of user/business needs with the product owner and technical lead in conversation -- but in this conversation the product owner (who is not an engineer) needs to "own" business/user needs, even if engineers are allowed to have an share opinions on them!

I have occasionally experienced this well oiled machine, and it works very well. As an engineer it is a huge RELIEF to have someone else responsible for human/business needs -- even though I do have an opinion about them and like to be educated about them, and think that's necessary to be a good engineer, and want that person to be interested in my opinion. But them having the responsibility (to the org) and final say over it leaves me feeling so much less stress, and able to focus on the technical problems and being the final say and authority and having accountability for those.

Getting this to work succesfully can't be done by just having the right structure on paper (although different structures can help or hurt), it takes skilled people who are about their jobs and get along and have experience that has given them some lessons on how to work together well.

A rare thing indeed.

torginus• 2 years ago

I refuse to believe anyone not under threat of grievous bodily harm has written down the phrase 'In a dynamic, fast-paced world' of their own free will.

lutarezj• 2 years ago

“Who are our customers?”

After the first 2 days on the project this should be clear, shouldn’t it? And all the other proposed questions are answered in the first 10 minutes on the first contact with the PO. 10 months later on the project the only thing that matters is what is needed and when.

Scrum's “Product Owner” Problem

Related Stories