These days, most companies are expected to have some sort of digital or connected solution. Even industries that have been paper-based or seem removed from connected solutions are feeling pressure. Their executives may think they need a solution, but what should it be? And how do you determine if software is the right solution?
It is very, very easy (and expensive) to build the wrong thing. Here are some high-level steps to help determine if software is the right solution.
1. What is the real problem?
Any product book you can find (or any good one) begins with this key activity. Before considering solutions, a company should define the problem they are trying to solve (e.g., improve customer acquisition, increase retention, drive more sales) as well the problem they are solving for their customers.
The first problem might be something like, “We have trouble acquiring new customers.” The company may then decide they need a flashy app or tool to acquire customers. However, the real reason they’re having trouble acquiring customers may have nothing to do with lacking software.
The second problem, the customer problem, is a lot more nebulous and difficult to define. This is why people tend to jump right to the solution. However, starting with the solution tends to create bias and reaffirm what you already were setting out to “test.”
So instead of saying, “Customers want better search capability,” a better problem statement might be, “Customers find it difficult to find the information they need.” The latter doesn’t lock you into a specific type of solution. Instead, it enables the team to be more creative in solving that problem.
Validating these problems leads you to the next two activities.
2. Who is the customer?
So many times, I’ve heard people say things like, “This could help all our customers!” Sure, that might be true, but I’ve found that if you’re not specific in who your customer is, then instead of building something that helps everyone, you end up building something that helps no one.
There are many ways to define the customer, such as developing personas or using the “Jobs to Be Done” framework. It’s also a good idea to define an ideal customer profile that you can keep in mind at each step of the process.
Focus is key, especially early on. Solve the problem for one customer set, and then expand to more.
3. Are you just copying the competition?
In my previous job as a Product Manager, I used to hear, “Let’s just do what so and so is doing, but better.” It’s definitely important to do competitor research and see which features others offer or lack, but that’s only one part of the picture.
If your competitor already has a released product and you’re just starting, chances are, by the time you release your product, they will have moved on to the next thing. I’m not saying it doesn’t make sense to try and disrupt a market, but it’s more beneficial to talk to the customers using your competitor’s product and find out what they like (and more importantly don’t like). Then you can apply that input when developing your solution.
4. What do real customers think?
Throughout my career, customer research is the one that has caused the most controversial conversations for me. Sometimes, when I pushed to talk to current customers directly, my sales, customer service team, or even executives have said things like this:
- “We don’t want to annoy our customers with more meetings; you can’t talk to them.”
- “The sales team knows the customer better than they know themselves.”
- “Ask the customer success team; they talk to customers all the time.”
I understand why these suggestions are common. It is, of course, easier to talk to colleagues at your own company rather than scheduling time with a customer. However, a second-hand account of what the customer needs is never going to be as good or accurate (or without bias and agenda) as a direct conversation with them.
In a B2C situation, there are many ways to find user research candidates. Tools such as userinterviews.com can help you find a large group of people to interview. Try to talk to potential new customers, customers who have left, and customers who are using your competitor to get a well-rounded data set.
Once you have a hypothesis/problem statement, work to validate that with customers. If it’s wrong, don’t feel bad. You may have just saved your company millions of dollars.
5. What does success look like?
After all of those activities, if you decide that you should be building a software solution, remember to use metrics! Here are some items you should discuss and figure out before you release:
- Are there any factors to consider for success?
- How are we measuring success? And over what time period?
- What would be the desired outcomes for the business?
Make sure everyone is on the same page with the ways you are measuring success. It’s never pretty when the product team thinks one thing is a success, but the sales team thinks otherwise.
If you’ve gone through these exercises and found that your company problem and customer problem really didn’t warrant a software solution, that’s okay. You learned where to focus efforts (e.g., in marketing, sales, operations, or customer service) to actually solve the problem you have vs. spending money on a software solution for the sake of making software.