Building Go-To-Market strategy for 0 to 1 journey as a devtool

[00:00.23] - Kanika:

Actually, more than who will purchase for a dev tool, GTM, what I feel is more important is who is your champion. Who will use the tool? Who owns the problem? Who is most affected by these microservices in your environment not getting tested properly? Or who is most affected if there’s a bug, you do 50 rollbacks, and hotfixes? That’s what our SDRs do, actually. They call everyone, and they don’t really sell a single feature. All they do is just ask, "Is this your problem? Is this your problem? Okay, this is not your problem, no problem. Okay, let’s move on." But if this is your problem, then let’s solve it. I think that’s one thing: find the person who owns the problem. Then, we see two more things that I have learned over time, especially when I worked with Keith Butler, the CRO at Observe. He said, "You have to look for the person who can take you to the EBE." Someone who is insecure and trying to do a science project for themselves is probably not your buyer.

[01:10.37] - Kanika:

Yeah, Hypertest looks really exciting. I want to learn everything. Please send me all the details on Gmail, or let’s have a meeting on Saturday. Well, sorry, if it’s not important for you right now, then we are busy with people for whom it is important. I think devs are pretty good with us. They don’t really mess around. I’ve usually seen developers say, "No problem," and if they see a problem, they will be open to taking us to their manager once they have a bit of confidence. Nobody takes everything to their manager. I’ve really not felt that devs have let us down in that way. But yes, so that. And then one more thing: you do a meeting with one person, and if he’s constantly the only one meeting you, he doesn’t bring in other people, which means he has no influence in the company. So, three things: he owns the problem, he has the most influence or at least some amount of influence. I’ve usually seen people, he could just be a tech lead, but if he rallies five people in the next meeting, you know he’s your guy.

[02:36.25] - Achintya:

Hey, guys. Welcome to the Modern DevTool GTM Brew podcast. I’m Achintya, co-founder of Reo.Dev, and also the host for this podcast. Today, we’ll talk about zero-to-one go-to-market strategies for dev tools. To do that, we have a very dynamic entrepreneur here with us. Please welcome Kanika Pandey. Kanika is the co-founder and VP of Sales at Hypertest, a low-code test automation tool that makes integration testing easy for developers. Her entrepreneurial journey includes her previous role as co-founder and CEO of Modern Health, an organization focused on corporate fitness. She is an ex-Googler and the author of Stronger Than Yesterday, a book I got a chance to glance through some of the pages and found really interesting. She talks about the modern lifestyle and enhancing physical health. Kanika, so glad to have you here.

[03:27.40] - Kanika:

Yes, I’m very excited to be here, also because we are both alumni from the same school, so it’s great to be on your podcast.

[03:38.26] - Achintya:

Yes. Kanika, since we are talking about a zero-to-one journey in this podcast, I was interested in knowing your journey as an entrepreneur, from starting at Google and then being a co-founder at Hypertest. Did you always want to go down the entrepreneurial path?

[03:56.00] - Kanika:

The short answer to this question is no, because I did not know who I was. I think the evolution of who I am as an individual got me to be very certain that I wanted to be an entrepreneur. I met a lot of people, even while at ISB, who were very clear they wanted to be entrepreneurs. I really wish I had that clarity. I only knew something that Epictetus, a Stoic philosopher, has said: if you want to live your life, there are only two things you need to do—persist and resist. Persist essentially means doing hard things, chasing those goals, and having the persistence to achieve them. Resist is about not getting stuck on cravings and knowing when to stop. Getting to Google for me was a hard goal. A girl born in Dehradun probably thought at that time, this will be the highest point of my life and the hardest goal. I achieved that goal. And then when I knew that was not who I was, I decided I had to chase something else. That chase, the whole persist and resist, led me to being very clear when I was doing Modern Health.

Modern Health didn’t work out, but I was not going to go and get another corporate job. I would go and find another founder where I could join in the founding journey. This is who I am—someone who didn’t know who she was but wanted to be, and now someone who’s very clear that this is what I will do for the rest of my life.

