Ep. #52, Serendipity as a Service with Piyush Agarwal

Rachel Chalmers: Today I am thrilled to welcome Piyush Agarwal to the show. Piyush is the co-founder and Chief Revenue Officer at Reo.dev where he leads go-to-market strategy and sales. Over the past two years he's worked closely with over 100 dev tool companies, advising go-to-market teams on how to turn developer activity into pipeline gold.

A second-time founder with more than a decade of experience across consulting, edtech and fintech, Piyush brings a rare blend of strategic depth and startup execution. Before Reo.dev he built Scholar, an edtech platform that scaled to over 1.5 million students before being acquired by BYJU'S.

Whether it's product led growth or founder led selling, Piyush has been in the trenches and knows what it takes to scale dev tool GTM motions that actually convert. Priyush, thank you so much for coming on the show.

Piyush Agarwal: Rachel, thanks a lot for having me here.

Rachel: So I remember the first time I encountered the Reo.dev product and it just blew my mind. So many people have tried to do this, but Reo has a unique approach. What made you realize that developers leave better fingerprints than sales calls ever capture?

Piyush: Rachel, great question and I think this all goes back to us figuring out that this is a real problem. I'll give you some context as to how we stumbled upon this problem, to be frank. I think couple of data points.

One is my co-founder, he used to run the revenue function for a devtool company himself. So this is a problem that he faced firsthand, tried all the sales intelligence tooling out there, it did not work. So that's how we came up with this idea.

And then one of the stories that goes back almost two years, we were talking to a devtool founder and we asked him, how do you know who's using your product? And his answer was, we go to conferences and by serendipity we run into our users. And that to me just did not make sense because you've built a product, people are using it. How do you not know who those users are and where will your growth and revenue come from?

Rachel: So what we need is serendipity as a service.

Piyush: Yeah, I mean that's not how you build a business. I mean it's good to build a product, but if you have to build a business, then maybe serendipity is not your go-to strategy.

Rachel: You've advised over a hundred devtool companies. What is the biggest go-to -market mistake you see everybody making?

Piyush: Oh, I can go on about this for a long time. I would categorize this based on the size or the stage of the company. If I talk about really early stage devtool companies, which is really founding teams, I think one of the things that I've seen quite often is GTM comes almost as an afterthought.

You've thought about this wonderful problem and maybe built a product around it, but you haven't really thought about go-to-market, which is fine if you're doing this as a hobby, but if you're going to make this a business eventually, then you should probably start thinking about GTM a little sooner. I think that's what happens at a very, very early-stage of the company's journey.

As you mature a little bit, I think it's about really figuring out your ICP. So many early-stage devtool companies are struggling because they don't know who really needs their product. That is more than half the battle.

So if you could really sharply define, and it doesn't have to be a huge dam on day one, but if you can really sharply identify this team, this kind of engineering teams or AI teams need my product, then the odds of winning are that much higher.

And then if I roll forward a little more, slightly more mature companies, slightly more mature teams, I think there I see a severe lack of intelligence being provided to the sales teams. Sales teams are given quotas and a list to go after, but not the intelligence that they need to succeed. And this is a very tough category.

I mean you're selling something to an audience which is so learned, which is so technically savvy, way more than you are. Most of the salespeople are not developers, right? So you have to give them the intelligence to succeed, which I see as a big gap even in the biggest of companies. Like we've worked with some public listed companies, Fortune 50 companies, and even there, there's a paucity of intelligence being provided to the sales teams.

Rachel: So as I said, tons of people have tried to gather the publicly available data on developer behavior from GitHub and GitLab to provide this kind of intelligence to sales teams. Many have failed. How do you at Reo tell the difference between developers who are just kicking tires or playing around and the kinds of behavior that are the prelude to an actual sales motion?

Piyush: Great point, Rachel, and I love that you touch upon this because to solve any problem deeply, you have to really care about it. I think what's unique about Reo.dev is 100% of our users come from the devtool industry. So we really care about what is the difference in the buying behavior of a technical team as compared to any other team.

And I'll tell you what are the big differences there. If you think about a technical team, whatever they are building is infrastructure that will power the product of your company. And if something goes wrong at the infra layer, it has big repercussions. Your product will be down, you will lose business, and so on and so forth.

Therefore, developers are very, very careful about picking the right products. They go through long detailed evaluation cycles and you have to support them in those evaluation cycles. And therefore, if you don't capture the right signals, if you don't interpret the right way, you will start interfering either too early when they're not ready to buy or too late when the decision's already been made.

So you really have to spot that window of opportunity when this team is in market. And if you do that, you are less likely to run into tire kickers and more likely to run into real opportunities which will convert into paying customers in revenue.

I can talk a little bit about signals. What kind of signals mean that there's a revenue opportunity versus somebody just casually browsing. And I think both are important.

If you're going to build like a generational company, you can't ignore the tire kickers because they are curious today, but they are your buyers of tomorrow. You have to support them.

