From engineering to product: the good, the bad, and the ugly
It’s been a year since I moved from an Engineering position to a full-time Product Manager role, and I think it’s a good time to talk about the perks and the cons of this transition.
I had the luck of being able to transition within the same company, which allowed me to speed up certain aspects of the new role, for example, I already knew who the stakeholders were, and I also had a good understanding of the product, from a tech perspective, and the internal processes.
Now, without any further delay let’s get into it and talk about the good, the bad, and the ugly aspects of it.
The Good
You understand the tech stack and its limitations
This is one of your main advantages, you’ve been probably working with the tech stack that is used in your company, or you at least have an idea of its limitations.
You can use it in your favour by being able to, for example, spot quick wins that will require minimum effort as the stack you are working with has the facilities to perform certain activities.
It also works the other way around, let’s say your digital product is a web application that as a feature, not the core of your business, allows users to do video calls. You are supporting video calls with Twilio and now there’s this idea of adding a screen-sharing functionality; you are probably already thinking about browsers that won’t be supported and analyzing if that will be a problem.
By understanding your tech stack sometimes you can have a quick assessment of feasibility and the real value of an idea in a matter of seconds.
You know what you like to see in a ticket
You’ve been on the other side, you’ve complained about the quality of tickets, you’ve praised tickets for being good, and you’ve also heard your colleagues doing the same. You know what you like/don’t like to see.
Every second you can avoid discussing a ticket just by writing the user story or the acceptance criteria clearly from the beginning, you are accelerating development and hopefully accelerating the shipping of value to your user.
Be critical of your tickets as you were critical of the tickets assigned to you as an engineer. Try to forget all the knowledge about the context of the ticket you have, and think about it as almost a self-contained ticket you should start implementing next sprint. This exercise can potentially improve your communication with Engineering a lot.
You have an idea of how much effort it takes to do something
You should deliver the highest amount of value you can, by spending the lowest amount of available resources. That's something you have probably heard from colleagues, managers, and CEOs.
Your job is not just delivering value, your job is also keeping the business alive. You should be focused on delivering value to your user, but you can't, for example, block the whole engineering team for a quarter doing something that will deliver a minimal amount of value to a reduced subset of users.
Here you have a potent weapon, if you've been working as an engineer for a couple of years, you can probably estimate in your head how difficult is it to build something. This can help you a lot in defining if it makes sense to build something or to look for a workaround, and to create a better prioritization focusing on what actually will deliver the most value while keeping your business afloat.
Speak “fluently” with Engineering
Managing stakeholders is one of your key responsibilities as a Product Manager, and within those stakeholders, you'll probably have an Engineering team. They'll be finding the right solutions to the problems, and after that executing and implementing them.
Never forget that your responsibility is in the WHY, and WHAT to build. Not in the HOW to build it; so you must be able to communicate well with Engineering, facilitating them to make the most informed decision when deciding on HOW to solve a problem.
To do that, it's useful the fact you can fluently speak about technologies, you also know engineering lingo, and you can use it in your favour to accelerate knowledge transfer to the team.
The Bad
You need to take a step back and work as a facilitator
Sometimes you discover a problem, you instantly think about a crystal clear solution, and you get tempted to open your IDE and automatically implement it.
You need to keep yourself back and limit your actions to your actual responsibilities, there are people in your team whose actual job is to find a proper solution, and implement it.
If you think that it will take more time for you to communicate the problem than to fix it by yourself. Then it might be a warning flag about some weak points in your communication skills you can improve.
Decoupling yourself from the solution space
This might be one of the hardest things to do. You need to position yourself in the problem space, after spending a good amount of years standing in the solution space it's time to move.
One of the main obstacles to making this change is that customers and stakeholders are usually standing in the solution space. When you ask for feedback or a stakeholder has a request you'll probably receive a solution. It's your job to find out what the real problem is, define it, and then prioritize it.
As a Product Manager, you should not be handling tickets with solutions, your responsibility is to define problems, and the acceptance criteria that in case of being fulfilled ensure the problem is solved.
Value is not delivered just by adding new features to the app
Sometimes your product is not just your digital product, and sometimes value can be delivered without coding. Value can be delivered by process optimization, or by setting a parallel process to take care of it.
It's a common mistake that you try to do everything through the product, you try to keep all your stakeholders happy by providing them value through the product. You are used to probably solving any problem by developing a new feature. This can end up transforming your product into a monster. You always need to have in mind what's your product vision, and what's your core business.
Let's say your company's core business is linking final users and certified plumbers and your vision is centred on providing a simpler, faster, and smoother experience to people with some plumbing problems. As a quality measure, all the plumbers need to have a certification that should be renewed every year. How much does it fit on your product vision to develop a feature that allows plumbers to upload certifications once a year? Can it be handled externally?
You should challenge everything before adding it to your product and try to answer the question if you are building the right product. Some problems might be real problems associated with the company vision, or necessary to keep the company running safely, but that doesn't mean they should all be tackled by adding a new feature
Taking into consideration business factors
This is about the new business world opening up above your feet. Now you don't only care about giving a great experience to your user, you also need to align with business goals, and make sure to provide value in a way it ensures your company hits those goals.
Sometimes you discover a problem, or someone comes to you with a fantastic product idea that could potentially make a lot of customers happy, but you need to take into consideration way more factors to prioritize it. You can't just prioritize because you think something is great, you need to be able to justify why something is a priority.
Also, you'll find yourself working on stuff that is not that exciting, but it's really important to make it and make it right to for example hit that goal and be able to walk in a good position into that funding round.
End-to-end ownership
At this point, you might be asking yourself why am I spotting it as bad. Well, end-to-end ownership is a good thing to have. But it's a double-edged sword, you've been your whole career caring about features from the moment you start thinking of a solution until they are shipped. Not anymore.
The end-to-end definition changes as soon as you move into Product, a feature is not born when you start trying to solve a problem, the feature now is born when you discover a necessity, a pain point, or an opportunity. And now you need to nurture and follow it not just until it's shipped, but until the value is actually delivered to the user, and then check that the value delivery is held across the time.
The Ugly
Working with uncertainty
This might be one of the worse things when you move from Engineering to Product, you'll hear as a joke from experienced Product Managers on customer-facing products that every 10 features only 1 works, but behind every joke, there is some truth.
You'll find yourself working with a lot of uncertainty, generating hypotheses from insights, and trying to make some sense of data. And even working sometimes by gut feeling taking into consideration your knowledge about your users.
At the end of the day, you are trying to define the WHY and WHAT to build. You are working on diminishing the uncertainty, so your team can work with the certainty of building the right product.
Measuring your progress and performance
It might be hard at the beginning to measure your performance and your progress. I've found it to be not as straightforward as in Engineering.
While I was in Engineering, I could see a clear career path, and measure myself by taking into consideration the problems I was able to solve, the effort I need to put into solving each problem, and from there get an idea of my performance.
In Product, your delivery is communication, and your growth can be measured by the understanding of the problem space and users. This understanding will allow you to make more informed decisions and create a better roadmap that will deliver value by committing just the right amount of resources. But measuring that is not as straightforward.
As an Engineer, should I give Product a shot?
It's something personal, and you should deeply think about it. But as a bit of advice, I would suggest you try it if you answer with a "YES" to any of the following questions.
- When you have a new feature, do you want to understand the problem it’s trying to solve?
- Do you care about the impression a solution will cause the user? Are you interested in what happens with a feature after it’s released?
- Are you interested in what happens with a feature after it’s released?
- While developing do you spend a significant amount of time trying to empathise with the user?