Wednesday, October 28, 2009

Career Change: How to Become a Product Manager

There are many paths into product management in the software world. Whether it is putting your product knowledge to work as a software engineer or your customer knowledge as a sales engineer, one thing that seems to be consistent is that you need a background in software to manage a software product.

I'm going to spend some time talking about how to make that change into product management. Many of these concepts will apply to anybody wanting to transition into product management, but we may cover some topics that are specific to where you are coming from.

As a starting point, let's identify and characterize some of the "standard" career paths that you can take in product development:

You can go down the technical path, becoming an architect or a principal engineer. I call this the "How" path, because your job revolves around how to accomplish the needs of the business.

Another path is into functional management, progressing from a team lead through manager and into director. I call this the "Who" path, because you primarily are concerned with who will accomplish the needs of the business.

Tangential to functional management is project management, which is the "When" path. Your primary focus is the scheduling of deliverables.

I would categorize the path through business analysis as the "What" path. This may be an intermediary step to get to product management for many people. As a business analyst, you define what needs to be built and delivered.

The last common option, and the one we are going to concern ourselves with, is product management. This is what I call the "Why" path.

Any time you change your career path, you will be required to change the way you approach solving problems.

I can see many people arching their eyebrows and muttering, "The product manager is the one who says 'What'." My argument is that the "What" is a by-product of understanding why a market exists and is experiencing a problem that your company is capable of solving.

I have a lot of ideas swirling around on the topic of making the transition to product manager, far too many for a single post, even with my (too?) lengthy prose. As such, I'm going to make it a series of posts.

  • In part two, we will discuss the mental shift required to move into product management. This is one of the most difficult steps and your success with this step will determine whether it is an appropriate career path. We will also discuss what you will give up when you make the switch.

  • Part three will explore how you can gain product management experience while you are still doing your day. There are many things you can start doing today to assist in your career change.

  • Part four will review options for gaining the remaining knowledge and experience you will need to make the transition.

  • Finally, we will wrap it up with a discussion of getting that all-important first job, including how to present yourself during your job search if the first job is not at your current employer.

I am going to bring multiple viewpoints into this discussion, both through conversations with others in the product management community, through the existing body of work already out there, and, hopefully, through your feedback.

Special thanks go out to Bob Corrigan for his early feedback on this topic. His ack/nak blog is a great source of Product Management information. You should read it!


Rian said...

Interesting post. I would add one more path, and that is the path of the User Experience Design Professional. I personally think UX practitioners make great PM's because they know how to identify and meet user needs when building software.

I look forward to the upcoming parts!

Travis Jensen said...

Thanks, Rian. I totally agree with you. There are many ways into product management that I didn't mention: UX, as you mentioned, customer service, sales engineering, and others.

All of them bring unique and valuable viewpoints to the profession. They also bring their own short-comings that need to be overcome.

The key is to identify each, maximize the first, and minimize the second.