But then how do you figure out who's ready to buy today? I think there are some good telltale signs over There you will see things like team evaluations. You will see multiple people getting involved. You will see them looking at things very differently than an individual developer would. And it depends on the category a little bit.

Some categories are very prone to curious developers. Some are not so prone because it is an enterprise product. But at end of the day, if you really classify your signals well, you should be able to figure it out.

Rachel: How does the rise of AI and generated code and agents complicate this picture? I mean, I can imagine a single developer setting teams of agents onto multiple software products, looking just like a team of actual developers performing evaluation. Is that muddying the waters?

Piyush: It's actually making the job of a sales team that much harder.

Rachel: Yes.

Piyush:

If you go back 15, 20 years, the sales team would pick up the phone, call the CTO, make the sale, and then the CTO would go and enforce the product. When developers came in the picture, this whole motion collapsed. Now, developers are the real evaluators. They are the influencers. And if you don't have them on your side, it's not going to work.

And oftentimes when you're calling up the CTO, it doesn't help because that person doesn't know what the team is evaluating. So your product's relationship is really with the developer, not with the buyer. And you have to navigate all of that as a sales team.

Now, if you think in the future what's going to happen is that this relationship between your product and the buyer is getting abstracted even further. There's a developer in the middle, and then there's an agent which is doing stuff on behalf of the developer. So really the answer lies in figuring out what's really happening in that engineering team, what's their priority? And if you can figure that out, then you will be able to drive go-to-market. Otherwise, it's just like spray and pray.

Rachel: It sounds like magic. Are you actually using any generative AI in the product?

Piyush: I think significant, there are two types of AI use cases in our product. I would say one is predictive, and then the second is generative. I think we use predictive AI very heavily to predict which one is a real revenue opportunity while which one is still getting there. You got to nurture it more.

And there's so many use cases of that in our product, because at the end of the day, what we're serving is intelligence. Then the second layer, Rachel, is where generative AI comes in, because all of these intelligence data points are there in the product. Can we make the job of a salesperson easier? That's where generative AI comes into the picture for us.

Rachel: Totally makes sense. Why did you choose commercial open source as your wedge instead of going broader from day one?

Piyush: I think it's an interesting question because we never thought of the market this way. It's the market who taught us that not all dev tool categories are the same. I mean, this is two years back, when we started building Reo is when we realized that the problem statement also varies with sub segments.

And I mean we have come a long way from there. Today, almost 50% of our customers are closed source and the problem statements are slightly different. In an open source company, I would say the problem is so deep that you don't even know who your users are. And then the next layer of complexity becomes, okay, who's going to become my customer in the next quarter or the next year?

I think the similar problem, or a very similar problem applies even for closed source companies. You don't have the advantage of them using your open source. But you still got to figure out are they really facing the problem that you can solve? If they're not facing that problem, there is absolutely no point chasing them from a revenue perspective.

Dev tool products are not whimsical purchases. They're not casual purchases. They solve a problem. If a team is not facing that problem, they're not going to buy. Buying a tool is probably 20% of their job, 80% is implementing it. So they're not only thinking of your product as the cash that they will invest, but more about the time. So really it's about finding that cohort which really feels the pain. And for us, on day one, that was commercial open source.

Rachel: That makes sense. Are developers transparent about being in this purchasing product or do you get pushback just because you're finding them at this vulnerable moment?

Piyush: You know, I think this is one of the things that we have found to be a myth that developers don't like to buy or don't like to talk. They like to talk at the right time.

Rachel: Yes.

Piyush: We have rarely seen an engineering team push back on help or support, or even a sales team knocking at them when the timing is right.

Rachel: Can you give an example of a hidden sales opportunity your platform found that a traditional sales team would have totally missed?

Piyush: Let me give you a couple of these examples. I think the first one is developers struggling in silence. It's such a fantastic opportunity. But the typical nature of an engineering team or a developer is, "I will figure this out on my own," because they are builders at heart.

So you don't want to give up when you see a problem, you want to solve it. But then there is a flip side to that curiosity or that challenge, which is you are consuming time and maybe not solving it in the best way possible. So I think one of the things that we really help our customers do is find engineering teams who are silently struggling so that you can proactively reach out, offer help. And more often than not, that converts into a revenue opportunity.

Rachel: It's been hugely successful for you. You've raised 4 million. Congratulations. And now you're opening a US office. What changes when you go from India-first to dividing your attention across continents and the most incompatible time zones in the world?

Piyush: That's the most fun part. It's almost exactly the opposite side of the globe.

Rachel: As an Australian, I feel the pain.

Piyush: I think it's been for us, we have worked with a global set of companies from day one. Our first customer from India was our 40th customer. So we've been a global company from day one, serving a global audience. But I think for us, opening a US office was mostly an endeavor to getting closer to our customers.

For example, just yesterday I was at the office of one of our customers and what was supposed to be a 30-minute meeting converted into a three and a half hour whiteboarding session. And the ideas that came out of that discussion cannot happen on Zoom. And for us, it was really that, how close can we be to our customers? Can we really sit in their offices and problem solve with them? And I think that's where the US office has been such a great boon.

