A Balancing Act: Diving Headfirst into the World of Product Management

Today Jared Niederhauser details his transition from software engineering to product management and how he combines modes of thinking from each discipline to ultimately create a better product.

{{Divider}}

Background

For half of my life, I’ve been a computer scientist. I studied computer science at university, worked as an engineer in industry, and wrote computer programs in my spare time. So, it was no surprise that I joined the Engineering department at GetYourGuide in 2015. Immediately after joining, I started working with amazing engineers to build impactful systems in our Performance Marketing department - read more here - but after two years I felt like it was time for a change.

After a good bit of reflection, I came up with a short list of what motivated me most in my work:

1. Learning new things
2. Connecting people with inspirational travel experiences

Fortunately, learning and development are highly promoted at GetYourGuide. After several discussions with my manager and other colleagues, I narrowed in on a challenging new opportunity: becoming the Product Manager (PM) of the Subscriber Inspiration team.

This opportunity checked all the checkboxes:

1. Learning new things? I had zero experience as a PM, so this was a chance for tremendous learning… ✓!
2. Connecting people with inspirational travel experiences? The Subscriber Inspiration team’s mission is to inspire travelers with amazing travel content… ✓!

So, it was with a bit of trepidation and a healthy dose of excitement that I stepped back from the Engineering world and decided to try my hand as a PM.

The first thing I had to learn was also the most basic: what is a PM? You can learn more about the role in this previous article; but, in short, a PM is responsible for defining the product vision, features, and roadmap, then working with the engineering team to execute. Coming from my engineering background, this transition meant splitting my mind into two halves. The first half held my existing engineering experience, while the second became home to my nascent and burgeoning PM half. These two halves weren’t always at odds, but there are certainly differences in thinking I quickly discovered.

Half 1: The Engineering Mind

Being an engineer is great. You get to create something from scratch and, if you do a good job, it will live on and be useful for years. Because I always wanted longevity in my code, I was often concerned with things like maintainability, testing, scalability, etc. Things which would make the code useful as the company grew and as more engineers joined the team and had to read what I wrote. Consequently, when I received a problem, I would sit down and sketch out a dream solution replete with the best technology and devoid of any bugs. My engineering mindset could be characterized by the aspirational mantra: Write once, use forever.

Half 2: The PM Mind

Shortly after I stepped into the PM role, my typical Engineering mindset started hitting a wall. As a PM you develop a roadmap filled with bets and assumptions, and the only way to validate these assumptions is to gather data and test relentlessly. For this reason, the speed of learning became paramount. This mindset encouraged the following practice:

1. Deploy working code as fast as possible
2. See how users respond
3. If successful, then scale. If not, iterate and start over

My engineering half wanted to produce perfect, long-term solutions whereas the PM half simply needed a hacky solution which could be used to gather data. Navigating this dichotomy is challenging enough, but I soon learned that good PMs need to fracture their minds even further.

Half 3: The Other PM Mind

Thus far I’ve only talked about how to implement a well-defined feature.  But what about the future? What do we need to do once we deploy our work? This is where the challenge of long-term vision and roadmaps come in. The first half of my PM mind focused on what needs to get done this week, this month, or this quarter.  The second half is longer term. This kind of long-term planning becomes necessary when you start thinking about personnel and hiring. Adding someone new to the team requires time, planning, and justification. If done inadequately you can hit two pitfalls:

1. Realizing you need a new team member too late
2. Basing long-term vision on your current resources

The first pitfall can derail momentum and delay progress.  The second pitfall is harder to notice and can be far more damaging.  If we always make plans based on the team we have right now, we may be artificially limiting our impact. I call this Scarcity Driven Development and the other half of the PM mind should be aware of this risk and try to avoid whenever possible.

Finding Equilibrium

In spite of the seeming contradictions between these three competing mindsets, it is possible for them to exist harmoniously. The key is understanding what questions each mindset is uniquely good at addressing:

• How can we validate our assumptions and ensure we’re on the right track? (Short-term PM Mind)
• How can we integrate a proven feature into our system and ensure it scales? (Engineering Mind)
• What does the “dream product” look like and what would be required to get there? (Long-term PM Mind)

My experience as an engineer has proved uniquely valuable for me now as a Product Manager, and, on my best days, my ability to see both short-term and long-term outcomes results in a better product.

If you’re also looking to inspire travelers or challenge yourself, check out our careers page and come along for the journey.

‍