5 Spicy Product Management Takes

What’s your spiciest opinion about product management?

I scoured the Twitter streets and found a few interesting ones to react to. Let me know what your thoughts are in the comments!

Roadmaps are a waste of time

Carl Vellotti on Twitter kicks us off with a classically spicy topic in the PM world: roadmaps.

It’s an age-old topic. Business wants reasonable expectations and clarity, product needs to remain flexible and is painfully aware that timelines don’t work.

So, what do we do?

I am required to produce roadmaps in my current role. I use the three following tactics to ensure maximum alignment:

1. I break down the roadmap into four quarters. Any timeframe shorter than that is suicide.
2. With every roadmap communication (e.g. email, meetings, etc.) I remind everyone that a roadmap is not a plan. The further to the right you look, the less ‘plan’ it even is.
3. I try as much as possible to reduce the workload and keep available time in each quarter to be flexible.

Data breeds average products

Amit says the quiet thing out loud and I’m here for it.

It’s always hard to go against the ‘data-backed’ crowd. They have science and research on their side, right? How could that be wrong?

My overall problem with this is mostly semantics. Most people or organisations claim to be ‘data-driven’ which I think is wrong for a few reasons:

1. They likely don’t have enough data (unless they’re Google/Facebook).
2. The data that drives them is biased (researcher bias, retrofitting research to the CEO’s already made-up mind, etc.).
3. They use the pretence of ‘data’ to justify a decision and never again critically look at it.

Instead, I’ll always advocate a data-informed approach.

It’s subtle, but it makes a world of difference.

Being data-informed means you’re aware the data collected might be insufficient, biased, and could completely be skipped during decision-making.

A data-informed PM with great product sense and the gut to make decisions is the true winning formula.

SCRUM is bad for velocity

I wrote a 6-part series on moving away from a SCRUM-ish approach to product.

Clearly, I agree with this take.

Read: Moving from SCRUM-ish to Shape Up.

Build first, problem second

Ugh.

I don’t know man. This one’s tough.

I can’t picture myself working on any product, project, or even feature that wasn’t initiated by some sort of problem. Even if you’re hoping to build something brand new, something creative, something you dreamt of, surely it still stems from some sort of problem, right?

Problem → Solution.

That’s the cornerstone of what we do as product people and, dare I say, entrepreneurs.

I guess it is a spicy take!

Frameworks are training wheels for dummies

I have a bone to pick with frameworks and it feels good to see others seem to agree.

I don’t dismiss frameworks entirely. They can provide useful inspiration (in the same way a case study or a template can).

My problem is when frameworks are sold as solutions to problems. Often, they don’t even provide anything of value. Take the RACE Framework:

This framework is meant to teach us that to get customers you should:

1. Reach customers
2. Get them to act
3. Convert a few of them
4. Engage them

I’m confident a 6 year old with a lemonade stand could tell you this. And without the fancy words, even better.

That’s my quota of old-man-yells-at-clouds for today. What are your spicy PM opinions?

Want to read more? I went deeper into each unpopular PM opinion on my Substack.