One thing I try not to spend too much time doing in my product manager capacity, is testing. Though, I should clarify what I mean by this since carrying out experiments is kind of synonymous with the product management role.
Specifically, what I’m talking about is the kind of testing you do once some code has been developed and you’ve got a system/app/product that can be tested using more or less formal software testing techniques. Having moved from testing into product management, I try to make sure I don’t get sucked back into doing work that doesn’t jive well with my new responsibilities and associated compensation. Why bring up compensation? Because that lends weight to the rationale. Namely, that I should spend my time doing the highest value activities that I possibly can. Since I’m being paid a product manager salary, I should try – insofar as it’s possible – to stick to the PM activities that justify my cost to the company.
Is this the most important/valuable thing I can be working on right now?
Actually, the notion of always trying to work on the highest value activity I can is one that I’ve applied for many years and is a principle that has served me well in whatever capacity I’ve worked. In case it’s not glaringly obvious, the principle is this: whenever I’m doing or about to do some work, I should carry out some kind of sense check: is this the most important/valuable thing I can be working on right now? If it’s not, then unless there is some compelling reason for me to do it instead of the most important/valuable thing, I should drop what I’m doing and go work on that instead.
Generally, my managers, clients etc have appreciated my adherence to this rule. I recommend it.
Anyway, I’ve digressed. I try hard not to get too involved in the testing efforts. But this week I did. After many weeks of delays and issues outside of my product teams control (my product team is made up of the QA, product & project management functions – with ancillary developers, designers and an architect) leading to some fairly serious delivery timescale issues, I decided it made sense for me to jump in and help out with some of the testing to keep things moving along.
Long story short: I loved it. I still get a thrill out of just exploring a piece of software, looking for bugs and issues. And I was reminded of how much value it actually adds to my own work in the process. Since from a product perspective, I’m going to have to scrutinise the product and make sure everything looks/feels/reads/works ok at some point during the delivery cycle anyway – why not combine it with some testing? There are some obvious benefits:
- I understand what’s been delivered better. Even though I wrote the original specs, things tend to change during development; design decisions get made etc which I then forget about and have to pick up later down the line.
- Understanding the functionality and finished product better and sooner helps me write better documentation for our users.
- Spotting gaps that may be missed by our QA team means I can feed back to development sooner.
- The load is lightened (at least a little) for the QA team.
- Getting involved in the testing just keeps me a bit closer to the development process, which I can otherwise become a bit removed from while focussing on higher level PM activities like surveys, marketing, speaking to customers, partners etc.
Dig into testing
So what’s the learning here? I think it’s to try and set aside some time, in my increasingly busy schedule, just to dig into some of the testing so that I do stay a bit closer to the process. On reflection, I feel like over the course of time I have become a little more removed from the development activities than I would like. And that getting more involved in the QA can help me provide better feedback, faster – and see and appreciate at a deeper level what’s been delivered, sooner.
Is it the best, most valuable use of my time? We’ll see. Stay tuned for more PM Diary entries to find out!Thanks for reading. Feel free to reach out via a comment or on the socials if anything resonates.