This seems pretty apropos for a first topic for this blog: Value of Test & Learn.

"Test & Learn" is popular in industry these days due to the expectation that it will help individuals and organizations achieve their goals. However, as with most new things, it becomes empty vessel into which hopes, dreams and aspirations are poured.

What it is:

Test & Learn is merely a process of continual course correction, a belief that it is worth my time to ask questions and incorporate the response throughout my creative process, not just when I'm done. It is a departure from traditional problem solving, where experts take a question back to their desks, then return with a polished, thought-out solution.

Test & learn seeks to create minimal viable prototypes - those that capture only the key features necessary to answer the question - and does not waste time polishing ancillary elements. These are refined over multiple iterations, converging on a set of design criteria and a solution.

Test & Learn provides greater confidence that the correct conclusion has been reached, because a number of preceding iterations have been tested with the target audience, retaining the positive elements, while removing the negative.

Net: Test & Learn lowers the risk of failure upon market introduction, mitigating the risk of catastrophic throwaway costs (marketing spend, inventory build, capital investment, etc)

When to use:

Whenever you're venturing into the unknown.  At the very least, it will help you sleep better at night, knowing that your approach has been validated.

Things to watch out for:

In my experience, Test & Learn is looked to as the magic bullet to solve long-standing development problems:

• Shorten development time ("Test & Learn speeds learning, so I can get done faster!")
• Decrease resource burn ("Test & Learn lets the market do my work for me!")
• Remove need to develop expertise ("Test & Learn uses the market as my expert set")

Sadly, while these sometimes occur, they are not the core benefit. The sources of failure for the above hopes are readily apparent:

• I will shorten development time: pulsing the market for feedback takes time, and you probably won't recoup that relative to a traditional process
• I will decrease resource burn: the work still needs to get done
• I'll remove the need to develop expertise: removing negative elements in each successive prototype requires expertise in the relevant disciplines