Ever since we’ve started STOIC, I’ve been asking myself a very simple question:
Can we make it work?
In fact, this question encompasses two separate questions:
#1 Can we make the underlying technology work?
#2 Can we make the product usable for regular people?
For #1, I’ve largely relied on a triumvirate of trusted partners, namely Pascal, Hugues, and Jim. I might have had my doubts at some point, but I trust them enough to know that they’ll eventually figure out a way to make the technology work. And once Yves joined this little group, I knew that we had enough firepower around the table to make it work soon enough. I could not tell how long it would take to solve the most critical issues, but I knew that it would be counted in months or quarters, not years. And today, I know that we’re just a few weeks away from having something quite solid to build on top of.
Unfortunately, there was nobody I could rely on for #2. There are a lot of people within our team and outside who could tell us that things were not good enough, but nobody who could fix it for us, or even tell us in which direction we should go. On that front, we were on our own, and I would have to carry most of the load myself. Fortunately, with François and Florian on deck (later followed by Zhipeng), I had enough resources at my disposal to try quite a few ideas. And with Jacques-Alexandre keeping a watchful eye on everything we did, I had a pretty solid sounding board to check that we were going in the right direction.
But none of that was enough to convince me that we would ever make it. I’ve described this to a few people who came to our Dojo sessions by explaining that the product needed some critical mass of features to become truly effective at supporting the development of real-world applications. And while the number of required features is large (we have the largest MVP ever), it is finite. Unfortunately, the more features you add, the more complex the product becomes. This, in turn, puts you at risk of sitting on some kind of asymptotic curve (the asymptote), whereby the more features you add to make the product effective, the more complex it becomes. And you never cross the line that would make the product usable for solving real-world problems that are actually experienced by its targeted audience.
For the past 26 months, I have lived in fear of sitting on the asymptote…
Here come the solutions. While still relatively immature, this is the concept that will quickly kick us out of our asymptotic path and put us on a fast track to escape velocity (metaphor overload). After careful consideration, I am now convinced that solutions is the missing piece in our puzzle. The missing abstraction. Right between objects, which are too small, and applications, which are too large. Solutions are just right. And the reason why size matters is because it helps you solve the fundamental paradox that drove this asymptotic journey in the first place: if you want a platform to be generic-enough, its feature set becomes almost infinite. But the more features you add, the less usability you get. Therefore, you need a way to add features without reducing usability, and solutions can do that very well, much like what drivers do for an operating system.
This last metaphor is worth pondering. Indeed, one way to describe the STOIC Platform is as some kind of operating system for the business. It’s a system (rather than a platform) that provides all the building blocks for supporting the development of virtually any kind of business application (no Angry Birds 2.0, sorry). And it’s called a system rather than a framework because it does that in a deliberatley systemic way, whereby most components of the system are built on top of the system itself, which by the way is the hardest part of the exercise of putting together a working operating system (think bootstrap).
Well, today, thanks to our solutions, I think that we found the solution to our paradox.
And my fears are gone…
Time for some fun!