I just finished a major release at work, so the last weeks have been crammed with helping the Team crunch out features rather than blogging. We don’t have QA analysts on our Team which means the PM and Devs must ensure a quality product is released. Testing can be intimidating to a new PM who has never been responsible for a release before, but there are key advantages a PM has when it comes to testing. Teaching these advantages to a new PM will help them feel confident and able to help make the product launch as success.
PMs aren’t responsible for the code – It’s very hard to test your own code. A developer doesn’t know what they don’t know. If they knew how there could be a bug in their code, they would have fixed it when they wrote it. Plus the sense of ownership for the code they wrote may make a Dev go soft on their testing so that their code doesn’t look bad.
A PM brings a fresh set of eyes to finding and exploiting soft spots in code, being able to ignore the effort that went into creating the code. Just because a new UI or process was hard to write, doesn’t mean a PM feels they need to go soft on testing it. I always enjoy this mental image of a Developer testing their beautiful product:
For a PM, it’s time to take a whack at the product and get that delicious candy inside.
PMs know what bugs are important – Rather than spend time on bug hunting for edge cases, such as clicking a button too many times too quickly, a PM can go for the stuff that’s really important. A PM knows what customers really value in the product, and they can thus ensure the critical features are working for launch. As an example in this last launch, I was sure to validate the main use cases of our API that a customer uses, rather than all the ways the API could be used, and found issues that would have definitely led to customer complaints. The Developers had tested the way they use the API internally, but didn’t know about common usage patterns for the API. By prioritizing testing on what’s important, a PM can make sure they give the most value to the Team with any testing time the PM can share.
PMs know the special customers – Every product has special customers, such as those with weird data or special integrations. The PM can make sure these cases are checked, simply by asking the Team “Did you think about X?” where X is a special customer. In this last release, I found bugs in customers who were special due to custom skins on their account and due to customizations they had to the product. A developer who isn’t used to the customer base wouldn’t know about these specials, so they wouldn’t think to test them.
Hopefully you find these tips helpful in inspiring your next bug hunt, or helping a new PM get into the right mindset for helping to test their first launch.