10 things I learnt moving from Engineering to Product

from an IT guy to a Product guy : What did I learn?

I have been wanting to publish this article for a while but wanted to make it perfect before I do so, kind of the first thing you should not do as a product person in my opinion because of build-mesasure-learn cycle, so here are some of my raw learnings:

1. Move from solution space to problem space: The first realisation I had as I made the transition from a IT engineer role to a Product manager role post my MBA was to give away the love to get into technical details of everything and rather focus on the bigger picture. I had to train myself to not get into the nitty gritty of an issue which in my earlier role was essential and focus on the bigger picture or vision of the over all product. Your role now is not to find the solution but construct the right problem statement. The problem solver that is with in you as an engineer needs to be channelized in the right direction to not get lost into technical details rather focus on customer problems more from the prospectives to keep it simple in terms of UI/UX. Do not forget you have a team to fix it technically, your job is to solve it holistically.
2. Don’t project manage rather product manage: Realise how Product management is different from Project management. In a Product role it is extremely important to have your own point of view and not just execute orders from higher management. Coming from a high power distance culture and organisations where I had to manage big IT infrastructures it was hard in the beginning to put forth my point of view (POV), along with staying into the solution space. I had a narrow focus to think about the output rather than the outcome while product management is all about the latter. To put that POV in place you have to be an avid user of your product & market for which you need to invest time.
3. Prioritise everything: Being at the centre of Business & technology to act as a bridge is not easy. Managing the expectations of your development team and stakeholders to run a smooth sprint and retrospective is something that you learn over time. What to build first is the challenge but that is what you have to get right and there are different frameworks (effort vs value , RICE model etc) that help you do that. Basically you have to learn how to prioritise every task and strike that right balance. Not everyone will be happy you have to make your choices and rationalise it in front of the organisation.
4. People,People & people: In my very personal opinion apart from the fact of Product management being a very strategic role it is a very people oriented role because you as a Product manager do not have any authority over anyone but you are responsible to get a lot of stuff done. People skills come handy in such situations as in the end it just boils down to people and collaboration. If you care about people (not for the sake of it, honestly care) people care about you, your work becomes their work/goal.
5. Be assertive not authoritative: Dealing with a number of stakeholders across the compony you have to ask for a lot of things and say a lot of “No’s”, some people find their high in portraying an authoritative personality which in my opinion won’t get you anywhere expect out of your team/company so you don’t necessarily have to be strict but definitely assertive to have the respect from your team/colleagues along the journey of getting the job done.
6. Know the market not the code: There is often a discussion about do product managers need to know how to code. While it depends on how technical the role is I am of the view that it is better if you know enough to understand what the latest trends in the market and focus on where the market is heading. You have a full tech team to support you, the best way you can support them is give the technical autonomy and feed them with good, tried, tested business logic/hypothesis.
7. Be the QA of your customer: You as a PM should have to have a clear vision of the end product/feature you need, clarity of thoughts is more important than anything else, how can you pitch an idea to your team which you are not sure about. You have to do your research and talk to stakeholders and users to get there, you might never have all the data & answers you need but you need just enough to be in the right direction. Take a decision and make it right. (Build, measure, learn & iterate). One major part of the role of a PM is to be the QA of the team (QA for the customer). To master it find a way to build a regular feedback loop from users.
8. Root cause analysis: One skill that came handy during the transition from an IT guy where I had to write a lot of RCA’s about what went wrong when something did go wrong and how to make sure it never happens again was to get to the root of it. In a product role managing Stakeholder can be the most tricky part as more often than not people come with a solution rather than the problem and you have to extract the question to understand the crux of the problem and propose a solution you think works best for the company/stakeholders. Remember not to execute orders and stay in the problem space.
9. Measure & Improve: No matter how mature your product is there is always a room for improvement and you can not improve what you can not measure. Data is an essential part of it and you should have a knack of it. From what data to track to what KPI to measure for the improvement/success of your product. Different stages of product might have different needs but the sooner you make data a part of your decision making the better you become in explaining the rational not only to yourself but also to your stakeholders.
10. Ship, ship & ship: In an IT role the biggest pleasure I had was to punch in those commands and bring a dead server back up in production and in a Product role the biggest pleasure I or any other product person should get is pushing that product/feature, that the users need, out in the market so take that ownership and be a doer. Live your product/company !!

To summarise it all I had to make a mind shift from a service focus to a Product focus by really understanding the core business. As an engineer one can really be talented at developing software and with enough time at hand we can probably build anything. However, the challenge is to understand why businesses made that product development decision and once built how to measure that progress/impact of the product/feature. Most products exist for the purpose of furthering a much larger business goal/vision. So the idea is to deeply understand those bigger business goals and visions and help design, build, ship that vision out in the market. You are an enabler in doing so :)