[05:32.10] - Achintya:

That’s amazing. Let’s come to Hypertest. Tell us more about the product. What does the product do, and how do you differentiate in a market where there are potentially a lot of tools?

[05:42.05] - Kanika:

Yes, there are lots of tools. Tell me about it. That becomes really hard. Hypertest is a developer tool that is trying to make integration testing and unit testing very easy for developers. That’s what Hypertest does. Where Hypertest shines is the fact that you don’t have to write a single line of code to be able to test even the most complex things like queues and sockets, which no other platform can do today the way Hypertest does. We’re a developer tool, and most of our customers are developers who love us, and we are excited to start this journey.

[06:30.28] - Achintya:

That’s cool. And, Kanika, in the zero-to-one journey, defining ICP becomes very important. I remember a story that you told me of how you defined your ICP because testing tools were always focused on QA managers and quality teams, but you focused on developers. I think our listeners and viewers would love to hear that story.

[06:51.42] - Kanika:

Yeah, absolutely. Just the name Hypertest and the word "test" would make anyone believe that, "Oh, you should be selling to testers." Even a dummy would say, "You should be selling to testers." It made integration testing easier, and integration testing in many organizations where developers haven’t found an efficient way to do it is being done by testers. If you built a product that solved a problem for a tester, who would you go to? A tester, right? But it took us a while. And honestly, more than me, Shalet and Karan, hats off to them. They started on the journey a lot before I joined them, and they struggled a lot. They struggled. When I joined, I was full of excitement. I had been in testing for nearly a decade. I know all the heads of QA. I thought I would just go and tell them this is what we do, and I would just convince them. Nothing of that sort happened.

How do you define your ICP? You have to fail. Maybe you think this is your ICP and it doesn’t work out. What I wanted to add when I was sharing the story with you is that you could have the best relationships. A lot of people emphasize so much on selling, asking, "Do you have the best CIO connects?" Nothing of that sort works. If you don’t solve a problem for that particular group of people, it’s not going to solve your problem. We realized it was not working for testers at all. They just did not buy into what we were doing. But every time we spoke to a dev, an engineering manager, an engineering leader, they would get excited. Now, it was hard to get to them. We had two different problems: we could get to someone very quickly, but they would say no. We found it hard to get to someone who always says yes. Of course, the answer was to go do the other harder thing where you get the yes.

[08:48.22] - Achintya:

That’s cool. In this zero-to-one journey, I’m sure there have been failures, and now there are successes. How does this GTM process for Hypertest look today, and how has it evolved? Can you tell us about that journey?

[09:05.44] - Kanika:

Yeah. We are very clear now, and we don’t go to QAs. We just don’t. A lot of times, we very politely guide the head of engineering or the VP of engineering who involves the QA team that we are an out-and-out developer tool. We’ve made a conscious choice. For anyone who understands this space, they will understand how hard it is to go and tell a VP of engineering who says, "I have integration testing being done by this guy who is my head of SDET," to say, "No, sorry, sir, I want to talk to your developers." A lot of times, we were asked, "Why?" The answer can’t be, "Because it works for us," because who are we? We have to explain to them why you need your developers and why it works for you. What are the benefits we can give you if your developers get involved? I think that’s the biggest change in what we’re doing—we just don’t waste our time anymore. Our qualification is very, very strong. If we qualify a deal, it is going to be a sale. We’re that strong with our qualification at the moment, or we’ll just disqualify.

[10:22.17] - Achintya:

That’s very insightful. What goes into defining that? Because I feel that narrowing your ICP in the earlier stages is almost half the battle won. How do you define your ICP? What are the parameters that go into it?

[10:42.05] - Kanika:

