Your life gets so radically better after you ship something - Patrick McKenzie
We've all had that one idea that came up when we least expected it, but from that moment on we couldn't think about anything else. Whether it was for a problem we needed to solve, or something entirely different, knowing that you want to start a new project is an exciting feeling.
Sadly, most ideas never get to see the light of day. We buy a domain, set up some accounts, spend a night overthinking and over-engineering an MVP that we never put out into the public, fail to collect any feedback, and slowly lose motivation. After a couple of weeks, we completely give up on the idea of putting it out and put it aside, then, after some time passes on, the cycle restarts. It sounds like avoiding this should be straightforward, but too often, that's exactly how side projects are started, and how they inevitably end.
With that said, let's do it a bit different this time around, let's focus on the fundamental aspects of your idea, break it down into actionable pieces to build the absolute minimum we need, and get it out as fast as possible.
🤔 What's the core of your idea?
Instagram started as a check-in app called Burbn, which allowed location-aware photo and note-sharing. After making the decision to cut down on all non-essential features, Kevin Systrom and Mike Krieger ended up with one core feature they wanted to pursue: photo-sharing. For the first two years, the application was exclusive to iOS. And still, the rest is history.
Keeping it simple and focusing on the core aspect of your idea is key to building the first iteration of your product. You might not have to start with every feature you've already thought of, narrowing the selection down to what makes your idea stand apart from an existing product is the important step to going from having the idea to building it.
If we were to build the next Facebook today, we'd have a hard time doing it if wanted to deliver every feature they've released over the years. We'd probably have much more success thinking about which aspect of a social experience we want to improve, focus on that one thing and make it the best possible version, and only then continue scaling if that part worked out.
👟 Is my idea really worth pursuing?
After the initial excitement, you might start to question your idea, doubting that it could really succeed. While it's hard to tell early, there are some good signs to watch out for when deciding whether to pursue an idea or not.
Most importantly, make sure that you're solving a problem. If it solves one of your own problems, even better.
When you're going for a problem that exists, the outcome will be useful. Diving into building something that you're not yet sure people will use might work but leaves you with a lot of uncertainty, and as such is the less desirable path.
You can and should also ask other people what they think of it, this can help to evaluate an idea even further. And you'll never know, if they respond with "I'm actually looking for something exactly like this!", you've got your first user just by that. Sounds good?
🐣 What if I'm late?
If there's already competition for your idea, it might seem scary to pursue. But crowded markets aren't necessarily a bad thing, they validate your idea to a certain degree. If someone else also decided that it's worth to build this certain thing, chances are high that it's actually needed.
Of course, building a search engine today will be a tad harder than doing the same thing in the '90s, but it doesn't mean that it won't work out.
If you're in a less crowded market, you should also relax and not give your competition too much credit, as they'll probably struggle with some part that you'll solve. And just by that, you've created a reason for their customers to use your product.
Building something that might partially exist doesn't automatically make it impossible to succeed, there's a lot of great products (Linear, Notion) that have started and keep succeeding even though we've already had task and knowledge management software for decades.
Especially in the world of software, building a product that's better to use than what has been around might even be a selling point by itself.
🛶 Building the first iteration
Now that we've made sure we're solving a problem, and if it has been solved already, doing a better job at it, let's get into building.
When we start a project, we might think of a lot of early tasks that come up, often in the fashion of
- buy domain
- set up accounts
- set up billing
- create account management
- compare potential competitor features
- create landing page
- ...
If we go down that road, we're going to have a hard time. There's a lot wrong with those to do's, starting with all the steps we might not have to do right now. If we focus on what really needs to be done, we'll end up with a fraction of what we initially collected.
Sure, having a working billing and payment system is nice, an automated newsletter will surely be helpful eventually. But right now, what we really need, is the most fundamental version of the product that we want to build. And nothing more.
Don't even attempt to work on anything else except what your idea is about, and once that's done, prepare to ship early and get some feedback.
The inner perfectionist might be telling you, "let's automate this to make it scalable", or "refactoring that part will improve performance", or "I don't want to release something this unpolished". This is less about perfection than it is about anxiety and procrastination, and I've been there way too often.
Building in public has enabled countless success stories in recent times, and shipping early is the first part of getting there. Sure, it might not be the best experience yet, but you might not even know what that looks like. And this is exactly where the next part comes in.
So once again, if we look at our to do's, this is what we should have:
- build a crude, plain first version, include only what's needed to convey the idea
⛵️ Ship early, get feedback
If you're not embarrassed by the first version of your product, you've launched too late - Reid Hoffman
In the past couple of decades, entrepreneurs all over the globe have learned that getting feedback early, not only gives you validation, it's also crucial for iterating and improving on your idea.
Whether it's Paul Graham or the Lean startup with "build, validate, learn", shipping a minimum viable product or a "crude version 1" as fast as possible is the most important step to getting your project rolling.
Don't worry about it being "too early", if it solves the problem or helps you to describe the idea, it's ready. If you spend any additional hours on your product without getting validation or feedback, you might be wasting valuable time building things nobody will use, just because you don't know.
When it comes to finding early users, you might reach out to your peers if you're solving one of their problems, or share it in communities like Indie Hackers. Once you found early users, make sure to give them the best experience possible. This means putting in manual work at first, but you won't ever get better feedback than from your early users, so make sure to delight them.
🌁 Building and learning in public
Shipping early not only allows for receiving important feedback, it also enables a couple of other benefits. For one, it'll keep you accountable.
Time and time again do we say to ourselves: "we'll build this thing". By announcing what we're working on and keeping our potential users informed from the beginning, whether it's through a blog, a simple changelog, or even a plain mission statement with a waiting list if we're still building, we can already get first hints of validation.
Building in public also gives your project exposure. While you could limit the first iterations to your closest friends, why not put it out for anyone to try? This doesn't mean that you have to give everyone access, you remain in control of who to onboard in the early stages. Expanding to an audience of people who aren't your closest relationships might also yield more honest feedback, especially if the idea still needs validation.
Lastly, even if this project might not turn out to be the next big thing, by putting it out into the public, and by collecting and sharing the experiences you made along the way, there's huge potential not only for creating great content, but also to explore different ideas that arise over time, or for people with similar ideas to discover you.
This way, even "failure" can be turned into valuable insights for the next attempt.
🧭 Continuous iteration
Iterating based on collected insights like feedback, metrics, and other pieces of information that help you make decisions in product development has become the default for most teams already, either through the Lean Startup method, Agile, or other processes that encourage working in cycles and improving the product each time you touch it.
The feedback you get from engaging directly with your earliest users will be the best you ever get - Paul Graham
Being able to ship fast and get insights from your early users quickly enables a much better feedback loop, you'll be focused on building things people want instead of following unvalidated thoughts of what they might need.
In return, users that can follow the progress as it's made might become even more passionate about your idea as well, seeing how their feedback turns into reality, allowing them to participate in the development process.
It's not important to work in n-week cycles, or follow a particular methodology step by step, as long as you keep delivering improvements, do what works best! Having a framework can help organizing projects, but depending on your team size, you might not be able to leverage those benefits yet.
📈 Early decisions
When building a product, a lot of decisions will come up. Try to optimize for speed of making decisions instead of spending too much time on deciding things that can be changed later on.
Typical decisions around things like naming and design are a great example. We spend countless hours picking colors and fonts or thinking about witty taglines.
And let's not get started on naming, if you don't have the perfect name yet, be careful not to spend too much time trying to come up with something, as renaming will always be possible.
A convincing analogy for decisions I recently picked up is thinking of them as one-way or two-way doors: Most decisions are two-way doors, they can be made quickly and if necessary, reverted.
Then, there are one-way doors, for which you should take your time, as it will be hard or even impossible to revert if it turns out to be the wrong decision.
Don't confuse two-way doors for one-way doors, especially when starting out, velocity is everything. In the early days, not making a decision can be more expensive than making the wrong decision and course-correcting later on.
😴 TL;DR
I hope you enjoyed this exploration into the early phases of going from having an idea to shipping it. Most of those thoughts have already been explored at great lengths by brilliant minds in the industry, nevertheless, they're fundamental for getting from zero to one.
→ Build just what's necessary to convey the idea
→ Ship it as soon as possible
→ Get early users, onboard and delight them, get feedback
→ Iterate and improve continuously