Too often, we want to start working on a solution in a heartbeat 💓.
Starting On The Solution Too Fast
We start designing. We grab a coffee and start coding at once. Or load up our tools and get that project started. 🏃🏻♂️ Run. Run. Run.
There's nothing wrong if you're doing this to learn by doing, but if you want to build a viable product or just something that solves a problem for you or others, the diving-in-head-first-method might not be the best one.
I get it:
as a coder, I know how fun it is to code a solution to any problem.
But more often than not, this gets you into trouble further down the path:
- Missed scenarios 😕
- Wrong assumptions 😞
- Error-prone implementations 😖
Solve By Focusing On Value First
Prevent those troubles by thinking about #valuefirst: what is the thing you're trying to solve /create. And, more importantly:
WHAT IS THE VALUE YOU CAN PROVIDE WITH THE SOLUTION? 🤔
If you need to test before you can define the value, start with setting up a proof of concept (PoC) using tools that help you to validate your assumptions:
- non-coding / low-coding tools
- Use Excel
- connect services using Zapier to set up a workflow
- validate your idea using a SIMPLE landing page
These kinds of PoC setups can be done quickly and while they aren't going to be the final solution, they WILL prove to you if all the time you're investing will pay off eventually.
It's better to waste 10 hours on an idea proven wrong than 1000 on a working solution never being used
Don't worry about scaling, best practices. Look and feel. 🙅🏻♂️
Worry about testing and validating the solution you want to create and the value it will create for its users.
Actionable steps to do this
Here are the steps I take when I validate the value of my idea:
- Create a simple PoC in code/demo video/visualization showing the main idea of the solution
- Create a simple landing page for my idea (using Carrd.co)
- Get the PoC in people's hands asap and get to test it out by/with them for early feedback
- Tweak the idea and ask for $$$ (if a viable product is your goal)
This mindset isn't earth-shattering: it's what the book The Lean Startup and Pieter Levels' book Make: bootstrappers handbook already describe.
Stop building on assumptions and start validating before you build
Code Hard, Ship Harder
Let me know how you've validated your ideas. Any tools, tips or tricks are welcome!
This article is also published on Medium
Top comments (5)
Agree it's not stressed enough that we should look at taking the lean startup approach to creating MVP before coding is done. Since if you are not trained or learn about the approach of doing this it can be a real pain in the end.
Very true. If you want to learn code, code. If you want to build valuable products, go the lean startup route
I agree and would add that "solving (relevant) problems is the only thing to generate true value".
Thanks for your comment! 🙌🏻. I agree.
Relevancy is a hard one, though. As relevancy is all subjective and contextual to the people involved (both makers and users).
But - in the context of creating viable products - if you find a problem (often the easiest is to look for your own and create a solution to that) it is part of the challenge to check if the problem is relevant enough to other people for them to start paying for it.
If the problem is there, but people don't think it is a big enough problem you won't win.
If the problem isn't really relevant because there are old school manual workarounds that don't cost a lot of time or money, you won't win.
Find a problem that many people can relate to, and wished there was a modern solution to and you might win. It is then a matter of execution:
Some comments may only be visible to logged-in visitors. Sign in to view all comments.