ADVERTORIAL

Throughout my career, I’ve met many people looking to make a jump into product management from a variety of other roles. I try to give them whatever advice I can, but the transition I can speak to the best is that of Software Engineer to Product Manager, as it’s the career move I made many years ago. This post attempts to solidify the advice I’ve given over the years, and hopefully can be helpful as others explore such a transition.

Product management skills

If you’re looking to make a move into product, I suggest that first you consider what skills you can acquire in your current role that can set you up for success and help you stand out to hiring managers. The most readily available skills coming from engineering are raw technical skills and customer service skills. Both are great pragmatic teachers of the two most fundamental capabilities for any product manager — discovering the right direction for a product, and creating a shared understanding of that direction across teams and organizations.

Technical skills

Technical skills can obviously be a huge asset as a product manager. A strong understanding of REST (REpresentational State Transfer), for example, can set you up nicely for a product manager role managing an API product. Even if your product isn’t technical, “speaking developer” is a huge asset — clarity is the chief export of a good product manager, and communication is much easier when you speak the language of your audience.

For anyone approaching product management from a less-technical background, genuine curiosity and a desire to understand technical concepts around your company’s product will go a long way. You don’t necessarily need to pause your career and enroll in a coding bootcamp, but the more you can learn about what your colleagues in engineering are up to, the better. Consider attending technical training sessions, even if they’re intended for others outside your current role, and listening to recordings of calls with support engineers. Better yet, get to know a few of the people who actually do write code. Learn what challenges they face and how they think about approaching those challenges. Finally, depending on the specific product management role you’re aiming for, it may be necessary to teach yourself some coding fundamentals on the side — and your interest in doing so should help confirm that you’re pursuing the right path.

Customer service

Technical capabilities are just one small piece of a product manager’s skill set. An understanding of customer service and customer behaviors and needs is perhaps the most important skill a product manager can have. Above all else, a product manager’s job is to understand the problems that customers (or prospective customers) face, to share that understanding inside their company, and ultimately to build effective and financially successful solutions to those problems.

I’m also a firm believer that, while there are many ways to understand your customers, nothing can ever replace the good, old-fashioned business of talking to them. To have successful conversations, you need to establish a good rapport and listen patiently to critical feedback — and learn from it without being defensive. Even convincing customers to take the time to talk to you in the first place takes practice.

One actionable outcome, particularly for those just beginning their software engineering career, is to seek out roles that include some customer support component. Luckily, my first software engineering job out of college did this. I had an offer to join a small startup as a customer success engineer, with the promise of moving into software engineering in about six months. I nearly rejected it because I wanted to write code right away, but in the end my excitement for the company narrowly won out. With hindsight, it was one of the best decisions I’ve stumbled into during my entire career. So keep an open mind about customer service!

Two sides to every coin

It’s important also to consider the downsides in the journey from engineer to product manager. While “speaking developer” can be a boon, it can also be a weakness if not looked after. Depending on your seniority as an engineer, it’s wise to remember that you should avoid having an opinion about implementation details at all costs once you switch to product. Telling engineers what to build and how to build it risks robbing all the joy from their work. Furthermore, the longer you’re in product, the more your technical skills will diminish, and you’ll be less able to make good technical decisions anyway.

For example, the first product I managed as a product manager was also one that I was the development lead on. I had Architected the entire technical solution prior to moving into my product manager role. Between the two roles we experienced some turnover and growth, and I found myself working with several engineers who knew me only as a product manager. For a time, it was not uncommon for me to write a user story, have the team refine it, get back an estimate larger than I expected, and respond by asking why the estimate was as big as it was. I would say something like: “All you need to do is add another column to the campaign table, and a small dropdown over here to set it.” This quickly created a challenging relationship between me and my team, as they felt undermined and micromanaged. It’s a bit like commissioning a painting only to tell the painter “No, not like that,” as they select the colors from their canvas.

As a product manager, there should always be a balance between customer empathy and developer empathy. A good working relationship with your scrum team is important — people perform much better in psychologically safe spaces, and healthy relationships are key to this. On the flip side, sometimes the right thing for your customers will absolutely be a chore to your scrum team, but you should always put the needs of the customer ahead of the needs of your team.

Making the transition to product manager

You’ve got some good skills, you’ve been patiently working as an engineer, and it feels like the right time to make the switch — but how? Your options fall into one of two categories: a role in the organization where you already work as an engineer, or a role at a new company.

Perhaps an obvious observation, but an important one, is that making a role switch within your existing company, if and when an opportunity arises, has many advantages over applying for your first role at a new company. There are two reasons for this. Firstly, people know you, and you have (hopefully!) a good reputation, and that simply makes you a much less risky hire than someone external. The second, more important reason is that you know the product, you know the customers, and the problems. You start day one with months or years of directly applicable experience.

I made that internal transition in 2015 during my time working at SendGrid. I haven’t looked back — indeed, I joined Stream as its director of product management seven months ago. I use what I’ve learned to identify and solve problems for customers in the in-app chat and activity feeds spaces. For me, the eventual transition from one maker of cloud components to another felt natural — given my background, I love that I get to direct a team whose products are tools designed for developers.

Speaking of which, if you’re working on any type of project that involves in-app chat or messaging technology, I’d love to get the Stream Chat API and SDKs into your hands. All new Stream accounts start with a free trial, and I’m especially proud of a new offering that makes a full version of Stream available completely free to qualifying small teams and personal dev projects. Sign up for your Stream Maker Account to start experimenting with your own chat product today.

Beyond the question of where to look for opportunities lies the question of how to prepare. To that end here are a few suggestions:

1. Demonstrate your mastery of the pragmatic: Especially for a junior-level or first product manager role, any hiring manager is likely first and foremost to need you to keep a scrum team running. Make sure you can speak to Scrum and Kanban (often mistakenly called Agile), and how you think about prioritizing work with your team, managing stakeholder expectations, and tracking dependencies. These are essentially the fundamentals of product management.
2. Be first in line to disprove your own hypothesis: Good product managers can keep an engineering team organized. Great product managers are practitioners of the scientific method. Weave into your interview process, not a desire to make decisions about what to do, but rather a desire to formulate hypotheses and find the cheapest, fastest, most customer-behavior-driven ways to disprove your hypothesis. Prioritization is, at the end of the day, more about what not to do than what to do.
3. Keep your hands on the day-to-day, and keep your head in the clouds: Product management theory — in terms of why we do what we do and how we can be better to take our teams and companies closer to the ideals of good project management — is not to be overlooked. Even when things feel chaotic, don’t forget the wisdom of thinkers like Marty Cagan and Simon Sinek, or any of the other stimulating thought leaders you draw inspiration from.

Finally, I’ll leave you with an axiom of mine that steers much of the way I think about product management:

Some argue the chief export of the product manager is the decision, but the trick is to not actually make any big decisions, rather, create so much clarity about the decision, that the right choice is obvious to everyone involved.