Week two focused on the customer development process and running experiments.
The Customer Development process, developed by Steve Blank, offers a framework for product development that can feel familiar to designers trained in empathetic human-centered design. (Though Blank uses Customer Development to bring the rigor of the scientific method to the art of starting a company, a scientist’s hypothesize-research-test-iterate process can be similar to a designer’s process.)
Before class, we asked students to watch Blank talk through customer development and entrepreneur Eric Ries discuss lean startup methodology, which offers an engineer’s take on the customer development process.
Blank’s perspective comes from the business side of startups, and Ries’ from the engineering world. Our in-class lecture, given by Giff Constable, gave a product designer’s take on iterative development.
Giff began by re-introducing the process and practice of customer development, using slightly different language. He moved on to an overview of why customer development matters before walking through the types of experiments one could run. His talk was full of anecdotes from what he’s seen and done in Startupland. His slides are online.
And the audio file:
Giff’s talk kicked off a discussion on the tension between testing and inspiration: can A/B testing lead to “the right answer”? Or is “inspiration” – gut, instinct, hunch, whatever you prefer to call it – necessary?
We spent time debating an idea similar to this one from Giff’s blog:
Here’s a truth with startups and new products: understanding test results and root-causes is often really hard. Yet it rarely makes sense to spend the time and money to get statistical significance or perfect clarity. We need to exercise judgement and intuition to interpret results, but that does not invalidate the usefulness of getting outside of our own heads. Sticking one’s head in the sand is not a valid approach.
When I discussed this challenge with my project-teammate Jon Berger, he said, “We test to uncover clues, not facts.”
Overlaid on our conversation was Walter Isaacson’s biography of Steve Jobs; Jobs pretty famously didn’t subscribe to notions of A/B tests, and it seems to have served him well. Yet Jobs is only one anecdote, and we all know the plural of anecdote is not data ..
In any case: it’s important stuff, relevant to technical and semi-technical designers figuring out their places in the product development process, and it doesn’t lend itself to clean answers.