Six hours south of Chicago is Bourbon County, Kentucky—an area best known as the heart of the American whiskey movement. This past spring, my friends and I traveled there to explore the distilleries and, of course, sample some of the best bourbon in the world.
We were blown away by the size of the massive rickhouses where the bourbon barrels are stored, where the spirit absorbs its characteristic oaky flavor over the years. But the images that stand out the most were the pot stills at Willet and Woodford Reserve, where un-aged spirit is distilled from a (mostly) corn mash before it’s barreled.
A still operates by heating a mash of fermented grains. That causes the alcohol to evaporate and separate from the less useful byproducts of fermentation. The key is that the still is responsible for separating the useful bits from what you don’t need.
In a similar manner, product managers take in feedback from a multitude of input channels:
- Interviews with users and stakeholders
- Contextual inquiries
- Market and usage data
They extract what’s important; taking all of that information and zeroing in on the actual problems the users are facing. Then their cross-functional team can develop solutions that are usable, feasible, and delightful, and they can answer the question: “Why is this important?”
So how does that look in practice? What can you do to really drill in on the actual problems of your users? Here are three suggestions:
Talk to your users
Avoid the temptation to simply look at what your competitors are doing and then brainstorm features with your team. While you’ll certainly end up with a product that way, there are a few reasons why that approach is problematic:
Your software will lack any clear differentiation when it hits the market. You’ve created a clone and will constantly be playing catch-up.
Your competitors may be overlooking key needs that they are not addressing (which could become your differentiation if you unbury them). Moreover, there may be aspects of your competitor’s product that users don’t even find valuable. You could end up wasting time and resources because you haven’t validated that people actually need that functionality.
You’ve potentially robbed your team of the possibility of solving the underlying problems in a better way than your competitor. In order to do that, you need to understand the problem and not just the solution.
Teams can work in a vacuum, thinking they understand all of the problems that users could be having and that they are on track to solve them. However, it’s quite possible that your product team thinks and behaves in ways quite unlike your users.
When you bring users into the fold, you uncover deeper issues (opportunities!), understand whether you are building the right thing, and get a greater sense of priority. We need to learn the perspective of the user first-hand, or risk navigating far from that which our users would find most valuable.
Ask open-ended questions. Then explore.
An open-ended question is one that cannot be answered with a simple yes or no. Open-ended questions cause conversations to develop well beyond the topic at hand. When you ask close-ended questions, you shut down the conversation and narrow the focus to what you already know about the subject. You want your users to add the color you need in order to understand what their problem really is.
My favorite open-ended question is: “Why?” Many times a conversation with a user will start with their suggestion of a solution for a particular issue they are facing:
“Can you make these columns sortable?”
Asking why can help us understand the reason they feel the need to sort the column:
“Well, I always start my day by checking for the most recent changes.”
And there is the insight. In this case the user doesn’t necessarily need sortable columns, they need a way quickly understand what the most recent changes are. Now your team can design a solution that solves for that need.
People ask for features that will somehow move them further along the path toward their goal. It’s our job to find out what that goal really is. Once we understand that, our cross-functional team can figure out the best way to deliver a solution that solves the problem.
Be naive. Don’t rush to judgment. Listen.
During the research phase, our goal is to distill problems, not invent solutions. And we certainly don’t want to rush into a solution without fully understanding the problem. If we step into an interview thinking we know it all, or try to impress the user with our knowledge of the domain, then we’ve ruled out learning, and they will be unable to teach us anything we don’t already know.
We have to be curious and inquisitive, and willing to be wrong, because only by broadcasting that can they correct our understanding. Then we can be sure that our solution is based on a correct understanding of the problem. This doesn’t mean that you shouldn’t do your homework prior to speaking with a user. You should absolutely arm yourself with whatever knowledge is available, but you should start your conversation asking them what they know. And dig further, using those open-ended questions. Then repeat back what you heard, to confirm that you understand.
In some cases, I will ask an open-ended question about something for which I think I already know the answer. It gets people talking without the pressure to agree with you (since they don’t yet know your opinion) and validates information you’ve gathered elsewhere.
People have a tendency to be agreeable, so if you ask a question in such a way that it sounds like you are suggesting something, chances are they are going to agree with you, which may be good for a nice ego boost, but not great for building outstanding products.
In summary, the idea behind distilling requirements is that you start with problems rather than solutions. When you do that, you give your team the flexibility to generate multiple solutions and innovate beyond the first suggestion that comes to mind. By talking to your users, asking open-ended questions, and avoiding a rush to judgment, you’ll extract valuable information that can be distilled into requirements your team can run with.