I think it comes with trial and error, Achintya. Again, both Shalind and I are very big fans of Jyoti Bansal. I think in one of his sessions somewhere, he said, "The best way to do this is to have a lot of meetings." I have been with really fast-growing scale-ups like Perfecto and Applitools, and I used to always be the highest record holder for the number of meetings in a week. Here, you just cannot compare. I’ve thrown all those records out of the park because we just do so many meetings. In every meeting, we ask a few questions consistently: Do you see the value? Is it important for you? Do you want to do it right? Then we look at the responses that come from a dev, and we look at responses that come from a VP of engineering, and we listen to the response of a QA. To be honest, today, if you don’t tell me the title, and you tell me the responses to these three questions after a demo, I’ll tell you whether it fits our ICP or not. Those meetings and those three questions are how you get to it. I think anyone who says, "I always knew about it from day one," I’ve not met such people, at least, who knew when they got going, "This is what it will be."

It will change. Again, whom do you go to first? Do you go to the head of engineering or do you go to an engineering manager? Those are, again, decisions that you make subsequently in the process.

[12:22.49] - Achintya:

Got it. That’s the definition in the qualification criteria. Tell us more about the top of the funnel. How do you reach out? What are the channels you use? How do you message things when you reach out to them?

[12:37.18] - Kanika:

See, everyone wants to get to the top of the funnel. I’m assuming you’re talking about the economic buyer in this decision-making process? We are at this moment completely direct. We’ve got an SDR team who does a phenomenal job. If they listen to this podcast, I’m giving them a big shout-out. They do a phenomenal job, but they are also limited in how high they can go. Usually, they’ll be able to get someone in middle management. But I’m fortunate to have some SDRs who can even get us top management meetings. That has not been a complaint. We also use alternate channels, which a lot of people would have explored, like LinkedIn message ads, to reach the right people. A lot of times, we may get to them, and they may not be right, but that’s really not the question you’re asking. Largely direct. We don’t have a channel partner model. A lot of people have approached me, asking, "Do you want to build one?" Probably not right now. It’s very early.

[13:41.49] - Achintya:

Also, when the SDRs outreach, too, there is definitely the economic buyer and middle management. How do you guide GTM leaders at early stages? Because in most cases, they see the buyer might be slightly up the ladder, but the SDR got a meeting with the mid-manager and might have to move up. In certain cases, you might have to move down because you started with the founder but then realized that it’s the VP of engineering. There’s always an orchestration, but you get an entry where you get an entry.

[14:13.31] - Kanika:

I’m going to go to the investor, then he will connect you to the founder. Usually, it doesn’t do anything, but it sometimes goes somewhere. You’re basically talking about navigating through the chain to figure out two things, right?

[14:30.10] - Achintya:

Who will purchase.

[14:31.16] - Kanika:

Who will purchase. Actually, more than who will purchase for a dev tool, GTM, what I feel is more important is who is your champion. Who will use the tool? Who owns the problem? Who is most affected by these microservices in your environment not getting tested properly? Or who is most affected if there’s a bug that is reported or you do 50 rollbacks and hotfixes? That is what our SDRs do, actually. They call everyone, and they don’t really sell a single feature. All they do is just ask, "Is this your problem? Is this your problem? Okay, this is not your problem, no problem. Okay, let’s move on." But if this is your problem, then let’s solve it. That’s one thing: find the person who owns the problem. Then we see two more things that I have learned over time, especially when I worked with Keith Butler, the CRO at Observe. He said, "You have to look for the person who can take you to the EBE." Someone who is insecure and trying to do a science project for themselves is probably not your buyer.

[15:43.28] - Kanika:

Yeah, Hypertest looks really exciting. I want to learn everything. Please send me all the details on Gmail, or let’s have a meeting on Saturday. Well, sorry, if it’s not important for you right now, then we are busy with people for whom it is important. I think devs are pretty good with this. They don’t really mess around. I’ve usually seen developers say, "Not a problem," and if they see a problem, they will be open to taking us to their manager once they have a bit of confidence. Nobody takes everything to their manager. I’ve really not felt that devs have let us down that way. But yes, so that. Then one more thing: you do a meeting with one person, and if he’s constantly the only one meeting you, he doesn’t bring in other people, which means he has no influence in the company. Three things: he owns the problem, he has the most influence or at least some amount of influence. I’ve usually seen people, he could just be a tech lead, but if he rallies five people in the next meeting, you know he’s your guy because he can make it happen.

