How I Built a Company the Lean Way -- by Using the Scientific Method Starting a company is one of the most irrational acts you can do as a human being. That's why employing hypotheses and experimentation is crucial.
Opinions expressed by Entrepreneur contributors are their own.
In the past five years, the cloud management company I founded has grown from a one-person business into a global employer of over 300 people. Recently, VMware, the most important provider of infrastructure and technology in our industry, purchased us -- an exciting milestone as we look to the future and continue to execute on our vision.
In spite of all the twists and turns I've experienced, there's been one thing I did right in the early phases of building this business: committing to continuous experimentation.
When I left my previous company, I had an idea of where I could bring the most value in the market, based on my previous experiences in cloud computing. But I'd also been inspired by Stephen Blank's The Four Steps to the Epiphany and indirectly by the Lean Startup movement. As a result, I knew I would start my business from the top down: by devoting myself to a market (cloud management) and to the scientific method for entrepreneurship -- dispassionately testing all assumptions and hypotheses, and following where they led.
So, where did I begin? And where do you begin? Here are the steps.
Develop your initial hypotheses.
The process of entrepreneurship starts with a set of hypotheses to identify the product or service you will bring to your customers. A good hypothesis is that it answers critical questions regarding your initial business concept that can be proven only through experimentation.
I started my own journey by putting a poster on the wall and using sticky notes to capture the critical hypotheses I needed to test. Every two weeks, I selected a set of hypotheses and designed experiments to prove or disprove them.
En route, I thought about the ecommerce company Zappos -- a supporter of the Lean Startup movement --and its initial hypothesis that people would buy shoes online. For the file-sharing company Dropbox, the hypothesis was that users needed a radically simplified way to share files. For the coffee retailer Starbucks, it was that Americans would embrace the Italian coffee culture.
Design an experiment.
Next, choose a set of hypotheses to test, and design an experiment to test them. A good experiment should eliminate all ambiguity from the hypothesis to the answer. It should also prove or disprove the hypotheses with the least possible investment.
I was inspired at this stage by stories from entrepreneurs like Dropbox's Drew Houston, Zappos founder Nick Swinmurn and Starbucks's Howard Schultz. To prove his hypothesis, Houston didn't invest in building yet another file-sharing app; he instead created a video that demonstrated the ease of use of his idea for Dropbox and how it could be a differentiator.
Similarly, Swinmurn didn't choose to buy inventory for his new online shoe store, instead, he took pictures of shoes. He posted them on a website and purchased the shoes from the store only after receiving a customer order.
Schultz, meanwhile, chose to cram his early concept for delivering Italian coffee culture to American consumers into 300 square feet, inside another retail store.
Experiment and observe.
My experiments ranged far and wide -- from driving an advertising campaign, to creating an A/B test website, to performing customer interviews with large financial institutions, to delivering professional services.
For example, one of my sticky notes asserted simply that, "Cloud cost management is a feature and not a market." The experiment I designed to prove or disprove this statement was built around helping five local businesses optimize their cloud costs.
As an early-stage entrepreneur, you have to be willing to conduct these sorts of tests to determine what works, what doesn't and how you can identify real and durable problems in a market. You need to to take risks, to be willing to fail and understand that you're always learning.
Dropbox's own critical video experiment resulted in its beta user requests growing from 5,000 to 75,000 users, validating critical hypotheses without investing in a single line of code. Starbucks's first store attracted 1,000 visitors per day to a location that had previously never seen more than 200. Zappos's website resulted in actual sales of shoes, which were fulfilled with purchases -- at list price -- from a local store.
Discuss results with advisors.
Before starting the company, I created my own informal board of advisors, who included a venture investor, two technology CEOs, a business development executive and a technology founder. All were dedicated to my success, with no strings attached.
I met with them for coffee throughout the experimentation process, and always discussed with them what I was learning. Having talented colleagues to provide feedback and advice frequently produced new insights.
Rinse and repeat.
Once you secure answers to your first hypotheses, it's time for you to go back to the drawing board and create new hypotheses, design another experiment and test it. A hypothesis without an experiment does no good. You gain the most knowledge when you're testing the ideas you propose.
Start the business.
I equate the start of my company to an experiment I called "the sale." After several months of developing hypotheses and running experiments, I had a good sense of where I could add strong and durable value for customers in the market. But what I hadn't tested was price.
I hypothesized that a prospective customer would need to be willing to spend $50,000 annually -- roughly the average price required to sustain the business model -- on my product, to support the inside sales-driven model I was projecting. So, I designed an experiment around cold calling a handful of prospective customers and trying to convince them to purchase my minimum viable product for $50,000 per year.
In the process of being rejected, I hoped to learn about the additional features these companies needed to justify purchasing a product at that price point.
As part of the exercise, I first spoke with the CFO of a fast-growing technology company. While the CFO understood the problem I was addressing, he had almost no input on features, and no interest in paying for a solution. But then he surprised me by asking for another call the next day with his vice president of engineering and members of his team.
The assembled team not only had deep knowledge in the area in which I had built my MVP, but had already built many of my features themselves.
By the end of the call, the vice president of engineering made the surprising statement: "Sure, we'll buy." When faced with the potential for a sale, the first instinct of every good engineer is to do exactly what you shouldn't: keep talking. Instead, I proceeded to explain how the CFO was hadn't been convinced the previous day, and that maybe the engineering VP should talk to him before agreeing to a purchase.
"Our CFO is in the room right now," the VP said. "We'll buy. Just send us the contract."
As I hung up, my excitement at having a first customer was tempered by the reality that I had no contract to send, nor a business entity under which to extend it. Since my experiment had been designed for failure, I hadn't given much thought to what to do when confronted with success. Thus began my next challenge: creating a business entity and onboarding a first customer -- fast.
Reach a conclusion and communicate it with peers
Starting a company is one of the most irrational acts you can do as a human being. You are taking great personal and professional risk for an unknown outcome. While there is no foolproof way to manage this uncertainty, there is a way to minimize the risk: continuous experimentation in the presence of customers. My company exists as a direct result of a commitment to experimentation, a route you should seriously consider when you start down your own entrepreneurial path.