Unpopular PM opinions on roadmaps, data, SCRUM, and more
Unpopular PM opinions on roadmaps, data, SCRUM, and more
Unpopular opinions. We all have 'em. Some spicier than others.
Carl Vellotti asked his audience for their most unpopular opinions as product manager. Here are a few that caught my attention.
Carl opens the thread with a classic unpopular PM opinion (making it, therefore, an oxymoron?): roadmaps are a waste of time.
I tend to agree.
It's not exactly that roadmaps are bad or that you shouldn't have one. It's that roadmaps are interpreted by most stakeholders as set plans.
And who could blame them?
Throw some big features on a piece of paper. Organise them from left to right. Add dates. Looks like a plan to me.
To top it off, the business does need to know where we're going. Sales need to know when they'll be able to sell feature X. Customer service should have an idea when issue Y will be fixed.
As much as PMs and engineers would love a 'we'll get there when we get there' approach, it's not exactly feasible for most businesses.
So what do we do?
In my current role, I am required to produce roadmaps. I take three practical actions to mitigate the issues:
I break my roadmap down into quarters. Monthly or even weekly (shock, horror) roadmaps are insane.
I caveat every roadmap-related communication by reminding that a roadmap is not a set plan. It's in everyone's best interest to remain adaptable. The further to the right you look, the vaguer the items.
I allocate time for reactive work every quarter. This ensures flexibility.
I love that.
Speaking against the 'data-driven' crowd is always unpopular. Some people have a visceral reaction to this. How dare you not trust data?
Here's why.
There's not enough data. Unless you're Facebook or Google, chances are the amount of data you're collecting is minuscule. A hundred heatmaps, ten user interviews, and three Gartner reports do not constitute enough data to make decisions.
Collected data is biased data. Most of the time data is retrofitted to fit a narrative. Even with the best intentions, it's easy to fall into the trap of only collecting data that justifies the action we want to take.
Data is used as a crutch. It is used to make a decision and pretend to distance ourselves from it. "Look, I did the research!"; but the 'research' is never questioned, biased, and anecdotal. It then becomes incredibly hard to go against 'the research' and egos get involved.
So, do we throw away all the data and build what we feel?
Perhaps.
Product sense and strong leadership can lead to exceptional products.
At the very least, I suggest tweaking the words: data-informed, not data-driven.
A data-informed product manager is aware they don't have enough data.
A data-informed product manager knows their data is likely biased.
A data-informed product manager is not above questioning or bypassing data.
Data-informed + a deep customer understanding + product sense. That's the winning formula.
Yes. 100x yes.
I've written a 6-part series on this: Moving away from SCRUM-ish.
I've said all I had to say about this topic in this series.
But yes.
Carl wanted spicy, he got spicy.
I simply cannot get behind that opinion. It doesn't even compute in my brain.
I'm not sure how you find a product (or feature) to build without starting from a problem. Perhaps I’m not creative enough.
Sure, you could come up with something funky to add to your product; but the idea must still stem from some kind of problem, right? A challenge? Something you'd like improved?
The product you end up with may not solve the problem you started with. That's fine. Zuckerberg didn't set out to build Meta and 'give people the power to build community and bring the world closer together' back in 2004.
But he started with a problem.
It all starts with problems.
Oof.
I tend to put frameworks into two categories.
Category one: are you kidding me?
Most frameworks fit into this category. The 'Did you really need to write this down?' category. Here's a classic example: the RACE framework.
So you're telling me that, to market my product, I should first reach people, persuade some to do something, convert a few, and then engage so they stick around?
Well blow. me. down. I wouldn't have thought of that. I was going to just scream in a well, spin on my head three times, and shove garlic cloves in my ears instead (the lesser-known SDS framework).
Category two: ohh, magic
This one is sneakier.
Magic frameworks organise your work to perfectly fit your outcome. They don't actually help you do the work or get to the outcome. They just look cool after the fact.
For example, here's the Bullseye framework sometimes used for product growth:
Working through this framework doesn't actually help you figure out which growth channel is best. It's just a fancy way to present your research back and retrofit your findings. Looks cool on a slide.
I don't dismiss frameworks entirely. They can be great inspirations, like case studies or templates. I would just urge anyone to take the blinders off and see that frameworks are not the work.