Software Engineer to Product Manager

Gwen Shapira
7 min readJan 22, 2018

I got an email this morning:

“What’s it like to be a product manager vs being a programmer? Why did you make the change, and was it always the obvious course for you?”

I get that question quite often. Sometimes from engineers who consider making the transition themselves. And sometimes from engineers who have trouble believing that product management is real work. They want to know what I do all day and how does that contribute to the products I work on.

Since I explain my job and the path I took getting there so often, I figured I may as well blog. This isn’t a guide to how to become a product manager or how to be an awesome product manager. This isn’t even the most important things I’ve learned about being a product manager. It is mostly about how being a product manager is different than being a software engineer.

Let’s start from the last part of the question. Was it always obvious to me that I’ll be a product manager?

The answer is, not really. For the first 10 years or so of my career, I barely knew product managers existed. I kinda knew that there were these people, who sat near the engineers, but also talked to marketing and dressed slightly better than engineers (but not nearly as well as marketing). They mostly talked to my manager. I’ve had lunches with them, and they could talk about the product and the customers and the use cases, but not with much depth. I cataloged them in my mind as something close to technical account managers and solutions architects and then forgot that they exist.

I first started thinking of being a product manager when I first saw Maria Colgan present. I think it was Hotsos 2008 or 2009. Good 10 years into my career. She explained something about the Oracle optimizer, or something about how to model data in a data warehouse. Whatever it was, it was deeply technical, and her explanation made everything clear and was immediately applicable to my job. Her title was “Product Manager” and I decided that I want to be just like her.

I started paying attention to product managers. I met a bunch from Oracle, and when I moved to Cloudera, I made a point of talking to a bunch at Cloudera too. That’s when I learned the first big lesson about product management: They are all different. The range of activities that people do under the title of “product manager” was frankly staggering. So, it was no longer clear to me that “product manager” meant “be just like Maria”. And I decided that I want to try being a product manager and see what it is like. The product managers I’ve talked to encouraged me and said that I definitely had the potential to be really good at that.

Which leads me to the next big lesson of product management: Everyone thinks they can be good at it. As an engineer, you rarely run into all sorts of people trying to do your job for you and who strongly believe they can do it better. Everyone knows that engineering is hard. Unfortunately, very few people believe that product is hard and what makes it challenging. This also means that when you inevitable suck at your job, as everyone does when they first start out, you will feel really terrible. You thought you’d be good, and everyone around you thinks it is easy, so how can I possibly be so terrible at this? It is really painful to discover that product management is actually difficult in a culture that believes everyone can be great at it.

I hope this explains why I made the change — I admired few product managers, that made me want to try it myself, it looked easier than engineering and everyone told me I’ll be good at it.

So, what is it like being a product manager who used to be an engineer?

People will tell you that being a product manager is a technical role. This is a lie. It is true that you need to be able to hold your end of a semi-technical conversation or the engineers (and sometimes customers) won’t take you seriously. And it is true that product manager is a bit more technical than most marketing or sales positions. But it isn’t technical. The problems you are solving are not technical problems. Engineers do that. They will be unhappy if you try to do their job. If, like me, you derive real joy from solving technical challenges, you are going to miss this a lot.

So, if you are not solving technical problems, what problems are you solving? The general problem that product managers need to solve is the question of “what are we building next?”. You do it in multiple levels: What are we doing next sprint? Next release? Next quarter? Next year? Next 3 years?

You need to have an answer to those questions, you need to repeatedly give the answer, explain it, justify it, defend it and evolve it.

Everyone will have opinions on what the answer should be. They will also want to know why your answer is correct. It has to be a good answer for customers, for sales people and for the company executives. It has to relate to the vision of the company, to what customers want / need, to what competitors are doing right now and to what is technically feasible in a given timeframe.

In order to do it well, you need to be well informed about the market (Everyone is doing microservices and clouds, it looks like Kubernetes is winning, QA is slowly disappearing). You need to be well informed about your competitors (and decide who is a competitor and why). You need to be well informed about your users and customers (not same thing!). Who are they? What are they trying to solve? How are they solving it? How do we fit in? You also need to be well informed about the company strategic direction, and the sales motion that drives the business. If your sales people talk mostly to people in role X, you need some features that appeal to that role, but perhaps strategically we prefer to sell to role Y and need to figure out how to reach them.

All this means that you spend 90% of your time communicating with people. You talk to customers, to share your plans (roadmap!), to explain the product and to hear about their use-cases and challenges. You talk to engineers to hear what is possible. You talk to executives about strategy. You talk to sales teams about how they sell the product and to whom. You talk to support about the challenges they are facing and to marking about how best to position the product. You read industry journal and hacker news and your competition blogs. You write strategy documents, roadmaps, user stories, epics, blogs, presentations, value propositions, positioning, sales scripts, demos. You review engineering designs and design-designs. You keep asking “How will this make sense to a user?”.

All this means that if you are a bit of an introvert, like many engineers, the job will sometimes feel impossible. Simultaneously, you will feel the least productive you ever did — because you just spent 4 weeks talking to people in order to form an opinion that is communicated via 3 lines on a powerpoint deck.

For me, there are two things that are really satisfying about the job.

The first is when you recognize need for a product that no one else saw, you advocate for it, get resources, get it done, tell the world about it — and it works. It gets adopted. Competitors fold their own product line because yours replaced it. Users send unsolicited feedback saying how awesome it is. Sales people say that it helped them nail $$$ deals. You know that all the talking added a tiny bit of awesomeness to the world.

The second is when the engineering team knows what they are doing. They don’t feel like they are building random stuff because “management said so”. They understand the users, they understand why the product will make life awesome for the user, they know that random feature requests will get evaluated based on user-value and user feedback. They are not afraid of random people with opinions jumping in and wasting their time. And you know that all this talking made the job of people you care about a bit more satisfying.

If I sound ambivalent about the role, it is because I am. I thought product management is a bit like “Engineering with people skills” or “Engineering with a bit more talking”. But it turned out that there is no engineering involved at all, that it is 90% talking about “fluff stuff” like strategy. And that unlike engineering where you feel sense of accomplishment every day or at least every sprint, product satisfaction takes much more patience.

As I said in the beginning — product manager roles differ in different companies, or even in the same company. I’m pretty sure that if you asked my colleagues, you’ll get a totally different story. But you asked me :)

This story is published in Noteworthy, where 10,000+ readers come every day to learn about the people & ideas shaping the products we love.

Follow our publication to see more product & design stories featured by the Journal team.

--

--

Gwen Shapira

Knows a thing or two about Kafka, Databases and Apache. Opinions are my own, and often not even that.