Product is Hard by Marty Cagan at Lean Product Meetup

One of the hardest questions I get is, what is really the best way to split up our product team and who is responsible for what. This still takes a long time to break down, and I don’t have a crisp answer for it yet.
But what follows are some of the other questions that are more straightforward to discuss.

What are characteristics of good product managers?

One of the best books recently is Principles by Ray Dalio. It’s a bizarre culture, and definitely not for everybody. He talks about principles for how people should work, and also life principles, and those are gold.
He talks a lot about how to make a decision. First principles. But also the believability test. If somebody has expertise in an area, then it has more weighting. And this is a problem for many PMs, they don’t do their homework, so then you have a situation where the CEO is meeting customers every week, and the PM hardly does. PM shouldn’t decide anything if they’re not out there with customers at least as much as the CEO. And you need to share what you learn so that others see that you are believable.

Meetings all day, no time for doing real work

This is very common for product managers, particularly at medium to large companies. At a startup you’re incredibly busy, but at least it’s real work.
I don’t know how you can do this job if you can’t find four hours of quality time a day to work on real PM things.
I’ve got to the point where if I don’t turn on airplane mode on my phone, I can’t get through anything hard.
A lot of PMs, particularly in the Valley, are getting those four hours from 6-10 at night.
The other way, is to stop going to all these meetings. Product people feel like they have to be at every meeting their product is talked about.
Four hour a day reality.

We can’t find enough engineers or designers locally

The results, particularly for innovation, for a co-located team are much better.
Remote employees are better than contractors and outsourcing.
If you can have a tech-lead sitting with you, then they can at least talk to the other engineers sitting elsewhere.
If we can’t keep the three roles together (design, engineer, PM), then ability to solve the problems drops way down.
Contractors are mercenaries. And to solve hard problems you need passion, and to be a missionary.

Process

The dual track model is how good modern product teams work.
But most agile teams are actually waterfall.
What makes something waterfall?
- Requirements drives design which drives code
- Result is output
- All risk is at the end
Even if you’re doing two week sprints, but those three things above are happening, then it’s still waterfall. It’s better that it’s two weeks instead of three months, but it’s still the bad way of working.
Dual track agile is designed to avoid those three characteristics
- Tackle risks up front
- Define collaboratively
- Outcome not output

We’re in a regulated industry, how do we experiment?

Our execs are addicted to roadmaps

Maybe the single most common product team frustration
I understand leaders here, they are trying to run a business, they need to know when things are going to happen
Outcome-based roadmaps.
- Transition to this, can take about a year to do though.
- Keep doing the roadmaps you’re already doing, but immediately start adding what the business result is once you complete the items on the roadmap.
- Then every time you talk about that roadmap item, you talk about the KPI.
- Once it goes live, you start reporting on that business result.
- The board level should care about business results, which you are highlighting here. It’s the middle management layer that cares about features.
- Keep returning to the KPI you expected and the result you got.
- If you want an empowered product team, you’ve got to give them the problems not the solutions.

Our technical debt has overwhelmed us

Early at ebay we lost a third of customers due to tech debt issues
Netscape lost the browser wars due to tech debt
- Three points:
  - This issue needs to be treated as a business continuity issue – it can literally kill companies
  - Dial up engineering capacity and down product and design
  - Pick your battles
You cannot avoid having tech debt. You need to control it though. Do not let it get way out of control.
We’re not even talking about the point of having major outages. If you cannot respond to the needs of the market or your customers, because it takes your engineers so long to build anything, then tech debt is not in control.
Ultimately it’s the CTO’s job to ensure the systems and architecture can meet the needs of the business.
Sometimes CTOs say that product won’t let them address it. But the CTO is wrong for even asking the head of the product. This stuff is not up to the head of product.
If you’re in serious trouble, you need to make a call to dial down product and dial up engineering.

If OKRs are so great, why are they so painful?

I’m hoping for a better system to come in the next few years.
Too many teams have too many problems when moving to OKRs.
The point of OKRs is to have a clear objective for the business, and a measurable result.
It’s not implement a feature.
For most teams, who are not empowered teams, OKRs just bring the issues to the fore. Which means it is difficult to recommend them to everybody.

My engineers just aren’t excited about what we need to do

It’s the responsibility of the PM to excite the team.
Bring them to see users and customers in person. Particularly users who have a clear pain.
Share the full business context. Life time value, cost per customer, share all of the economics. Anything that adds context.
There’s so much innovation in the developer platform space (AWS is a great example). Developers are really good at innovating when they clearly see the problem.
Engineers are consistently our best source of innovation.

My CEO tells me what to build and to just “trust him”

Often the PM has not done their homework.
But when they have done their homework, sometimes they don’t share what they’ve learned enough.
When there is a disagreement, try to run a quick test, so that you have some data rather than opinions.

Published by