THINK BIG --> but Bet Small
Don't confuse "think big" with "bet big"
The Digital Leader Newsletter — Strategies and Techniques for Change Agents, Strategists, and Innovators.
I have not failed. I’ve just found 10,000 ways that won’t work.
—Thomas Edison
Most businesses have at least one “big bet” strategy either in formation or underway. A Big Bet strategy is any initiative which is significant both in its potential and its investment size, and also has significant risks involved. Success is not pre-ordained. Big Bet strategies happen at the enterprise level, the division level, the functional level and at the team level. These might be your digital transformation, innovation strategy, technology platform programs, acquisitor strategy, AI initiatives, operating model transitions, and product or launches.
Of course you know the outcome of the vast majority of BIG BET strategies?
They fail.
Seventy to eighty four percent all major initiatives, regardless of company size, fail. They fail to deliver on budget, on time, on impact, on scaling, on customer experience, on operational improvements, on delivering the transformative business value to rationalize the expense and effort. They fail in every conceivable manner.
How do you avoid this failure? Here’s one major strategy for dramatically improving your odds of success for your Big Bet strategies …
THINK BIG, but Bet Small.
To Think Big, Think in Outcomes
The launch of Amazon’s Marketplace business in 2002 was a Big Bet. It worked out. This business supports millions of sellers, and is responsible for over 50 percent of all units shipped and sold at Amazon. Developing a big vision for creating an outstanding customer and seller experience was critical in laying the foundation for success.
As we developed our vision and strategy for the marketplace business, we focused on two core principles to enable success:
Trust — Customers should “trust” buying from a third party as much as they “trust” buying from Amazon the first-party retailer. Thus the entire customer experience with third-party sellers needed to be indistinguishable from their experience buying directly from Amazon, the retailer. Leading with “customer obsession” meant that even though Amazon was not the seller of record nor responsible for fulfillment on these marketplace orders (there was no FBA at this time), we operated with our sellers in a partnership mindset. This principle led to a robust and complex choreography of integration points, requirements and necessary coordination.
Scale — We knew we needed to be able to operate a large business with low head count. The critical strategy for this was seller self-service. We needed to envision supporting hundreds of thousands of sellers, not hundreds of sellers. Managing your business at Amazon had to be self-service. We established early partners, built technology helping sellers integrate, test, and operate. An extensive roadmap of capabilities with “scaling” while enabling “trust” was established.
There was tension between these two principles. To create “trust” meant tight integration and oversight with sellers. A completely different strategy than EBay, the dominant marketplace in 2002.
But to “scale” meant making it easy for sellers and having a low headcount and costs in seller operations at Amazon. It was the combination and forcing function of these two principles together forcing better design, creativity and innovations —better thinking and strategy.
These principles were the high-level “outcomes” we envisioned in the marketplace business. They were also unproven concepts. We didn’t know if customers would adopt. We doubted that sellers could operate with the precision Amazon operated at. Many Amazon fulfillment and operations leaders were committed to the perspective that these sellers could not “deliver” to meet customer promise. The Marketplace plan was oriented to testing both customer “trust” and “scale through self-service” as quickly as possible.
The BIG BET was framed as building a multi-category retail marketplace with authoritative selection, a high-trust customer experience and a truly “scalable operational business”. But the critical foundational “first bets” were testing the customer and seller experience.
The marketplace wasn’t going to be built in one release. Although we didn’t have the vernacular of “agile”, “minimally viable product” or “OKRs”, this was how we were acting — we thought in terms of outcomes, constraints and fast feedback.
Outcomes and constraints are how to avoid “analysis paralysis” and over-building. Outcomes and constraints avoid “Thinking Big” turning into “Betting Big.” In our case, the key and difficult first outcomes were
Launch the apparel category in time for holiday season 2002 (October or November 2002)
Launch with all of our key apparel partners (~40)
Enable “size” and “color” variations on a single detail page (new)
Have an integrated shopping cart, checkout and single payment (all new)
Everything else we faked, hustled, postponed, delayed and compensated for with unscalable human effort — for a deliberate and short period of time.
Post launch, we begin adding key elements to further our principals including
Creating a self-service registration pipeline
Creating a test environment and automated “test criteria” approach
Creating “item authority” by reconciling items being sold by multiple sellers
Building a partner network to help sellers lacking key capabilities
Creating different merchant paths and methods of integrating for depending upon the merchant’s preference
Building a seller-tools team to build key tools for our sellers and key technology to manage our sellers
We were thinking big, but did not confuse “thinking big” with “betting big.” We envisioned the outcomes and core components of the marketplace business at the start, sequenced them, launched them, proved the risky hypothesis and kept iterating, improving and iterating.
The constraints and top-down attention to detail forced a decision making and delivery pace enabled with clear eyes and no confusion about decision making — it only took a handful of leaders, all working in close physical proximity, to make 95% of all decisions.
And Then, Bet Small
The better you become at creating ways to test repeatedly in small ways, the more likely you are to achieve big success.
Before I even joined the Marketplace team in early 2002, Amazon had already tried—and failed—to build two other third-party seller platforms. Before Amazon Marketplace, there was Amazon Auctions and then the zSHOP. The first two were failures; the third is now the “dreamy business” Bezos referred to in the 2015 Amazon shareholder letter.
And although Amazon certainly invested in the Marketplace business, and it was high risk, it did not put the enterprise at risk. Instead, leadership invested in relatively small experiments to test, learn and refine Amazon’s understanding of the winning formula.
What do small bets look like? Here’s one example.
For the Marketplace launch, our initial sellers (big apparel brands) thought customers would want to shop through seller-branded storefronts. A digital “front door” for customers to shop. So we built the seller-branded online storefronts with some basic merchandising and self-service features. Once we launched storefronts, we found customers were more likely to shop through “side-doors” instead of front doors. They shopped by searching and browsing, not by navigating to the seller storefront. We stopped investing in merchant-specific storefront capability and instead focused on improving Amazon’s category-based browsing and searching capabilities.
The invention is not disruptive; Only Customer Adoption is disruptive. — Jeff Bezos
My favorite buzzword is agile methodology - an approach for iterative, incremental solution design and delivery. I’ve worked with, managed and turned-around several programs using an agile methodology.
In the cases where a turn-around was needed, typically key leadership in the initiatives apparently define agile as “the methodology of no accountability.” Scope, time, cost? You can’t hold us accountable because we are agile (wink, wink). They are wholly noncommittal to outcomes or constraints. The semantic travesty occurs when agile is used as an excuse for not getting real outcomes—the kind that actually matter for customers and the business.
PRINCIPLES FOR BETTING SMALL
There are many well-known and well-defined manners and resources for testing business concepts. The “Testing Business Concepts” book in the Strategyzer book series is one. An example is called the “Wizard of Oz” approach where a capability appears to be automated, but in fact, behind the curtain, humans are doing the task instead of automation.
There are dozens of frameworks, methodologies and aids for testing concepts — all are very helpful. Underneath all of them are what I call the “principles for betting small”:
Formalize —> Define your key risks, principles, strategies, hypotheses and constraints. Frame them as outcomes
Prioritize —>Evaluate the outcomes according to value, risk and “ease to test”
Strategize —>Design and execute experiments to test and learn — as cheap, fast, meaningful and in parallel as feasible
Scrutinize —>Review, debate and draw insights with a critical eye and judgement. The risks are slowing down and falling in love with a concept
Mesmerize (or monetize, your choice) —>Iterate to prove and refine the critical outcomes of the new capability, and then scale your Big Bet
YOU STILL HAVE TO BE RIGHT; A LOT
Amazon’s Leadership Principle Four is “Leaders Are Right, a Lot.” It reads, “Leaders are right a lot. They have strong judgment and good instincts. They seek diverse perspectives and work to disconfirm their beliefs.”
Creating and adopting a THINK BIG but Bet Small mindset is not without risk. Using it as a crutch for either bad judgment or poor execution can spell the death of your enterprise. Just as “agile” has been allowed to become the development methodology of no accountability, “fail fast” can become the excuse for more failing than needed or poor execution of your tests.
Just because your digital transformation or other transformation strategy requires testing and iteration, that doesn’t mean you can afford repeated attempts at something that you should get right the first time. “Failure” has become an excuse and almost an expectation; this is the risk of many current transformation models. The difference between a test failure in which you learn and an execution failure is sometimes obvious, sometimes really subtle. The more involvement you have, the better your odds of knowing which one it is.
“We are biased toward people who never give up. That’s something you can’t find on a résumé. We look for courage, and we look for genius. There’s all this talk about how important failure is, which I call the failure fetish. ‘Failure is wonderful. It teaches you so much. It is great to fail a lot,’ people say. But we think failure sucks. Success is wonderful.” — Marc Andreessen
Thinking Big but Betting Small tactics anchored with strategy defined by outcomes creates the balance and forcing functions guiding you to BIG BET success.
About The Digital Leader Newsletter
This is a newsletter for change agents, strategists, and innovators. The Digital Leader Newsletter is a weekly coaching session focusing on customer-centricity, innovation, and strategy. We deliver practical theory, examples, tools, and techniques to help you build better strategies, better plans, and better solutions — but most of all, to think and communicate better.
John Rossman is a keynote speaker and advisor on leadership and innovation.