I often get asked by developers what’s involved in moving into product management. I usually respond that switching roles requires a change in perspective more than anything. Before investing in the education and training required to make the switch, make sure that it fits your temperament.
Understand the role
Familiarize yourself with the less glamorous parts of the job, including:
- writing users stories
- ordering the backlog
- calculating value
- stakeholder management
Reactive thinking to Proactive thinking
As a programmer, you have to react to a lot of different demands. There is always a new product or feature that needs to be built. There are always urgent bugs to address. There are always new SDK versions and language updates, and there are always new technologies and software patterns to learn. Tech debt needs to be addressed, code needs to be refactored and environments updated. But the nice thing about being a software developer is that you only have to worry about the feature you are working on at the moment, or the current sprint. You don’t know about a bug until it is found. You don’t worry about a new version of an SDK until it is released, or until your current version is deprecated. And often you don’t think about refactoring your code or addressing tech debt until you hit a wall. Balancing all of these demands is an artform but requires a slightly different temperament than what is required as a product manager, who must look far beyond the current sprint.
As a product owner, you have to think long term. You own the product roadmap, therefor you have to anticipate customer and stakeholder needs well into the future. You have to worry about the long-term financial viability of your product. You have to worry about external and internal risks that may surface at any time in the future. You have to worry about what your competitors are working on and will release down the road. In essence, rather than reacting to the demands of the current sprint, you have to anticipate many possibilities and unknowns that may occur immediately, 6 months down the road, or never happen at all.
From detail orientated to high-level vision
Programmers are extremely detail orientated, not only by necessity but as a culture as well. Of course, a missing semi-colon can cause a compile-time error in most languages, but most programmers find the need to define coding conventions among teams, officially to aid software readability, but in reality, to prevent conflict. Programmers can be really passionate about whether to put a curly brace on the same line as the function definition or the next line, and it is entirely cultural to the language, there is no technical reason for either. As one becomes more senior and progresses to be a software architect, your scope expands and you become less detail orientated and start looking at the system as a whole, but as a product manager you must take this perspective shift to an extreme. A product owner must be able to state their product vision in one concise sentence than must define the intent of the product for its foreseeable lifetime, just as salespeople have to have a convincing elevator pitch to grab attention of potential customers in only a few seconds. If you ask most programmers to describe what they are working on for the next six months in one sentence, they would struggle, or it would come out as a list with many commas.
If you are a programmer and would like to try your hand at creating a product vision, a common use this common formula:
For [our target customer],
who [customer’s need],
the [product]
is a [product category or description] ,
that [unique benefits and selling points],
which unlike [competitors or current methods],
our product [main differentiators].
This is product management in a nutshell.
Empathy
Developers have instant empirical feedback for most of their work: compile errors, failed unit tests, code reviews and bug reports. Code either meets the requirements, or it doesn’t, and it is hard to argue about it. With product management, things are much more subjective, and that can take some getting used to. Stakeholders are not always rational, and even when they are, they probably don’t see things the same way you do. You need to have great empathy to understand where all your stakeholders are coming from. That means developing great soft-skills and being a sort of salesperson for your vision. If you have an aversion to sales, then product management is not for you. You must sell your vision to every person you communicate with, and that is a lot of different types of people with a very diverse set of cultures, jargons, expectations and concerns. Be prepared to learn about sales and marketing and finance and legal, and every other profession under the sun, because you are going to have to meet with these people and sell your vision to them in their own language.
Customer first
This one is easier. The primary role of the product owner is to provide as much value to the customer as possible. Calculating value is a skill that can be learned, but the value is always to the customer. The good news is that if you are used to thinking about UX for your software, or if you are used to writing documentation for your software, you are used to putting yourself in your customer’s shoes already. Calculating value can be complicated, but it is not a huge shift in perspective for good developers. You should always put the customer first no matter what your role in the organization is.
Saying No
As a developer, you really never get to say no. Sometimes there is an ask that is not technically feasible, sometimes you slip a deadline, sometimes you have objections that are heard, but you don’t really get to just say “No”. As a product manager, saying “no” is central to your success. This sounds like more fun than it actually is. Saying no can be extremely difficult at first, when you are confronted with a powerful and insistent stakeholder. It will take time to learn how to do it skillfully and gracefully without getting frazzled.
Letting go of being a developer
Coding is fun, but as a product owner, you won’t have any time left to do it. In fact, you will have to delegate almost all technical decisions to your team. You will have to learn to hold back your technical opinion and let your dev team take the lead. Your technical opinion will also carry less weight no matter how valid. It is inevitable that your technical credentials will be put in doubt when you transition to product management, and this can be a blow to your developer ego.
In addition, what I said about saying “no” also applies to the dev team. You will have to be comfortable with making a business decision that can put strain on your relationship with your former developer team.
Meetings, Meetings, Meetings.
Developers hate meetings. As a product manager, you are going to have to get used to them. Be prepared to spend most of your time in meetings or otherwise communicating with people. If you can’t handle many hours of back-to-back meetings or phone calls in a day, this is not the job for you.
Passion
More good news, this one is easy. Developers are already a passionate bunch. If you hit a nerve with a programmer on a certain language, operating system, or design pattern, you will hear an extremely convincing argument for or against. If you can channel this energy into your product, it will make your job easier, as long as you can back it up with solid technical knowledge and a solid business plan. Yes, you are going to have to learn how to write a business plan, and you will have to modify your methods of persuasion to adapt to your audience. Again, you have to sell your vision in a more subjective way. Soft skills are key to making sure your passion serves you well and does not hinder you.
So, should I do it?
If this hasn’t scared you off, and you think you have an aptitude for product management, then now is the time to start taking courses, reading books, and learning about the details of how to do the job. Developers can make great product owners, and even if you don’t settle into product management forever, knowing how to think like a product manager will make you a better developer.
If, however, this does not look like your gig, don’t fret, becoming a software architect will give you the same career advancement without some of the more jarring shifts in perspective.