I love the idea of the minimum viable product. Identifying what is absolutely necessary for launching a new viable product and building it timely with discipline within a tight timeframe is a virtue.
And, as with most virtues, it is not something you are born and die with. It is something you have to study and work a lot in order to build it. Take us with SourceLair for example. In early 2011 we launched an “alpha” version of SourceLair in a university presentation; half-assed, flaky and certainly unreliable. It was merely a proof of concept. Fast forward eight years later, last month was the first time I am confident to say that we shipped an actual minimum viable product; Dojo.
On May 31 we held a sold-out Docker Fundamentals workshop at our office, at which we launched Dojo privately. Dojo provides our attendees with all they need to attend our workshops using only a web browser; slides, private community and a fully featured Docker workspace — no need to install anything.
Even implementing the minimum viable version of Dojo had its fair share of complexity. We had to handle authentication, multiple protocols (HTTP + WebSockets) and even managing multiple Docker in Docker instances and proxying dynamically multiple subdomains to their corresponding Docker container ports.
So, how long did it take for us to implement it? Just five person days. And we did not implement just a proof of concept, but a minimum, yet fully functional, polished product, to make it viable.
And, how did we do it? In a nutshell, we set a goal to achieve with Dojo, then embraced our constraints, set priorities and eventually executed with discipline.
The goal was crystal clear. We wanted to get every attendee up and running within five minutes, instead of spending almost thirty minutes to get everyone onboard, like we used to.
Constraints were crystal clear too. We decided to implement Dojo less than two weeks before the workshop’s day and we couldn’t spend all our time on it, since we had other projects going on as well.
At first it sounded too risky and we almost ditched the idea, but then decided to give it a try and see if we could implement just a proof of concept within a single work day. So we set our priorities, gave that first day a try and after everything rolled like an egg we moved on and implemented the whole thing with discipline.
Priorities
Let’s talk about priorities. Setting priorities was the most crucial and cognitive-heavy part of the whole process. After identifying our priorities, we had a straight path to walk to the completion and launch of Dojo and clear emergency exit points, in case things went south.
Time
Launching in time is what we call Priority #0. If we did not manage to launch in time for the workshop, the product would not be there to use and our whole efforts would have been wasted.
Functionality
Realizing and separating the necessary functionality that identifies the product itself from the functionality that provides added value is key to the its success. This informed us about what we absolutely needed to implement for Dojo to make sense. More specifically, if we did not provide a fully-featured Docker terminal and instant passwordless sign in, we would totally miss the point to onboarding our attendees frictionlessly.
Experience
A minimum viable product is not a half-assed product with crippled experience. It’s just exactly what we need to make our point. What is being shipped as part of it should always have considerate and polished experience — from its typography to response times.
Non-priorities
As important as it is identifying your priorities, it is also identifying your non-priorities. As with every new product idea, our brains were experiencing an idea-orgasm. More and more ideas and possibilities would pop up about what could be part of Dojo — many of them were so great that will likely ship in next versions.
Extensibility
In general, extensibility is a really important part of software design. At this first stage though, it was a no-go. The whole thing might be proven a flop after the workshop, so we decided to put the effort into making things extensible in the future. We even preferred <style> tags to a sexy Webpack or SASS bundle and wrote just ten lines of JavaScript in a <script> tag 😮!
Performance
Working on optimizing performance sounds so sexy… and nevertheless it can be such a bad decision when not done at the right time. If we worried about that 100ms Docker terminal lag at first, we would have not managed to ship our product at all. This is us adhering to Donald Knuth’s famous (and often misunderstood) quote:
Premature optimization is the root of all evil (or at least most of it) in programming.
Scalability
Building Scalable™️ products and business models sounds even sexier than building performant ones. Dojo was built to be used simultaneously for just a handful of people. Why even deal with making it scalable to hundreds of thousands? Instead, we opted-in to use flawed monolithic architecture that let us ship it in less than a person-week.
The last part of the equation is sticking to these priorities with discipline, implement just the damn thing and be prepared to take the emergency exit at any point and waste no more time on it. This is something that will not work out of the box for the most. It takes time and many repetitions to build that mindset that will bring the work under your control and not let you be under the control of all these intimidating uncertainties and exciting ideas, when building something new.
Being able to build and ship a minimum viable product is the virtue of embracing constraints, setting your priorities within these constraints and executing the plan with discipline. It does not mean making expenses on quality. It means making compromises and on functionality and being smart about how you spend your time building it.
It’s the most useful virtue for the first steps of a new product, which are the riskier ones for its success. Work on it and build the damn thing!
Did you enjoy this article? If yes, it would mean a lot if you hit the green heart (💚) on the left to let us know how you liked this article!
Also, if you are interested in giving Dojo a try, take a look at our upcoming workshops on Docker and JavaScript!
