There was a problem. Please try again.
Thank you!

Over his career, Instacart VP of Product Elliot Shmukler has seen the interplay of people and products unfold across many industries. For instance, the former Wealthfront and Linkedin product leader knows that much of what takes people sideways with money and career involves emotions. He’s also seen the same dynamic at play as product managers make decisions to pursue ideas, essentially their currency at a startup. Bake into the equation different product management styles with shrinking launch windows and the pressure compounds. That’s why Shmukler champions A/B testing not only as a sound product development practice, but also as an effective management tool.

While at eBay, Shmukler pioneered the use of A/B testing to improve eBay’s Search experience and helped launch eBay Express, its largest product bet at the time. At LinkedIn, he led a 15-person product team that was responsible for nearly half of LinkedIn’s page views. While he was the VP of Product at Wealthfront, Shmukler not only helped the startup grow from $150 million to over $3 billion in client assets, but also launched Direct Indexing, Single-Stock Diversification Service and its first mobile app. Over his career, he’s learned to extract the full benefits of A/B testing for his products and team.

In this interview, Shmukler shows why he uses A/B testing as a management framework, illustrating how it works to not only accelerate decisions, but also empower the teams making them. He outlines the framework’s benefits and challenges, as well as how to implement and scale it a startup. Any product or growth leader will learn from his data-driven approach to product and team management.

A Tale of Two Decisions

At the heart of any management framework is the goal of making better decisions. As people naturally gravitate to the different permutations of better — quicker, higher quality, cheaper, etc. — they neglect to take a nuanced look at the distinct types of decisions that a company makes. In an annual letter to shareholders, Amazon CEO Jeff Bezos speaks of two varieties of decisions: the irreversible (Type 1) and the changeable (Type 2). Here’s how he describes them:

As a company grows, there’s a tendency to broadly apply the Type 1 decision-making process to every choice, including Type 2 decisions. To paraphrase Bezos, what results is a slowness and an unthoughtful risk aversion that leads to a failure to experiment and diminished invention. If Type 2 decision-making is applied indiscriminately, he argues that most companies will go extinct before they get large, having used a lightweight process for irreversible choices.

Shmukler believes universal A/B testing is an ideal way to focus an organization on using Type 2 decision making for most choices. He says, “In the traditional sense, A/B testing is about having at least two versions of the product live: an A version, typically the original implementation or control, and a B version, which you think might be better,” says Shmukler. “Thus when A/B testing is applied to Type 2 management decisions, it’s very easy to walk back through the door as Bezos suggests by simply turning off B and returning to A. Universal A/B testing may even highlight when a Type 1 decision is needed. If you’re having significant trouble coming up with a way to test a direction or sense you won’t be able to roll back the test without consequence, you might be dealing with a Type 1 decision.”

While Bezos warns of “one-size-fits all” decision-making from the helm of Amazon, Shmukler has seen similar pitfalls at early-stage startups, especially in the product management function. The notion of PM as CEO of her product is well-known, but when it comes to decision-making, there’s a real truth to it. The path to shipping a product takes an acute ability to expertly triage different types of decisions along the way. To complicate matters, product managers naturally bring their own management style to how they make the decisions.

Elliot Shmukler

A Case For A/B Testing as a Management Framework

Early in his career, Shmukler co-founded Sombasa Media, which he eventually sold to About.com. It was at his startup that he first noted two different product management styles of making decisions: the way of the visionary and the data-driven PM. “The visionary product manager reads the tea leaves and decides more on gut feel, while the data-driven PM uses experimentation and analysis to make calls,” he says, “There are many effective decision-making frameworks out there, but I wanted to use one that would simultaneously surface the best choice for the product while still encouraging the inherently different approaches to ideation among my product managers.”

For visionary PMs, a lot of power is generated when they know something works and they want to bring it to the rest of the world. Shmukler admits that many of the visionary PMs that he’s known have been or become founders or CEOs, because of their deep belief in taking something personally relevant to scale. “Reid Hoffman built LinkedIn to reflect how he approached professional networking and his vision for how it should work online. Obviously, the product has evolved over the years but the site is still largely true to his original vision, which was right on the money.”

Data-driven PMs develop their insights methodically and are less headstrong before making decisions. “I’d characterize these product managers with the phrase: ‘strong opinions, held weakly.’ Data-driven PMs come to their stance not so much from how they're living their life, but by looking at and collecting new data. As more information comes in, they’re much more likely to refine those insights,” says Shmukler. “It’s more of a challenge to give recognizable names for these types of PMs because the data is at the forefront. But you’ll find them working on growth teams and gravitating toward roles where data already has a very strong role.”

