When we talk about starting a project off correctly, we often mention problems to be solved. Unfortunately, solving problems alone is not the path to success.  We must also make sure we are solving the right problems.  Luckily, this task is not challenging and just requires us to ask a few questions.

Who Do We Ask?

The first thing to do is to identify who speaks for the solution.  This speaker is the person or persons that will use the product.  They may be subject matter experts (SME), but more often are an end-user or a representative for the users.  These people are easy to identify because they are the ones faced with the problems we are solving.  These are the people on the front line that will be most impacted by the solution.

For example, an accounting package may be required to have features based on the desires of the CFO.  However, the accountants using the software need to be able to enter and retrieve the data the CFO wishes.  Since the users are ultimately providing the features to the CFO, then they are the ones that will best define the problem.

What Do We Ask?

Once the target speakers are identified, it helps to explore their routines.  Make sure you go beyond daily routines as there are processes that only run weekly, monthly, or annually.  As they share their schedule, there are opportunities to point out pain points and struggles they have.  Ask them what they find most annoying or time-consuming in their routine.  Look for repetitive tasks that can be automated or simplified.

Ask them how beneficial the solution is to them when the interview process is done.  List out what problems are going to be solved.  This list should get a response along the lines of “that will significantly improve my life.”  Be clear about the solutions as far as what it will, and will not, provide.  This is a critical part of setting expectations.

Digging Deeper to Find What We Are Solving

An important part of the interview process is digging down to the core problem.  There are problems that only exist because of the current processes.  Once you ask why something is done you might find a simpler solution.

A favorite example I ran into (and similar to several other situations) dealt with a large report.  The solution was a web application that dealt with data on millions of objects.  The user needed a report that could bring back millions of rows almost instantly.  They were fine with a paging solution, but did not want to accept a solution where we asked for search criteria that brought back less data.

As we dug into the goals we found out that no one actually needed all those records returned.  No shock there.  No human can consume millions of records.  They wanted the records so they could see the count of records returned.  Yes, the end solution was to provide a record count based on any search.  A single number is what was needed, not complex queries and paging solutions.

Never Stop Learning

The moral to this story is to understand the problems to be solved.  Do not simply have them listed and then run off to craft a solution.  Understand the “how” and “why” of the problems.  This will help you design a solution that is useful to the end user and not a complex approach that is too slow, expensive, or hard to understand.  Better yet, look for milestones where the speakers for the project can assess how the solution is going and provide feedback.  It never hurts to check your work along the way.