Cross-post from Failcon’s blog.
Letting go of fear to empower continued improvement and how we pulled off 300% revenue growth year over year in CloudSigma.
“NO! We cannot go back to the shareholders and tell them that online music needs to be given for free and therefore the cost of licensing is killing the business. Besides – I DON’T BELIEVE IT! And, we promised them bigger than Spotify!”
That was two hours before the board meeting, and I was the CTO of this music company. We were out of cash, after having burned more than five million US dollar and spent four years trying to sell an online music product no one really wanted to pay for. The business-plan had obviously failed, the financial forecasts were off by infinite factors (from negative to positive) and very little worked on the commercial side of things. Except – sticking to the plan.
Because the founder’s plan and idea was obviously brilliant and the market just not ready for it yet. Besides the co-founders had promised the investors the consequence of the financial plan – millions and millions and so that was what was going to happen.
Six months later, the company joined the deadpool. Millions of dollar were wasted resulting in lot’s of upset shareholders and depressed team members.
It’s a Bullshit Business Plan
Only 10% of startups and projects are successful says the rumor – this number is hard to evidence but looking at venture funded startups, the number is 25% [1] and these are the companies that have been fighting with others to get funded by VCs increasing their chances of survival, so it’s safe to assume that the un-funded startups fail at a higher rate.
So what are these winning companies doing differently? We believe that they simply did not blindly follow a business plan.
A business plan is another word for “I know the future.” In a complex reality full of interdependent vendors and suppliers creating a fast moving market, that is of course not possible. This leads us to the kind of failure I tried in the music startup where I acted as CTO, explained above.
The problem is that business plans involve time projections of where markets and customers go – what the demand will look like in the future while at the same time markets develop and evolve over time.
When founders and investors write and agree on business plans and reflect these in minute financial projections, which their teams get benchmarked and paid against, they are casting hubris upon themselves to think that they have God-like powers to predict what will happen with customer demand in the future. They set their team up for failure due to the lock-in with the implied financial forecast sold to investors and their companies as well because this management methodology of following the plan slows down how fast the company can change and capture the essence of the market.
This only gets worse and compounded by the team itself when they actually carry out the execution of the plan, because such execution often happens disconnected to reality – inside the building, where brainstorms and meetings are the only “reality” check of product/market fit for the team.
Over time, the disconnect between market demand, the business plan and the product itself becomes so deep that yet another startup joins the deadpool – the distance between the market and a product the market doesn’t want is so deep that not even a 99% discount or giving the product away for free will help.
Uncertainty cones, Risk and Product/Market Fit
Let’s first check out the original project management uncertainty cone, by which millions of projects and thousands of companies to this day manage product development.
In short, when an idea is born, there is a high risk of misunderstanding between engineers , the founder of the idea and market demand and this risk can only be mitigated by project management as in:
- Documenting the product definition (a couple of months later)
- Approving the product definition (many meetings and months later)
- Write a requirement specification (easily nine months)
- Write a product design (another six months)
- Actually doing the product (anything from six to 24 months or more)
- Finally accepting the product (often time 2-3 years later)
How we do it at CloudSigma, which we believe is the recipe for our success, is to first invert the uncertainty cone. This means everything gets shifted upside down. When we start out something we are probably quite close to reality but that over time the product idea, the market and the product itself will diverge and go each their way.
This is a provoking thought and counter-intuitive; if a team works closely together, how can its work possibly diverge with the market?
The reason for this is that the team is rarely able to listen to the market over time and has fallen in love with its own perceived brilliance regarding the business plan, which in part outlines the product they are building.
At CloudSigma we believe that success has a relatively simple fabric:
- No one knows the future. Predicting it is arrogant and dangerous.
- Paying customers are the best source of market intelligence a company can ever have.
- Give customers what they want now and they will reward you.
Therefore, we inverse the uncertainty cone, reflecting that when a startup (or a new feature, a new project) is first conceived, there is relatively good connection or fit between the idea of the product and market demand at that time. Over time, however, this gap widens.
The distance between point A, where the market will be in the future, and B, where the product ended up, which determines if the project fails – which we will call Product / Market Fit.
In other words, the trick is to push the trajectory of the product development up to the trajectory of the market demand, and give customers what they want as fast and as early as possible.
Making it operational
In order to push the product development up to the market or customer demand, we have a couple of favorite models, frameworks and tools.
First of all, the obvious: if we want to check if the product is matching what customers want – then lets launch it and see what happens.
For that to be operational reality, we develop all things we do (not just software) by the use of Agile Scrum:
- PLAN the product in a single and simple semantic structure – the user story: As a
I want because - DO the work – in two weeks of work resulting in several user stories done, so we can potentially launch something
- CHECK the work by a demo of the results and approval of the product owner (the customer’s proxy – the product owner)
- CHECK with real user stats IF the new feature or product is being used
- ACT if the “plan” needs to be changed
- Start over
We call these iterations experiments where we test our hypothesis and theories.
We don’t have opinions because we want to avoid “I told you so”, darlings and other problems.
In short, no one can make an argument out of a failed experiment since its nature is: maybe it works, maybe it doesn’t – lets check it out.
Minimum Viable Product
In this way our product development becomes a tightly connected set of trials and errors where we launch minimum viable product improvements into the market and see what reception we get by the demand in a never ending cycle of Plan, Do, Check, Act (PDCA).
The first thing that is interesting with this approach is that there are no long term plans!
Each release is simply a product/market fit optimization of the previous.
Trial and Error – an opportunity to improve
Reflect a bit on this approach: is it not so, that everything we learn in life, we do in sequences of trial and error.
From learning to walk as babies, to complex math skills as young adults, to dealing with friends, love and family as adults. All of it is done in trial and error with no long term plan, because we cannot predict reality nor our own skills before we actually do and check stuff.
That is fine and respected and how it’s supposed to be. We are better human beings and more respected when we show how much we learn.
Except for one domain: Business.
Here we are suddenly required to write business plans that are flawless in predicting the future and model this future in financial plans.
Isn’t it obvious now that the Business Plan is a Bullshit Plan? Every successful startup and founder out there knows it and had the guts to change what they do the moment they see failure in a cycle of plan, do, check, act.
At CloudSigma, we believe it to be self evident that the only way to stay ahead of the competition is to admit that we cannot predict the future and therefore we must understand the market by fast iterations of trial and error. Each error or failure simply being an opportunity for improvement.
Three HR Rules – No Blame, No Complaints, No Justification
Most professionals do not like to be wrong or make errors. They would rather play politics in their companies to blame someone, complain about something or just make up justifications in order avoid the catastrophe of admitting fault.
Therefore in CloudSigma we have three and only three HR rules to entirely avoid this behavior and at the same time make it possible that team members admit errors:
- No one blames no one
- No one complaints about anything
- No justification
In order to empower factual and non-emotional PDCA iterations or learning cycles.
We believe these three HR rules to be key to our success because not only do they empower the agile and lean operational reality, but also the result of blame and complaints is the creation of victims.
Victims cannot win.
It’s about the engine – not the map: The Business Model Canvas
We think of business plans not much differently than planning a road trip around the world by dictating exactly which roads are allowed to be used, at what time, to get from a starting point to an endpoint. Over time and distance, it is of course entirely impossible to predict roadworks, mechanical problems and what ever else happens – and therefore, it is generally safer to understand your car and general navigation than following a plan blindly.
Another problem with business plans is that they consist of 200 pages sitting in a ring-binder in the CEOs office far far away from the team and daily operations, only to be dusted at the occasional board meeting – no one reads it.
This means that the team members most likely will never have had the chance to understand the business they are supposed to be part of building, except for their own little domain (sales, RnD, marketing…) leading to a siloed and eventually over time and scale, a dysfunctional organisation.
In CloudSigma we believe that the 200 page business plan is better replaced with a one page diagram explaining the “engine of the car” – the business model – and proper training in how to drive!
This is effectively done by using the business model canvas covering the nine generic areas which any business must master with excellence in order to sustain long term growth.
The business model canvas is a brilliant way of hanging “what we do as a company” on the wall in your office for all team members to see and interact with on a daily basis.
Because its a simple “one pager” with stick-it notes covering the entire business, chances are that your team members will actually understand and interact with all areas of the business other than their own day-to-day domain, which leads to cross functional teams that automatically finds areas of improvement once they see the big picture.
Results so far
First, our revenue has grown non-stop since launch in 2010 with 300% compounded annual growth. That’s explosive and scary.
Second, Gartner Group has recognized CloudSigma as the innovation leader in IaaS and named the company Cool Vendor 2013.
Third, our now 40+ colleagues have so much fun and just do stuff faster than any other company. Life is good and we enjoy every single day of building our company in a team of high performing energy packed winners.
Share this Post
- Manage Docker resources with Cgroups - May 12, 2015
- Docker, Cgroups & More from ApacheCon 2015 - April 30, 2015
- How to setup & optimise MongoDB on public cloud servers - March 24, 2015
- Presentation deck from CloudExpo Europe - March 17, 2015
- CoreOS is now available on CloudSigma! - March 10, 2015