A year and a half ago I decided to become a product manager after 5 years as a software engineer. This past June, however, I decided to switch back into engineering.

What happened, and what did I learn?

Why I became a product manager

When I started at Artsy, I hadn’t planned on becoming a product manager. As I onboarded and worked on projects like building Artsy’s ecommerce backend Exchange, I found myself wanting to be involved in the “what” and “why” of our product and not just the “how.” I’m an artist, and so art and the art market are special topics for me. I felt like I would have more impact as a product manager, and I definitely wanted to have greater impact on the art world.

My previous job had me doing a blend of product management and engineering work, and so I had already had a taste of PMing. I spoke with our VP of Product at the time and she agreed to let me try it out. And just like that, in January 2019 I became the product manager for the Auctions team.

Becoming a product manager

Product management is a surprisingly difficult job to define. Everyone agrees on one thing: product managers lead the product development process. However, what product development actually entails differs from company to company because of differences in resources, culture and priorities. In practice, product managers may find themselves doing a lot of things that on the surface have nothing to do with product development.

Product management can be distilled down into two tasks:

1. Ensuring that the right feature / product is being built for your users, and
2. Doing whatever it takes to make (1) happen.

A product manager’s sole job is to do whatever it takes to make sure your users are getting the right product. That’ll almost certainly involve talking to users to understand their needs, analyzing product usage data and working with your team and stakeholders to create the next great feature, but there’s nothing in those two tasks that says you need to do any of that. You can do this job any way you’d like as long as you get results. If I knew that I could have built a better product for my users by pogo sticking across the Brooklyn Bridge then you would have found me out there pogo sticking all day, every day.

All that to say, the job is highly ambiguous by design. Any problem could be your problem, and it’s up to you to judge whether or not that’s the best use of your time for your users.

Redefining work

Compared to engineering, this ambiguity was a huge shift for me. As an engineer, my thinking was previously limited to our systems and our codebase, and I largely thought about how to use them to build products. The “how” was now largely abstracted away from me. It took me a long time to get out of that mindset, largely because I was uncomfortable with how ambiguous PMing was.

There are a few reasons why the ambiguity was uncomfortable. The first was that the actual output of a product manager didn’t feel like work. As an engineer, you can write code and instantly see the results of your work. There’s a clear pipeline of progress, from initial commit to opening a pull request and deploying your code.

As a product manager, though, your output is much more amorphous. You might spend your time reading up on user feedback, or you might make docs or comment on other docs. You might spend your whole day in meetings talking about the same thing over and over again with different groups of people. You might get interrupted repeatedly throughout the day with questions and problems. Days would fly by and I would have no idea what I did even though I was busy all day. I just couldn’t get that feeling of progress.

I worked through that by keeping a detailed journal. For the first three or four months I recorded what I was doing every hour of every day. That practice gradually transformed into a more manageable daily journal as I got used to the work style. No one ever saw those notes – it was just so I could keep track of what I was doing, what I was thinking about and feel some accomplishment by writing things down. It helped bridge the gap, and it’s a practice I still maintain.

Another thing that helped me with the “feeling” of work was reading the perspectives of other managers. Andrew Grove’s High Output Management was especially useful. Somewhere along the line I read the phrase “the meeting is the work,” and it clicked for me. A core output of my job was to communicate with others (more on that later). As an engineer, it’s counterintuitive. The more time you spend in a meeting, the less time you spend writing code. Product managers need quiet thinking time too, but a significant portion of the job is working with others. Meetings are how the work gets done. That framing helped me feel more productive.

Compounding the problem of not knowing what work “felt” like was not really even knowing what my work was. Here’s a great journal entry from my second or third week as a PM:

What I don’t have clarity on:

• Am I taking on too much for the first quarter?
• How do I narrow down the work that I want to do next?
• How do I organize everything?
• What am I supposed to be doing?

It felt as existential as it looked!

Before I understood that part of my job was to systemtically remove any and every roadblock getting in the way of shipping a great product, I tended to focus my energies solely on going through the product development cycle. I could prioritize and propose a feature, but if something wasn’t possible it just wasn’t possible. As my understanding evolved, though, I began to see that a lot of what wasn’t possible actually was possible. It just depended on me creating change.

Knowing that felt both enormously empowering and terrifying. If I was unclear before on what my job was, I felt even less clear now that any problem could be my problem. But I got used to it, and over time and with coaching from my manager I was able to suss out what not only could be my problem but what should be my problem. There are some things nobody can change, but there’s a surprising amount a single person can do. In the end, I think this expansive view of work is the right framing for not only product management but really any job.

