Is your team obsessed with making customers awesome?
Are they visiting customers to observe how they work, learn what issues they face and understand what could make them more awesome?
Are they conducting usability evaluations, tracking and analyzing user behavior, fixing known problems and simplifying workflows?
Are they learning from fast, safe, capital-efficient experiments?
Are they discovering and paying down technical debt that inhibits better product development?
The choice of what to build or fix is hard. It requires the insights of many to do it well. If you want to do it poorly, delegate all of this work to a single Product Owner (PO).
Your PO decides what to do, while your team figures out how to do it. That’s the standard line pushed by Scrum and derivative processes like SAFe. It’s amazing how many shops fall into this trap. Practitioners of this approach say “The PO is there to ensure that the team delivers value” or “The dev team needs to understand the PO’s vision.”
Installing a PO turns a team of intelligent people into “orderneers” — engineers who take orders.
Mary Poppendieck, author of many outstanding books on Lean Software Development, said, “Delegating decisions about what to build to a single Product Owner is outsourcing the most important work of the development team to a person who is unlikely to have the skills or knowledge to make really good decisions.”
We have massive technical debt, poor reliability, ugly UIs, bad usability and new, barely used features because almighty POs are making all of the decisions.
Why would Intuit, makers of best-selling financial products, send engineers out to customers to observe how users experience their products? Why would Toyota send a Japanese engineer to live with a California family for two weeks and ride with them whenever they used their vehicle?
To learn.
Because customer obsessed companies know that you can’t make people awesome if you aren’t learning about their needs. And it takes a team to do that well, not one PO.
Tom DeMarco, a software development guru, author and legend of our field, said that the best teams are Networks Not Hierarchies. In his book, Why Does Software Cost So Much? he said, “The maddening thing about teams is that they happen by themselves, but it is difficult or impossible to make them happen. Failure to force teams to form is due, I believe, to managers trying to set up teams with themselves as leaders. That sounds like a good idea but it isn’t. I am more and more convinced that those who talk most about leadership have the most difficulty forming meaningfully gelled teams. The reason is that gelled teams aren’t really led. They are networks not hierarchies. All members are virtual peers. The leadership function is distributed. That is, different members take control at different times.”
Meaningfully gelled, customer obsessed teams are fully capable of deciding what bugs to fix, what new features to create and what tech debt to pay down. They share leadership, as Tom DeMarco says. They have no need for someone telling them what to do or being protected from tough prioritization decisions.
I recently recorded a video discussing this topic. You can see it in #ModernAgileShow Episode 3.
If you liked this article, please considering sharing it with others. Let’s gracefully retire the PO role and replace it with meaningfully gelled, customer obsessed teams.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!