At 14, I was intrigued with computers—initially drawn to hardware, fixing my own PCs. But like many technologists, I soon discovered the allure of software, thanks to my passion for gaming. This passion led me down the path of software engineering, taking me through the halls of FAANG, corporate banks, and startups of all stages. I've experienced it all from an engineer's perspective, from software development to leading technology teams as a CTO. And I genuinely love engineering.
But somewhere along my journey, an unexpected twist awaited: a pull towards Product Management. Make no mistake, I'm still deeply rooted in engineering as a Fractional CTO at MISSION+, but now equipped with a product perspective.
In this post, I'll delve into the common pitfalls for fellow engineers considering a similar transition, and discuss how an engineering background can be a significant advantage in the product realm.
Discovering a Passion for Product
While engineering was fulfilling, a particular experience at a former company ignited my passion for product. I found myself conceptualizing products more effectively than the designated product managers. This vexed me quite a bit, so sometimes, I took time out of my usual sprint tickets to design the end-to-end solutions and presented them to the product managers. They were surprised and I loved it. It gave me a sense of satisfaction and filled up a missing piece in my overall job satisfaction.
This realisation also drove me to self-educate, diving into books like "Hooked" by Nir Eyal and "INSPIRED" by Marty Cagan. But it was "The Lean Product Playbook" by Dan Olsen that resonated most deeply, thanks to its logical approach.
The Engineer's Perspective on Product (Why it’s Limited)
From my experience, the most significant challenge for engineers transitioning into product roles, or even those looking to better understand product managers, is their fixation on technicalities. Often, this comes at the expense of overlooking the primary purpose of a product.
Unfortunately, to many engineers, a product is merely a target—a problem to solve, a task to complete. It's not something they necessarily "love" or feel passionate about. I guess that’s the missing piece I was yearning for; a love for product.
For me, what made a good product was not the hours of clean code that went into building it. While I, as an engineer, deeply value well-written code, a truly great product is a labor of love.
A great product for me:
- Delights its users
- Becomes a pain for users when unavailable
- Elicits massive frustration when malfunctioning
It’s the product manager's main responsibility to ensure that 1) happens and 2) and 3) almost never do. They take it upon themselves to love the product and deliver those three points above. Which hopefully then drives revenue of the product and all those other key metrics that drive key business results like high satisfaction scores, a low customer acquisition cost and churn rate etc.
You’d be surprised how many of us engineers tend to forget that. After all, we're here to build solutions for a business and for our users. Without the business driving demand, there would be no engineering tasks to undertake.
The Paradigm Surf
As I transitioned from a technical role into a product manager role, a common but understandable misconception from my peers is that it requires a huge paradigm shift in thinking/methodologies.
What was code commits, bug fixes and sprint goals now became stakeholder management, customer acquisition strategies and product metrics. Yet, the reality I’ve found is that it’s less a “paradigm shift” but more akin to a “paradigm surf”.
I ”surfed” between being a Product and Engineering Manager, understanding the need for a Product Roadmap, GTM Strategy and a clean user experience but I also understood that sometimes, things just go wrong for engineers, like a broken library or a bug in the latest patch of the framework.
Now, this may not mean much to the more classic Product Managers who were not engineers, but for me, the enemy of good is great. I appreciated the struggles of the engineer and also the need to build a “delightful” product that didn’t irritate or anger.
This surfing does not come lightly to be honest. Appreciating engineers and loving the product are sometimes at odds with each other. A feature could have been promised to a user, but the technical complexity might have been miscalculated due to imperfect information, and now we need time to fix the issue before launch.
I mean, this is what engineers who become Product Managers are made for. This is the time where they can use their engineering brain and think of a workaround, based on their lived experiences. They can mitigate problems early, and not shift the burden downstream by just trying to solve the upstream problems.
Perhaps if you’re transitioning from a technical role towards product, this might be something you’d realize yourself and ideally, see it as a huge advantage as a leader and manager of your product team.
Making The Transition By Learning Through Experience
Books and videos provided foundational knowledge, but real-world experience was the ultimate teacher albeit an unkind one. I had to learn and unlearn every single metric that was defined by “the textbooks”. I had to constantly redefine and rescope them so they helped me delight my customers and of course, bring revenue.
The constant surfing and sometimes wiping out when things went bad taught me more than I ever could learn from any book, talks with people, or YouTube videos. Which eventually led to one of my proud achievements when launching a product that garnered 5,000 customers within a year, with minimal marketing spend.
The biggest satisfaction that I’ve experienced (one that I wouldn’t have from a purely technical role), is when users tell me they loved the ease of use combined with the aesthetic beauty of the product. That for me is a pat on the back. That is one of the joys of being a Product Manager.
Embracing the Dual Role
There’s been online discourse often debating the ease or difficulty of transitioning from engineering to product. In my view, it's all just a matter of perspectives—influenced by one's emotions, abilities, and experiences.
Here’s the truth, sticking to an engineering mindset entirely will never bring you success in a product role. You need to be willing to learn and to surf between the two worlds, embracing both aspects and adjusting the way you manage people, processes and products.
Success in product management requires a willingness to adapt, to surf seamlessly between the technical and conceptual realms but then again, if you came from an engineering background, this is your biggest advantage yet, your biggest challenge.
My advice would be to think of yourself as a surfer, and a surfer adjusts for the differences in wave peaks and troughs. They maintain or change their direction, centre of gravity and style usually with absolute poise and coolness throughout the entire surf. Sometimes they wipeout and that’s ok, they get up, battle the waves again and continue their surf.
Maintain your engineering aspects when you need to and shift to adjust for your product aspects. Keep your balance and poise right, and I can guarantee you, it’s gonna be exhilarating. Wipe out? No worries, get back on that surfboard and try again. Now, get on to the product surfboard and ride the waves between Product and Engineering.
As an engineer, when you learn to ride the waves, you’ll make a great product leader, manager, and builder.