The role of QA in product development, and why not read a book about sales?

It’s always easy to make fun of the relationship between the product team & the sales team, but we have to call out the fact that both are essential if you want to sell big ticket products to big companies. I’ll talk about sales teams in a future issue but, for now, why not consider putting down that latest product management book and reading a book that describes how sales teams work? You never know what you might learn!

I recently had the pleasure to speak to Dan Olsen, author of the classic Lean Product Playbook. We bonded over a shared love of adventure games & interactive fiction and tried to get as many 80s gaming references in as we could. You can check out the episode here!

On the next episode, I’ll be speaking to Princess Akari about her community efforts in Nigeria and some of the challenges Nigerian product managers have in realising their true value. Coming soon!

I was delighted to have a chance to get on the other side of the microphone on Etienne Garbugli‘s Lean B2B podcast, albeit somewhat less delighted to have the video released when I hadn’t done my hair & make up. We spoke about what happens after you’ve got product/market fit, some of the ways you can continue to grow your B2B product and some of the traps you should avoid.

It’s available on the website now and I think it’ll be coming to a podcast app near you soon.

Etienne is the author of Lean B2B, which has a second edition coming out really soon. I’ll obviously be interviewing him about that on my podcast when the time is right.

I ran a poll on Twitter recently because I’ve seen a lot of agile fundamentalists complaining about waterfalls and stage gates. I was curious to see what my network was doing. The results? A slight majority of people are using manual QA teams, and 2/3 of them are just fine with that.

I should call out that I have never worked in a company where there wasn’t some form of manual QA team (although in one company they were eventually all let go and we had no QA team at all). I should also call out that every manual QA person I’ve ever worked with has been an invaluable partner in building quality products. They care deeply about the user experience, hunt down & find bugs and make sure we fix them. I’ve never regretted working with these people, and in many cases wonder if they’d make good product managers.

But.. I still have a philosophical problem with manual testing. Even if we ignore the Agile part of it, and the not entirely unfounded allegations of waterfall thinking, there’s still the fact that human beings are really bad at doing repetitive tasks. And there’s nothing more repetitive than having to manually regression test an entire site to make sure the latest changes didn’t break anything.

In situations like this, I’m always massively in favour of automating as much as possible. Part of that’s down to test driven development and having good unit tests across your codebase. That’s definitely something teams should strive for, but it’s also a bit like marking your own homework. Having a robust suite of end-to-end tests is a really, really good idea. It enables you to programmatically define user journeys, clicks, navigation etc and run them via real browsers. You can even run them across multiple browsers and mobile operating systems if you want and get a variety of artefacts including videos, usability & accessibility reports. I strongly recommend QA teams upskill in this area if they don’t have the skills already. This allows any necessary manual testing to be by exception, and allows teams to concentrate on exploring the new stuff.

But do we need QA people at all? Agile fundamentalists will say no. I don’t agree with that because I think having external arbiters of quality is A Good Thing™. It’s very true that developers should care about writing quality code, and ideally write some of those functional tests themselves, but having strong, quality-obsessed partners constantly working to keep everyone on top form is something I encourage. They just need to be given the tools & training to concentrate their admirable talents on the areas that need them, and ideally brought as far up the development funnel as possible. That’s to say, don’t just throw them a work package at the end of the sprint and say “check this”! They need to know what’s coming, why it’s coming, help with acceptance criteria, check it in flight and be considered true partners in developing a quality product.

There’s a great video from author Dave Farley of Continuous Delivery that digs into this in much more detail, and I agree with just about all of it. Check it out!

Thanks for reading. I’ll be back soon, probably talking about sales teams unless something else distracts me. If you found this useful, interesting, or anywhere inbetween, please share it with your product friends!