Case Study: Doppler (backed by Sequoia) CEO Brian Vallelunga Found Growth By Killing A Product

Identify and focus on your startup's popular core offerings. Kill the rest.

Aug 10, 2020

The Problem - Figuring Out When To Kill An Unpopular Product

With limited resources and capital, every decision counts when deciding to develop a product or service for your users. The challenge of abandoning the ones that don’t pan out in a timely fashion can be the difference between life and death of your company.

Action Item: Consistently pinging your users and customers on their attachment to a product or service can give you an early indication to either double-down or walk-away.
The Solution - Collecting Data, Keeping Your Users Informed, And Assessing Team Bandwidth
Brian Vallelunga was proactive in asking his users which product they preferred more and collecting data around their feedback, while also understanding his team’s bandwidth to support both products. It was clear that given limited team bandwidth and user preference for Enclave over Radar, that the latter be sunsetted.

Action Item: It’s critical that you understand both your team’s bandwidth to dedicate engineering resources across multiple products or services, as well as your users’ preferences for your core offerings.
The Takeaway - Being Comfortable With Uncertainty Allows You To Make Hard Decisions Confidently

Vallelunga took the time to understand that his decision to sunset Radar was “reversible”, thus removing the fear of uncertainty from his decision. If it turned out to be the wrong choice, he could always revive the product.
Action Item: Eliminate uncertainty in your decisions by figuring out which ones are permanent, and which ones are reversible.

Founder File: Minting Kings

Doppler on Startup Spotlight: Startup Spotlight #9: Doppler

Founded in a small apartment in the Design District of San Francisco, Doppler started off as a crypto machine learning marketplace. After 8 months spent attempting to get this concept off the ground, Vallelunga decided to shut it down.

After deciding it was time to move on from the Blockchain project, he took some time to reflect on the experience. Looking at all the pain points Vallelunga had faced when running the crypto project, secrets management surprisingly kept popping up due to everything being such a manual process. From controlling access with contractors to frequent outages due to human error, it felt like he was back in the analog age. When Vallelunga looked for tools to help alleviate the pain, the available products in the marketplace seemed too complex. So, he decided to build a new secrets management tool -- an easy to use product every developer could fall in love with, not just the super senior security engineers.

Doppler CEO Brian Vallelunga.

The Problem: Figuring Out When To Kill An Unpopular Product

What was the main problem in deciding to discontinue Radar?

Radar was Doppler’s secret scanning product that would actively look for sensitive pieces of information in a GitHub repository on push. The goal of the product was to help teams ensure they keep a strong security hygiene when it comes to managing secrets.

After a couple of months of actively talking with customers and looking at the engagement numbers we saw a very strong trend that our users liked the feature, but they didn’t love it. More importantly, all of them said they would rather us double down on our loved secrets manager instead of trying to keep up with GitHub’s free scanner.

Describe the nature of the problem. What are the critical constraints?

The main constraint was engineering resources. As a company, you only have so many problems you can tackle concurrently. There would have been a lot of work we needed to do to keep up with all the other scanners, and it seemed like even after building all of those features we still wouldn’t have a product that is as differentiated as our secrets manager product.

What was your initial thought process in solving the problem? (Be detailed and walk me through each step of thinking!)

It started when we started feeling overwhelmed by the number of feature requests for our secrets manager product Enclave. We had a huge backlog of tasks for Radar but Enclave always seemed to get the engineering resources. We started looking internally why that was the case and found all of us personally liked the Enclave product more. That sparked the investigation of why and if customers felt similarly.

After spending a couple of weeks talking with customers and looking at the data we decided to make the quick decision as a team to sunset Radar. We started by announcing it to our customers privately over email and listened to the reception. We shared why we made the decision, when Radar would get turned off, and how it would impact Enclave. The responses were glowing, they appreciated the decision and were happy that more features were going to be built for Enclave. Days later we released the email in the form of a blog post found here.

The Solution: Collecting Data And Keep Your Users Informed At Every Step Of The Way

How did you determine the difference between customers merely liking a product versus loving it for Doppler's Radar?

It was night and day! Our Radar customers used the product because we asked. They would install it and forget. When we asked what new features they wanted, it was always for our secrets manager product. Also only the customers we had super close relationships with used the product in comparison to the vast majority of Enclave customers we don’t know personally.

What questions or types of questions did you ask that led you to the conclusion that your customers wanted you to focus on Enclave?

We asked them which product would they rather we support if one had to be discontinued. Everyone said sunset Radar and double down on Enclave. It was super quick and very clear what they wanted. Why they wanted it was a whole other question. We found that making sure secrets weren’t in git didn’t feel like a priority since most of their repositories were private. On the other hand, one of the largest value adds of Enclave is how much more productive their engineers become. I think this is because productivity is easy to calculate in engineering dollars saved vs dollars saved by preventing a security breach event.

What was your process for deciding how the engineering resources get distributed across products and services you are trying to maintain for customers?

It was rather simple, we had 2 engineers and 2 products. For the first several months we focused exclusively on Radar to get the product live. Once Radar was live we switched back to Enclave to help relieve the ever-growing backlog of feature requests. After clearing through some of the Enclave backlogs we asked ourselves if we should continue supporting Radar.

The Takeaway: Being Comfortable With Uncertainty Allows You To Make Hard Decisions Confidently

Has the renewed focus in Enclave after dropping Radar made up for the latter's lost revenue?

Absolutely! We never ended up monetizing Radar, it was only potential. Enclave was monetized from day one and the numbers are only growing.

Emotionally, how did you navigate uncertainty before making a decision on keeping or dropping Radar? Did you struggle? How did you manage or overcome said challenges?

I prefer to leave emotions out of critical decision making. I found the best practice is to gather data and then present those findings to the team. As a team, we then make decisions on what the best path forward is. When you are always focused on finding the right answer for the company, one’s individual emotions rarely impact the team's decisions.

Did that solution come with its own caveats or tradeoffs? If so, what are they?

Definitely! We knew that sunsetting Radar would mean letting go of a potentially high revenue product line. Long term it felt like the right call and gave us the affordance to ship features in Enclave that our customers today really love. The heart of Doppler is Enclave, and no matter how much we invested in Radar, we knew that would never change.

What is your general advice for founders on how to face the challenges related to killing a product?

A large part of being a founder is getting very comfortable with uncertainty and hard problems. The good news is that most decisions are reversible. By categorizing decisions into the “reversible” and “permanent” buckets, it makes it easier to execute on the hard decisions fast.

Sunsetting Radar is a great example of this. From the outside, it looks like a big decision but it’s actually quite a reversible one. If we heard from customers during the email announcement that they wanted the product to stay we could have postponed the sunsetting. Then dig deeper into why they wanted it and seen if they were willing to pay more to keep the product alive. By splitting our actions into stages, we make the sum of the changes more reversible, thus less risky.

Previous F2F Q&A Articles:

Latest Forbes Articles:

If you enjoyed this article, feel free to check out my other work on LinkedIn and my personal website, frederickdaso.com. Follow me on Twitter @fredsoda, on Medium @fredsoda, and on Instagram @fred_soda.

Founder to Founder

Discussion about this post