From data paralyzed to data informed

I studied a hard science in school and have always valued rigorous, quantitative reasoning. That kind of reasoning is valuable in science and engineering, but when faced with the fuzzy world of business it can only take you so far. The data you might want to make a decision frequently doesn’t exist, and even if you can get it you probably don’t have the time to get it. I found myself initially in loops of analysis paralysis, struggling to find a rigorous justification for why we should build what we were building.

I found my way out of that loop by focusing on finding the best possible outcome. Instead of getting caught up trying to maximize my quantitative understanding of an opportunity, I focused on getting just enough information to understand the relative upside and downside profiles of the opportunities in front of me. I used a rule of thumb that 70% confidence is usually good enough to make a call. I didn’t always know what the exact impact of a feature would be, but I knew enough to know that whatever we were doing had the highest impact out of anything on the table. That allowed me to make decisions with confidence.

With that frame of mind, my quantitative skills turned into a huge asset instead of a hindrance. I feel confident navigating Artsy’s database and running my own SQL queries, which helped me work alongside our Data team to analyze performance and potential impact for a new feature. And when that work was impossible, I was able to take the data we had and still make an informed decision with it.

Learning to focus on users

That style of thinking didn’t just extend to why we should build a feature, but also what we should build. When considering a feature, I found myself jumping immediately to how the feature would work on a systems level rather than what the user experience should be. That was a double-edged sword. While it made discussions with the engineers on my team seamless, I sometimes would rule out features in my head because I knew they “weren’t possible.” Of course, that did an injustice to both our users and the engineers on my team. Our users deserve the best experience on Artsy, even if it feels impossible to me. And the engineers on my team could really find a creative solution for just about anything I threw at them.

Similar to my data paralysis, part of the problem here was that creating a great user experience was fuzzy for me, and I subconsciously rejected fuzzy things because they didn’t align with my version of rigorous knowledge. It was easier for me think about systems than it was to think about creating a truly delightful user experience, and so I thought about systems.

That changed as I really dug into user needs. I cultivated user empathy to an entirely new level by immersing myself in user feedback and user research. I began to really feel that the choices we made impacted the livelihoods and passions of collectors, institutions and artists. And that helped snap me out of it: our users needed a better product, not better systems, and so I began to focus much more on how to make a better product.

To understand how to build a better product, I spent a lot of time examining other products to understand what made them compelling. How did a product meet users’ needs? How did it delight them? Where did it fall short? What would I do to improve it? Doing this over and over again sharpened my product sense and made it easier to think through how we could build a better experience for Artsy’s users.

Influence and communication

Influence is the currency of product managers. Good product managers work to expand their influence within an organization so that they can quickly mobilize the organization towards the right goals. Since product managers don’t make anything themselves, a product manager that nobody listens to simply can’t be effective.

The interpersonal skills I had built up and practiced as a software engineer didn’t directly translate to the skills I needed to build influence. As a baseline, engineering communication requires precision and clarity of thought. Since you’re typically talking with other engineers, you have shared language and set of tools to help get your point across. For example, if you can’t succinctly express your idea in words you can just write that thought out in code and other engineers will get it.

Product managers work with a lot of different kinds of people: engineers, designers, marketers, sales people, operations, executives, users, enterprise customers, vendors… the list goes on and on. Each person has a different perspective, both from their organizational role and their own life experiences. You have to meet them wherever they are, so your communication style needs to be highly adaptive.

Good communication feels seamless but is typically accompanied by a lot of planning and foresight. There was a lot I needed to learn to be an effective communicator and, in turn, an effective leader. How to write a good document, how to run a meeting, how to craft a compelling story, how to be just the right amount of direct, how to be just the right amount of concise… and, as a fairly verbal person how to draw good diagrams and pictures to communicate my ideas. There’s no shortcut to improving these skills. Getting better is a matter of practice and feedback.

Learning to say no

One of the most difficult things for me to learn was how and when to say “no.” As an engineer, I prided myself on having a can-do attitude and making seemingly impossible things happen. As a product manager, though, I have to make sure that we’re always building the right thing for our users. Since my job is to make sure we’re doing that, I usually have conviction that we’re currently doing the right thing. That means that, on average, when someone requests product resources or proposes a new feature, I have to say no.

I like to be helpful, and so I was terrible at saying no at first. I wanted to help anyone and everyone who came to me because, like when I was an engineer, I wanted solve everyone’s problems. But as I focused more and more on user needs, it became clear what we should be working on to have the best impact on our users. That gave me the conviction I needed to start saying no.

