Making my career roadmap I had time to reflect on how I got into product management. It happened almost ten years ago and at the time there was very little information about the role and what one needs to succeed at it. I was super lucky to receive mentorship that helped me to transition from my engineering mindset to a product one. Now I'd like to help future product people who are considering getting into the profession.
Still today a professional product management education that leads to an entry PM job is a rare case. Most product people switch from other roles. Here is my completely unscientific list of roles from where new PMs are arriving:
- Engineer
- Designer
- Business analyst
- Project manager
- Marketing or sales-related roles
Switching from these roles people will encounter different challenges becoming product managers. The mindset shift will be smoother if folks remember the core responsibilities of a PM:
Find a problem worth solving (that is urgent, pervasive and customers are willing to pay for solving it)AND
Help to come up with a solution (that is valuable, usable, feasible and viable for the business).
Keeping those in mind we can see how people could use the skillsets from their previous roles to help them in product management. An engineer would know a lot about creating solutions, especially in the feasibility domain. A business analyst would bring their expertise in finding and validating a problem, while a marketeer would know how to assess the viability of an idea. All their unique experiences would be highly relevant to product management. However, to become a well-rounded PM one needs to cover all the bases. This means learning aspects of problem or solution domains that one might not have needed in their previous role.
In the upcoming series of posts, I'll cover the transition from each role separately and in details, and the following is a quick overview.
Engineer > PM
The first and the most important thing to learn when switching from engineering to product management is not to jump to a solution too quickly. Engineers are builders and they're getting paid for creating things, solving problems. Things work slightly differently for PMs. We're getting paid for solving only the right problems. And sometimes the decision to do nothing is as viable as any other.
The problem space is where the fresh engineering PM should spend most of their efforts at the start. They need to understand and practise product discovery, get in touch with their customers, get a wide understanding of various problems (and there are always lots!). Only then it's time to look at solutions.
At first, the solution space will feel easier to engineering PMs, that's what they used to do. However, they need to be especially careful with the business viability of a solution. A good solution is the one that brings value for both customers and the business. Hence engineering PMs will have to learn how their business works, what makes them money and what are their costs.
Designer > PM
Product discovery is the domain that often shared between PMs and designers. Hence it's highly probable that the problem domain of product management would be a naturally strong side of designer PMs.
Coming to the solution domain, designer PMs should not have any problems with usability or valuability of their solutions. This leaves two areas where designer PMs should focus their learning first: feasibility and viability. Things can look wonderful in a prototype or a mockup, but when it comes to a real product a lot more considerations should be made. Is the solution secure, scalable, performant? A successful PM should have just enough technical knowledge to address these concerns.
Also, designers tend to be highly customer-centric, which is a great trait for any PM. However, a successful product should bring value to the company as well as to its users. This means a designer should be business-savvy to grow as a PM.
Business analyst > PM
This is probably the most natural progression path. Even though business analyst is a widely defined role that could differ much between companies and industries, in essence, a business analyst is a problem solver. That's a great start to a successful PM career.
BAs are usually skilled in researching problems and coming up with solutions. They might have extensive technical or business knowledge. Probably the trickiest part for BAs to become PMs is to start thinking at scale.
A successful product is pervasive - meaning it appeals to many people. While BAs often focused on one or a few problems for one or a bunch of customers. When they become PMs this thinking needs to be abandoned in favour of creating products for the majority.
Project manager > PM
Good news project managers - you get to keep your job when you'll become PMs. Yes, despite some myths, project management skills are highly relevant to PMs. We need to deliver, often, on time and on budget. Sounds familiar?
So I suppose most project managers will have a good understanding of the delivery side of making a product. This means it's discovery where project folks should spend the most time at first. Luckily, you can still run discovery as a project ;)
Marketing or sales > PM
Coming from strictly business roles such as marketing or sales, people usually bring their unique perspectives into the new role. Most sales folks out there are skilled in talking to people, understanding their problems and envisioning the possible solutions that could make sense for the business. They might be less aware of the delivery side of things - feasibility and usability.
Product management is actually a part of marketing, academically speaking. Hence anyone coming from the marketing side should have at least a basic understanding of both problem and solution domains. However, the devil, as we know, is in the details.
Marketing is such a broad domain that no one individual could cover it all. The easiness of transition to a product role will depend on the specification of a marketer. Quite often it's the technical side of product management that is the most challenging for marketing PMs.
Surely those are just some partial observations and every transition case is different. In future pieces, I plan to go deeper into every path and hopefully provide some tips on how to simplify getting into product management.