Last updated at Mon, 06 Nov 2017 20:17:35 GMT

You have heard, no doubt, of the Lean Startup.  If you need a refresher to place the name, it’s a book, but it’s also a business trend with such momentum as to have a website advertising it as a “movement.”  And, frankly, that advertisement is hardly a stretch.  The title and the terms coined in it are on everyone’s lips in the tech industry these days because people at companies of all shapes and sizes want to capture some of that startup magic.

For instance, it’s pretty likely that you’ve heard a process described as “lean,” and it’s a veritable certainty that you’ve heard the term “minimum viable product” tossed around at some point or another.  You may even have heard these terms used correctly.  I say this because the use of these terms has become so ubiquitous among the book’s readers that non-readers adopt them as well and map their own situational contexts onto them.  Definitions drift.  “Minimum viable product” has come to mean “beta” or “prototype” and “lean” is a hipper, newer version of “agile” that has something to do with Toyota, or something.

But if you peel back a layer from breathless use of buzzwords, you’ll find genuine, serious substance underneath.  To summarize the Lean Startup in a ridiculously short sound byte, I would offer, “apply the scientific method to your business.”  And that’s an extremely powerful concept.

You’ll note that there’s nothing in my description about startups, per se, and that’s intentional.  As Eric Ries argues in the book, there’s nothing to say that the same approach can’t be leveraged within large, established businesses.  He even gives a number of examples of exactly that application.  Make no mistake; the Lean Startup approach has lessons for you no matter what your business and no matter how well-established.

Business, Science, and Software

For me, and for most reading, our business is the business of software.  The question thus becomes, “how can we apply the scientific method to building software?”

To do that, let’s consider the scientific method a bit more formally.  Here is what it involves, quoted from the linked page.

  1. Observation and description of a phenomenon or group of phenomena.
  2. Formulation of an hypothesis to explain the phenomena. In physics, the hypothesis often takes the form of a causal mechanism or a mathematical relation.
  3. Use of the hypothesis to predict the existence of other phenomena, or to predict quantitatively the results of new observations.
  4. Performance of experimental tests of the predictions by several independent experimenters and properly performed experiments.

Let’s condense that a bit to the following process.

  1. Make observations.
  2. Form hypotheses.
  3. Conceive of experiments to test the hypotheses.
  4. Execute the experiments and record the results.

With that in mind, let’s examine a software scenario with and without the scientific, “Lean Startup” approach.

Two Scenarios

First, let’s consider a traditional scenario.  I have an e-commerce website, and my goal is to get people to sign up for my newsletter so that I can send them information on deals that I’m offering.  As I’m designing the newsletter signup page, I wonder what size and shape the “signup” button should be and where it should be positioned.  To arrive at an answer, I consult with a UX person in my organization, and we do some research, including a lot of reading, and even sending out a survey to our customers on what button placement they prefer.  After a good bit of deliberation, we decide a yellow button at the bottom-center of the page is ideal.  We then promote the changes to production and move onto other projects.

Now, let’s consider what a more scientific approach might look like.  Once again, I consult with someone in UX, and do some research to narrow the field to two options that we feel good about.  Rather than pick one, we promote both to production.  This is accomplished via a technique known as “split testing” or “A/B testing.”  Site visitors are randomly shown one option or the other, but in equal proportions.  We then see which button color and placement triggers a higher rate of subscription to the newsletter.

This is the scientific method as applied to business.  The UX folks and I made observations about the industry at large, and then we hypothesized that, of our apparently best options, the yellow button in the bottom-center might be a little better than the red button at the top.  We then conceived an experiment (deploying both buttons to production), ran it, and recorded the results.  We can repeat this same approach over and over, with many different buttons and placements, gradually iterating toward the best sign-up rate.

Before You Get Out Your Wallet…

Fresh off of a read of the Lean Startup or flush with the success of a business experiment, groups have a tendency to want to solve with instrumentation.  The questions start to fly.  “What’s some good split testing software?”  “How can we get this incorporated into our existing software as quickly as possible?”  “Do we need to overhaul our codebase and process so that we can ship to production more often?”

While all of those are questions and options worth exploring and ones that may prove beneficial, you don’t need to do anything drastic to benefit from the scientific approach.  Think of experiments you can run with your existing delivery process.  Consider how you can use your software, as-is.

Log Files as Scientific Notebook

To get the ideas flowing, why not consider your own log files?  Before you furrow your brow skeptically, consider a chemist in the lab, performing experiments.  Or, maybe, think back to high school chemistry class.

When doing experiments, you would have beakers, Bunsen burners and test tubes, to go along with an impressive array of chemicals, mixtures, and minerals.  The memorable action would occur at the moment you added an alkali metal to water.  But think back to the part you’ve probably blocked out a bit: the note-taking.  Oh, there was so much note-taking.  You’d measure and mark down the weight, volume, and makeup of the ingredients.  You’d probably have to mark down air pressure, temperature, and all sorts of other stuff.  By the time you finally dropped the sodium into the water, you needed the cathartic explosion just to alleviate the boredom.

Now, imagine how happy you would have been to have some kind of magic data gathering service that captured all of that information for you.  Imagine how happy a professional chemist would be to have every conceivable data point captured automatically, including ones that seemed irrelevant at the time.  To be able to go back later and examine old environmental data would be a bonanza for the chemist.

You have that ability in your software.  Your log files have tons of important data.  When considering which button to use to entice users, why not go back to your logs and see if you can determine which existing buttons in your application are most frequently clicked?  With your logs, you have the unique ability to run experiments after the fact!

The logs in your application produce immense amounts of data.  Make this experimental data.  Your log files should be at the core of your experimentation.  They should serve as your metaphorical scientific notebook.

Ready to start performing experiments with your log data? Logentries lets you capture log data from your app lic ati ons and perform analysis.  Create a free Logentries account in less than a minute at logentries.com.