It was March 2017, and Jyoti Bansal was elated. Cisco Systems had officially acquired AppDynamics for $3.7 billion. As an application performance management (APM) company, AppDynamics developed software to monitor applications across an ever-increasingly complex network of code, third-party interfaces, virtualized servers, and various other inputs. Essentially, the company enabled other companies to monitor applications and resolve performance issues with unprecedented speed. Bansal founded the company in 2008 and served as its CEO until 2015. At the time of its acquisition, AppDynamics had raised more than $300M in funding from several different venture capital firms.
Bansal reflected on his company’s success, recalling how difficult it was to find product-market fit during those early months back in 2008. At the time, they had no customers, additional funding was nonexistent, and several of their assumed markets – finance and banking among them – were not taking any spending risks because of the recent financial crisis. Bansal needed to figure out the profile of his initial customer quickly or he’d be out of business. He undertook a systematic process that helped him (1) find initial customer prospects and (2) refine the messaging for his product so it would resonate. What he learned during this process would subsequently help him build one of the fastest growing startups in Silicon Valley history, and as of 2017, earn the highest ever price paid for a private software company.
In 2007, Bansal was working as a software engineer in Silicon Valley. He noticed that applications were becoming more and more distributed, with many more moving parts — and with various aspects getting virtualized into the cloud. He knew these changes meant that companies would have to rethink how they monitored and managed these new systems. Bansal explained:
"People were building apps everywhere. I knew the bigger enterprises had a large number of software applications and the environments that hosted these applications were becoming very complicated. I also knew there would be a lot of code involved with these new applications. And every time a company produces code, it needs to be monitored. The existing solutions would not be good enough for modern applications and the IT operations staff responsible for keeping them running."
Powered by that insight and a $5M investment, Bansal started searching for customer No. 1. He initially cast a wide net, knowing he needed data and feedback to drive prioritization and focus to his efforts:
"I started with LinkedIn cold InMails. I would say: “We are building the next generation of monitoring for Java applications. Would you be interested in talking to us and giving us feedback?” I chose Java for two reasons. First, most critical enterprise applications at that time that had revenue tied to them were written in Java, and second, by focusing on only one technology type, I narrowed down my universe of potential targets and made things simpler for my engineering roadmap. I would also try to target people who were responsible for IT operations, because my insight was that these people were actually the ones who felt the most pain when application performance decreased. Developers produced the code, but it was the IT operations people who scrambled when applications experienced downtime. I initially created a target list of a few hundred potential prospects by crawling LinkedIn, and then I would just send them each an InMail. If I sent out the same message — say, 100 times, and got a hit rate of 13 responses — I’d analyze where the responses were coming from. I started to see that I’d get more responses from companies of a particular size, or more responses from this kind of job title. That’s what informed my focus, and then I’d iterate on what was working and double down on that."
Bansal’s cold emails quickly evolved into a system of testing, something he referred to as his “go broad, then segment” strategy. Some key segments Bansal explored were:
Bansal also emphasized the importance of asking for feedback in these cold emails rather than pushing for a sale immediately:
"At that earliest stage, you don’t really exist as a company. You have less than ten people on your team, you don’t have a product yet, and you think you should be trying to sell — but selling can put people in a defensive mindset. You have to engage them in the process, make them feel like they’re partnering with you in solving a problem that they care about. When I was sending emails trying to sell, the response rate was very low. When I sent emails asking for feedback from them as the expert, my response rate was much higher. It was dramatically different. But then I learned another important lesson."
Bansal soon discovered that simply getting responses wasn’t enough. He needed to be able to distinguish the customers who were desperately seeking a solution (because their feedback was the most valuable and they were the most likely to become an initial customer) from the responders who were casually curious about AppDynamics’ technology and the broader changes in the IT monitoring space. One way he accomplished this was by learning to ask initial responders the right set of questions.
Once a prospect was willing to engage with him, Bansal had to go through another set of experiments with his messaging strategy and questions to determine who had a “hair on fire” problem, and who was just kicking tires and learning. He explained:
"I learned that people are too nice. I’d say “What do you think of this?” And they’d go: “Oh, that’s cool…” But when I started to ask people more of a closing question such as: “If we build this product, would you be willing to buy it?” I got a lot further. Other critical qualifying questions I learned to ask were “Why do you need to buy anything?” or “What’s pushing you to buy something now?” If they didn’t have a clear, compelling reason to buy, there was no way they were going to be a good use of our limited time. And there just weren’t enough hours in the day for us to be screwing around educating people. When we found a customer prospect who could articulate a compelling need to buy, we quickly learned to listen carefully to everything they said."
Bansal’s conversations with the right set of potential customers began to unravel some key assumptions he had made about the market and about what his customers might want in the product:
Assumption 1: Customers would be cloud-based in two to three years, and therefore would want a cloud monitoring solution to consider.
Bansal’s first pitch to customers was similar to the pitch that sold his investors. AppDynamics was building a cloud-based platform that would provide companies with the tools to monitor and fix errors within a customer’s network of applications. Bansal, like many others in the Valley at that point, assumed that the adoption of the cloud was going to be a very rapid process that would happen by 2011 at the latest. In contrast, the customers he spoke with saw a much longer timeline for their company transitions to the cloud. As a result, they didn’t see AppDynamics as a solution to their current needs. Bansal elaborated:
"Potential customers] kept saying: 'We like what you’re doing, and it all makes sense. I can use the cloud product you are describing in four to five years, but it doesn’t solve my problem now.' We needed to understand our customer’s current and most severe pain, partner closely with them, and solve it together. That was our ‘a-ha’ moment. If we were going to stay in business, I needed to sell today. There was no funding for being right eventually. I had to solve the problems our customers had now."
Assumption 2: The solution from AppDynamics could have a SaaS management component, not all ‘On Premise.’
Bansal and his team assumed their software had to operate as Software-as-a-Service (SaaS). SaaS business models were in vogue with venture investors at the time as market sentiment was shifting and falling in love with the predictability of recurring revenue. But investors are not customers. And being right too early is the same as being wrong. As Bansal engaged with prospects, he initially suggested customers would have to adjust their approach to be compatible with AppDynamics’ technology. Again, Bansal himself went and spoke directly to his customer prospects and heard things that were opposite to his initial beliefs about their needs:
"I would talk to these customers — some of them were these large banks. And they said, 'We need the entire solution to be on premise. All the data is stored on premise.' And I thought, maybe this is just a traditional company’s stance. Let me talk to some more modern companies. That was in 2009. We called four more companies and all of them said we have to do it on premise… Even Facebook, perhaps the most cutting-edge technology company on the planet at the time, was saying we have to use on premise software. If I hadn’t sat down and had the conversations myself, I’m not sure I would have believed it."
Assumption 3: Customers wanted detection and correction of application issues.
AppDynamics was designing a complex product that would manage the entire monitoring process — from identifying issues in the system to automatically solving them. But discussions with IT departments showed they didn’t need a “find it AND fix it” solution. Customers simply needed a way to visualize app performance so they would know as quickly as possible that there were issues and where those issues were occurring. Bansal and his engineers decided to cut the product roadmap back significantly and instead focus on simple application visibility.
In sum, three of the key hypotheses that Bansal had about what was best for customers turned out to be false. He was asking too much of his early prospects at first: operate in the cloud, change your system architecture to work with our platform, and use services that you find superfluous to your needs. The team was hearing a list of needs from its customers that was very different. Bansal explained how they adjusted for these needs:
"We changed our message based on early feedback. We were now going to our customers and saying “Bring your existing applications — cloud or no cloud — we will get you set up so you will have the best monitoring system you can find. We had been asking far too much at first. We were too far ahead of the customer’s current problems. It should have been about reducing the greatest friction they felt right now, not 2 or 3 or 4 years from now, and it had to be EASY for them to engage with us. Our message evolved to: 'You don’t have to make any changes in application architecture to use our software. You don’t have to make any changes in how you run IT to use our software. You don’t have to be in the cloud to use AppDynamics.' Our messaging evolved from talking about our product to selling by solving problems."
By the end of 2009, Bansal had secured his first 5 customers. YAP, a startup speech-to-text platform, was the company’s first customer. A week later, a division of Electronic Arts came on board. Then Netflix, then Priceline, then TiVo. In addition to these customers, Bansal’s initial conversations had established relationships with many more future customers. By casting a wide net, astutely assessing who had urgent need, and using the feedback to focus his efforts on 6 key dimensions — language, functionality, industries, size of company, and buyer/user personas — Bansal and his small team were able to build a product that had an immediate impact and value for their customers — and therefore, gain momentum, additional financing and ultimately massive success.