From Idea To Product
A lot of people have great ideas for products. The challenge of turning those products into ideas is that the ideas are usually only half-baked. What is in your head often comes out a lot different in reality. Things don’t flow as well in the real world as they do in your head.
You can start building without a design, but if you’re designing on the fly, you’re going to spend a lot more time building whatever you’re trying to build. Trust me, I know from experience.
Of course, many of us don’t have the luxury of having a user interface designer on hand. So we download a user interface framework like Bootstrap and start building. And then for whatever reason, we find out Bootstrap doesn’t do some particular thing we want, and integrating that becomes a bit of a challenge. So then we throw that away and try some other framework. And all of a sudden, something that seemed straightforward in our head became a lot more work than we originally thought.
“In the biz”, we like to refer to building MVPs, or minimal viable products. That is to say, something with the least amount of functionality that would satisfy the requirements for an initial release. If you’re building a free consumer app, that strategy works well. If you descope the idea in your head to a minimal set of functions that can be built quickly, it will work to your benefit.
If, however, you plan to charge a significant amount of money for your product, your MVP needs a bit of polish. Nobody’s going to pay $50 a month for something that barely does anything and looks like crap doing whatever it does.
But in either case, you need to build something before you build everything. You can’t achieve feature completion in version 1.0. In my experience, the best products I’ve used tend to be the 3.0 version. Microsoft Word 3.0 was the pinnacle of the application, in my mind. While some useful features have been added in the two plus decades since 3.0, most of it has been cruft and wiz-bang features that marketing types use to justify a paid upgrade from existing users.
Back to the 1.0 thing. When you’re building a product, you need to figure out what your killer features are, and then decide what the bare minimum for each of those features can be built in a relatively short period of time.
When we started out building Assign It To Me, Vince and I each had our own grand visions of a perfect 1.0 release that had everything under the sun and the kitchen sink. We learned pretty quickly that if that was our release list, we would never, ever release anything.
You can’t get to a 3.0 if you don’t have yourself a 1.0.
Less. Much Less.
So we descoped. We pared down the functionality down to the minimum set of things that would make our application worth using.
- Project management. Check.
- Task Level Time Keeping. Check.
- Project health dashboard. Check.
- Task Level Collaboration. Check.
There are a few other things that we included, but all of those features had to be in a minimally viable state.
But that’s not all. When you’re building a software-as-a-service (saas) solution, you need the infrastructure to handle subscriptions. Whoa. More scope. Shoot me now. All of a sudden, there’s more to build than just a client app.
- Web application server. Check.
- Database. Check.
- Secure Payment Processing. Check.
- Multi-tenant architecture. Check.
I think you’re starting to get the picture. It took us a while to get the core infrastructure and base application in place. And we had to say “no” to a lot of features while getting to 1.0 (Vince can attest to all the pushback I’d give him every time he had a good idea for a new feature). The best thing you can do while getting to 1.0 is to push as much as you can into your backlog. Get a solid foundation and make sure you design it to be expandable. But be careful not to overdesign. Just don’t design yourself into a tiny box. Once you get that foundation, adding things gets easier.
Not Now, Later
When we reached 1.0, our application wasn’t the prettiest thing out there, but it was serviceable. It worked, and it did what it needed to do. Making it prettier was easy, because all the hard parts were now in place. Since hitting 1.0, improvements have been coming at a furious pace. If we tried adding some of our latest features to the 1.0 version, we would have never released. Seriously. We’d still be developing.
The path to 1.0 was not smooth at all. We hit roadbumps, got demotivated, made progress and then got re-motivated. This vicious/virtuous cycle is pretty typical, but if you’re looking to make a product, it’s not an insurmountable task. The key is to manage your releases and to be ready to look at some of your less important features and say “Not Now, Later”. Focus on getting something out. If you’re self-bootstrapped, it’s unlikely that you’re going to get an A+ product out on your first try. Pare down your product and aim for a B product instead. It’s much easier turning a B into a B+ and then into an A than it is to start with nothing and end with an A+.
One of Vince’s favorite sayings is “continuous improvement over delayed perfection”. It’s much easier said than done, but if you can find the discipline to adhere to that saying, you’ll get better results faster.