I’m writing about one hundred things I’ve learned about being a product manager.
Many years ago, my parents bought me my first PC. It was fairly pricy at the time, and represented the end of my reliance on stolen minutes on other people’s computers. And because I’m a muppet, the very first thing I did was to brick it by attempting an ill-advised upgrade.
Despite relying on each other for the success of their products, the Sales and Product teams often have a jarring relationship. This is far from ideal. By looking at where things go wrong we can identify a better way of working with each other. The prizes on offer: shorter sales cycles, more easily achieved targets and customers who are always happy to hear from you.
I recently spoke at ProductCamp London about conducting lo-fi usability, that is, easy, quick and inexpensive usability testing that anyone can run. I did a neater version when I was invited recently to present to the BBC product managers and user experience practitioners, which I’d like to share with you.
Quite a few people are put off usability testing because they think it’s complicated, time-consuming and expensive. What you may not realise is that you can run a set of usability tests in a single afternoon that will uncover eighty percent of the problems your product has. And the only specialist equipment you’ll need is a pen, some paper and the computer you need to access the software or website.
This my friends is lo-fi usability testing – a high-return, low-cost method for these cash-strapped times. In this first instalment, I’ll be discussing what usability is and why testing it is so important.
You expend a lot of effort getting people to buy your product and they’re happy with it.
You then go back to your satisfied customers and tell them what they have is now mediocre, so they have to move onto your latest and greatest product version. You see this everywhere, from washing powders to family cars, so it must work for enterprise software, right? So why are your no-longer-happy customers now chasing you with pitchforks and burning torches?
Your developers may be happiest when they’re hacking gnarly code, leaving you to get on with engaging with the market, but this doesn’t mean you can ignore their need for context – the ‘why’ of their project.
Over the years, I have spoken to many disgruntled developers over a beer after work. This isn’t entirely coincidental as they tend to dwell in the kind of pubs I enjoy: real ale, good selection of crisps, ability to hear oneself think, minimal bar fights, that kind of thing.
What tends to be a recurring theme of their disgruntlement is that they don’t see the point of their current project. They feel aggrieved that they’re not doing something more interesting instead. And you know what, if it’s your project, it’s your fault. Bad product manager.