@johncutlefish's blog

Check out Iterate.fm, my podcast with friend and coworker Tareq

Talking Product: Running Themes from a Year of Conversations

Published: January 05, 2017

I’ve talked to lots of product people (and engineers, UX, and agile coaches) over the past year. I am commonly asked if certain themes bubble up again and again. So I dug through my notes and recordings and looked for some running themes, and then selected some exemplary quotes.

Some of these are verbatim (when I had the recording). Others were reconstructed from copious notes.

Recruiting and churn is a big deal.

We are having an incredibly hard time finding qualified PMs. It’s just so hard to find that perfect fit. Our cross-functional teams are demanding (especially the more senior developers and QA). The business is demanding. Our customers are demanding. Attrition is high when we even fine them.
VP of Product#### The plight of junior PMs, and the need for training

Our track record when we place associate PMs directly on teams is abysmal. I feel bad for them, and I feel bad for the teams. We’ve experimented with training programs, but everyone is just so damn busy. They just don’t get it, and I’m doing a terrible job helping them get it.
VP of Product#### Need for product managers, the title, team assignments

We’ve been questioning the need for PMs. I know we are *supposed *to have one on each team. But do we really need one? How do they actually add value? There’s a lot of confusion among our engineers and designers around the role of the PM. I can see the need for a more senior PM for the whole product, but it feels like we create “mini-products” just for kicks. It seems like another role should exist, but I can’t describe it exactly.
Director of Engineering#### Career development challenges

Where do I go from here? I want to keep working with teams, but the only way up is either to quit and join another company, or to move to another part of the organization. Biz-dev maybe? Remember, there is one of us for between four and six of “them” (engineers). Above me is a VP, and the reality is that we only need a team that is *so big.
*Senior Product Manager#### Tensions around using data in product development

The engineering team talks about data all the time. We have two data scientists at the whole company, and they are split across all of the departments. They (the engineers) treat this like a science … like a big machine learning experiment. I respect that, but we are simply not resourced to do that. Even if we were, I don’t think it would be what they expect. There’s serious tension at the moment around this topic. The product team didn’t hire for these skills.
VP of Product#### Filling the “gap” between the business and front-line teams

About a decade ago we used to see the product manager as protecting the team from the business. No one wanted to deal with the business, so we forced this person to act as a go-between and to channel their needs. They were the translation layer. It just isn’t like that anymore, honestly. And when it is — when the team seems to be asking for that — we typically know something else is going on.
Release Manager#### Impact of velocity on product management

Speed. Things are so blazing fast these days. We could release even more often if we wanted to. This has put an immense amount of pressure on the product management team. Maybe five years ago you could have argued “oh well, this will take a while, we need to do more research”. Now there is a definitive argument for just shipping and iterating. And killing the work if we need to. I’m not sure that has stuck with everyone. You have this political thing now with getting to iterate on something once shipped. On some level that is a luxury!
Senior Product Manager#### Engineer / product manager tensions

The discussion is always about them and *their *product. Not *our *product. Or it is about their ideas. You would think that they believe no one is watching. We see what is happening with what we build. We look at the metrics. We see the shifts in strategy when stuff goes wrong. They return from “high profile” meetings with our “new direction”. Yes, this sounds bitter.
Engineer#### Teams taking on product management responsibilities

The interesting thing, is that as the individuals on the teams matured, we started to see a changing role for product. The teams became more self-sufficient. Without a PM/PO, we could hand them a problem — even a sort of nebulous one — and they’d make progress. That changed the game for the PM, and made it easier in some regards, but also harder. The game is more complicated.
Director of Engineering#### Looking for an edge…

I’d say things are good. We are always looking for that extra edge. The discussions these days are more about metrics and how we measure our efforts. Or how to really get UX working directly with engineers. That kind of stuff. There is this sense that there must be something better out there that we are not doing. The business is doing well, also, which hopefully is due in part to our work. If there was a downturn things could get pretty dicey.
CEO#### Growth and debt challenges

It is easy to blame the product manager in this case. So convenient! But taking a step back, our team is digging out from serious technical and leadership debt. There’s only so much we can do at the moment. We grew and grew, and now we are dealing with it. I’d say that half of the crap we’re dealing with is self-inflicted because we are so nervous nothing is actually getting done.
COO#### Organization design and silos

We’ve toyed with combining our product and engineer departments to form a single product development group. I think we’ve got it under control at the moment, but at a certain point the cultural differences between the departments will come back to bite us. At the start, that’s how we worked. But as we grew, the more loose “departments” became hardened. Throw UX into the mix — now aligned with the product organization — and you have a lot of moving parts.
CTO#### Coaching and product owners

My role is to help the teams, including the product owner. Repeatedly, I see the product owner as the source of friction. At one point we had to do retrospectives without the product owner present because the situation got that bad. The blame rests on everyone’s shoulders, but I find myself spending most of my time trying to help the product owners.
Agile Coach#### Respect and trust

Respect is so easily lost, and so hard to build up again. We have a strong engineering culture, and to be blunt, we don’t suffer fools lightly. If the PM seems manipulative, waffling, or unsure … the teams pounce.
Engineer