This is part two on a series of posts on my transition to Product Management. If you’d like to see where this series began, feel free to checkout part one.
As I’ve gone back and looked over some of the email traffic from my first couple of years in my role as Product Manager, one of the most obvious things that stands out is just how much was going on at the time (and how little I’ve apparently retained)!
The backdrop of this period was a parallel effort in the company to:
- Modernize our software development practices by moving to a process built on Agile Scrum, and
- Shift way from our custom, consultative software development model to a product-centered approach focused on broader market needs.
Either one of these would be a large, challenging transition. Looking back, attempting to tackle both at the same time was borderline insanity!1
Looking more closely at the transition to Product-oriented development, this is also seems to be a pretty common phase in the startup life-cycle.
As I’ve talked to other folks in the industry, I’ve noticed that many startups, particularly those in the B2B space, initially succeed by developing a solution for a couple of “whales” that serve as an essential lifeline that keeps the company operating. Over time, as those successes beget more successes, the company can step back and focus more on the market than individual opportunities, and at that point, a pivot to a Product-centric development process makes a lot of sense.
The trouble is, this is often not an easy transition. Ignoring the challenges in shifting the entire mindset and culture of an organization, there’s the basic politics of handing off responsibility for feature selection and prioritization from technology leadership to product leadership. As you can imagine, this transition can be very difficult if not handled delicately.
Well, here I found myself at the very center of this transition. And, while today I’m hardly what one would describe as delicate, back then I was the proverbial bull in a china shop.
Imagine, for a moment, a hotshot developer. This guy has been in the industry for a solid twelve years by this point, but in a lot of ways he’s not encountered significant adversity. Technology has always come fairly easy to him, and he’s demonstrated those skills on a number of major projects. And now, out of the blue, management has tapped him to take on the task of building up a new core of Product Management at the organization, and he’s feeling pretty self-important about the whole thing!
He’s confident. Too confident.
While having a reasonable emotional intelligence, he’s also fairly insensitive to how he comes across, particularly in written form. He particularly values being technically correct, and as we all know, that’s the best kind of correct. Unless, that is, you’re not a cold, logical computer, in which case it can come across as annoying, nitpicky, and argumentative.
On top of all that, he’s impatient and easily frustrated, having not yet begun his journey into Stoicism. He’s baffled when people don’t listen to his arguments, and frustrated by the things he can’t seem to change.
In short, he’s pretty rough around the edges.
Now throw an enormously delicate organizational change management task at him.
In my defense, looking back, I’m genuinely surprised the whole thing didn’t completely blow up in my face. But it took me a good solid year or two to begin to internalize one of the most important lessons I learned from those days:
- Product Management is an exercise in leadership.
- Leadership and authority are not the same things.
- Product Managers have no authority.
- Therefore, you have to find other ways to lead.
See, in those early days, I internalized a fallacy: That my job was to be “The CEO of the Product”. It was a canard that you’d often see repeated when defining what Product Management is in the context of software development.2
But here’s the problem: While a CEO is the ultimate authority in an organization, Product Managers often have no authority at all. In my own organization, this is codified right in the org chart, as there is no line connecting me to development management in any way.
I didn’t really appreciate this at first. In the beginning, I thought3 that my power as a Product Manager came from my title, which granted me a sphere of control and the authority to operate within it. I assumed that others would listen to what I said because I was “The Product Manager”, and therefore they simply had to.
It took me a couple of hard years to realize how faulty that model is; that my success or failure in pushing my vision would be determined by my ability to influence others through kindness, patience, humility, and empathy, and my ability to build relationships based on trust and mutual respect.
Seeing how much more effective this approach could be, I came to realize that I’d been thinking about leadership all wrong, and that real leadership was measured by my ability to effect change by connecting with others, convincing them of my ideas, bringing them on side, and then working together to shift the world a little bit closer to that vision.
In hindsight this is pretty obvious stuff. But, as usual, I decided to take the long way ‘round to get there. Fortunately, the company gave me the time and space to learn a few of these lessons the hard way, even if it meant I had to make a few apologies along the way. And by the time I needed to start building a team, I had internalized enough of these lessons that I had a much better idea of the kinds of people I wanted to hire, and the values I wanted them to embody.
Even if I had no idea how to actually go about doing it.
Remarkably, overall, it went pretty well! We still have a lot of work to do, but we’ve come a long way in the last five years. ↩
I find it interesting, if not a bit ironic, that just as in the last five years I’ve learned how utterly incorrect this is, if you look around you’ll discover the industry seems to have separately come to the same conclusion. ↩
I hope not consciously… I don’t like to think of myself as an authoritarian, though my behaviour has occasionally suggested otherwise. ↩
No webmentions were found.