Given these vastly different styles, it can be a challenge as a leader to reconcile these different approaches to product management. For heads of product, this scenario may sound familiar: a visionary PM says, “We need to do X.” Then, a data-driven PM responds. “No, X is wrong. It won’t work. We need to do Y.” Shmukler faced this countless times — and on a daily basis as his team grew. “It’s draining and very hard to resolve without seeming to favor a side,” says Shmukler. “Instead of giving a verdict, test both theories and let data be the judge. At first pass, this method may seem to favor the data-driven people, but it empowers each PM to push ideas forward. They learn independently rather than feeling that a decision was made for them.”

Your team's undoubtedly better with diversity of thought, but trigger the relief valve when tension mounts.

To illustrate its simple effectiveness, here’s how Shmukler has applied A/B Testing as a management practice. “A group of visionary PMs wanted to change how we talked about the company, specifically in the language on our homepage. The more metrics-driven PMs said they had run those experiments before and that it hadn’t had an impact on sign-ups,” he says, “To resolve that situation, someone has to make the decision to deploy time and headcount to do the test or not. Either way, someone will think you’re making a bad decision. Visionary PMs will say you’re too data-driven and not being grounded in the bigger goal and data-driven PMs will say it’s a waste of time. Universal A/B testing solves this, as no such decision has to be made. Instead, there’s an understanding that any idea from a trusted team will be tested in a lightweight way. The results — rather than a single arbiter — decide if ideas should be pursued further.”

In this case, Shmukler asked the team to work together to put the theory to the test to gauge impact. “The visionary PMs wrote the new content for the homepage and the data-driven PMs took point on structuring the experiment. It took a day or two to implement and we collected data over a month,” he says, “All the tests’ results are public on a dashboard that the entire company can access. Both camps are happy: the data-driven PMs got to use data to experiment and determine results, and the visionary PMs got their idea out there. In this specific case, the new homepage language did not have a significant impact. There were no hard feelings. The visionary PMs recalibrated and redirected their energy to new, different ideas.”

Universal A/B testing also allows Shmukler to say “yes” to multiple product ideas — with the only restriction being that they need to tested. “It’s a great way to implement a Type 2 decision making process and prevent the team from getting bogged down with a Type 1 approach unnecessarily,” says Shmukler. “It not only helps the team steer clear of the ‘one-size-fits-all’ trap that Bezos cites, but it increases experimentation, autonomy and learning throughout the organization. Most critically, it fosters goodwill among smart — but very different — PMs who want to try out their ideas.”

Regardless of which idea wins, there isn't a lot of conflict among PMs because the results come from an authoritative test, not an authority. The key is that it’s done quickly and transparently to everyone. Here’s a summary of this method’s benefits and challenges:

Benefits

Challenges

Get ahead of complaints from crestfallen colleagues about squashed ideas. It’s so easy to test. Soon you’ll have a dozen A/B tests running.

How to Implement and Scale A/B Testing

Through the years, Shmukler has heard all the objections around implementing A/B tests not just for product development, but as a management tool. “For growth and later stage companies, it nearly always takes a crisis. At scale, people get stuck in their ways and it’s hard to convince them otherwise merely on theoretical merit,” he says, “But for startups, the protest is always around time and cost. I’ve used this system at a startup when it was 20 employees and barely retrofitted it as it grew past 100 people.”

Shmukler has worked at both large companies and startups, and has found that, regardless of size, this testing framework produces very little friction to launching an experiment, because its not a drag on time or cost. Here’s how:

Invest in a lightweight experimentation tool. In Shmukler experience, it takes just a handful of engineers to do the initial build of a tool and dashboard to run, monitor and evaluate A/B tests. “Most folks who’ve never done this think the resources required are more than they actually are. With less than a month of work, startups can get A/B tests practically automated. PMs can get the results quickly and without a lot of work. If they want to dig into data, they can, but they don't have to since most of the core evaluation is being done for them,” says Shmukler.

If you don’t have the engineering bandwidth or chops, there are many tools available. “If you're using a tool like Optimizely, you probably don't even have to write any code to enable A/B testing,” says Shmukler. “It takes care of it all for you: the testing, the data gathering and the evaluation. Of course, you have to build the different features, but that must be done in any model. If you're using an A/B testing tool, it's almost no additional work for you. There may be some cost, but usually there are freemium options for early-stage startups. It’s a worthy investment when you consider that it’ll help you make sound product decisions and align your team. In the long run, rolling out releases blindly will always take longer.”

