Every day is feedback day for a product manager! It’s a firehose of meetings, articles, documents, and JIRAs. But some times you need that feedback to drive a decision, the anecdata frosting to your data cake, and that’s when you’ll want some structure. Here’s a few examples to use with the “how to get product feedback” process.

Is this a good product idea? Ideas are easy, compared to execution… but maybe this idea has survived the internal hurdles, and is ready to face customers. That means you’ll need to decide what you will ask and how you will structure the resulting feedback. 

• A questionnaire is a useful structure to use when having meetings and interviewing customers. I don’t like to expose that I’m filling out a form while having a conversation, but it sure is handy to have a half dozen questions that I want answers to before starting the call. If you haven’t read Rob Fitzpatrick’s The Mom Test yet, you should really go do that before writing your questionnaire. Some ideas:
  • Is this a problem you have today? 
  • What tools do you use today? 
  • Are you happy with their price and performance? 
  • What are the features you couldn’t live without, and why? 
  • Can we schedule a follow up to watch you do the job with the tool?  
• The answers to those questions go into a document or spreadsheet where you can re-read, summarize, and share them, following line product management process.
• A survey gives you broader reach than synchronous meetings with a structured questionnaire. If the questions are well designed, you’ll even get useful summarization reports directly from the tool. Of course, there are two pitfalls: if the questions are poorly designed then your results are useless, and the asynchronous nature of an emailed survey means you’ll get a low attach rate. To defeat the low attach rate, PMs will sometimes offer a carrot like a gift card or some company swag… but frankly, I’d rather give t-shirts to customers I’m talking with than customers I’m sending a form to. I don’t use this tool very often.

If your idea has made it past the problem finding stage into solution exploration, you’ll need to move from the first questionnaire to a second form. A deck describing the problem you plan to solve, the features you think you could build, and some mockups of what you think the user experience might be is the next tool. This is a tougher meeting to run, because you need to give the customer time to think and imagine using the product. My advice is to build mockups or interactive tests for some common workflows gathered from the questionnaire. A generic tool can look fine until you try to use it for a specific task.

Closely related to “are we building the right thing”… “did we build the right thing”. When you’ve got software for customers to try out, you can’t just toss it onto the waves and hope it floats. You’ll need at least some of the following tools.

1. Awareness campaign. You need a deck that you can use internally and externally explaining what’s new, why it’s useful, how to get it, and what it will cost (including non-monetary things like migration efforts or changed requirements). Parts of this material can be re-used for public blogs and videos after you launch, which is handy.
2. Roadshow. Take your deck and demo to the customer base with a questionnaire. You’re looking for an ideal outcome of someone willing to test it with production or at least lab. It’d be nice to get an internally quotable remark like “this is absolutely great give it to us now please.” Reach for the stars, especially with a new product. Will the customer go public with you and help market the product? Will they take reference calls from other customers? If you don’t ask, you don’t get.
3. White glove synchronous acceptance testing. Depending on the type of product you make, this could mean flying all over the world to install stuff in situ, or it could mean giving them access to a URL and doing a lot of remote video calls. The important part is that the customer spends real time doing realistic tasks with the product. You need to build a flow chart of what you want to have happen, what feedback to get, and work that process. What workflows do you want exercised? What could block those from working, and how will you ensure they don’t get blocked? Who will help with install and on-boarding? Pro tip: if you have field or partner resources who will need to be part of that on-boarding after you ship, then you should engage them into the pre-release white gloves as well. You’ll build relationships and they’ll get training, win-win. Also, make sure you’ve got your own engineering on call during this time, because you don’t have time to waste waiting for support.

If all you use is an awareness campaign, then your feedback tracking can be pretty lightweight… it’s that you did things and then a record of whatever you heard. A roadshow or white glove on the other hand can be very powerful feedback. I like to use a spreadsheet with columns for the goals we wanted to get.

At the other end of the product lifecycle… can we safely deprecate this thing? “Deprecation” is one of those funny words meaning everything from “it may go away in five years” to “it’s dead to us now.” Regardless of what it means in your company, deprecation of a feature or product is a change in agreements with customers and needs some care. Check with legal before going too far, you might have some surprises in specific customer contracts.

• Does anyone use it? Sales data if you have a SKU, support tickets, feature requests and bug reports. Maybe you’re lucky enough to have user analytics, but a lot of enterprise on-prem products don’t. Don’t be afraid to just ask your field engineers and support people in public channels, but also don’t be surprised when that gets you nothing or incorrect data.
• Is there an option for the customers who do use it, or is this the end of the road for that workflow? If it is the end, is that annoying or a churn-production event? 
• Do you need a way for them to migrate this workflow to a new tool? Does it need to  be in product or can be be a script or a document to follow? Note this decision cannot be made by asking the customer “do you need an automagically delicious one button migration”. Rather, ask how much they think this migration would cost them to manually perform. If spending two person-weeks of R&D saves one customer one person-week, it’s not worth it. Five dozen customers a person-week each, maybe so.

Again, this is a decision that’s well suited to spreadsheet logging: who did we talk to, what did we find, and what’s the plan for mitigation if needed.