The confluence of inexpensive, professional-grade equipment and high capacity storage has radically changed the way I take pictures. Although I have a lot more failures, the likelihood of a “money” shot is far greater than before. Cloud computing and lean methodology offers similar game-changing resources for your business and can radically change how you make a product.

I recently returned from a vacation and started reviewing the mountain of photos I took. I was surprised to discover that in two week’s time I took over 2600 pictures. Did I keep all these pictures? Absolutely not, but each one was valuable. I’m a much better photographer now than ever because of how cheap failure has become. Back in the film days, I may have taken about 200 pictures in the same time frame. Because film and processing were expensive, I took great care in deciding what pictures I would take and how much bracketing I would try. In short, my cost aversion to incremental failure led me to maximize the value of each picture at the expense of overall learning. The result, while decent, was not spectacular. I had plateaued but didn’t know it.

This isn’t my first digital camera, but this latest one introduces (to me) three significant factors that changed everything. With my camera I have essentially unlimited resources (I can fit 5000 high resolution images on a single SD card), instantaneous feedback (“Hey, you blinked; lemme try again”), and dead-simple bracketing (which I explain below) over a large set of variables. This lowers the cost of failure while also giving me the tools to learn at an amazing rate, which results in better pictures. And because I’m taking more pictures, I recognize and seize photo opportunities that were previously unavailable.

Now imagine that instead of “photo”, I say “new product”? Wouldn’t it be great to quickly test new ideas and iterate to an optimized product? Yes it would, and obviously we are in an ecosystem that enables us to do that. As entrepreneurs, we need to know how to take advantage of unlimited resources and instantaneous feedback to propel our business forward. Cloud computing gives us unlimited computing resources at the click of a button, while the lean methodology provides tools to solicit instantaneous feedback on product ideas. The secret sauce in all of this is to pay attention to your failures to maximize learning.

With photography I start with an idea and will go to a site to see if I can capture an image that is as good as my hypothesis. I can test an idea by iterating over numerous alternatives in a short amount of time. Note that some factors I’ll need to plan in advance, like location, time of day, weather conditions, and what effects I want, while others I can change on the spot. Some variables I can test in parallel via bracketing, while others have a potential opportunity cost, such as switching a lens. An example is when I went out to the Hudson River to recreate a desert motif in ice. Here, I needed the sun at just the right location and it needed to be a clear day, otherwise the allusion to an oppressive desert sun wouldn’t work.

In the online product world, platforms like QuickMVP or Unbounce give us tools to test product ideas in a similar manner. They do this by making it quick and cheap to set up a landing page along with some advertising to drive users to the page. These platforms typically offer A/B testing, which when done well is similar to bracketing. With bracketing you can take multiple exposures of a single shot and vary exactly one variable in the exposures. In my camera that variable can be ISO speed, exposure correction, dynamic range, and film simulation. It is essential that all but one variable is held constant so that you understand the effect of that variable as it varies. Similarly, an A/B test is not effective if too many variables have changed between the tests. When this occurs you cannot extrapolate what you’ve learned about the variable from the test.

As I mentioned earlier, not all iteration is cheap. Some, like switching a lens, has an embedded opportunity cost. Even under the best circumstances, it takes me at least 30 seconds to swap a lens. If this reminds you of changing priorities during a development cycle, give yourself a pat on the back. The analogy is that a product development cycle mirrors a photo shoot (or site). What I discovered is that my success rate dropped enormously if I didn’t plan in advance which lens I wanted to use and why. Many subjects, like wildlife and sunsets, don’t wait for you to switch lenses (or even focus). The same is true of customers. If you’re out of focus or have the wrong perspective on your product, you will fail. If you try to switch lenses mid-shoot, you may lose the opportunity. Here’s an example where a Great Currasow crossed our path. Unfortunately I didn’t have my telephoto lens on the body, so the bird is small in the frame. However, had I stopped to switch lenses, I would have missed it completely.

Interestingly, this can lead to a strange paradox. Sometimes it makes sense to stay the course and keep shooting even if you know you’re using the wrong lens because the opportunity cost is too great to switch. Often you can salvage a shoot so long as you’re still taking pictures. In product development this means staying the course until you finish the iteration. If you’ve designed your product development cycles effectively, you will be able to test the updated product and learn definitively what works and what doesn’t. The alternative is being mired in uncertainty simply because you never released anything! To prevent this from becoming a suicide mission, the hidden lesson is to keep your development cycle as short as possible, but no shorter (h/t Einstein). Once you have launched something, gotten feedback, and revised your plan, then go back out for a new shoot.

The lesson here is that like hitting on a successful photo, a successful product is no accident. With virtually unlimited resources and a proper plan, you can quickly iterate over many variants of an idea until you find one that “works”. The key is that tests must be designed with failure in mind to maximize learning. If you’re not defining and testing hypotheses nor learning from failure, you will eventually run out of the one resource that is persistently finite: time.

What are your thoughts? Can you think of other examples where this analogy holds? How do you maximize learning? Let us know in the comments.