Rachel: Well, it's wonderful to have you here. If you could only track three developer signals out of all of the signals that you are collecting and tracking, what would the top three signals be in terms of cueing you in to where the team is at?

Piyush: This is a tough one to generalize, but let me give you broad strokes.

The first one is developers playing with your code. That is by far the number one signal because it tells you that this person or this developer is right now in the middle of building something.

And then you just need to qualify what stage of adoption are they in and is this the right time to intervene or not? But tracking how are developers interacting with your code base is the strongest signal that we have seen across categories.

I think the second one is, again, I spoke about this a little earlier, is developer struggles. Are they stuck somewhere? Are they not able to figure something out? Are they trying to build something but they need help? Are they worried about some aspect of your product, like scalability, compatibility and so on. I think that cohort of signals is again very, very powerful.

And then I think the third thing is the context of that engineering team. What does this engineering team typically work on? What's their stack? What kind of technologies do they prefer? What is the engineering philosophy of this team? I think if these three things are put together, or I would say these three are the most overlooked signals that most of the dev GTM teams have not been looking at.

Rachel: So just as a thought experiment, Reo is fantastic, but it's a for profit company and a product that you have to pay for. Assuming that a very early stage founder can't yet afford Reo, although they're going to be very successful and they're going to buy your product in the future, how might they get started? What publicly available tools and signals could they use to detect those patterns that you're talking about?

Piyush: It's hard, to be honest, because a lot of this is not available that easily. That is the whole reason we built this product. I think I want to start by thinking about how expensive or inexpensive a tool is. It depends on how you look at it. Are you looking at it from an opportunity cost perspective or are you looking at it from a price perspective?

Like if I'm investing in a tool, I would really look at the back end. I would say that even for a very, very young startup, nothing is expensive out of the box. It depends on what are you getting in return. Like if you hire somebody for, I don't know, $200,000, is that person expensive? It's very hard to say unless you know what are you getting from that person.

If that person comes and changes the trajectory of your company, then that was a great deal. And I think we're not prohibitively expensive. But if somebody were to not use Reo, I think their best bet would still be to figure out what kind of engineering teams have the most urgent need of their product, and where will that data come from. You'll end up putting together multiple tools or spend significant bandwidth in building it ground up, only to rip it apart and replace it with something like a Reo.dev later down the road.

Rachel: So you heard it here folks, even if you're super early stage, at least look at Reo or hack something together yourself from what you can in GitHub and LinkedIn and see how far that gets you.

Piyush: And like you said, we are always happy to help support. We are early-stage founders ourselves, always happy to support early-stage founders.

Rachel: Piyush. How do you learn about the market? What are some of your favorite sources for learning about AI?

Piyush: Rachel, candidly, I'm so fortunate because we work with a lot of AI companies and I'm spending almost six to eight hours with my customers a day. So I would say that is my number one source of learning about this industry. What's the latest? And every day I'm surprised by the innovation that's happening in this industry. It's moving so fast.

So I would really say my customers and this industry, the people that I talk to every day, they teach me a lot about what's happening in AI.

Rachel: I love that. When I was running Alchemist Accelerator, I used to try and teach startups that customer discovery is not a one and done customer development is the lifetime of your company. So the fact that you're doing these whiteboard sessions with your companies and learning from that, all founders should be doing that.

Piyush: I'll give you a statistic. This was a couple of weeks back. I was sitting and just trying to see how did I spend time in the last 365 days? I think we spent north of 1500 hours talking to customers and prospective customers and devtool builders last year.

Rachel: That's really impressive. That's what, 30 hours a week?

Piyush: Yeah.

Rachel: Fantastic. Piyush, you're immensely qualified to be Prime Minister of the Galaxy. So congratulations. I'm appointing you. If everything goes exactly how you'd like it to for the next five years, what does our future look like?

Piyush: I think GTM Spam would reduce significantly.

Rachel: That would be so great.

Piyush: Our mission is to eliminate GTM Spam. Just reach out to people who need your product and just go talk to them.

Rachel: It's a brilliant vision. You've got my vote. Last question, favorite question. We're called Generationship, after the starships we're going to build that will take hundreds of years to get to Alpha Centauri. I'm giving you one of these for your position as Prime Minister of the Galaxy. What would you name your generation ship?

Piyush: Amazing. I think this is the best gift I've received. I would call it Perseverance.

Rachel: Perseverance? Yeah. That's a beautiful name. How does that apply to your work?

Piyush:

I think it applies to anything that you're doing. Because if it's difficult to do, you most likely won't get it right the first time. What will eventually get you there, just like a starship is the perseverance to just keep going down that path.

Rachel: Yeah. Samuel Beckett said, fail again, fail better. It's a very powerful mantra.

Piyush, it's been an absolute delight to have you on the show. Thank you so much. Good luck with the US office and with all of the work that you're doing, I've no doubt we'll be hearing a lot more from you.

Piyush: Lovely, Rachel. Thank you so much for having me.