That still didn’t make it easier to say no. Prioritization decisions can have a big impact on other teams, and it’s hard to see your coworkers feel disappointed when something they want won’t be prioritized. Learning how to say no kindly and empathetically is an art form. But in general, it’s best done by clearly communicating priorities and correctly setting expectations in the first place so that people don’t come with requests that won’t get fulfilled. Doing that involves educating your coworkers on how the product prioritization process works, socializing your product roadmap and spending lots of time to answer questions. It also may involve looping stakeholders into the prioritization process so that their voices are clearly heard and they feel ownership over the roadmap. It’s much easier to get things done when everyone is in alignment from the beginning.

Coming back to engineering

After the first six months of working as a product manager I felt like I had gained my “product legs.” I had launched some successful features, had weathered major organizational change and had a clear idea of what our users needed and what the future ought to look like. Over the next year I continued to hone my skills and expand my scope as a product manager. Overall, things were going well.

I never stopped coding, though. I did small projects here and there, both inside and outside of work, but I never really had the time to do anything big. After a year of being out of engineering I started to get an itch to build and do technical work. I even had a few dreams where I was coding! I have dreams about all sorts of weird things and don’t dwell on them, but something about my surreal dream edition of Visual Studio Code stuck with me.

I reflected on this more and looked through my personal journal to remember my prior experiences as an engineer, when I’ve felt happy and why I wanted to transition into product management. One thing I realized is that, as an engineer, I didn’t always feel empowered. I felt like my role was just to code. But having worked as a product manager, I knew that it didn’t have to be that way. I worked with engineers who had solid product skillsets and saw how empowering and useful it could be. Being actively involved in coding and defining the right user experience felt exciting to me.

I also reflected on what kind of work I wanted to have and how I wanted to spend my time. In general, my favorite days at work have been when I do a blend of people / business work and creative technical work. I enjoyed the strategic and people-focused work of product management but I missed making things and technical problem solving. While I did get to exercise technical thinking as a product manager it was rarely a good use of my time to go deep. I realized I could achive that balance better as an empowered engineer rather than as a product manager.

After a lot of thought, I decided that my longer term career direction made more sense as an engineering leader rather than as a product leader. Fortunately, Artsy’s leadership agreed to let me transition back into engineering, and at the beginning of June I was re-minted as a software engineer.

Onboarding the second time

At this point, I’m six weeks back into engineering and my experience feels very different than before. I’ve spent most of my time ramping up and onboarding for the second time. Relearning our stack has been both a humbling and rewarding experience. I’ve forgotten a lot of the details of the frameworks we use, but this time instead of racing to get through tickets I’ve decided to really slow down and take the time to read the docs and do tutorials to make sure I fully understand what’s going on. While it comes at the expense of speed in the short-term, it’ll make me a stronger engineer down the road, and I know that tradeoff is worth it. I also can’t speak highly enough of my fellow engineers, who have been incredibly supportive while I learn.

Provide value, not code

I’ve also found my perspective is very different than before. While previously I would have seen my role as writing great code, now I see my role as leveraging technology to provide value to users. What’s the difference? In the former, I’m doing a task while in the latter I’m driving outcomes. It feels much more empowering as a mental model for what I should do as an engineer. It’s also helped me shed any hint of perfectionism I had before since writing “perfect” code or building the “perfect” system usually isn’t relevant to providing value to our users.

Developer experience is a product

Working as a product manager really taught me the value of engineering, which is frequently the bottleneck in delivering value to your users. Creating the right strategy and vision for a product is critical work, but none of that work matters if you can’t quickly get it to market. The faster you can move the more quickly you can create the ideal product your users want, which in turn dictates how successful your product will be. Gains in engineering efficiency snowball into massive benefits for users over time.

That’s led me to start seeing our developer experience as part of our product. It’s much more than just our toolchain – it’s the end-to-end cycle of working with a designer and product manager to understand product requirements to building the feature to shipping it and monitoring in production. What does the ideal process look like? Where are our bottlenecks? What investments will result in the best outcome for our users? These are questions I’m asking myself as I ramp up, and I’m excited to dig into this more.

Should you be a product manager?

If you’re an engineer wondering whether to make the jump to product management, my advice is to try it out. Product management and engineering are complementary skillsets that build off of each other. Knowing how to do one role absolutely helps with the other. You may find that you love being a product manager and continue on that track, or you may discover instead that you love being an engineer empowered with a product skillset. In either case, it’ll turn out great.