Let’s go back to how Rand changed that one confusing word in Moz’s product interface.
Moz’s product development process was clear: anyone could submit a feature request to the product managers. The product managers would then decide whether it made sense to move forward with it and when this change could be added to the product roadmap for release.
Rand tried to follow the process but his request wasn't prioritized. He brought it up a number of times over the course of another six months with no luck: more important features needed to be developed first.
So Rand decided to go directly to one of his friends and Moz developer Kenny to accelerate the process.
He asked Kenny: "Can you push this to production? You don't need to tell anyone, just push it out."
At the time, Kenny just put his two-week notice at Moz.
Kenny obliged: "Yeah, I can do that. What are they going to do? I'm already quitting. They can't fire me anyway."
And so the change was made. “Opportunity” was changed to “Organic CTR (%)”.
Quick win. Big impact.
End of story?
Rand forced his way through the process and as a result enraged product managers, product designers, engineers, marketers… Pretty much everyone involved in the product development process.
Was Rand right to fight this hard for a quick win that would clearly make users happy? Was the product development process too rigid, too cumbersome? Or should he have followed it like everyone else?
A few of our podcast listeners shared their thoughts with us - brought to you with no filter.
Hanna-Mari thinks that Rand’s approach isn’t good for morale:
"It's super frustrating when people jump in with requests directly to the engineers. You don't know what's getting done, who's doing something they weren't really asked to do, and what planned features get pushed back because of it. Besides, we're talking about people with their egos and emotions - if someone constantly goes around the people assigned to manage the product it can make them feel like their authority is being undermined. It's not good for the morale."
Richard thinks Rand has misunderstood his role entirely:
“He should not be the one forcing his ideas into production past the broken development process. His job should be to fix the damn process! Or even better: help people fix the process because they will know what's broken. He doesn't - because he is too far away from it.”
Finally, Reuben chooses the middle ground:
“If everyone starts shooting ad hoc requests to the dev team, there will be chaos. On the other hand, if a simple usability fix needs to "wait in the prioritization line" for months and go through a bunch of endless meetings to get approved, then that is even a bigger problem. There needs to be a well-defined yet flexible process of shipping as fast as possible while staying true to the target and more importantly, the user.”
Here's Rand's perspective on the matter: your product development process must be well defined to prioritize the right features in line with your vision, yet flexible enough to ship quick wins as fast as possible to keep your users happy.