It happened! That spark! An epiphany!
You got a brilliant app idea. Or maybe a new concept for a SaaS platform.
As developers, our instincts say to start coding right away and bring this idea to life!
But hang on. Before diving into development, it's crucial to validate the idea first.
Just because you can build something doesn't mean you should. Validating an idea reduces risk, saves time and money, and ensures you're addressing a real market need that someone is willing to pay to solve.
How can I validate an idea? Good question.
Understand Your Target Market
Who is going to use or buy your product? Get ultra-clear on your target demographics. Consider factors like:
- Age, gender, location
- Income level, education
- Values, interests, pain points
Research similar products and analyze their target markets. Figure out how your idea differs and who would find value in those differences.
Conduct Competitor Analysis
Ignore this step at your own peril. What other solutions currently exist? How do they meet (or fail to meet) your target users' needs?
Make a list of direct and indirect competitors. Study their offerings closely to understand positioning and identify potential gaps/opportunities.
If you are going to try to sell to customers in the niche, how credible do you think you'll sound if they ask you about these competitors and you don't know anything about them?
Validate Demand Through Surveys
Create simple surveys using Google Forms, Typeform, or SurveyMonkey. Reach out to people in your target market and gauge interest in your idea.
Ask about their needs, what they dislike about current solutions, and if they see value in your proposed offering.
The questions don't need to be complicated. If there's interest, it'll quickly become apparent.
Interview Potential Customers
Surveys provide breadth of feedback, but interviews offer depth. Have phone calls with your ideal users. Dig deeper into their needs and hear reactions to your idea.
Pay attention to subtle cues like tone and energy levels. If they seem genuinely excited, you're onto something!
Early on, these interviews might be something that happen naturally when you are trying to solve a problem for a customer. Yes, before you've built your product and while you're learning about the market, you'll very likely have opportunities to solve real customer needs -- and they'll pay you for the privilege.
This is part of the idea of doing things that don't scale.
Define Your Minimum Viable Product (MVP)
Determine the bare minimum set of critical features needed for an MVP. Avoid getting bogged down by bells and whistles at this stage.
Your MVP should showcase the core value proposition and resonate with early adopters.
I read a story about an org that delivered on the core value proposition but also added links to every feature they could think of to the UI in the app. None of the additional features were implemented. The links led to individual feature surveys asking those already paying customers what the feature would do for them and how it would impact the value of the product. Brilliant!
Create a Landing Page
Set up a simple landing page explaining your product and allowing for signups. Use concise, emotional copy focused on user benefits.
Promote the page through social media, communities, and target emails. Have a form to collect emails and gauge conversion rates.
You're only interested in determining market demand for the idea. See solid conversion rates? Great! You've got your targeting down. Low conversion rates? It might mean your targeting is off (as opposed to just a poor idea -- though that could be it, too).
Pre-Sell the Product
Consider pre-selling through a crowdfunding campaign or by offering discounted early access. This tests if people are willing to pay for your idea.
Just be transparent if the product is still in development. Manage expectations appropriately.
The goal of idea validation is not to guarantee success, but to minimize assumptions. By testing key hypotheses, you gain confidence to move forward or quickly pivot if needed.
Approaching development informed rather than blindly optimistic will save much heartache down the road. Do the work on the front end to validate demand, understand the market, and clarify the MVP.
Once you've checked those boxes, you'll know much better how to fit the need.
Then (and finally 😅) sling some code!
Top comments (5)
Great recommendations here! I have definitely fallen into the trap of "code first, validate later" because I was excited about an idea only to have it bite me because there are already multiple products that do exactly what I was building.
Thanks for sharing, and keep up the great work!
Thanks, Jake!
We've all been there... or, at least I know I have a few times 😛
I am definitely saving this one to read again whenever that spark happens!
It's so easy to dive into code when starting something new, I have a tendency to spend most of my energy on an idea or concept without validating it, and the result is always the same, everything becomes WIP and I burn out before delivering any value.
Thanks for the awesome post :)
Do most people seriously just write code with the intention of making a product, or having an audience? For me, that's rarely the case. I do it because I want to, because I enjoy it, and usually just to try out ideas for my own amusement.
Code doesn't have to solve problems, code doesn't need to be useful. Code can produce art, code can educate, code can be given away, code can be art. Making pointless stuff is a great way to practice and improve your programming skills, and possibly to come up with totally new ideas.
Making "Useless Stuff" is, to my mind, the most enjoyable, valuable, and rewarding type of programming you can do.
Back in my college days, I had a Statistics professor who explained the odds of winning the lottery to be so remote that it didn't matter if you bought one ticket or a thousand... from a stats perspective the difference a vanishingly small rounding error.
But.
That didn't stop him from buying a single ticket for his favorite drawing twice a week.
Why?
As he explained it, he knew from a statistics perspective that the odds were wildly small. This kept him from making foolish choices and "over investing" on multiple tickets in any one drawing. Though, that one ticket in each drawing was enough to allow him to dream bigger.
It wasn't an investment in the unreasonable expectation of winning.
It was an investment in his dreams.
Making "Useless Stuff" (wonderful article btw) is a wonderful exercise! My flavor is raspberry pi. So, too, is creating a SaaS product while having done no customer research. In my view, these are equivalent. They sharpen the axe and explore the craft. We get to tinker with APIs that we may not otherwise be able to play with professionally.
The article is an attempt to clarify the expectations for the latter.
If the goal is a real deal business, approaching like one is a good idea :)