I was a Software Engineer (and an Engineering Manager) for about the first 10 years of my career.
Then I got bit by the product bug (a topic for a later time), casting the second decade of my career into a completely different trajectory.
Over those 10 years, I’ve been able to enjoy a lot of benefits from having an engineering background. But I’ve also had to deal with some baggage.
Here’s a summary of pros and cons I’ve taken note of along the way. Hopefully they’ll help you if you’re thinking of making the same transition.
Obvious, and hopefully redundant disclaimer:
The below applies 100% to me and only me. Engineers come in all varieties and from all backgrounds. Contrary to popular belief, they are not part of a single hivemind. Take this article for the strawman it is.
Easy Street
Let’s start with the good news. 🙏🌈🦄
PRO: You’re a systems thinker
Engineers are fundamentally logic-driven systems thinkers. As a Product Manager you’re constantly faced with challenges of how to make complex sets of components work together: people, teams, products in a suite, market segments, growth-drivers, metrics etc.
Being able to logically map discrete pieces into a complex interconnected system is a huge leg up as you traverse the Product Management landscape.
Example: When I joined Shutterstock, a mature and complex company in the middle of multiple long transformations (esp. systems migrations), the key characteristic that allowed me to thrive was my ability to mentally map out the complexity. The dependencies on other systems, how they intertwined with organizational structure, what limitations they had on products and business lines, and where there was opportunity to push forward by bypassing some of them.
In my first few months, we launched Shutterstock Music on Premier, their enterprise offering. My background as an engineer helped me allow my team to focus on the task at hand while I took on a lot of the responsibility to navigate the complex network of dependencies — and sought out opportunities to punt on ones we could solve at a later date.
PRO: You understand how software is built
Let’s face it, a HUGE part of software products is… well, software. The minutiae of software development (lifecycles, release management, quality assurance, devops etc) is hardwired in your brain and you can clearly articulate things like why a trivial-feeling change in requirements can result in 10x more (or less!) work in implementation. Or why a thing that looks ready is still quite far from “production-ready”.
You also have infinite empathy for why work estimates in advance might as well be generated by the toss of a pair of dice.
You understand the processes, the systems, the practice, and the art.
All this will make you an awesome Scrum Product Owner or Technical Project Manager. Both of these roles are in a great Product Manager’s toolbox.
In our current day world where “product management” still has a myriad of different definitions, you should be able to find an environment that appreciates your core skillset. This can give you the opportunity to create PM value while you seek out and fill the blind spots in your PM skill set.
Example: In my early days of shifting from engineering to product management, the easiest move was taking on a mix of product and engineering management responsibilities. My roles at Kollabora and Greatist were both hybrids of the two. I was nowhere near a “Full HD Product Manager” yet, but my understanding of how to tactically deliver functioning software gave me a solid leg to stand on to while I worked to round out my product skills. In hindsight, I was mostly running feature factories at both, but I had enough self-awareness to push myself and tap into the talents of others to fill in my skill gaps. CEOs of both companies were very product-minded and I was lucky to surround myself with product-savvy engineers and designers.
PRO: You’re able to represent technical matters
Even though you’re no longer responsible for making technical decisions, a PM often has to represent technical choices and restrictions to stakeholders.
When you’ve got a technical background, you’ll have a significantly easier time explaining the downsides of a tough technical choice your team had to make to deliver — or get other teams to buy into a new technical direction a thing your team built provides for them.
You’ll also be much more effective as a disruption shield for your team. When you have a deeper understanding of the tech involved, you’ll never let a benign-feeling request slip through without proper vetting.
You’ll never be “this person”:
Example: At a complex environment like Shutterstock, the risk of engineers and engineering managers being bogged down by endless alignment meetings and other overhead is huge. A lot of this is technical minutiae around the opportunities and limitations of an implementation posed on other teams or functions of the business.
By being a product person that my engineering colleagues trusted to accurately represent their work, I was able to build a lot of trust and goodwill simply by removing time-draining activities from their calendar.
PRO: You’re a subject matter expert for some pretty big markets
It might not always be obvious from the surface, but a huge chunk of the software product market is targeted towards other builders or maintainers of software products.
They don’t get a lot of headlines, as most famous software-driven companies out there sit at the very top of the stack: the Facebooks, Twitters, AirBnBs, Spotifys, and Snapchats. Companies that offer a whole new interface to engage with the world for regular human beings, whether in a personal or business context. Thus, they get a lot of the exposure and attention.
But below the surface are hundreds of massive companies building tools, platforms, and services where the user (and often customer too) is highly technical: the IT department, the software engineering department, CTO / CISO / CIO etc.
This gives you a direct inroad to understanding customer needs and market dynamics for very lucrative markets.
Example: While at Shutterstock, one of my responsibilities was building a product strategy for their Platform Solutions offering. The main user of this suite is 3rd party developers integrating with the Shutterstock API. Being familiar with what types of APIs (capabilities, functionality, documentation) developers appreciate gave us a running start in defining a product strategy that would be embraced by customers (3rd party companies needing creative assets or platform capabilities like computer vision) and users (developers) alike.
Womp Womp!
Here’s where the good news end, I’m afraid. Now, let’s dive into your eng-turned-product life as a manifestation of sadtrombone.com. 🌧💽📉
CON: You will bikeshed and as a result, you won’t get along as well with engineers as you think
I started out my product career assuming that the last of my worries would be working with engineers. After all, I was one of them! Of course I’d strike an immediate rapport with them.
Wrong.
First off, there’s nothing worse than a PM that doesn’t respect their lane.
Second, you very swiftly forget how important context is in engineering. What was the perfect solution for one environment, might not work at all in another. Forgetting this is a fast path to bikeshedding — you giving completely unsolicited input into implementation details without detailed understanding of all the required considerations.
There’s probably no faster way to deplete your trust reserve with engineers.
Example: Candidly, I have more of these than I care to admit.
The one that still stings the most was early in my product career. I was interviewing for a very desirable product position at a cool media company and my conversations with everyone had gone really well. They were very transparent that I was on home stretch as the leading candidate.
Then I went to my very last interview with a lead developer on the team. It was an absolute disaster! I came out the gate way too strong with opinions on their implementation, process and approach. Rightfully, this engineer immediately categorized me as a product person that would not respect their craft. I ended up being passed for the job. 100% deserved!
CON: You know way less about software businesses than you might think
Being at the heart of creating software products gives you a sense of hubris that you understand the entire end-to-end of commercializing software much better than you really do.
As an engineer you’re probably well-versed in the ins and outs of the industry. You follow the news about the latest Y Combinator programs, know the most recent hyped management paradigms, you read blogs by business luminaries, and engage in Twitter feuds on startup building do’s and don’ts.
But when you enter the world of product, you’ll be faced with the intense complexity of how functions like sales, marketing, customer success, finance, design etc. operate — and how profound their contribution to everything really is.
Engineering might be the most complex function involved in building software, but you have a lot of catching up to do in order to understand how the other functions operate. Especially with finance and business.
Example: This has been a slow-burn incremental realization throughout my product career. Over time, I’ve gotten to work with remarkable sales, marketing and business professionals that have opened my eyes to how far “the-thing-you-build” is from “the-business-you-generate”.
My biggest “a-ha!”-moment on this topic came recently at Produx Labs consulting a later growth-stage company in the Insight Partners portfolio. Their product was quite adequate. Not perfect by any means, but well ahead of the competition and well liked by users.
The engineer in me wanted to just dive in and improve the product (and the process by which it is built), but luckily I had strong enough mentors to point out that the core opportunity is bringing the product and the people responsible for taking it to market closer together. This helped me avoid a complete waste of my time, and allowed me to have a real impact on the company’s trajectory. Fixing how the product and business interfaced turned out to be much more impactful than anything in the product itself.
CON: People are much more complex than machines–and being right is not enough
As a Product Manager, influence is one of your most important skills.
As an engineer, you’re used to the beauty of the closed systems of logic: if your code / architecture works, it works. Its efficacy can be measured and its merits can be validated. As a result, interfacing with other engineers can also be quite straightforward and logical.
Going from straightforward logic to the infinitely complex world of human emotions, hidden agendas, unspoken motivations, conflicting incentives, and group dynamics can be a slap in the face. But being able to ingest the human element is critical in product.
Example: Once again, this category has more painful memories of self-reflection than I’d like to admit.
I don’t want to name names here, but at one of my companies, I had a very difficult developer to work with. They were talented, but their attitude towards others was clearly souring the overall motivation of the team — and often even stakeholders. I kept focusing on building the perfect process and structure for the team, hoping that it would provide enough of a guardrail to keep their behavior mitigated. False.
It was only after I started having really close 1:1s with this person to understand the unvoiced frustrations driving their behavior that things started to make sense. I also allocated more time to those around them impacted by their behavior to understand the full extent of the damage done.
Doing this, I was able to create more of an environment that embraced their talent, kept their “unique personality” from creating negative energy, and helped the team run more smoothly.
I should’ve done this significantly earlier, but my naive belief that it was more important to fix the system than understand “a component” of it drove me down the wrong path. 🤦♂️
CON: You’re far too “quant” by nature
This is a close relative to the one on influence above. As engineers, we love data and things that can be proven. Anecdotes, results below statistical significance, instinct and empirics are often viewed as faulty and useless by us.
This is obviously a strength in some cases, but unfortunately those cases aren’t as common as you’d think.
Most interesting software product innovation happens in environments of uncertainty and unpredictability. While there’s always room for quantitative approaches here and there, as a Product Manager, you will need to balance that out with qualitative research methods: anecdotal evidence, talking to users to understand their needs, deciphering things data alone can’t reveal etc.
Example: My first product-related role at Kollabora was very challenging. Obviously, I was still at square #1 with my product chops, but more importantly, I was still heavily in the quantitative mindset. The thing was, I was building a product from scratch with no pre-existing data or evidence. In hindsight, I should’ve spent most of the first 6–12 months meeting with crafters face-to-face. Instead, I hid in an ivory tower of building “the perfect platform” based on assumptions, relying on 2nd hand knowledge from subject-matter experts, focusing on implementation and hoping for data-backed proof to emerge.
I did re-learn knitting, though, so that was something.
CON: You’re probably too much of a perfectionist and have a bias for the generic
Software Engineers take a ton of pride in their work.
This is, of course, amazing.
As a systems thinker, you’re also probably inclined to think in terms of generics and in terms of malleability — how does your solution scale to different use cases gracefully. Any unscalable dirty trick or specifics-over-generics choice will feel like you are diluting the quality of your work.
Unfortunately in Product, quick & dirty almost always wins the day and your ability to boil a complex abstract thing into tangible specifics through examples is a characteristic of a winning product person.
Example: Weirdly enough, you’re reading it!
Writing the generic parts to this blog post is remarkably easy for me. I’m very comfortable extracting generalized knowledge from my past, and examining it at a high level of abstraction.
But articulating specific examples is a very painful process for me. It’s not that I don’t have examples nor that I don’t understand their impact to convey my point. It’s that my built-in filtering rejects most of them as incomplete or unfitting for the point I’m trying to make.
When I feel like the specifics don’t convey the point in enough detail, I immediately meander into generics, diluting my ability to connect with you — the reader.
All this said, the engineering-to-product transition is one of the smoothest product origin stories out there. Engineers come with a lot of really important skills for managing software products built-in.
The biggest pitfall to complete this transition successfully is blindness to these challenges I’ve outlined above–and some others I’ve probably failed to note. I keep learning every single day.
I hope by stubbing my toe in all of them and writing about it in public I’m able to help you avoid these annoying mistakes.
If you’re on this same path, please share your experience, both ups and downs.
