I’ve been building technology products for quite some time, for both the large scale enterprise and for my own technology startups. A few of them worked really, really well while most of them didn’t.
I got my first serious amount of product building experience working with Johnson & Johnson in the mid-1990’s. They were redoing their international ecommerce tools and I contributed to building backend systems for processing digital orders for doctors and also forward-facing websites to build brand awareness to the Japanese market (color contacts were all the rage, especially for Japanese girls between 12 and 17).
The planning sessions alone took months to work through and we wouldn’t lay any code until those critical decisions were made. Then we’d work against those plans for months and months, shipping the product publicly a year later. And, if we did any user testing I wasn’t aware of it.
At the time I didn’t know any better — this was my universe and I was too young in my career to have an educated opinion of the matter. But, over time, I realized that the way that people and organizations built software was broken and that there was, to put it simply, a tragic and colossal amount of time and effort wasted.
Well, life’s too short to work on products with the hope that they perform as intended — and it’s just not smart business.
But old habits die hard.
My first legit product company was launched publicly in August of 2007 — my mother clipped the article that was featured on the front page of the Austin American Statesman and I was proud of the work that I had done to put it together.
This was a year before the idea of the “Lean Startup” was even introduced to the world and so it took a bit of time to get the project out the door — too long, if I’m to be honest. But, that was somewhat reasonable since I was only able to work on it at night and on the weekends — I was fully and gainfully employed at the largest computer company in the world (at least at the time) and so my days were spoken for.
Also, I applied all that I had learned from the big co’s to build out my product: A huge business plan, a large and robust product and engineering roadmap that included a ton of features that would impress the new users who would undoubtedly flock to the site once it went live. And getting some serious press would only guarantee untold success and riches beyond my most wild imagination, right?
Unfortunately, the months and months of planning and software development did not create a storybook ending and the product was ultimately a failure.
You see, although it attracted a few thousands users it did not reach the critical mass necessary to secure any sort of traction and the server costs were quickly eating away at my savings; I shut the project down, licked my wounds, and began to think about how I’d do it differently if I were to ever do it again.
At the very least I began asking hard but important questions — for instance, I wondered if building a smaller version of the app could have validated my hypothesis and market with greater speed and with less cost…
There are a number of legitimate goals that a new startup has when they first begin laying the foundation for a new venture; these include finding the right core team members, raising venture capital, and building a great product that people actually want.
And although a founding team will attack many of these things simultaneously I believe that there is a definite prioritization within the large-scale list of objectives, the first and most important of them focused on the product and market fit.
This is why building (and maintaining) a high level of velocity is critical as well as doing things that don’t scale are vital ingredients in this process and should be top-of-mind for the founding team.
And, you have to keep getting better and better at it as a new team so you can grow and become the company that you want to be. Moving with speed doesn’t happen just for the first iteration of the product — it happens after the first one fails to land and then after the first pivot and then again after that and after that until you land the proverbial plane.
What we’re learning to do, as a company and as a product team, is to refine our approach and get better a building Version Zeros (or Zero Dot Zeros). I was reminded of this great principle of shipping early and often by another one of Paul Graham’s essays that account for many of the things that can kill a startup (this is quote is long but worth a review):
Companies of all sizes have a hard time getting software done. It’s intrinsic to the medium; software is always 85% done. It takes an effort of will to push through this and get something released to users.
Startups make all kinds of excuses for delaying their launch. Most are equivalent to the ones people use for procrastinating in everyday life. There’s something that needs to happen first. Maybe. But if the software were 100% finished and ready to launch at the push of a button, would they still be waiting?
One reason to launch quickly is that it forces you to actually finish some quantum of work. Nothing is truly finished till it’s released; you can see that from the rush of work that’s always involved in releasing anything, no matter how finished you thought it was. The other reason you need to launch is that it’s only by bouncing your idea off users that you fully understand it.
Several distinct problems manifest themselves as delays in launching: working too slowly; not truly understanding the problem; fear of having to deal with users; fear of being judged; working on too many different things; excessive perfectionism. Fortunately you can combat all of them by the simple expedient of forcing yourself to launch something fairly quickly.
And then, in a recent Macro Article, David Mack of SketchDeck shared his experience of launching while in YC and how the time between launches kept getting smaller and smaller:
We started releasing a series of fledgling products, with an increasing focus on efficiency. Every time we launched something that failed to find any users, we’d go back, work on it, and launch something a bit different. Each time we discarded a product, we’d chastise ourselves for the amount of time we spent on it, and spend less time on the next go-round.
Our MVP gestation time kept shrinking, from three months, to one week, to one day, down to a few hours. In the end it was our most minimal release, a single page that submitted a file and an email address to our inbox, that got us the most traction.
We started to call this release the “v0.”
Ooof. I can empathize pretty deeply with the self-chastisement! You release something “small” and then you realize, post-launch, that you could have actually launched a much smaller version with likely the same outcome!
Consequently, even in the last few months (and weeks) our team here at TOMO has had to learn (or relearn…?!?) this lesson for ourselves. Our first iteration which was tested by 40+ organizations (and 2,000 staff) taught us a lot but we most likely could have built an even smaller version of the app to satisfy our initial user test.
And so as we near the launch of our next iteration I can’t help but wonder if we have over-engineered the product or if there was an easier way to develop a solution that will gather the same quantitative and qualitative results that we are looking to receive.
Great questions to consider but the honest truth is that we won’t entirely know until we release it. Frustrating, I’ll be honest, but it keeps you on your toes and I love the challenge that it naturally presents.
After my first product venture blew up in failure I took some time to reassess my efforts and to introspect a bit about the experience. I learned a great deal about not only building products but also about myself, which I think is just as valuable and important.
At the end of the day I loved the experience and wanted to give it another try but if there was one thing that I had taken from my first attempt was the harsh reality of failure and if this next attempt was going to end up in the same spot I’d rather get there faster and minimize the resources required to test my hypothesis and market.
Thankfully, the codebase that I had created for my first project could quickly be refactored and reused for an entirely different market and so in just a few weeks I was able to release what I can now call an “iteration” on the original concept except for a different market.
Would it work? There was no way to know but at least I could get it out there faster than previously before.
And so I did and 7 months later I launched a “Dating Website for World of Warcraft Players” and it received just as much attention as the first project except that it actually worked — in a few weeks I had tens of thousands of users and within 3 months I was considering acquisition offers.
I eventually chose one of the offers and experienced my first real software and company sale; I think I took my wife out for sushi that night. But even as we celebrated (and as I considered my options from here on out) I can remember distinctly thinking about the events that transpired and how I could repeat what had worked for another project.
Could building smaller, more agile projects be a better way of validating the market and really be a better and more effective way of building technology applications? Or was this just a fluke, a stroke of luck (which it was in many aspects), and nothing more?
At the very least I liked the idea of getting things out faster — it kept me motivated and I had a bit more fun that way.
As we consider our own Version 0.0’s for TOMO we’ve already gotten better at it (imagine that). As I mentioned, our first prototype was a success insofar as we got the feedback we needed from 40+ businesses which has helped us isolate down to a much more discrete and hair-on-fire issue.
But it gets better as our testers helped us identify an even greater opportunity by reducing the process of paperwork and administration down to an instant transaction. We believe that our entry point is simple, discrete, and creates immediate value and we’re excited to get it into the hands of our waiting testers.
If you’re curious, we are first building out a small tool to help 1099 contractors fill out W-9 forms — sure, it’s not exactly the sexiest thing but the solution that we’ve built it pretty darn cool and it’s going to prove a core hypothesis around profiling, tooling, administration, and paperwork.
If you’re interested, sign-up to be notified here when we launch. In addition, I wrote a little bit more about this here as well:
Our quest to continue to build the smallest viable solution, our “Version Zero Dot Zero”, is a never-ending quest until we hit the holy grail of product-market fit.
And, you know what — if this doesn’t land then we’ll try something else until we do. That’s the magic of building product, that’s the magic of building a startup technology company, and it keeps it very exciting.
At TOMO we’re looking to automate paperwork through a unique combination of technology and workflow. If you’re interested in staying in the loop of our progress, follow us on Twitter or sign-up for our global newsletter.