Product-led growth is the holy grail of customer acquisition and expansion for most technical companies but often falls short of generating the revenue turnover needed to truly scale.
This talk explores ways that product-led companies can build credible revenue teams for technical buyers and covers practical strategies for introducing a human touch to revenue growth. This will be presented through the lens of consumption/usage growth and is mostly designed for Customer Success and Sales leaders with an eye towards founders in this space as well.
1 / 26 Use ← → to navigate
Auto-generated transcript - may contain errors.
Tap a timestamp to jump the video.
Hello. My goal today is to share some ideas with you for building successful revenue teams at product led technical organizations. Very briefly about me, I was born in New Jersey. I've lived in the UK for almost six years. Still sound like this, but, New Jersey, it's actually a nice place despite what the media may tell you.
I built my career at Twilio from series d through IPO and then being a publicly traded company. I'm now at a a climate tech startup called Watershed. And during my time at Twilio, I held roles across almost every function in the go to market organization.
So from building the customer success team, in the States and then across in Europe, running the engineering support team, did a stint in sales just because I enjoy suffering. And then I was leading operations as chief of staff for Europe as well. So sort of that whole scope of what go to market looks like and how go to market teams in different ways plug into the more technical sides of the organization.
For those of you who haven't heard of Twilio, it is an API platform for communications. So deeply technical product and really focused at software engineers, software developers. And I think over my time there, I really wanna share a bit about what I've learned and hopefully will be useful for you in the room today.
The first is ideas for how to build a revenue model in a deeply technical product led organization, some thoughts about how to find the right go to market people for your type of organization, and then I'll close out with some ideas of how to build a whole company revenue culture when you're in that more product led space.
Just to set some context, so when I say technical product led organizations, this is typically features and characteristics of what I mean. Your organization might have one, two, all of them. But these are really organizations that lead with documentation and quick starts. Your customers probably will tend to build a solution rather than buy a solution.
Your target audience is more likely more technical than not. Again, think software engineers. And then b to b. So I know that there probably are also lots of b to c product led organizations. For the purpose of our conversation, we'll sit within the b to b space.
Sorry for anyone who's afraid of clowns. This is an image that came from one of my first all hands when I very first started working. And this image was thrown up on the screen at an all hands organization by an incredibly senior leader at the organization.
And this image was used to essentially describe salespeople. And this very senior leader was up there and was cracking jokes, and you could just see the sort of scattered people who were in the room, who worked on the go to market side, just their faces kind of fall.
Some people were very clearly getting angry. For those of you who work in technical roles, if you think of salespeople and see this in your head, keep your answer in your hearts. But I do think that this really does embody, a a fundamental tension between two sides of an organization, especially in technical orgs where the product and engineering side may or may not necessarily trust the more go to market, less technical side.
And this is, you know, something that these organizations tend to struggle with. Why is this a problem beyond just the obvious cultural implications of of disrespect, resentment, miscommunication that can come from this? It's actually a real risk to your business. This fundamental misunderstanding can really create artificial walls between two sides of the house that fundamentally need to work together.
I think the basic premises of product led organizations is that, you know, your product is what drives customer acquisition. At the same time, that money tree is only gonna grow itself so far before you start to need people to come in and really push it further.
If this is sort of the perception of that side of the house in your organization, you're really gonna struggle to make those two sides work together. Right. So with that cultural context in mind, I wanna share an example of how addressing that head on really led to a positive outcome in our organization.
So imagine yourself, we were in many customer meetings that looked just as joyful and and pleasant as this. And one of the things that we were trying to figure out was the messaging side of the product was doing extremely well. We were seeing huge customer adoption across sort of every range, mid market up to the enterprise.
But our voice product was really struggling. And we couldn't figure out why we weren't getting enough adoption. We couldn't really figure out why for whatever reason, what we felt was a far more valuable product was gaining less than no traction. And part of the reason for that, as we learned through multiple conversations with customers, was that they just felt it was too clunky to use.
And the people who were responsible for managing voice solutions, for talking to customers over our voice product, weren't engineers. They needed a better solution to be able to manage their workflows in and out that didn't require them to talk to an engineering team or build a fundamental solution from scratch.
So we iterated on these conversations. We gathered all of the information we probably possibly could. And this was really resulting in a new solution that was called Twilio Studio. And this was essentially a drag and drop widget interface that eliminated the need for people to be able to do, build build their own solutions and kind of use our APIs rather than something that was more user friendly.
Why am I telling this story and why is it important? Doing good product looks like doing great sales and customer discovery. If you're gonna be building a product that your customers need that actually solves a problem for them, you need to be doing good sales and customer discovery and plugging into that information between your two sides of the organization.
I would like to posit that in product led organizations, there's actually no such thing as the revenue team. You need both sides of the house to be accountable for revenue, to be working in conjunction to grow the business. And I would like to transition to some ideas for how how you can do that.
Business buyers buy from people. I know I'm probably stating the obvious here, but for organizations who are especially looking to move up market, you're going to need folks who can talk to your business buyers and can really drive that value conversation to reach some of those bigger, larger enterprise customers.
This is a wild oversimplification of what this might look like, but bear with me as I walk you through how to think about structuring a go to market team in this context, and hopefully you walk away with some ideas that you can apply to your own organization.
So the bottom of this pyramid is is literally everyone. Whatever your intake point for customers is, you really want your product leading the way and you wanna make it as easy as possible for people to get started, for people to get building, and testing and trying what you have to offer.
As you start to move up market, you really wanna start to blend and think about how you use your revenue team in conjunction with your product. The best way to think about this is your product is the momentum, your people are the accelerator.
So as you're starting to move up that mid market range, you want those two working in really close conjunction. So you've got the less expensive side of, hey, my product is driving this and giving me my momentum, and then I'm accelerating the expansion size of those potential deals by bringing in sales people.
It gets to be a bit different when you move up into the enterprise. Seek and ye shall find, this is really where people are going out into the market, generating leads, whale hunting, really going after those big brand labels, and you're you're a bit detached from the product doing that for you.
But what's actually happening here is that revenue team can create some really good signal about what those types of customers and prospects want to see from your business. So you wanna start cascading that back down so that your revenue team can then act on that signal in your lower tiers of your customer base.
Why is my arrow pointing down? Because underpinning all of this are your product and your engineering teams. And if you nail this, what you actually want to see, I know cycles don't have points on them, but what you really want to start doing is creating this generative cycle of learning from your foundation and really creating a product that's accessible to the whole market.
And then iterating as you go up that funnel to the larger enterprises so that you're closing those bigger deals and driving more revenue. Now, to make all of this work, you need to find the right people. Again, these are a bit of generalizations, but across all of the revenue roles that I've held, these three things have held true across the most successful folks that I've seen during my time.
Just to anchor us in what I mean by revenue roles. So on the revenue acquisition side, these are folks who are going out in the market, drumming up new business. You've got your more entry level folks, SDRs, sales development representatives, your outbound commercial AEs, all the way up to the enterprise.
Your more technical folks who might be supporting those sales reps as they go out to market, and that's sort of one side of the coin. The other is revenue expansion. So the easiest way to make a dollar is to take someone who's already spending a dollar with you and trying to convince them to spend another one or pound, I should say.
And these can spend all the way from your product support team, your account managers, your CSMs, your technical account managers, depending on the structure of your organization. But both sides, I think, what I'm about to show you really do matter. The first is curiosity.
And I think this really matters because at the end of the day, selling to customers is all about solving a problem for them. You're not gonna solve a problem if you don't understand it, and you're not gonna understand it if you don't have folks who are willing to commit to a really good discovery process and who have a genuine sense of curiosity about what your customers are struggling with.
I found a really good way to test for this in interview cycles is to actually ask your your candidate to teach you something. It might sound counterintuitive, but it really gives you a sense of what drives them. It gives you a sense of what keeps them interested.
And then it also gives you a sense of how they use that curiosity to explain something back. The second is problem solving. And I know I might sound like I'm stating the obvious here, but this is much easier said than done. What you're really looking for here is how quickly someone goes from questioning to recommending.
And you wanna make sure that they are spending as much time as possible on the front end of that equation because the reality is you, again, cannot solve a problem unless you properly understand it. The way that we have interviewed and the way that we've tested for this in interviews is really role playing, where we'll put a customer problem in front of a candidate and ask them to essentially pretend to solve that problem with us, And you get a really good sense of how they explore and poke
out what that problem might be, and how they think through constructing solutions. I think this next piece is probably one that's worth a little bit of debate. But what I've seen work best is, you know, folks who come to the table with a real sense of technical aptitude.
You're not trying to hire engineers to be salespeople, but I think the most critical piece of bringing on folks in the context of technical organizations is ensuring that they're able to have a shared language with the product and engineering side of the house.
That's critically important. I think one of the ways that we've seen this show up and the way that we test for it is is case studies. So we've gone back and had a look at, you know, here's a pattern of customer problems that we've seen in the past.
We're gonna construct these customer problems in such a way that we're gonna force our candidates to come in, evaluate those customer problems, and then in the interview process, actually walk us through how they identified ways to solve those problems using the products that we offer and bring to market.
I also think that this builds credibility. At the end of the day, you want folks in front of your customers who are credible, who can really put their money where their mouth is, and testing for this technical aptitude upfront really starts to bake into your overall culture that you're a shared team.
So if you're a start up, I think it's gonna be really important to think about finding kind of the magic trifecta and spending the time to find go to market people who embody each of these three things somewhat equally. You're gonna be asking them to wear a lot of hats.
You're going to be asking them to do a lot of stuff that might be beyond the very narrow role of just being a salesperson to start. So really testing for these three things is gonna make your job and your life a lot easier in the long run.
For mid sized organizations, I think you've got a little bit more flexibility across all three. But from my perspective, I think what I've seen work best is over rotating on the problem solving and curiosity piece. Because inevitably as you start to grow, you'll be able to have more technical resources to sit alongside your go to market team as they go speak with customers.
And I think that equation flips somewhat for the enterprise where in theory, you've got a fairly significant technical team, solutions architects, sales engineers that can sit alongside your sales reps as they go out into the field. So you still want that technical credibility there.
You want folks to have a decent understanding of what you're building. But I think the curiosity and problem solving piece, that ability to do really, really good tight discovery, starts to become slightly more important in the enterprise context. Ideas for building a revenue culture.
So I began with a mildly horrific picture of a clown. I think part of that was really the biggest impact of that image of that all hands meeting was on the culture. And I think there was a lot of uphill work that had to be done to reset the the perspective that folks on the revenue team had, the disrespect that they were wrestling with.
That took a lot of time to fix. It took a lot of time to resolve. That trust took a lot of time to rebuild. So these are just some ideas for how do you build a revenue culture across your entire organization, whether you're on the technical or non technical side.
Become a part of each other's worlds. I've never actually seen the Little Mermaid, but I've heard that's a song in the film. And I think in summary, goal is to really create a unified vision of what you're working towards. I've divided this into two sections and the first is structural practices.
By structural practices, mean, these are the things that your organization bakes into its operating cadence. This is part of how you run your business. This is part of how your teams work together, and they're non negotiables. Not every single thing on this list is something that needs to be adopted, but I do think that each thing on this list is something that has tangible impact.
You can go back and you can iterate on it, and it does build a shared sense of accountability. Shared parsed mode it's hard to say fast. Post mortem exercises are incredibly useful. We've used them in sort of two separate ways. So on the technical side, where there's been incidents with broad customer impact, making sure that you've got revenue folks sitting in those war rooms, making sure you've got folks on the customer facing side of things, sitting in the resolution meetings and making sure they've got a really clear understanding of what happened,
why, and what's being worked on. Is a gonna build a lot of empathy? Those teams are gonna see what the technical side is going to going through to bring forth res resolution. On the flip side of that, you've got really good shared context so that you can then bring answers to customers who might have them when things go belly up.
I also think it's really important, we do this on our deals. So when a deal is lost, bringing in product folks especially to sit through a deal postmortem to understand why that customer didn't choose your solution, why a customer potentially churned and left your platform or left your business, really creates that shared sense of accountability of revenue and customer ownership.
But it also helps both sides of the house really understand what customers care about and how to resolve those issues to prevent the same thing happening in the future. Product team deal sponsorship is fairly self explanatory, but this works really well when you're trying to push either a new feature out into the market, or it works really well when you're trying to expand a new set new area of your platform out into the market as well.
It really ties product decisions, product roadmap to revenue outcomes. And again, it kind of closes that feedback loop between what sales is seeing, what product needs to know, and tightens that cycle between the discovery of, hey, here's what a customer problem is, to product actually going and building something to solve it.
Technical team embeds is something that I'm testing out in my current organization. And it's an interesting play on how do we again close that gap. So the way that this has manifested itself is we've actually put account managers and CSMs onto product teams for a quarter or two.
And their entire job is to go back and answer products questions with customer They sit in team meetings, they sit in road map review meetings, and the entire goal here is to really make sure that there's a mini voice of the customer that's being heard on the technical side of the house to deliver the best outcomes.
I think these last two are, you can customize them as you need to. So customer advisory boards are are I tend to see them we've seen them and done them at a much more mature scale, but I think an organization at any size can use them.
I think the key to making these work is really bringing in vocal customers. So customers who have really strong opinions about what your product does, really strong opinions about how your product impacts their business, and then bringing them together to share ideas, but ensuring that the folks from your organization internally are sitting in those boards and listening to what customers have to say.
Shared quarterly reviews are something that we do externally with our customers. People call them QBRs, people call them EBR's. There's a lot of alphabet soup around them. But they tend to reside on the sales and account management side of the house. They're really good exercises to understand, hey, where's our revenue going in this account?
Is the customer seeing enough value out of our solution? Get your technical and product people into those meetings at least once a year. It's a really good way to build credibility with your customers. It's a really good way to show your customers that that side of the house is also committed to their success.
And it's a really great way to hear directly from the people paying for your product, why they do so, and what they need from you to continue paying you for it. Cultural practices. These are very much bend to the will and the shape and the vibe of your organization.
But what I've seen work in my experience, at Twilio as well as at Watershed, this is the way that you get teams to actually talk to each other internally and to build that camaraderie that you need for a single unit and a a team that's cohesively pulling in the same direction.
We used to do own the ticket days, and this was once a quarter where the technical side of the house, the revenue side of the house went into this support queue and were responsible for answering tickets for a whole day. It takes some planning.
It means that you really need to understand what work needs to get done before doing this. But we found the outcome a, built a ton of empathy for not just customers, but also what the product support team had to go through. It also really helped us understand where gaps were, where we needed to either fix things because of ticket patterns, or understanding how customers saw our product versus how we thought they saw it.
Shared hackathons is an interesting one. We used to do this, once a half. And the way that this would work is the CSMs and the account managers would essentially say, right, over the course of a quarter or two, we've noticed these three things tend to be the biggest customer problems.
We'd bring them over to the project product and engineering side of the house, and we'd spend about a day trying to figure out how to fix them and kind of having those tiny, mini embedded teams, putting forward solutions that would then become road map recommendations side by side.
One of my favorite traditions at Twilio is earning your track jacket. And this is an expectation of all employees where you essentially had to learn how to use the APIs, come up with an idea for an app, build that app, and then present it out to the rest of the organization.
There's a theme here, this idea of building empathy, this idea of getting your hands dirty and understanding what your partners are doing on the other side of the organization. But it really taught and really tested that technical aptitude I spoke about earlier. But it also made sure that people really understood how the product worked and understood how to explain it to customers.
Lastly, I think all hands meetings and what we like to call show and tell meetings are really cultural milestones and really that cadence within your business that provide an opportunity for shared celebration. It's really important when there are wins that both the technical and nontechnical sides of the house are celebrating together.
It's a really good way to recognize revenue generation coming from both sides of the house. And it's also a really great place to present customer stories where people can ask questions and learn from each other where success has been had. So for startups, I think this the the structural piece of this is really important.
As you're starting to think about learning what your customers want from you, learning about how you wanna build the the model and structure within your organization, implementing some of those structural pieces is gonna be really important from day one because that's the pattern you're gonna continue with, especially as things get busy.
On the mid size of things, I would recommend having a look at where your gaps are, where you think there's either misunderstanding or a lack of understanding, and then backfilling some of those ideas to potentially solve for it. And then on the enterprise side of things, think understanding within the different verticals of your business where there's opportunity to bring those two teams closer together, and then getting really strategic about how you're using that time, what kind of things that you want to implement within the existing structure of your company.
So I just wanna leave you again with this idea that there's no such thing as the revenue team in these product led organizations. At the end of the day, everyone is equally responsible for the organization's success, and the more both sides of the house can work together, the better off everyone will be.
And I'd really like to thank you all for your time.
