The Lean Startup movement popularized the concept of Build-Measure-Learn (BML) as a means to reduce the risk of the creation of new products and businesses. The concept is simple: build a Minimum Viable Product (MVP), measure the product’s effectiveness in the market, derive critical validated learning, and then start the loop all over again. In over a decade since it was first popularized, Build-Measure-Learn has been applied successfully across thousands of organizations, from large enterprises to early stage startups. I used these concepts successfully in my own startup, running continuous experiments around the product, the market and the business model to form CloudHealth Technologies.

But what is often overlooked in the implementation of Build-Measure-Learn is the importance of cycle time: the average time it takes to make a single pass through the three phases. To better understand cycle time, we need to go back to the origin of Build-Measure-Learn: the writings of US Air Force colonel John Boyd. In 1976, Colonel Boyd wrote Patterns of Conflict, which provided the foundation of what would later become known as OODA (Observe Orient Decide Act). The concept was that by following a deterministic process - observing, orienting, deciding and acting - a military force could react more quickly to unfolding events and thereby get “inside the decision cycle” of their opponent. These concepts would be later applied in the second Gulf War, and brought into the world of technical entrepreneurship by the entrepreneur and Stanford University professor Steven Blank. But somewhere along the way from OODA to Build-Measure-Learn, we focused on optimizing for the iterative process over the speed with which we execute it. With OODA it was clear: if you want to disrupt your enemy, you need to make informed decisions faster than your opponent, allowing you to put them on the defensive and control the outcome. But when OODA was adapted to Customer Driven Development and eventually Build-Measure-Learn, somehow this sense of urgency was lost.

Cycle time is essential to any successful Build-Measure-Learn process. For example, it took me 10-12 cycles through my own BML process to have a viable business. It took another 45-50 cycles to take our early product to what venture investors call “product market market fit”: the ability to repeatedly sell and deliver a product to a target market with predictable results. In elapsed time, the former took about four months (~2 weeks per cycle) and the later 13 months (~1 week per cycle).

As an entrepreneur and/or product leader, you are the metronome for your BML process, and set the pace by which your team moves through its loops. Some considerations you need take into account when setting your cycle time include:

  • Complexity of the critical assumptions - Each loop through your BML process is intended to derive validated learning around critical assumptions. For example, you might be testing the applicability of a set of features for a target market, or the viability of your proposed pricing & packaging. The higher the complexity of the unknowns, the more time it will take to iterate through the process.
  • Complexity of the MVPs - As a general rule, it is important to focus on the M in the MVP. Too many times I see people spending months to deliver an MVP product that could have been done faster with a simpler solution. For example, for my first experiment in delivering cost optimization for the cloud, instead of building a software product, I chose to make myself the product. I engaged five companies in a consulting service in which I used my time, spreadsheets, custom scripts and anything else I could get my hands on to deliver a “product.”
  • Time to business objective - You are driving through a BML process for a reason: to achieve a business objective. When I first started my BML process at CloudHealth, it was to launch an initial viable business and product. Business objectives have constraints. For example, as a self-funded business venture, I had a limited amount of time I could go without an income. To accommodate this, I adjusted my cycle time based on a projection of how many iterations I thought I would need to achieve the business objective. Note: there will always be inconsistencies between iterations, and thus you will need to adjust incrementally between cycles.

Managing your cycle time allows you to control the two greatest enemies: risk and time. The wrong cycle time can result in failure. For example, if I had driven to a cycle time of a month instead of one week to drive to product market fit, we might have taken four years to achieve this milestone instead of 12 month - thereby missing the market opportunity, and almost certainly have become one of the many failed cloud management startups in our industry.

As a product leader, it is critical you leverage the powerful tools at your disposal - e.g. Build-Measure-Learn, MVPs, Lean Startup methodology. But it's also critical you set the pace for your learning to ensure you maximize your chance to achieve a successful outcome.