Five things I learned about product management from being a writer
Five things I learned about product management from being a writer
It recently occurred to me that there were some things I’d learned as a reviews editor that I still use as a product manager.
I recently read this piece in The Verge in which senior editor Tom Warren enthuses about his toaster. In it, he describes how well the toaster is designed “for humans” and he starts by saying: “I write about and review cutting edge tech products for a living, yet every time I pick up a new piece of hardware I always think about my toaster.” In fact, the article is headlined: “All tech products should be designed like my toaster”.
It made me think about my own time reviewing products. I spent eight years in the British technology press as a journalist, first as a staff writer — working on reviews, features, interviews and news stories — and then for four years as the publication’s reviews editor. My job was to look at the entire market of technology products being released and pick the dozen or so that we’d review in each fortnightly printed issue for our half a million readers.
I’m now on the other side of that wall, as a product manager whose teams create things that people use — though I am fortunate that with few exceptions the kinds of product I work on don’t get reviewed by journalists. But Tom Warren’s piece struck a chord with me — he looks at products every day, and that can’t help but lead to thinking about how products are used and made — and made me think about the things I picked up on as a reviews editor that I’ve held on to since those days.
1. Empathise
Product managers sometimes talk about being the “voice of the user”, but it’s not always clear what that means. As a reviews editor, I may not have been the voice of my readers, but I was definitely their representative. My job was to tell them whether a printer, monitor, Macbook, camera, iPod or game was worth their money.
That sometimes led to conflicts with manufacturers, who wanted me to put a particular spin on their product, or to review it without reference to its competition, or to use it in a particular way that may not reflect its actual real-life use.
What I needed to remember — and sometimes what I needed to reinforce among the reviewers who wrote for the publication — was that our job was to be the user, in the shop, browsing the catalogue, wondering about buying, and thinking: should I buy this, or not?
If you’re the product manager for a website, or a banking app, or a customer database, you need to always be thinking about why a user might or might not want to use your product. Or the user might not have a choice, in which case we need to think about how to make using the product easier, or simpler, or more productive.
2. Understand
One of the hardest things about user research as a product manager is getting people to use a product in a realistic setting. We can do corridor testing with colleagues but we don’t know that people who aren’t our company’s staff would react in the same way. We can take people to a usability lab with two-way mirrors and cameras rigged all over the place, but if we’re asking them to look at a recipe website, they’re not thinking the way they would be if they were on the site on a phone in front of the oven, or in the aisles of the supermarket. I’ve used companies that allowed us to test more realistically, calling on people to cook a recipe from a website while talking us through it, and then working through those recordings to try to uncover insights, but even that level of realistic testing isn’t fully true-to-life.
As reviewers, my colleagues and I had to think hard about how people would use the products we were reviewing. For a game, that wasn’t hard. In those times in my job when I could genuinely say that I was playing computer games for a living I could slip down to our testing lab downstairs, fire up a racing simulator and use the big monitor, pedals and steering wheel kit we kept down there to immerse myself into the game. I may not have been playing at home, but it was close enough.
For other products that was much harder. If you’re reviewing a fitness tracker, you need to go running with it. If you’re reviewing a sat nav device (remember those?) you need to take it for a long drive. It meant using the products in as close a fashion as possible to how a real user might.
As product managers we need to remember that the user will almost never use our products in the environment in which they were developed. How many of your users use phones rather than widescreen monitors? Is your site or your app optimised for someone in a rush on a phone in the rain, or for a developer in an office on a big screen with a physical keyboard? Does your product degrade gracefully if the user is on a slow internet connection, or has a low-powered device? Do your user personas reflect real usage, or theoretical habits?
3. Remember
I’ve lost count of the number of digital cameras I’ve reviewed. Likewise the number of digital music players or iPods. At one point I had a desk drawer in the office that was entirely full of USB sticks and memory cards. My job felt like Christmas Day most weeks because I got to tear open the enormous number of parcels and packets that would arrive on my desk. I became considerably more familiar than I’d ever expected to with the nuances of every single courier company that served London.
Apart from the entertainment value, the real advantage of this is that if you see all those products, you start to spot trends, and you develop an inherent understanding of how a product fits into its own history. Every new product needed to be assessed on its own merits, but having an understanding of ten years of the evolution of digital cameras meant you could quickly see what was a quantum leap into the future and what was a retrograde step into the past.
That skill is not a crystal ball, mind you. I consider myself pretty bad at picking winners. I saw the merits of the first iPhone, long before Apple had thought an App Store might be a neat idea, but I completely failed to understand why most people would want to use an iPad. But it did give me an appreciation for trying to understand why things develop in the way that they do.
It’s important for us to understand our products in context. The user might be coming to your booking app without having seen it before, but they’re likely to have booked something else online in the past. We need to understand that context so that we can know when it’s right to stay in the mode and present a familiar scene to the user, and when it’s right to break the rules and try something new. By looking at the competition and researching the recent history of what we’re trying to do, we can work out how to create the products that genuinely change the mental models our users have.
4. Listen
We didn’t have panels of real users to test things on, as I do nowadays as a creator of products. I had to rely on my team of reviewers — writers who were technology experts — to be able to accurately and fairly judge the merits of a product. What we did have was readers, and lots of them. As reviews editor it was also my job to field the mailbag, which by that time was largely metaphorical and took the form of an email address (although we did get a lot of letters, even in the mid-2000s, a surprising number of which were in green ink).
The advantage of being a mass market publication is that your readers talk to you. Not always coherently, but often they’d send in nuggets about how they’d used a particular product, or point up a shortcoming that we’d missed, or sometimes lay into a product that we’d praised. Again, not all of these criticisms from readers were fair, and not all of the additional praise was valid — sometimes the reader would have such a niche way of using the product (an edge case, we’d call it now) that you could tell that it wouldn’t really apply to enough other people to warrant a reappraisal.
We’d print the best of these letters to continue to inform our readers about products we’d reviewed. We’d reply to others to tell them how they might have missed something, or to try and help them use a troublesome product.
When our users talk to us, we should listen. Free feedback is a gift, and we shouldn’t dismiss it even if it comes from people with an axe to grind (or at least with experience you learn which are the people with a grudge). Take time to read or listen to the feedback, weigh it in your hands and judge it. If it has value, take the idea further with your product team, or if you can justify dismissing it having considered it, then trust your judgement and do so. Don’t be afraid to engage your users. If someone complains, it can be both disarming and powerful to engage them: people want to be heard.
5. Sympathise
People hate change. It’s become a cliche that when you put up a new version of a website, a loud chorus of users will be angry with you because you’ve changed the mental model of how they use your site. When you put up the next version of the site a few years later, the same people will complain about that, because they’ve recalibrated their mental models to the previous redesign, and now you’ve changed that too.
People would struggle with new products and new types of products. When I reviewed that original iPhone — which cost £269 up-front at a time when most people paid maybe £50 for their new handsets, if they paid anything at all up-front — I was met with an angry response from some readers who said it was an outrageous waste of money, that it was a fad that would never catch on, that we were wrong to publish a review of such a niche piece of technology. Apple sells roughly 200 million new iPhones a year, and the various Android manufacturers sell a considerable amount more than that.
I imagine that most of the people who complained 13 years ago are now happily using some sort of smartphone. It might even have become something they can’t live without. It wasn’t my job or my role to make that transition easy for those users, but it did give me an appreciation for how people feel when the world changes around them in small but meaningful ways.
You shouldn’t take your users for granted, but nor should you assume that people don’t like or even love your product. The most committed users are the ones who have built their mental models or their routines around the product, and what to you is a great new design is to them a forced change to how they have to think. Take them on the journey with you. If you can, work out how to engage with those heavy users, and tell them what’s coming. Let them see previews, or (even better) let them in to a beta version, so they can prepare themselves, and let you know what they think.
Thank you for reading. Do let me know what you think, whether you enjoyed this piece, hated it or were indifferent towards it. I’m not on Twitter much these days but you can reach me there @phowax, or on Linkedin.