[16:49.22] - Kanika:

Then, of course, he can bring his manager. We look for these three things. Honestly, if you don’t find them, then you could be just in a long sales cycle without a deal happening.

[17:02.00] - Achintya:

For early stages, what do you recommend to founders and GTM leaders at that point? Because you are discovering in many cases, it is a pre-product-market fit journey. What is it? What’s the stage when you say you can call it quits? Say, "Okay, it’s not working." You said only a few things work, a few things don’t work. Of course, you had your journey. You started with QAs but then moved to devs, and there were certain learnings involved here. What can they learn? What is a good time to call it quits and change?

[17:41.32] - Kanika:

It’s a good question. It’s a good question to a person who actually believes in never giving up. Because all co-founders should have huge arguments, so I had huge arguments with Shalind on, "Let’s keep chasing QA. Let’s keep chasing QA. I will convert the next QA guy." But when you do it over and over again and you see it is not working, and if you start applying first principles of how... and you see it’s working on the other side, I think that’s a good point to call it quits on this. I wouldn’t say just quit because five people said no. You will know. You’ll do it so many times, and you’ll see your passion fizzling, and you will know. That’s how I look at it. I’m pretty sure people have other experiences. I also believe that, especially if you’re on a tight runway, you also have to know if you’ve given more than a quarter to a particular strategy or a particular group of people or a method. I’m telling you, a quarter is very high in Hypertest. At Hypertest, we change things every two weeks. If it’s not working, why is it not working? You just have to constantly keep iterating and not get stuck. That just requires a different level of madness.

[19:00.18] - Achintya:

Right. No, it’s so interesting because, as I see it, at the early stage, there are a couple of experiments. There’s definitely a primary experiment that would have been talking to QAs and selling there, but there was always the secondary experiment: let’s get to developers. Then we started seeing that becoming more important as a pull rather than what we had.

[19:17.45] - Kanika:

Can I add something? Also with developers, the fact that we went and started asking them what problem they solve, a lot of developers don’t open up. I actually think that we still have a large majority of our opportunity untapped. That’s why we started looking for new things like Reo. Is there a developer who is looking for something similar to what we do in some other way somewhere on GitHub? Can I go and speak to that developer? I think those thoughts only come when you start getting deeply involved with solving the problem, which is: who is the guy? Who in this company owns this problem?

[20:02.42] - Achintya:

Cool. Kanika, the last question that I always ask in this podcast is, what are the sources, blogs, or any other resources that you recommend to early-stage GTM leaders for their zero-to-one GTM?

[20:15.02] - Kanika:

Yeah, sure. I’ve done long-cycle B2B selling for a very long time. My go-to books, if anyone asked me, would be very different from what I would say today. I think the biggest thing that developer tool companies face is indecision. There is one book, I kept it here, this one, which I think is extremely good. I would say, if you just apply it very directly to what it says, it can be very harsh. You have to be very subtle in using the language that has been communicated in the book. But I think most customers are open to a direct conversation. I’ve openly asked customers when they’ve said, "We would like to build and not buy," I’ve said, "Good luck with that. Can we explain to you what it takes to build something like Hypertest?" The Jolt Effect is a very good book. I honestly listen to more Stoic philosophy podcasts, which is also very good for all entrepreneurs because Stoicism is at the heart of entrepreneurship.

[21:30.19] - Achintya:

Cool. Thanks so much, Kanika, for spending time with us. This is very valuable learning.

[21:35.48] - Kanika:

Thanks, Achintya. Thanks for having me.