The Thinking Big, Testing Small Dilemma

“We are going to change the world, by positively impacting billions of people.”?—?Anonymous, Silicon Valley

Over the next decade, I believe the above statement will not be confined to the bubble that is Silicon Valley. A tremendous opportunity exists, in which we can use exponential technology to solve meaningful problems in the world. If this sounds familiar, then it should, because it is the mantra of Singularity University.

As I mentor at SU I’m constantly reminded that the next challenge of product development isn’t starting, it is sustaining.

This is especially true when navigating the path to 1 billion people.

• Before you can impact 1 billion people, you need to impact 1 million.
• Before you can impact 1 million people, you need to impact 1 thousand.
• Before you can impact 1 thousand people, you need to impact 100.
• Before you can impact 100… well you get the point.

And therein lies the problem, how can you possibly balance your ambitious 10 year vision with your day-to-day activities?

This is what I’m calling the Thinking Big, Testing Small Dilemma.

Remembering the Future

Creating the future is the best way to predict it, but remembering the future is needed before you can create it.

The human brain does a fantastically terrible job at answering questions like “What should our product do in 10 years?” and instead, should be phrased as “What will our product have done in 10 years?”

This phrasing may seem trivial, but it matters a great deal.

If your team can list out what your product has done in 10 years time, then you can start to reverse engineer a path back to present day. It won’t be perfect, but it will be better than mindlessly incrementing or on the flip side, following a detailed step by step plan.

Testing the Path

Years ago I watched Marc Andreessen talk about Lean Startup, comparing it to the theory of relativity in one breath and in the next saying we shouldn’t use it on big ideas.

This perspective is shared by others as well, such as Peter Thiel in his book Zero to One. I find this one particularly interesting as from the outside, it seems that PayPal’s early pivot helped make the company what it is today.

And even earlier this year, I responded to an HBR article on The Limits of the Lean Startup method.

I wrote:

“Lean Startup is impactful when used to test highly important and yet highly unknown aspects of your business. These are framed as Leap of Faith Assumptions, as Komisar wrote about in  Getting to Plan B . Spending all of your time experimenting on known and yet unimportant aspects of you business, while personally enjoyable, is often fatal. I feel Lean Startup gives us a focusing mechanism to help founders test their ideas against reality.”

Lean Startup is another piece of the answer to the Thinking Big, Testing Small Dilemma. You’ll need the discipline to visualize the important + unknown and rapidly test it. (over and over again, in the market)

Once you begin to do this, you’ll notice that your big vision has some assumptions that generally fall into 3 major themes:

Do They?

Before jumping to 1 billion people, do we have evidence that even 1 hundred people have this problem? What would it hurt to check and see? This is where customer discovery really shines. Get out of the building and go and see.

You’d be surprised how often we assume it is a problem only to find out that it isn’t.

Should We?

In addition to uncovering the problem, we have to ask ourselves if it is viable and if so, provide evidence. Sketching out your business model is crucial. If these people really do have a problem, how can you reach them? This is where tools like the Business Model Canvas really shine to quickly sketch out your model and put numbers behind it.

Even if your product is amazing, it won’t survive if you cannot generate revenue and sustain.

Can We?

Here is where we typically spend all of our time, proving that it is possible. Proving against all odds that we have the team and the technology to build it. This is dangerous since it is almost always a customer free zone where we spend all of our energy on wicked engineering problems. But what makes this feasible? This is where experimenting in code and hardware really shine. Experimenting in code this way is called a “spike”, taken from Extreme Programming. In hardware, we follow a similar method by rapidly prototyping using 3-D printing and just-in-time manufacturing.

Once you map all of these assumptions, you may find that your risk isn’t in can you build it, but should you build it.

Pulling it Together

I support having a big, 10 year vision of impacting billions of people.

I believe that over the next decade, we are going to see more products impacting billions of people all around the world. This is possible because we are more connected than ever as we stand on the shoulders of technological giants.

I’m merely suggesting that we test our vision against reality by:

• Stepping into the future, looking back and listing what our product has accomplished
• Visualizing our assumptions as a team into desirable, viable and feasible themes
• Focusing our initial efforts on the highly important + highly unknown assumptions
• Experimenting with evidence to uncover our path forward

There is a chance that you can go into stealth mode, build for years and then release it to the world. From what I can gather, this only works when you get it right the first time.

If you get it wrong, it is almost impossible to recover.