From Software Engineer to Product Manager
My Path to Product Management: Part 2
Product Management: the intersection of User Experience, Business, and Technology. Every product manager has a different story to tell about how they got here, and I’ve decided to share my own tale as a multi-part series.
In Part 1 of My Path to Product Management, I shared my thoughts on the common skills needed for both Software Testing and Product Management. In Part 2, I’ll go over how my background in Software Engineering has been both helpful, and sometimes detrimental, to being an effective Product Manager.
The Benefits
There are a few obvious advantages to having a software engineering background when working in Product Management. I find it easy to communicate with the engineering team, even when they jump into a technical deep-dive while working out potential solutions. I also have a pretty good understanding of what’s in the realm of possibility from an engineering perspective.
The most important skill I’ve carried with me to product management is the ability to empathize with the engineering team I work with. I sympathize with the team when they get stuck on a hard problem. I fully appreciate the importance of engineering best practices such as test-driven development and pair programming. I understand the value in slowing down to refactor and pay down technical debt. Read all you want about how to work with software engineers, but there are some things you can only really “get” by living it.
The Pitfalls
Sometimes, an engineering background can also make it difficult to stay product-focused. If you’re a technically-inclined Product Manager, I have a few tips to stay on the right track for the sake of your product and your team:
1. Don’t make assumptions on behalf of your engineering team
As a former software engineer, you know how to code. Maybe you’re even proficient in the language and frameworks the team is using. Perhaps you were once an engineer working on that very same product. This does not mean you fully understand what the engineering team is currently working on. Don’t assume you know how complex something might be to implement. Don’t assume you know that one particular solution is “cheaper” than another. Always check with the engineering team when an engineering decision needs to be made.
2. Prioritize based on value, not technical dependencies
After you break down an epic into bite-size stories, you probably have a feel for what order you would tackle them in if you were an engineer working on the product. That’s great, but that is not how you should prioritize your stories as a Product Manager. Your goal is to deliver valuable software to your customer as quickly as possible, not to implement the stories in the most logical order. Prioritize stories based on the value they provide, not because the engineering team is already working on that area of code.
3. Keep implementation details out of your user stories
As a Product Manager
I want the database to be encrypted in Triple DES with a 168-bit key
So that our data is secureWhen writing user stories, details are important. Implementation details are often not. You should only include the details that are necessary to provide value to the customer. If the customer doesn’t care about the exact syntax of the API, then it shouldn’t be in the story. If the customer doesn’t care if the validation is performed client-side or server-side, then it shouldn’t be in the story. If the customer doesn’t care about the specific encryption algorithm you use, then it shouldn’t be in the story. But, of course, if the customer does care about how encryption is implemented, go ahead and include those details.
As a Product Manager, remember that you’re a member of a balanced team consisting of product, design, and engineering. Your primary role is to make sure the team builds the right thing. While it certainly helps to have technical expertise, please take care to leave it to the engineers to build it the right way.
Until next time…
Stay tuned for Part 3 of My Path to Product Management: From People Manager to Product Manager.
To follow me through my journey to Product Management, check out the entire series:
