Show Me the Value!

I had mentioned that the journey within my career has molded me into a more well-rounded Product Engineer. In this post, I will try to breakdown what mindset such a role encompasses and how to navigate such transition.

What is a Product Engineer?

I've come across a lot of varying definitions for what a Product Engineer is and decided, in a typical engineering fashion, that I'll create my own version! 

Trying my best to keep it simple, I would define a Product Engineer as:
"A Software Engineer that understands their customer, the value that their product delivers to them and makes decisions with them in mind."

Although, don't let the definition of Product Engineer or customer trick you into thinking that this role is only for a subset of Software Engineering roles or teams out there. Oftentimes, roles that involve building internal services (e.g APIs for other teams to build products upon) are those that are in most need of great Product Engineers!

Why is that? Well, it isn't - that's just my opinion. 🤓 

What is the value?

Exactly! You've just completed your first step in becoming a better product focused engineer. 

This is a phrase that:

1. You should be comfortable with asking anyone within your team/organisation.
2. Anyone within your team/organisation should be comfortable with asking you.

Value exists in everything we do and is the reasoning behind why we're doing it at all (most of the time).
The fundamentals in learning to answer the above question involve:

1. Having the ability to describe value (to everyone*).
2. Having the ability to measure value.

* As Software Engineers, we're most comfortable in our world, one that is deep in the weeds of technicalities and  jargon. Developing the skills to describe a technical problem in a non technical manner will unlock your ability to influence many. 

I wanted to loop back on my earlier comment on why internal teams need great Product Engineers. Working in an internal team, as an engineer, it can be easy to lose sight of who your customer is and ultimately get caught thinking that the customer is system excellency. Don't let me confuse you here, as system excellency is vitally important for customers, but the value is in why it's important (e.g helping other teams move faster, create a source of truth to prevent issues with consistency or reliability etc.).  

In the past, I often found myself focusing too much on the function of the API and never its value. I was treating it as some form of technical skills CV building exercise. Ironically, the value is mostly driven by technical solutions anyway - the only difference is what starting position you place yourself in and the perspective that it unlocks. 

I'm going to take this opportunity to plug a well-known book that I have enjoyed as of recent by Simon Sinek, Start With Why. In the book, Simon details how a number of rail companies went bust due to the introduction of the aviation industry. He suggests that if the rail companies focused more on their why, providing a means for mass transportation, as opposed to their current what, a train, then maybe some of these companies could have pivoted with the changing times and continued to succeed with their mission. My theory is that, as engineers, we too can get caught up in building the train and forget about what problem we were intending to solve in the first place.

Aim to solve for mass transportation, not for trains. 

Navigating Your Transition

I want to finish up this post with some notes on navigating such a transition.
Again, I'll reiterate that I'm still undergoing transitions in several areas, and want to act as a peer on these journeys i.e this is not "5 easy steps to guarantee your success as a product engineer".

1. Acknowledge that you're at the start
The end goal can sound relatively trivial and obvious - but it's not. As an engineer, you may have spent years in your career within a company that did not allow you to grow in such a direction or your priorities lay focusing your career developing different skills within your repertoire. So allow yourself to be new at this - your organisation & manager will show empathy towards this as even starting on this journey will only bring value to the organisation itself.

2. Know your role
This wasn't necessarily planned but as soon as I typed this title, my childhood memories of watching the WWE, wrestling, came flooding back to me. 

This is one of the few times in life that I would recommend someone not act like The Rock. 

If you haven't been given the room to flex these skills before, you may end up feeling the urge to deflect such "roles" and "responsibilities" onto others, such as your Product Manager. I have made this mistake before. In my opinion, the mistake here originates from referring to it as a responsibility, as opposed to a core value.

Today, I focus on building partnerships with Product Managers, and the rest of the team. Working as a team, you gain the insights from varying angles that all work to converge to provide the most valuable output. For example, a Product Manager can hold some insights into a particular problem the customer is facing but you, as an engineer, can provide a number of checkpoints you can hit in order to deliver increments of value in a faster, more iterative, manner.

3. Establish a strong foundation
Stick with me here, as this point correlates to product management in general as opposed to a transition. Work with your Product Manager & team to create a framework that allows you to make confident, autonomous decisions.

If you don't feel like you have that, you should flag this to your team and advocate for building one. With it, you make informed decisions and eliminate distractions. Without it, every single new enquiry halts the team to a stop as you try to understand the prioritization. This unlocks a truer sense of autonomy throughout the team.

(I'm still learning here and encounter new types of enquiries coming my way that I first need to establish an understanding and framework for - but taking the time to do so enables me to move quicker over time)

4. Be Patient
This tip comes from personal experience (and of course, may not apply to all). No matter the destination, transitions can be difficult. You're growing in your role. Be patient with yourself.  You may be experienced and confident in other areas but you are allowed to not be as confident in others and seek guidance and help when needed. Just ask for it (as well as the value! 😅)