Comment by hansef | Hacker News Reader

Comment by hansef | Hacker News Reader

I've experienced this in my own 7-year practice as CTO of an agile rails consulting shop, growing from 2 to 20 people while working with dozens of clients ranging from government agencies to VC-funded startups and self-funded single founders. Some of these projects have been extremely successful, while others have resulted in high-quality software which never saw the light of day or met real user needs. I would estimate the ratio of success to failure has been 1:5. It's deeply disheartening for me, and for the outstanding development teams I've built, to see work we have put months or years of effort into collapse due to lack of focus and clear, cohesive product management and vision.

The successful clients all had someone inhouse they could dedicate full-time to defining a well-structured backlog, grooming stories, balancing feedback from stakeholders, acceptance testing work, communicating with design and development, and generally acting as the unary executive voice of the product.

SomeONE. And the problem is that the role here calls for both executive, rather than committee, function and requires a broad generalist skillset. A good product owner needs to think analytically, write clearly, communicate firmly and negotiate competing needs and priorities. They need to be comfortable discussing technical details, even if they are not themselves technical. They need taste and understanding for user experience, even if they are not themselves a designer. They need delegation skills and a keen editorial instinct.

There are many more people with money to build software than with someone in-house with a matching set of aptitudes and is available to own a project.

Instead we get a group of department heads, with overfull schedules and competing needs. We get people who come to us with ideas for apps they are sure will make them wealthy. We create beautiful software for them, they "launch" in the App Store, and we never hear from them again. We get VPs of Product who spend more time in endless fundraising meetings than talking to their customers and development team.

The real surprise is that the success ratio has been this high.

I've experienced the same problem, and I attribute it to the culture of "no accountability" in so many organizations, both large and small.

When I first learned scrum, the product owner was described to me as the "single, ringable, neck."

The problem is that no one wants to put their neck out there. Decisions can't be made without committee, and individuals are literally afraid to own anything for fear of being held accountable if things go wrong.

>"single, ringable, neck."

You don't "ring" a neck, you wring a neck.

Like one wrings a towel dry.

Take a towel into your hands and wring it dry.

Now imagine a clasping your hands around a neck and doing the same thing.

I've just used a mnemonic trick to prevent you from ever making this mistake again.

LOL thanks for the correction and the useful mnemonic trick!

I was fairly certain 'ringable' was not a word so I fudged the quote. Unfortunately, even 'wringable' isn't a word. I guess it has to be 'wring-able', which just doesn't look right.

I believe the problem lies in the difficulty of fully grokking the project owner role. It's nontraditional and not very glamorous.

Department heads are not product owners. In fact, I am a firm believer that being in any way responsible for staff is generally incompatible with the product owner role.

Yep, which just adds to the implausibility of this person existing on-hand in an organization. But if we can't find product owners in the wild reliably, how do we as consultants help nurture them in the projects we are engaged in, and help our projects and clients succeed?

That is quite a problem, especially since the product owner should ideally be someone with a vested interest in the product, which sort of implies that you cannot use a consultant as a ersatz product owner. Unless you intend to keep the consultant on for basically forever.

I has the luxury of working with a good product owner once. We recruited him for the task at hand, so he had no background in the organization doing nothing other than his PO duties. This turned out to be a great boon, and managed to avoid the usual pitfalls of developer-turned-PO or boss-also-doing-PO.

I'm not sure if we can find them reliably but we can reliably identify them: you need an engineer (better: a system architect) tinted with things like "usability", "UX design" and similar. He or she will be technical enough to drive the development team as a PO and have enough social skills to extract information from the client. A consultant will be fine -- maybe even better than a person from within the client's org.

Reply on news.ycombinator.com