One of the most common oversights in a failed product is a failure to know your customers. That may seem an obvious requirement. However, they tend to be misunderstood. We often build a solution without spending time understanding how the users will see it and their needs. It is not the same as building a solution that looks for a problem. This misstep is far more subtle. We have our customers in mind, as we should. Our failure is a lack of understanding.

Know Your Customers And Their Pain Points

Almost any problem can be stated in a way that leaves room for interpretation. It is challenging to avoid this. That leaves us an opportunity to solve the wrong problem or solve it in the wrong way. Think of a simple example involving transportation. A child needs to get to and from school each day. The solution could be to acquire the use of a car so they can drive back and forth. However, a child that is too young to drive will not be able to use that solution. We need requirements, constraints, and context. That requires that you know your customers and how they work. They are more than this one pain point and have multiple needs that provide context around our solution.

Solve The Right Problem

Another example of misunderstanding the customer is automation. We love to see automation for its strengths. It allows us to do things faster, with less room for error and less worry. However, it also can rob us of opportunities to customize a solution or learn by doing. There was a customer that had several manual processes that were done overnight. These seemed like a perfect target for automation. However, the cost to do these was low, and it provided a way to train new employees. Automation would have stolen opportunities for growth and possibly cost more than the current approach. We must look at the big picture to craft the best solution.

Identify The Correct Customer

One of the significant challenges in how to know your customers is identifying them in the first place. This situation is far more common in internal projects than commercial ones. Nevertheless, it can arise for any problem and solution. First, it is essential to recognize that the person signing the checks is not always the user that needs to be satisfied. That is challenging when the signer thinks they know better than the users. Yet, it must be addressed. Pleasing the wrong person or group may be the best short-term solution. However, it can be a reason for failure or lack of use over time.

Next, the representative is not the customer. Do not be afraid to push back and hold the representative to verify statements and positions with the users. It would be best if you were confident they fully represent the users. This situation can come from miscommunication or lack of understanding. Your best way to avoid it is to ensure the team understands the goals and requirements rather than allowing assumptions to persist.

Finally, ensure you are solving the problem for the right user. There can be competing views of a problem. An example is when workers want a job done, but owners need to afford the solution. We sometimes need to find a middle ground, but in others, we have one group to serve at the cost of another. That can be challenging to navigate and require political acumen, but failure to do so can lead to a solution that is not usable.

How Do I Get To Know Them?

There are many ways for us to do customer research up front and avoid misunderstandings.

• Ask them to explain the problem and desired solution in their own words.
• Watch them do their work and include more than just the problem to be solved.
• Plan for regular feedback from the customer (or a representative) as the solution is built.
• Discuss how often the task is done and why that timing is necessary.
• Be open to workarounds and think outside of the box. The solution may be different from what is planned.
• Be a partner with the users instead of just responding to requests.

Signing Off On This Question

The users are another facet of the product requirements. There should be a way to contact or communicate with them, and roles should be identified. While this often gets accomplished during a design phase, it is vital to have it from the start. That allows conversations to get started before any solution pieces get “set in stone” and can be highly useful during many early steps of software creation.

Improve Software Success

We have an e-book that can help you explore all the steps in building software, including a few templates. However, we ask that you share an e-mail address so we can send you a copy. We add you to our monthly newsletter, but you can unsubscribe anytime. Your data is not shared with anyone else. Learn more about our book here.