We have reached a point of over-validation, and it's costing us A LOT.

What if we were wrong about product validation?

I think we as a community have gotten a bit validation crazy. I see so many people, myself included, get stuck in this never-ending dead man’s land of product validation.

And why not? Who doesn’t want to mitigate as much risk as possible before launching into their product build? We are bootstrapping, after all. There's a lot on the line.

But what if there is a way to significantly reduce the amount of time and energy spent in the product validation phase while still having a very good chance at building something people want and are willing to buy?

I believe there is...

Who am I to be challenging the status quo? Nobody, really. Just a guy who sees an opportunity and hopes that by slightly reframing the way we view the traditional product build structure, we might just be able to make the game play in our favor a tinsy bit more.

Gut instinct CAN be a sufficient validation tool

I think we all know that gut instinct has become a dirty word in our community. We don't have "true validation" until we've got credit card numbers in the bank, right?

While I think this advice was given in good faith and with good intention, I believe that it has ultimately lead us down a path that is significantly handicapping our ability to execute by creating an unnecessarily large barrier to entry.

Now, I'm not saying that gut instinct can completely validate your product alone, but rather, that if we're smart about how we approach the process of product positioning, our gut instinct (along with a few other variables) can get us close enough.

Let me repeat that part again, I said..."close enough". This is crucial, we'll come back to that later.

Okay, enough chatter, let's get to it.

How it works

Here are the steps I took that allowed me to drastically reduce the amount of time I spent in the "validation" phase while still mitigating my risk. None of this is revolutionary, but putting these steps together in this way really helped me see the bigger picture and significantly accelerated my timeline while promoting a bias toward momentum and action.

1. Solving a problem for myself.
It starts with picking the right problem. I decided that if I was going to build a product (especially one where I was going to lower my standards for validation) it would need to solve a problem that I had intimate experience with (more on why I felt this was important in a bit).

Example: As an agency owner, I had a number of problems and obstacles that I faced on a daily basis. When I ask myself what my biggest and most stressful tasks were, it was clear that the thing I hated doing most in my business (the thing that brought me the most anxiety) was coming up with a price for a website project and then building an SOW document for it. The uncertainty of not knowing if I was pricing too high (potentially not winning the project), or too low (unnecessarily cutting into my profits), was extremely painful. Not to mention, the amount of time and struggle that went into building SOWs for projects not only killed me but due to procrastination from that resistance, cost me a lot of money, too.

I think I'd found my problem.

2. Find others solving the problem.
Once I defined the problem I wanted to solve, my next goal was to find other pre-existing solutions. As we all know, competitors are a good sign that you are barking up the right tree and since I'm cutting down on time in validation, this was an important step to take.

Example: So I did some research and found a number of rough ballpark competitors.

Tons of project management software (not what I’m doing). Tons of proposal software (still not what I’m doing, but closer). And then, I finally found a handful of tools that hit relatively close to solving my problem, though none exactly the way I wanted or needed. That was a good sign.

At this point, I know, you're saying, "yeah dude, we all know this" but just stick with me.

3. Defining a unique take on that problem.
While I could see how some of these tools might've been helpful in solving my problems, none of them quite did so in a way that was perfect for me and I spotted a few glaring holes:

A) With each of the tools you would have to still create the Scope of Work yourself (ie manually, using your own brainpower to fill out the tasks and assign hours and costs to everything). They gave you the tool to build it, but everything else was still up to you. Opportunity #1!

B) None of these tools helped you actually come up with a price for your project. Going through the hassle of building the SOW was only half the problem for me. What really caused anxiety was my lack of certainty around what to charge for a project. None of these tools offered that. Opportunity #2!

4. Validation & Opportunity:
It was clear that there was a market for SOW building software, but it was also clear that none of these tools solved the problems in the way I wanted them solved. This is exactly where I wanted to be. From this, 2 things were accomplished that would allow me to move on to the product build with ENOUGH (there's that word again) certainty to justify moving forward.

1. It was clear that the base/core concept of my tool -and the problem it solved- was valid. Given the success of competitors in the space, it was obvious that people had trouble building SOWs and were willing to pay to make that process easier. At the very least, my tool can and would compete at the level of these other tools. This, and this alone, was enough validation for me to get started. But...

2. I also was able to identify 2 opportunities for differentiation and added value for my target audience. These areas and features were above and beyond the core feature already validated. Icing on the cake, as it were.

The Takeaway: Because of the validation of my core feature and pain point (noted in #1), I did not bother with validating the assumptions behind the added differentiation features in #2. This was a strategic and intentional decision and a risk that I believe more of us need to be willing to take.

5. Protecting the downside:
Yes, there is a risk here. I'm moving forward building a product that I have not “FULLY” validated. But not all risk is bad and I'd argue that this was a good risk to take.

Here's why:

1. In exchange for this risk, I get speed and momentum. Having been a bootstrapper for a while, I have grown to value action over everything, and if assuming this risk means that I'm more likely to move forward, then I'm comfortable with that. Especially because...

2. I can always pivot downward and compete at the core level of the competitors that are already having success in the market (the standard SOW builders). Is this ideal? Of course not, you want to be able to differentiate your product. But it's much easier to pivot for unique differentiators than it is your core concept. Worst comes to worst, I could test alternative product differentiators if need be without scrapping the product entirely.

3. Lastly, my gut instinct assumptions (that pricing anxiety and resistance to tedious task-building, are real problems) is not worth nothing. Because I chose to solve a problem I'm intimately familiar with, I gifted myself a base-level of validation credibility even though I did not completely externally validate those problems.

At the end of the day, external validation is always going to give you less risk and more certainty.

My point here is that the amount of certainty we require might actually be less than we think. This is especially true given the nature of how easy it is (relatively speaking) to build a saas these days. We are not committing 2 years and hundreds of thousands of dollars to build this tool. As such, the risk is inherently lower, making it easier for us to justify a bit less certainty than in the past.

As a result, I would argue that the reward of speed, momentum, and action in many cases outweighs the benefits of the thorough validation practices that have become common in our community.

At the end of the day, do what feels right for you, but I'm simply suggesting that there might be another way to look at the validation process and it might be the difference between you building the tool that changes your life, and not.

Thanks for following along, looking forward to hearing your thoughts on this topic.

Remember, the goal isn't to have 100% certainty that your product will work, it's about finding ENOUGH certainty to get started.

Hi I'm Shane, founder of ScopeConcierge, a tool that helps agencies and freelancers quickly scope and price their digital projects. http://scopeconcierge.com/