If you’re still not convinced, Shmukler intently breaks it down further, “Really, what you’re doing is choosing a user, flipping a coin and putting them in either the A or B group. Depending on that association, you’ll show users a different page or send them to a different flow," he says, “At the start, you can quickly develop something simple. Just get the experimentation going. Continue to collect and test data — for all that’s happening with your product.”

Reduce the barrier to test to one decision. Making A/B tests a universal practice means making each experiment an easy, instant choice. “The friction to launch a test should be as low as possible. Essentially, you want the only hurdle to be just the decision to test at all. After that, the system will essentially run and evaluate it all,” says Shmukler. “It comes down to building great frameworks. For engineers, you need a framework where launching a test is incredibly easy — maybe it's a couple of lines of code to create a new experiment. For everyone else, this is where you need, essentially, an internal dashboard that automatically evaluates the test.”

Shmukler recommends that product teams use dashboards that automatically recognize when new experiments are launched. He describes one that he’s built in the past: “It lets you pick a goal for that experiment. Then, based on that goal, it shows all the metrics that you should be looking at for that experiment,” says Shmukler. “Then it immediately evaluates the data and gives a simple red or green signal to indicate if the change should roll out or roll back. If it doesn’t have enough data, it gives a neutral indication to recommend that the test should keep running. That's the level of simplicity and automation you want. You shouldn’t feel like you’re paying a price at each step to experiment.”

Untangle interactions among tests. As with any system, it’s prone to break at scale. “At LinkedIn, we eventually noted interactions between experiments. For example, tests on a sign-up flow and a profile page could color the other’s results. This becomes hard to untangle,” says Shmukler. “Use statistical methods to alert your dashboard if there’s a problematic interaction. It should allow you to choose to shut down one of the experiments and evaluate your remaining test. If you anticipate an issue before testing, consider using different selection criteria to route specific users into experiments to avoid those kinds of interactions altogether.”

At LinkedIn, Shmukler and his team used sophisticated selection criteria to avoid interaction between experiments. “We’d select from users that weren't in other experiments or sub-segment them to made sure that a segment was only in a single experiment at a time. You end up having to build more complex processes for selecting someone into an experiment then evaluating the experiment over time,” he says.

As the complexity increases with concurrent experimentation, dashboards must become easier to interpret. “The best dashboards are the simple ones — where it gives an indicative green or a red signal — but you still must read the results. You may want to run a red experiment for longer to gather and interpret more data,” says Shmukler. “But as you scale, you want less and less of that interpretation happening because you're going to distribute this information across a much larger team. The likelihood that everyone will extract the same interpretation decreases. So, fool-proof your dashboard so that it gives anyone the full — and same — picture.”

Understand the broad impact of your experiment. Both visionary and data-driven PMs will put increasing faith in A/B testing as the tool itself sharpens. “Most A/B tests tell you whether the experiment is a good idea or a bad idea. The next step is to develop a dashboard that shows the impact of the experiments on the key metrics for the entire product or the entire company,” says Shmukler. “Tests don’t always make that obvious. For example, you may optimize some small part of the sign-up flow and see a 10% lift in completion of that step, but that doesn’t necessarily translate to 10% more sign-ups because not every user may encounter that step.”

Deepening the capability of your testing software to translate an experimental result into top level impact should be on every product team’s A/B testing roadmap. “It’ll helps you understand what to expect in top level numbers as a unit and organization. Also, it helps people select experiments a little better by rooting them in the context of the company. It’s important to know if it’s a 10% win for the entire product or just for a small corner of the product. By reflecting the impact of an experiment on business metrics, the hope is to build each team’s awareness of these experiments, making them more meaningful to run.”

Tying it All Together

Many startups understand the value of A/B testing as a tool to grow a product, but it’s also a built-in mechanism to better develop a product team. Universal A/B testing not only resolves the tension between different product manager types, but it also does so while giving them autonomy and acknowledgement of their personal style. Even if startups face challenges with small sample sizes and alternative systems, investing in a lightweight experimentation tool is always worth it. As the company and number of experiments grow, so must the testing software — and it must employ simpler signals so any employee can understand the big picture.

“A/B testing does more than elevate products faster — it does the same for teams. Using universal A/B testing as a management tool sends a message to PMs of all stripes: intelligently tested ideas will rise to the top, regardless of who thinks of them,” says Shmukler. “They say that to go fast, go alone. And to go far, go together. This system allows you to be both ambitious and autonomous. Most people want to be both in their work — and everyone wants to see their ideas come to life.”

Recommended Articles