Especially as technical founders, when designing a product, it’s fun to think about everything it could be.
However interesting that might be for us, it’s important to not get carried away too much when it comes to actually building the product. It’s great to have a vision of where things could go and explore those a bit, but we need to keep the first version small. It’s not easy saying no, especially to your own ideas. Working on whatever you want is a big reason to run a business in the first place, but to increase the chances of success, the order in which you work on something matters.
The type of ideas we like to work on is where the long term vision of a product is sufficiently large, but where the very core, the smallest possible version, is very small (although very small is relative depending on the stage of your company of course). Working on something which could potentially be used by many many users all over the world makes the problem that more interesting to work on for us. But if we want to start up and grow, especially as a bootstrapped business, we need to be able to build the first version quickly.
Thymer is a good fit for us with these requirements. If we manage to get traction and get to the point of lift off, it’s easy to see how we could keep developing the product into a larger vision. Because it’s a very horizontal product, a feature like plugins alone could grow it into a platform, to become a control center of sorts for managing everything you need to work on or organize in your life.
At the same time, the core vision is really easy to describe: an IDE, but for planning/tasks. This alone is plenty of work, so we’re building just the (polished) parts which convey the core of that vision. That this core vision is oddly specific (many people will have no idea what an IDE is) is a good thing. It might be tempting to think building “project management software” is a better idea because it’s a huge market, but it’s very vague, has endless scope, doesn’t offer ways to reach any audience in particular, and there’s nothing unique about it. You can’t launch with a generic “platform” on day 1.
In the beginning you need the focus: reduce the scope on the product side so you can launch faster, and find a niche on the market side to find initial fans.
Building a huge product for everyone from day 1 makes it incredibly hard to succeed. In terms of marketing, paradoxically, if the product is for more people (everyone!), the less people will care. It’s just not exciting for anyone in particular, so it’s harder to reach initial passionate users that way. Plus, building up any kind of momentum takes time. If you spend years building, it needs to be an overnight success on the day you launch because you’re out of time. That’s a huge gamble. Instead, always be launching. When launching something small first and then building more on top while it’s already out there, you can do the momentum building and product building in parallel. There will be many more “launches” this way to generate some renewed interest with every add-on or new development.
On the building side, if you only keep building, you will eventually run out of runway. Even with a large runway, the longer it’s going to take, there’s a chance you’ll simply run out of motivation. And as long as you’re building in the proverbial basement, you don’t train your launching muscle. It’s easy to get bogged down in details which don’t matter that way and drift further and further from the shores of actual user/customerland. You also don’t get any feedback, so by the time you get new insights from initial users, it might be too late to course-correct.
Another risk is that by the time your “perfect” product is finally finished, it’s obsolete, and you need even more time to make it “perfect” again. That’s not to say you need to go on some death march either, or stress out about being the fastest and worry about competition all the time. There’s usually plenty of time, but markets and trends do move on eventually, so taking too long does have risk. All in all, the chance you will really launch something successful in the end will go down.
And yes, we all know some counter-examples of products being built over the course of years to become an instant hit. But that’s a lottery, and you don’t know all the many examples where it didn’t work, where launching that way failed, and the movie/book about its story was simply never written.
Next to the approach for building a single product, this also applies to what ideas to work on. In other words, it’s easier to build Zip2 first before you start SpaceX. Start small, keep it simple, grow from there.