From Software Tester to Product Manager
My Path to Product Management: Part 1
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.
I’m a tester at heart, and I always will be. I started out my career breaking things, and it’s still something I’m passionate about. If you give me an application, I will find something, and it’s gonna be good. As in, oh-crap-we-never-would-have-thought-of-trying-that-but-it-would-have-crippled-us-in-production good.
There’s probably not a plethora of Product Managers who have a background in quality assurance or testing software, but I’ve found many similarities in the skill sets needed for both of these roles.
Quality Assurance is not just about reducing the number of bugs: A good tester finds bugs that defy the product’s specifications. A great tester finds gaps in the user experience that defy the product’s purpose. Sometimes this might be a bug, but often it’s a missing feature. User-centered testing focuses on the bigger picture to make sure the product meets the user’s expectations, from the start of a task until the goal is accomplished.
As a tester, I’ve spent countless hours asking myself questions like “As a user, what might I want to do next?” and “What would I expect this button to do?”. This has left me with the ability to empathize with the end-user, as well as an impulse to question assumptions — both skills that are critical in Product Management.
Accepting User Stories
As a tester, you need a certain level of intuition about where there might be bugs. You could click on every button in the entire application to find these issues, or you could explore with a purpose in mind. With sufficient experience as a tester, you’ll be able to hone in on those previously-mentioned good bugs rather quickly. This intuition can be extremely useful when writing and accepting stories as a Product Manager.
When writing a story, my testing background allows me to visualize all of the edge cases before the engineers so much as write a line of code. What’s going to happen when the user enters invalid data? What’s the empty state for this page when there are no records? How will this feature impact our API users? I can include expectations around these scenarios in the current story or as a separate feature, or perhaps just by having a conversation with the engineering team. Either way, the team understands exactly which edge cases must be handled to meet my expectations. Adding this to the acceptance criteria up front tends to mean fewer rejected stories.
Your team is just about to start working on a new feature when someone finds a bug. What should the team work on first?
My spidey-sense for quality screams “fix the bug!”, but I know better than that. A good tester reports every bug, and lets the team determine which ones are important. A great tester understands the potential impact each bug and works with the team to prioritize accordingly. Some bugs are critical show-stoppers, while others are minor annoyances that only occur in rare circumstances. Product Managers need to weigh the value each would provide to the user when deciding between fixing a bug or implementing the next feature. Having a background in quality assurance makes it easier to understand the impact of a given bug, which is necessary to determine the value of fixing it.
Until next time…
Many of my strengths in Product Management are owed to my early foundations in testing software, but there are still a few more stops along the way. Stay tuned for an eventual Part 2 of My Path to Product Management: From Software Engineer to Product Manager.
To follow me through my journey to Product Management, check out the entire series: