Start Small
How to reign in your big idea and make progress at the outset.
Welcome back to Jab’s Lab, my weekly musings on startups, tech, business, and life. I am so grateful that you are taking the time to read my writing.
With the intro post out there, I feel good about my momentum. But let’s see if this second post is my Empire Strikes Back or more like a Zoolander 2.
Today is all about starting small.
This can apply to almost any creative endeavor, where the hardest part is often picking a small piece and committing to building and testing it, even if it is not perfect. In this post, I’ll be talking about how starting small applies to turning a high level idea into a product, startup, or business.
One of my great pleasures is talking to aspiring founders and hearing their ideas for new tech products. I am always happy to field questions about technical viability, competition in the market, and compare it to what already exists. This is how I responded for years when people brought ideas to me. It wasn’t until recently that I began looking at these problems differently. I felt like I was shutting too many potentially good ideas down because I wasn’t sure if they would succeed.
The problem with my thought exercise above is that it wasn’t helpful in actually building anything. Sure it can help determine the validity of an idea and weed out the impractical ones. But how do you go from a grand idea to actually starting to build the thing?
You start small.
To me, starting small is finding the minimum amount of value you can deliver to someone that will be worth their time to try. It doesn’t have to be perfect, it doesn’t have to be polished. In fact, it’s better if it’s not. Because starting small is not about being right, it’s about learning from your early customers.
Let’s talk about MVPs. Most people would define this acronym as a Minimum Viable Product, which I think is too ambiguous. I like to call it a Minimally Valuable Prototype. What is the minimum amount of value I can deliver to a customer? This does not have to be a tech product. It could be a tech-enabled service. It could be a database of valuable content. Just build something, anything. And get it out there. If you are optimizing before getting customer feedback, you have already built too much.
Just ship it.
Where should I start?
If you’re like many of the founders I’ve worked with, you have incredible thoughts on what problems you could solve. It’s so easy and sexy to get caught up in "What can my platform do once it's mature?"
Someday, you may have earned the right to solve all of those problems by building a robust platform. But today, you are just getting started, so choose to focus on one problem.
Take your grand idea. Hold it tight. It’s a wonderful idea. You crushed it coming up with this pristine thought. It’s your vision for a better future.
But at the same time, know that your idea is just a hypothesis – a hypothesis of what might provide value to people in the future. It may be right, but it might not be.
Bill Nye the Science Guy taught all of us exactly what to do with a hypothesis: use the scientific method! Let’s design an experiment to see if your hypothesis is valid. This experiment could come in many forms, which I will discuss in future posts, including:
Talking to customers.
Running surveys on prospective customers.
Building a true MVP.
Doing manual steps to make someone’s life easier, and then automating it.
The validation (however small) of your idea is the single best thing you can do to get started. Through these experiments, you will be able to answer the question: Which single problem do you want to start solving today?
How do you start experimenting?
Take your grand, multi-faceted idea in its broadest form, and think about 10 problems that it could solve for its users. This is often a difficult exercise, but get pen to paper on this.
From your list of 10 (if you came up with that many), you can usually narrow it down to about 5 high-impact problems to solve for your potential users.
From these, I would highly recommend finding yourself a friendly neighborhood technologist who can look at the remaining list and tell you which 3 are the most technically feasible in a short time (as always, I’m happy to be a resource for you on this step).
With these technical constraints in mind, pick one problem that you want to solve today.
This one problem doesn’t have to be the best problem to solve, nor does it have to be the most impactful – it should just be one you have a high degree of confidence it is worth solving. But even if it doesn’t, that’s that these tests are for.
In picking this one problem, you are making a hypothesis that “building a product that solves this problem will be valuable to my user(s).” And then you test it until you prove yourself wrong (or right). Who cares if you’re wrong – you’re learning along the way.
The beauty of the method is its imprecision. Sometimes, you’ll start testing an idea, and realize that your initial hypothesis was off. That the way you thought people would use your product is much different than how they actually want use it. Or the problem that you thought you were solving is not the problem that your user needs solving. What a wonderful thing to find out! It’s way better to know early with a small experiment than to spend 6 months building something people don’t want to use.
Every step of the way on this journey, you tweak your idea, and as you do, you gain some certainty about what you’re building. The certainty that you are doing something right (solving a problem that people care about) is worth finding.
Start small. Figure out what problems you could solve. Decide on a problem. Test your hypothesis. Learn fast from your customers. Lather, rinse, repeat. And eventually, you’ll have enough certainty to know that it’s worth building.
Until next Tuesday,
- Cory