Product Management is About Questions, not Answers
Product Management is About Questions, not Answers
If you want to be a better product manager, don’t be the person with the answers, be the person with the questions
If you want to be a better product manager, don’t be the person with all the answers — be the person with all the questions
“How would you improve the Daily Mail?”
I was stumped. The question was impossible to answer. I was 23 years old and was in the middle of an interview for a scholarship to a prestigious postgraduate journalism school (I didn’t get it) and was being grilled by a panel of academics and journalists. And they had just asked me the killer question.
The Daily Mail was and still is the second-biggest selling newspaper in the UK. Barring print strikes, the biggest public holidays, and the odd war, it has sold more than 1.5 million copies to the middle-classes of the country every weekday for the last hundred years. At the time I was being interviewed, the daily sale was 2.5 million.
It did so by serving its readers an almost perfect concoction of reporting, editorialising and feature writing that was calculated to press their buttons, tickle their fancies and yank their chains. I don’t remember how I answered the question, but as far as I can recall I had nothing to offer. I think if I were asked the question again today, I’d have a few ideas up my sleeve, but I’ve come to realise that what I should probably have done is talked not about answers but about the kind of questions I would have asked.
How would I improve this newspaper, this finely tuned machine for giving its readers what they wanted to read? I should have started by talking about who the readers are, and how I’d find out more about them. What makes them tick? What bits of the paper do they turn to first? What bits do they skim through? Which sections do they avoid completely? That would have allowed me to start to build a picture of what to change.
It’s worth asking what the word “improve” means. If I were the editor, I’d be interested in selling more newspapers, so the question doesn’t have to just be about the readers. I might have looked at the parts of the country in which the paper sold well, and the parts in which it sold poorly. Compared regions with similar demographics but differing sales figures. One might even go so far as to look at specific shops that sell better than others and ask why that is. But in any case, I should have started by asking questions.
It’s natural to want to give answers — and to want to receive them. We are conditioned from an early age that we should have the answers to things at our fingertips — times tables, place names, historical dates. I don’t disagree with this. Memorisation can unlock our abilities to do things with the things we’ve memorised. But we carry that on into adulthood, and we don’t want to look stupid when we are asked a question. When was the last time you said “I don’t know” in a meeting at work?
“I don’t know” can be a powerful statement, but we are fearful of saying it because we don’t want other people to think we are fools. Sometimes, when I tell a colleague I don’t know something, I can tell they think less of me, but I have trained myself not to care. I don’t need to prove myself by knowing things, because that’s not what my job is for.
It’s rare to admit to not knowing, and yet we don’t know most of the things, most of the time. Product managers, particularly, operate in a world of uncertainty that can be taxing — if not downright unsettling — for colleagues whose jobs need to exist in worlds of certainty. My product colleagues and I are taking uncertain futures — what is the right thing to build that will ensure our future success — and iterating on the solutions to well-defined problems that will allow us to steadily reduce that uncertainty.
The first step on the road to certainty is to admit what you don’t know. After all, if we knew what to build, our jobs wouldn’t be necessary. Why conduct that costly and time-consuming user research if you know that you can produce a feature that will double your user base or triple your revenue?
But we don’t, and so we go out and we ask people. We do guerrilla testing in corridors, bribing our colleagues with sweets and chocolates if they’ll tell us what they think of a prototype. We take our products out to lab tests where we ask people whether — in short — they are any good. We A/B test features just in case our earlier questions were wrong and the thing our test subjects said they loved turned out in fact to be a steaming pile of elephant dung when we let real users loose upon it.
A good product manager will not only ask questions at user research time. We are — usually — not the most experienced programmers in our teams, nor the most experienced designers, testers or researchers. It’s easy to think — particularly when we are working remotely and every interaction feels like a time-sink of a Teams meeting — that we should let our team be, and allow them to get on with it. And we should. But we should also make use of their expertise, skills and experience to help us shape both the problems and the solutions at hand. We should be asking more questions, not fewer.
It’s worth noting here that user research is not note-taking: we’re not asking questions in order to create a shopping list of product features that we’ll mindlessly deploy. There’s probably enough here for a separate article, so let’s just say that the product manager’s job is not only to ask the questions but to understand what to do with the answers.
A year or so ago, someone who works in a Silicon Valley VC firm asked an interesting question on Twitter:
Recent PM interview question I’ve been using: You’re the PM at Netflix handling the home screen. How do you determine how shows get promoted editorially vs algorithmically recommended? Walk through metrics/principles/trade-offs and how it impacts various parts of the biz.
What I found particularly interesting was how many of the 250 people who answered went straight to their pet topic: all automatic curation, all human curation, fully personalised home screen, let users customise the “panels” on the home screen, machine learning, you name it. My favourite answer was this one:
More than the ideas for solutions, it’s revealing what questions are asked first. Does the candidate start asking about metrics/objectives? What about time/resource constraints? So many PMs start framing plans without getting curious.
I have asked similar questions when interviewing applicants for product positions, and the strongest candidates are typically the ones who will not jump straight into a solution but who will lay out their basis for increasing their knowledge, decreasing uncertainty and improving the definition of the problem before attempting to solve it. We’re interested in what questions people ask. Meta-questions, even: who do they need in the room before they start to formulate the questions: UX researchers, product designers, service designers?
There’s room for knowledge, intuition and induction, mind you. The person who asked the question said that this was his favourite answer:
I’d be particularly impressed with candidates who can identify how this impacts partner dynamics, can correctly predict that some partners have already been contractually promised editorial promotional consideration in rights deals, how this impacts ecosystem over years, etc. And I’d also like someone who can give a principled case either for or against doing the “obvious” thing of “Giving the user our perception of what they are likely to want, all of the time, bowing minimally to other considerations”, weighing it against commercials and artistry.
I didn’t get the scholarship but I did join the journalism school and went on to spend 10 years in writing and editing jobs. As a writer, I spent a lot of my time interviewing people. I was looking for stories, of course, but also I was looking for enlightenment and illumination — of a musician’s creative process, of a CEO’s plans for a dying industry — and the way to do that was to delve deep into questions, as quickly and as deeply as possible. In Harper Lee’s To Kill a Mockingbird, her character Scout says:
“Never, never, never, on cross-examination ask a witness a question you don’t already know the answer to, was a tenet I absorbed with my baby-food.”
That’s great advice for a lawyer, but it’s terrible advice for a journalist, and by extension it’s also terrible advice for a product manager, because we’re not trying to convince people, we are trying to enlighten ourselves.
I read a great piece on the same subject not too long ago:
PM interviews cherish the “jobs for people” section of a candidate’s answer. The part that has them say, “this customer wants x so they can do y.” By doing so, they propagate a competition of who can make up the most arbitrary, yet convincing reasoning. That is maybe a decent measure of intelligence, but not of knowing how to build products. This is a small question, but it invalidates the entire interview’s legitimacy. It transfer’s the focus from product sense, to BS’ing ability.
It would be much more telling to ask a candidate how they would go about discovering those x values. It’s not important that a PM know book case use cases, but rather that they know how to discover the hidden needs of their customer. That is because most people who set out to build anything and really talk to their users, quickly discover that they are building the wrong thing.
This is exactly right. If you go into a piece of development with answers and not questions, the chances are that you’re not going to build the optimal thing for your users. Product management is about making inductive leaps and learning about our users in order to iteratively reduce our uncertainty, and the best way to do that is to ask questions. Lots of them.