Never answer the same question twice

If you want to be a bad product manager, keep answering the same questions over and over again. Part of your job is to be responsive and to answer questions from developers, sales representatives, and customers. Make sure you’re available and can help, since people appreciate it when they can get an answer quickly from a product manager. The more time you spend answering questions, the more credibility you will gain and the more they will appreciate you.

If you want to be a good product manager, try to never answer the same question twice. Rather than just answering the question, see if you can do something to prevent the question from being asked again. Developers, sales representatives, and other internal stakeholders probably appreciate your responsiveness. After all, that makes less work for them! Instead of them having to try to find the answer themselves, they know you can just do the work for them.

Answering questions is great for the person asking the question but bad for product managers because it is a drain on productivity. Of course these questions need to be answered, and building credibility is important, but there are much more efficient ways to accomplish both.

Pragmatic Marketing teaches that product managers should be focused on n = many, not n = 1. N = 1 is doing a task for one specific purpose, like answering a question for one sales representative, preparing an information sheet for one customer. N = many is doing a task that can be reused over and over, like preparing a FAQ document for all of the sales representatives, or creating sales support materials that can be used with many customers.

Every time you are asked a question, ask yourself these questions before responding:

  1. Is this something that the person asking the question should already know?
  2. Is this a question that others may have and I may get asked again?
  3. Is there a way that I can never have to answer this question again?

Once you have done that, the first thing to do is solve the immediate need, but then quickly follow up on #3. Create a FAQ if one does not exist, or add the question to your existing FAQ if it is not included . Update the Help section of your web site. Post additional information to your intranet. Create an email to distribute. Make sure that you never get asked the question again; when it comes up, people should be able to answer it themselves.

Of course, they will turn to you again. Maybe they forgot or did not know that there was a way to answer it themselves. Instead of ignoring the question or berating them for not knowing where to look, politely answer the question and remind them where they can go to get the answer in the future. Provide that stakeholder with a link to your intranet site with product information. Send the developer to the strategy document that addresses the issue in question. Remind the sales representative about the product wiki. Give the customer a link to the web page that provides the information they need.

The more you do this, the more it will start to sink in, and soon much of the time that you spend repeatedly answering the same question will instead be spent doing things that a product manager really should be doing, like visiting customers and planning your roadmap and updating your strategy. Being known as a product manager who can answer any question is good; being known as the one who has already answered them all is even better.

Translations available:

6 thoughts on “Never answer the same question twice

  1. Also it encourages an attitude of problem resolution rather than problem reporting. An answer found through a sales person’s efforts via FAQ’s posted by the PM will have more sinking effect.
    We are pleased when we discover things by ourselves.
    Nice post.

  2. I started life in Tech support and it took me some years of answering the same questions to learn this lesson. Make the knowledge available and don’t just answer the question, educate the asker. It’s the whole teaching the man to fish routine.

  3. Great post.

    I’ve gone on a number of job interviews where when asked to describe myself I would typically say (tongue-in-cheek) that I’m lazy.

    Of course I would need to explain myself and it would give me the opportunity to talk about what you’ve written about. I don’t continue to do the same thing more than once. If it’s a question, put it in a wiki. If it is a process, figure out if you can automate it.

  4. When I took over an application analyst role abou 10 years ago, there were common routine customer issues that took days, or even weeks, to resolve. The issues fell in two categories, user error, and requiring a simple 10 second DB process to fix. I created a FAQ, attached a couple of “3 Easy Steps to….” emails for customers, and semi-automated the process so these problems would be solved in a matter of minutes. It was so obvious….

    More recently, as a BA and Scrum Master, I use graphic one-pagers like Swimlanes, Decision Tables, Workflows and Activity Diagrams to “get everyone on the same page.” It is amazing how those simple one-pagers melt away the stakeholder confusion and eliminate the need for repetitive conversations.

Comments are closed.