Episode 3 — How to use your target audience to validate your SaaS product idea
We know what we're going to build, or at least we have an outline of the tool we're going to make plus, we know for whom we're building and the pain we want to solve.
Decent.
Before diving into the details and getting caught up with names, domains, wireframes and prototypes, we need to uncover the things that will kill us in the future.
We need to understand and defend against some arguments that will prevent our product from being a success.
We call these 'The reasons not to buy.'
Reasons not to buy include:
- We don't need it (you really messed up)
- You can't prove it works / I doubt the value
- I don't understand it
- It's too expensive
- It's too complicated
- It's too much hassle to implement
- If it goes wrong, I'll get fired
- The competition is better
- We're already using the competition
- We have an internal solution
- We don't feel good about you
etc
By identifying and addressing as many potential reasons for customers not to purchase our product, we will significantly increase our chances of developing a desirable product that people are willing to pay for.
Ideally, if there are no apparent drawbacks and everything appears to be positive, that would be perfect!
Hence, our focus should be on identifying and examining various factors that could potentially hinder the success of our product in the minds of our target audience.
Once we have compiled this list, we can utilise it as a guide to inform the design of our product, including its features, as well as how we position and price it in the market.
I cannot stress enough the crucial nature of this step. It's like mission-critical, with bells and whistles. If you attempt to address these concerns as part of a marketing exercise after developing the product, you will find yourself either vulnerable or in serious trouble.
By that I mean, out of money and looking for a new job.
Honestly, the latter is more likely.
If you have a marketing department, they'll hate you. If you are the marketing team, you'll hate yourself.
Trying to use marketing to dig yourself out of a hole because of your lack of foresight is a terrible place to be.
Trying to find a way of presenting your product in a positive light when you finally realise they your competitors have you pipped in every way is not only hard, it's disingenuous and if you're anything like me, would nibble away at you.
Going to market with conviction and a real belief in your product is better.
So. Much. Better.
It's been about fifteen years since I attempted to launch a SaaS for the very first time. I needed a deeper understanding of behavioural economics, which I had yet to develop, and I followed my gut instead.
Compounded by the fact that I was excited and keen for world domination, it went as well as expected.
The following is what happens when you're All-Passion-and-No-Planning.
- Decide what kind of thing we'd like to make
- Look at some other products and decide how we could 'make them better
- Find a .com domain name
- Find a cheaper .com domain name
- Settle for a .io domain name
- Write a loose feature list and start building
- Realise that you could make it do so much more!
- Increase the scope
- Increase the scope a bit more
- Abandon the MVP
- A long, long time later have a working product
- Whip up a website listing all the incredible features without any audience targeting or compelling pain-solving content.
- Wait
- Realise that you could have built it more efficiently
- Rebuild it again
- Wait
- Despair
- Post on Linkedin
- Sink money into Paid Ads
- Wait
- Reduce the price
- Wait
- Start loosely blogging about your industry
- Make a video for YouTube
- Despair...
I like to laugh about this now, and if you've been there, I raise a sympathetic glass to you. Lessons hard learned and all that.
I could have avoided this if I'd identified every way to kill the project before I started.
This Time, I'm Killing It
That was then and this is now. Older..Wiser. As per the (new) norm, I created a spreadsheet to list every reason I could think of that would kill this project.
Then, when I had as many reasons as possible, I asked our potential clients what would kill it for them.
I specifically phrased the question: "if we were to build (Insert positioning statement from Episode 2 here), why would you NOT buy it?"
Here are the results for our Self-Help Triage Support Bot Thing (Working title!).
We need to build a product that.
- It makes self-help so intuitive that fewer people talk to support agents.
- It must be straightforward to use, with little to no learning curve. Sales, marketing and customer support teams will all want to contribute to the content. These teams are incredibly busy, so we must make it easy for them to all contribute.
- It must not add another continual burden to the aforementioned overworked teams.
- It must be so simple that a child can use it (from the customer's point of view).
- It shouldn't try to do too much. There are already tools on the market that can offer on-page chat-based help but they are costly. It would be better to have a lightweight 'support triage' system that intelligently routes users to the information they need.
- It should not be expensive. Less than $20 a month.
- It must be reliable. If it goes offline, users lose a help path and will gravitate to support agents, generating a support cost.
- It should use as little free text as possible or be smart enough to handle customer support enquiries without getting 'stuck' and defaulting to 'you'll need to talk to an agent'.
- It needs to prove its value. We want to see how effective it is at helping people before they require a support agent).
- It needs to integrate with our existing support systems.
- We're going to want to try it for free.
I also snuck in: If you were going to search on Google for this solution, what would you search for?"
This question lets me know what kind of product our audience thinks this is.
Is this a self-serve customer support tool or a tool to reduce support agent costs?
I can use this as a jumping-off point for some marketing when we get to that.
More of that later.
So, there you have it. If we do all the above, we identify and start to design againt the many reasons not to buy.
Plus, we now know what we're building, who we're making it for, what our clients think we're building, what pain they want us to solve and what things the product absolutely must do (or not).
So, is it time to start thinking about a name and hunting for a domain?
Nope. First we need to see if there is even a market for our idea. Come and see how we do that in the next episode.
— Mark
Member discussion