Once you have validated the idea, if you can’t code, what is the best option for you: find a technical cofounder or hire a developer?

Thanks!!!

Because it’s a service-based offering, I already knew what my target audience needed. I just had to find out if they were willing to PAY for it. I built a one page website, and reached out to 100 people. 5 responded, 2 turned into clients (the other 3 are still being nurtured – timing etc.)

The difference is, the only resource is my skills. I didn’t need to build anything, I just had to reach out to potential clients. I’m scaling up, sticking with a productized service, with MRR as the key measurement. For anyone looking to validate a service offering, this method could be a good approach. Thanks again Alex!

Your article is perfect for figuring out (a) is there a need/pain. Our SaaS start-up works in the training/knowledge management space which I had been in for 10 years. That’s an advantage of being a non-tech founder – you should have industry expertise and be able to clearly identified the need/pain issue.

I agree with Steven Cohn’s comment below that there’s a different issue in identifying (b) whether people will actually pay to have that need/pain addressed. I 100% agree with Stephen’s ideas to involve potential customers in reviewing prototypes, testing alphas and essentially ‘making them part of the team’ not just to help with validation and deliver a more customer-centric product, but also to start the early sales process.

However, I felt there was another critical validation process for non-tech founders upfront – (c) would the tech solution I had in my mind actually work? I can see many non-tech founders wondering how to actually validate the technical aspects or design features of their product early on when they can’t code themselves. This can be a serious problem when you are developing something new or disruptive (as we were) and there is a risk it just doesn’t work.

In my case, to validate the tech solution, as a non-tech founder I just relied on tools I could use myself. I am very good with Excel, so built a complete mock-up of the product in excel (dozens of sheets representing different web pages). The entire thing was linked, so it could take data in, processes it and demonstrate outcomes. I then sat with 7-8 customers as they used the spreadsheet to observe early UX issues. We did 7 versions of the spreadsheet. It was crude but solved so many early issues and gave us an immediate sense ‘it could work’.

We then moved to more sophisticated testing, again just using tools I already knew how to use. We used an online survey tool to mock-up the data collection part of the product and an eLearning authoring tool to mock-up the output. Again we asked 5-6 customers to give it a go and we manually made it all work together. As a final step, I then used Power Point to mock up draft screens to show how the final product might work. We maybe spent 6-9 months on the above technical validation without writing a single line of code (while still working on our day jobs).

It was only at that point we engaged developers. There was still heaps of UX testing and iterations to follow over the next 12 months, but it was amazing how far we could get with validation of the technical aspects of the product just by using regular tools. Plus all those spreadsheets, online surveys, eLearning modules and powerpoint slides become invaluable for the development team as we progressed.

How many people do you talk until you consider your idea is validated?

When validating a new product or feature, you want to separate validating the Problem space and the Solution space. Basic qualitative moderated interviews as you describe above (whether in person or remote) are a great technique. It is very “validating” to hear a consistent pain point. But then I suggest that you ask for a “commitment” from those same customers. If the pain is great, they will gladly help you. There are three forms of “commitment” that they can provide:
1. Their time for free: review prototypes and test alphas
2. Their social capital: inviting others whom they know to meet with you
3. Their budget: getting customers to pre-pay. This is the ultimate form of validation.

But it is important that you do these steps to both validate the problem and also prototypes of your solution. This is the best approach whether it is for a new product or even a new feature of an existing product.