This article is part of The Preparation Stage section of 📕 Zero to Sold: How to Start, Run, and Sell a Bootstrapped Business.
As entrepreneurs, we are good at coming up with ideas. We envision solutions to the problems that trouble the audience we have chosen to help. We think deeply about a problem, mentally shape a product, and see how much it would benefit the quality of life. Then we get to work and build the prototype, eager to release it as soon as possible.
But just like the problems we work on, we need to validate the solutions we create. Working on an issue that isn’t critical for our customers is risky, as it might result in a product no-one needs. Working on a solution that doesn’t work for our customers has the same consequence. That’s why solution validation is an essential step before we dive into creating the product.
Solution validation is best done in direct communication with your prospective customers, just like when you validated that the problem you were going to work on was a critical one for your niche audience. Call up your prospects again if you can, or find new potential customers, have a chat and ask them a few questions.
The main question you want to answer through these calls is, “Will this solution solve the problem as expected, and won’t it create more problems along the way?“
These calls will be different from the problem validation calls you did at an earlier point in the Preparation Stage. This time, you will have to talk about your solution. As an introduction, explain what it will do, what steps they will have to take, and how you envision it to be part of their work. You will need your customer to understand how your service would be used to set them up for the questions you’ll ask to validate your solution.
In asking these questions, you’ll be making a risk assessment. Usually, when you look at risks that could come from using a particular service, you’d look at the severity of impact, the likelihood of occurrence, and the probability of detection of each potential risk. You’d then list each of the risks, ranking them by some sort of risk class classification. While this is often overkill for single-purpose services, it helps to make sure you build a reliable, side-effect-free product.
To be able to find these risks, you will have to ask a few leading questions and pay close attention to what your prospects have to say. There are two significant perspectives I suggest taking here: workflow impact and jobs-to-be-done.
Let’s take a look at both and the questions you can ask to validate your solution.
Workflow Impact
Your service will never be used in isolation. It will always be embedded in some sort of workflow, one tool among many to solve a particular problem that occurs as a result of an action and that, when solved, will allow for follow-up actions to be taken.
That’s why you will need to find out how your solution will impact the existing workflow of your prospective customers.
Workflows can differ wildly between your customers, but there is likely some common ground. Your job is to find out what that shared experience is and how your solution fits for the highest number of customers.
A good question here is, “At what stage of your workflow will you be using this solution?”
Answers to this question serve two purposes. They will validate your assumptions about where you expected your product to be used. More importantly, they will also uncover the stages of your prospect’s workflow that you didn’t expect your service to be used in. If you find a significant number of prospects mentioning a stage you missed when envisioning your solution, you can immediately get back to the drawing board and compensate for the oversight.
Let’s look at an example of this phenomenon that I experienced when we validated a solution for a FeedbackPanda integration into a teaching portal software that our customers used to teach. We reached out to a handful of customers expecting our desktop-only integration to solve the job of creating student feedback right where they would teach, only to find that many of them did their feedback later in the day from their phones or tablets. If we hadn’t asked for which stage of the workflow they would need our solution, we would have served them insufficiently. As a result, we built a mobile application as well as a desktop-based integration.
It might also be the case that your service will be used at multiple stages of your prospect’s workflow, and it might be used differently at each of these stages. Knowing this will allow you to either focus on one of those stages exclusively or to make your service detect the stage at which it’s used and present a dedicated interface.
At FeedbackPanda, the needs of a teacher varied significantly depending on if they were initially creating a piece of feedback or if they were editing an existing student reports later throughout their day. For new feedback, the focus was on the lesson content and prior feedback that had been written for the student. For existing feedback, the focus was on meta-information like ratings, parent responses, and overall statistics. The display component for student feedback detected this difference of intent and offered different User Interface components depending on the stage of our customer’s workflow.
Looking into the stages of their workflow allows you to develop a better and more in-depth understanding of how your customers handle their day-to-day activities. It will show you opportunities for features and integrations that you may miss if you only focus on the specifics of your product. Of course, you should still build a product that does one thing well. But it won’t hurt you of your service plays along nicely with the tools that are already used by your audience.
Jobs-to-be-done
This brings us to the other perspective you should take: how does your solution impact the Jobs-to-be-done?
The concept of JTBD is a helpful framework to look at what ultimately drives people to do work: not what is, but what ought to be. People are result-driven, and they use technological solutions, not for their intrinsic quality but to get a job done.
It also means that for every problem that your customers are aware of, there might already be a solution in place to get that particular job done. That solution might be crude, and it can take a surprisingly high number of shapes.
Just imagine a scenario like this: there’s a computer in a data center that needs to be rebooted once a day. How many different ways could this job be done?
1) A developer could write a script to restart the computer after 24 hours of running.
2) The intern could walk over to the computer every day after work and press the restart button.
3) The cleaning crew could unplug the machine once every night before they start their work, then plug it back in when they leave the building.
4) Some remote management software could log into the computer every day and reboot it using simulated mouse movements and key commands.
5) The CEO of the company makes it a ritual to do this job every day, showing that they still work on the small stuff.
6) A system administrator role was created to take care of this job and many similar infrastructure-related activities.
Do some of these solutions sound bizarre? Definitely. But you can bet that all of them are being actively employed somewhere to solve a problem as simple as rebooting a computer.
This list also shows that the cost of solving a problem can vary wildly. Automating the job may cost a few couple minutes of your developer’s time, but creating the new role of the system administrator to deal with these kinds of problems suddenly impacts the bottom line significantly.
That’s why it’s crucial to find out what’s in place to solve the problem right now. You need to know what or who you are replacing. Every existing solution has a cost attached. You will need to figure this out for your own pricing.
The example with the CEO is supposed to illustrate that there is are three kinds of cost. So the question you need to ask is, “How much does the existing solution cost in terms of time, money, or damage to ‘the self’?”
It’s excellent if using your solution can save a business some money. But if it alienates a CEO from his self-perceived connection with the company, you will have a hard time selling it to him. Understanding the emotional impact of changing from an existing solution is an integral part of the solution validation process.
Another vital question to ask is, “Could this solution cause friction in unexpected areas?”
The point of this question is to find hidden dependencies. Imagine you’re selling a CRM to small logistics businesses like door-to-door delivery companies. You’re trying to replace the chaotic piles of Excel sheets and Word documents that they have been using to keep track of their customers in the past. Your solution will take care of this, but you’re carefully validating it, so you ask about where else they are using Excel sheets. It turns out that a majority of your customers have an Excel plugin to deal with their fleet management and driver tracking. If your solution does not take into account this integration, it will add more friction to their process instead of removing it.
If you don’t ask how far the current solution to the Job-to-be-done extends into the operation of their business, you will miss critical friction points that need to be addressed by a solution that is worth switching to.
Sometimes, this requires a lot of digging. The person you’re talking to might not be aware of how their colleagues use the current solution, and how far it may have crept into other processes. You will want to talk to multiple people working with the current system to increase your chances of spotting those risky friction potentials.
How to Talk About Risk
From your prospective customer’s perspective, using your service should remove risk, deal with the jobs-to-be-done more efficiently, and make the overall workflow smoother.
To be able to assess that, you have to spell out the risks clearly when you’re doing your solution validation. Remember that this is not a sales call; you’re not trying to trick them into ignoring risks to their business. You’re validating your solution so that you can confidently sell it to your prospects later on. Here and now, you are figuring out how to minimize risk and maximize opportunity.
So spell it out. Engage your prospects in a lively discussion about their fears of changing their system. Ask them for previous painful experiences they had with switching to new solutions, and what could have made those transitions better.
Think about the kind of guarantees you can give your users with your solution. Can you make it reliable enough to offer Service Level Agreements? Do your customers expect those? Ask them about what kinds of guarantees the products they already use offer, and how often they have to make use of that. Depending on the niche, you will find that some of those guarantees are required by the regulatory environment, while in others, they are merely peace-of-mind up-sells done by crafty salespeople.
Throughout your solution validation conversations, you want to project a clear interest in solving your customer’s problems without causing new ones. If you communicate this clearly in each call, you will create goal alignment between you and your prospect: you both want a great solution that makes things easier for the customer.
