Why I'm leaving product management and returning to engineering

I decided to pursue product management at 25, six months before graduating from grad school. There were two reasons I chose this path: First, I wanted to learn the non-tech side of tech business—sales, marketing, product sense, and operations—in hopes of preparing myself for building a tech startup. Second, I wanted to leverage and maintain my hard-won engineering skills. Engineers love working with PMs who understand software systems, so I knew I'd have a leg up over the MBAs who couldn't code.

Five years, two PM roles, and one entrepreneurship journey later, I found myself at a career junction (two months ago), reflecting how it had all played out. If I was being honest, I couldn't say that I'd enjoyed my PM roles the way I'd enjoyed my software engineering internships, and being a PM hadn't really prepared me for a startup journey either (if anything, it was the reverse). All I could say is that engineers did like working with technical PMs.

If I had to condense all the reasons why I didn't enjoy product management, I'd say it was because at startups (both of my PM roles), the C-suite is the de-facto product owner for all product decisions.

Everyone below the C-suite executes on, or at best, influences product decisions in line with their mandate. As a product manager in this situation, I wasn't building the product (designers/engineers were), setting the direction and vision (executives were), or growing the product (sales / marketing was). However, because I was a product owner in name, the implicit expectation was that product success hinged on my decision-making. This disconnect between expectations and actual influence led to frequent burnout and constant impostor syndrome.

That's not to say that it is wrong for the C-suite to have product authority at startups—in fact, I'd argue that's exactly their job. It just makes being a product manager in that situation less enjoyable. Bluntly speaking, I don't think my roles were necessary in the way they were defined.

I'm sure this tension eases as products grow too large for the C-suite to manage all context, and sheer scale forces product decisions to be delegated. Even then, the best product cultures establish frameworks that keep role expectations and responsibilities clear.

This point is driven home by the fact that my favorite moments as a PM either involved building something myself or talking to users directly. At Parallel Domain, I helped build, test, and document a data generation API called Data Lab, and at Function Health I built a data pipeline that processed gigabytes of unstructured wearables data to analyze customer usage patterns and derisk our product roadmap, and presented those findings to leadership. Also, there were seasons of customer interviews in both roles where I systematically interviewed customers, understood their needs, and synthesized those conversations into concrete product insights to guide the product roadmap. Both types of these experiences were rewarding, but rare in my ~3 years as a product manager.

Finally... remote work (both roles). Much ink has been spilled over remote work, so I won't add much other than my own observations: I never thrived in it, and no one I encountered particularly enjoyed it either. At best, people worked around its limitations by traveling to central jobsites or moving near coworkers to maximize informal in-person interactions. Outside of that, the only people who seemed to make it work were executives that had frequent informal collaboration across teams, engineers that could work solo for long stretches of time, or those with families/spouses at home. Even then, I couldn't say I saw someone doing their best work in the remote setup.

I did learn a lot as a PM. I learned to communicate effectively in a work setting. I learned to commit to reasonable timelines, then overdeliver. I learned that it's always worthwhile to talk to the customer. Most importantly, I learned to pour my engineer's enthusiasm into the mold of customers' needs, and much more. But I was ready to move on and try something new—or maybe something old.

Back to my career junction. It was time to look for a new role. Remote work and product management were off the table. So what, then?

To guide my thinking, I cracked open a book I'd saved for a moment just like this: Designing Your Life by Bill Burnett and Dave Evans. It's about applying product design principles to building a fulfilling life—mining the past for insights, creatively brainstorming solutions, and iteratively trying "life prototypes." More importantly, I knew the book contained structured exercises to guide my thinking, which, as uncertainty about life and the world loomed large in my subconscious, was exactly what I needed.

Picking up a book to choose my next role might sound like overkill, but after picking up roles that were less than fulfilling, I was willing to go the extra mile. And boy, was it was worth it.

Through the reflective exercises in the book, I discovered that I'd prioritized mission above all other dimensions of work so far. Live by the mission (self-driving cars), die by the mission (healthtech), regardless of how little I resonated with the day-to-day (remote PM roles). And so far, mission alignment alone had not led to the fulfillment or growth I'd hoped for.

Next, I discovered that the most fulfilling experiences in my life scored highly on the following dimensions, in addition to meaningful impact/mission:

• Deep collaboration with coworkers I loved or customers who needed solutions
• Creatively utilizing technical skills to build real things, fast
• Communicating my work to the world, usually in the form of writing or presentations
• Total ownership over some component of the project, where I knew that my work was a critical part of its success.

Being a remote PM scored poorly on these latter criteria. If I had to rate my experiences at Parallel Domain and Function Health on these dimensions, I'd rate them a 9/10 on mission and a 2/10 on everything else. This dynamic, where the mission was inspiring but I had no part in it, felt like being a benchwarmer as starting players scored goals over and over again.

One of the best decisions I made was sharing this journey with friends (I can't underscore how important this was, especially in the long stretches of isolation without a job), and one of them (shoutout Lexi) suggested forward deployed engineering—essentially an engineer that goes onsite to build software for individual customers.

The more I learned about it, the more right it felt. I'd enjoy deep collaboration with both coworkers and customers, flex the technical skills I learned in college, communicate work I was doing to the world and to coworkers, and own the customer experience.

Moreover, forward deployed engineering is on the rise, as is its B2C cousin, product engineering. It's a good time to enter this job function.

In retrospect, choosing to return to engineering was an easy choice. The few times I had to program as a PM were among the best times on the job. I deeply enjoyed building Agentboard (though I wish I'd had teammates), and I was always tinkering with some project or the other in my free time.

I'm happy to report that I did eventually land an engineering role that I'm really excited about, and I actually start in a few weeks! More on that later. There so much more to say on the job search process and our place as engineers in a world where AI writes most code, but this post is long enough for now.