From Software Engineering ⇒ Product Management (A 3 Month Reflection)

So it's been about three months into a foray into what I'd call "official" Product Management. In the past I've worked with talented product folks, I've had a title as "product developer" (to emphasise the product aspect of my role), I've ran usability testing, I've worked with great user researchers, I've advocated on behalf of my UX colleagues, I've facilitated design sprints and workshops. I've certainly "worn the product hat". But I had not yet officially took the leap to slap the product label on myself.

This post is a reflection on how engineer to product management has been ~3 months in.

I'll look at product management mostly from a software engineer's lense. So I should mention my background. I've been writing software for over 10 years. I've worked in front-end and UI/UX roles, back end, full stack, cloud, platform, you name it. Early in my career I had the intentional goal of gaining a full understanding of how products are built end-to-end. That journey is still ongoing, but I have a pretty good handle on it after many years, and seeing many different environments.

If you're a software engineer and reading this, my goal is to at least try my best to convince you that product could be right for you, given a few factors. If I fail at that, hopefully you'll have a new found appreciation for what product is, and how you can work better with the product folks you work with.

So... it's been 3 months now—how is the product management life?

Before I get into some of the reflections, let me first define what product means to me. I think this is important as the product role is varied, and some folks see it differently to others. Mum, if you're reading this... this is what I do. The best definition that I've seen so far is from Lenny's Newsletter [1].

I don't think there's much more that I would add to this definition. It's pretty much entirely how I see it.

Using whatever means necessary to help set the vision and direction for your team/product/company, collaborating with engineers and folks in the company to steer the product in the right direction.

With the definition out of the way, let's get into some of the engineer to product role reflections...

Gergely Orosz posted a great Tweet [1] recently about the three overlapping areas we often see in product and engineering teams:

What amused me about the tweet is how Gergely represents the three areas as a Venn diagram with "danger zone" right in the middle. The idea he's trying to convey (I think) is that these three areas are all big skills to master, and trying to juggle them all (over the long-term) is a fools errand. Each area requires you to spend some time to sit with it, and understand it well to do a good job.

I mean... the tech side of the equation is huge. Depending on the company you work for and the tech stack, keeping up-to-date is frankly a never ending task. Whilst technology gets simpler in ways, the demand for what engineers need to do nowadays only gets bigger and bigger. We're moving more towards a full stack world, with software engineers owning more aspects like operations. It's a lot.

The work I had done before as a tech lead, principal engineer etc, often spanned these three areas. I'd be managing teams, providing feedback, coaching, and encouragement. I'd have the responsibility of trying to keep my tech skills sharp, keep up with the industry, review code, etc. But then also, drive outcomes, set visions for the team and product. Honestly speaking, it was a lot of responsibility.

Stepping into product has allowed me to let go (somewhat!) of the two areas of people management, and technical leadership, and focus more on the stakeholder management and product side. Whilst I'd always been interested in this topic area, product is such a truly deep discipline which I now have a continued respect for... there are many ways to create a roadmap, there are many ways to structure your discovery and planning process. In product there are no easy answers—but that itself is fun.

As an engineer, I always wanted to be managed in a certain way. For example: "Just give me the vague idea behind what you're trying to build, and let me come up with different solutions to move the needle". More often than not, I just wanted a KPI or a metric. "Show me which metric you want me to move, and as an engineer, as a team, we can work on moving that needle". In fact, as a tech lead / principal, this whole metrics-driven team management was something I had in the back of my mind and was always pushing for. Establish visible metrics for the team, align around those metrics.

However, very, very few environments that I ever worked in were managed in this way. More often than not there were many layers of thinking between the engineers and the solutions. A solution would come "over the desk", fully formed and "thought out". As an engineer, you'd go ahead and implement the solution. Maybe it would work... more often than not it would be a flop/dud. This whole process of being passed ready-made solutions gets pretty tiresome and demoralising. I remember well the company that asked me (as a UI engineer) to build them a bar chart with only one bar.

"MVP" is what they called it... But I called it something different! 🙃

Switching into product has allowed me to push back against this industry anti-pattern of giving engineers ready made solutions. Now, I champion to bring the customer into the picture, help us talk to them more frequently, and help the team understand the context of what they're building. As an engineer, this leadership style is what I always wanted from my leaders. Bring me the customer, bring me the metric, bring me the challenge, and collaborate with me on solving it. Being in product allows me to take the role of being that leader that I always wanted to have on my team.

One hesitation I had moving into an explicit product role is that I'd seen a lot of product folks doing what can only be described as "glorified admin work". Product were the ticket-chopping folks who'd take a piece of work and break it down. When you get to a certain level of seniority, this ticket-chopping responsibility often falls with you. In a perfect world, you empower your team to do that work, and avoid the trap of "becoming the ticket person", but it takes time to get to that place, and you need some team structures, norms to set in place, and some coaching to do before you get there.

What I've come to appreciate now is how product roles vary depending on the customer. If you want to take a product role, I'd suggest you think long and hard about who your customer is, and whether you genuinely care about them before you take the plunge. Because I think that whether you truly care, understand and empathise with the customer will impact your success.

Being that I work on developer tools, our customer is (mostly) the developer. Having a developer as the customer made the step from engineering into product that little bit easier. Whilst I'm not writing code all day, I do interface with folks who are. As a principal engineer, I was the type of principal that wasn't writing much code anyway... 9/10 times I felt like the biggest opportunity "levers" I had were people, and not technical. So I didn't go from writing code day-to-day to conducing user interviews with lawyers, I'm still working day in and out with engineers, both on my team, and the customer.

So things aren't all that different. The big difference is really how people see me, the conversations people want to involve me in, and the challenges people think that they should give to me. Before, I'd get people challenges, technical challenges, and product challenges. Now, I get mostly product challenges, and less of the other two, which allows me to focus more.

And that's it! For me, this product management stuff is now the start of another new career journey. I think that it's important to keep seeking out different nuances of your life/career which you can explore to keep things interesting. Granted, I didn't see things going in this direction this time last year, but here we are. Sometimes opportunities present themselves, and decisions have to be made!

I'm curious to see how deep the product rabbit hole goes, and for how long it will keep me busy and challenged. I'm also curious to see whether I'll start pining to go back into writing code. I feel that I already know the answer to that question, though: If a team/company has a great product-minded set up, I would gladly go back to writing code, but as long as companies still need help shaping how they do their product work, I'll will often find myself gravitating back to helping with product work.

I hope this post gives you a bit more insight into what it means to be in product. Maybe some of you reading this might think more about product as a way forward for your career. It's certainly been a way for me to work on communication, leadership, vision setting, workshopping, and more. You can always go back to software engineering if you want, taking a little time out to do something a bit different might help you bring some new perspectives into your work.