Sales–Product Tension: The Secret to Segment’s Success

Sales wants more features. Product gets bogged down with one-off requests. Progress and growth grinds to a halt. It’s a familiar story. In this conversation recorded at ELC 2023, Segment’s former CRO Joe Morrissey and former chief product development officer Tido Carriero discuss how they turned sales-product tension into a successful $3.2B acquisition.

Tido: Thank you. We’re excited to be here. Joe and I worked at the hip for several years at Segment. 

Before I hop into my part of the story, maybe I’ll, ask Joe a question.

Joe’s start as CRO

Tido: Joe, what were your first impressions of me? And feel free to tell some of the lower moments at the beginning of our relationship. 

Joe: The first time I met you was in the interview process. And for me, you were one of the big reasons I joined the company.

I thought, “wow, this is going to be a great engineering partner to work with. He really gets it.” And then when I joined the company, you and I had a meeting. 

And your feedback to me was, “look, this product is great. The problem is the sales team. The sales team don’t know how to sell the product. they could do it when we were small. Because when we were small, we could put every single salesperson through product training 

And then they just went out and sold. And now that we’re big, we can’t do that anymore. So my advice to you is, put everybody through product training.” And immediately I thought, “Oh boy, this is going to be more difficult than I thought.: Because I fervently believed that salespeople shouldn’t be selling on product and features.

They should be selling on value. And we really didn’t do that at Segment. I think that was one of the root causes of our challenges. And so, as I went around and I interviewed some of the other executives, I heard similar things. But I also heard different things about what the product was, and I was totally confused. So at one of the first e-team meetings I attended, I asked everybody to write down the answers to 3 questions. What problems do we solve for our customers? How specifically do we solve them? And how do we do that differently or better than the competition? There were 6 people in the room, and when we went around the room to have everybody read out their answers, we got 6 different answers. And what was clear to me was like,  we had built a great product. We’d actually built lots of great products.

 And at one stage, I think we came to the realization that we had built too much. Now, sales was partly to blame for that, as we’ll talk about later. But, we didn’t have a focus on who to sell to, what to sell to what to sell, and what value to articulate around that.

And so, that’s what I set to work on doing, in the first year: trying to drive some clarity around that. 

 So now maybe you can talk about the low point.

The low point: annual planning

Tido: A little bit into Joe’s tenure, we were, tasked with doing annual planning together. And I have this memory, I was halfway on vacation in Tahoe, but trying to do annual planning. And I was so frustrated with Joe, and what I felt like were these impossible set of priorities.

The key piece, as I think about the story now years later, was this alignment around value drivers. And it was not the most fun session we’d ever done. It was 48 hours basically locked in a room.

But it was Joe, maybe 3 or 4 of his top- performing AEs, SEs,  people who really had had a lot of success selling to different verticals and segments. We had several folks from my team, several of our longest-tenured PMs, all the co funders, most of the exec team. And we just sat there and asked ourselves these incredibly simple questions, which in retrospect, how we made it to tens or low hundreds of millions in ARR before we had ever really asked ourselves these questions blows my mind. But I think that clarity of, what the value was that we provide our customers, what they are really paying for, and what they care about was the thread that really started to unite us and started to bring us on the same page so that we could have a clear list of things to go after. A big piece of that and a partnership I hadn’t had on the go-to-market side was I finally had a partner who was really going to say: we do these 4 things incredibly well, and if you are not one of these 4 things, it’s actually revenue that we’re going to say no to. And so, once I realized that I could really rely on Joe to hold the team accountable to the boundaries we set together, that started to unlock, I don’t know, beautiful alignment and things we could go tackle.

Joe: So maybe I’ll let Joe tell a little bit of the story of the annual planning process and what we agreed on.Sure.And, you know, I remember I went at you really, really hard, but we had a huge number to do the next year and most of it–almost all of it–was coming from sales capacity, right? So I knew we were going to have to hire a lot of people.

It seemed like an impossible hill to climb. And historically, Segment’s growth had come from us building new things, launching new products. Before I arrived, the company was like launching products all the time. It had a tremendous product velocity, right?  And now, all of a sudden, we weren’t able to build anything anymore. For my entire time there, we hadn’t launched a new product and a lot of what we had wasn’t quite working.

So as we started going through the annual planning process, Tido, you sent me a list of 25 things that you could build in the next year, and you asked me to rank them 1 to 25. And as I looked through the list of things like HIPAA compliance and cloud prem solutions that our customers were really, really clamoring for, I thought, “there’s no way we will build any of this,” right? And so I went back to you and I said, “Look. Just do three things, okay?”

Let’s get product quality nailed down. Two, let’s make the platform extensible, right? And that was really, really important because we had to build up professional services. We had partners who could do things themselves if we had made the platform more extensible. And that would mean that there would be less lift on the engineering organization. The engineering organization would then be able to build more product later. But if we didn’t do this, we would never get ahead of the ball. And then the third thing was multi-region support. Because a big part of the number that I had to deliver the next year was international expansion.

And without it, without multi-region support, all the people I had hired and all the investments we had made in EMEA and APAC, we would just have to let those people go. And I didn’t see any other way to make the number up. And so I felt pretty happy about myself, going, you know, “aren’t I a good guy? I’ve just said no to 25 things and I didn’t ask Tido to build anything new.” And instead you started pushing back on all of those things eventually. And I was so frustrated. I felt like I can’t make this number. The partnership is just not working. 

Building a more focused product roadmap

Tido: Yeah, I had always, had in the back of my mind this spare capacity of 40–50% for customer emergencies. And so, I was still operating under that capacity assumption that there were just going to be all of these customer emergencies where someone had sold slightly outside of the lines. You know, 40-ish percent of capacity going to solve these little emergencies here and there, which are often were featurettes that no one had ever really said we did, but the marketing materials kind of said we did, and it was a reasonable assumption that we did it based on where we were with the contract.

And so, the big unlock for me, and I think what I needed to lean into more from a trust perspective, was that Joe was really going to be a different kind of go-to-market partner. We had zoomed way out. We had looked at a multi-year strategy, not just a list of 25 features and ordering them quarter by quarter by quarter, and we had really aligned that we can hit this plan together over the next 12 months and set us up for another good 12 months after that, if we do these 3 foundational things.

And so, a big piece of the puzzle for me was going back to the team. And the team had been accustomed, of course, to shipping several of these new features every year, at least, if not more often, and several of these customer emergencies, and saying, “pretend we don’t have to do any of that. Really, how fast can we do multi-region?” That was the really big one, multi-region. We had had a very senior engineering team look at that very closely and the estimates had come back several times that it was like a 24-month project. And that was delivered in, I think it was 13 months. That was because we had freed up all of this other capacity.

And so, the thing Joe brought to the table here was that we’re really going to tell customers if we do not do one of these things, that we don’t do it. We still would like them to be customers and, you know, here’s an SE workaround or here’s what you can do on the platform and build it yourself, or we can give you services to help fill in the gaps here. But we weren’t going to just endlessly promise that engineering will fill in the gaps. 

Joe: So just on that point, Peter later remarked that it was interesting that the best annual plan that we ever did, which came out of the struggle that you and I went through, was one that he was totally not involved in or there for. Which kind of spoke to me of, like, the learning is always in the struggle. You’ve got to go through this tension, you’ve got to embrace it, and you’ve got to find a way to resolve it on both sides. Because out of that comes platform for, driving growth. And I think one of the things that can happen is you avoid the tension, you avoid the conflict. You say yes to things that maybe you’re not comfortable with, both on the product and on the go-to-market side, and then the plan goes wrong. 

But I’m curious, Tido, now that you are founder and CEO of Koala, you’re leading both engineering product and sales. What have you learned now that you’ve crossed over to the dark side?

Why GTM feedback is essential to building great product

Tido: You know, I think my biggest learning is to get someone to the point where they are so excited about your platform and they are ready to go and there is one little rough edge that seems like a pretty minor thing in the grand scheme of things of the platform, but it prevents their whole use case. And how frustrating that is as a seller to not be able to really learn from what’s going on in reality in the market. And you feel incredibly connected when you’re having dozens of these conversations a week with customers. And so, I wish I had realized what a valuable resource the go-to-market feedback was back at the time, because this truly is a megaphone that is blasting the message with 100 people or 200 people, and they’re also collecting all of this feedback about exactly what’s going right and what’s going wrong.

I just don’t think I had a appropriate appreciation for both how hard it is to get someone on the brink of really committing to a large deal with you, and I wish I had done things a little differently in retrospect. But the other big piece is just how valuable that feedback is when it can be synthesized.

Obviously, a platform can’t be everything to everyone, but that synthesis and those mechanisms for getting scaled feedback… I actually think the stuff we were getting from our sales engineering team—those were like Joe’s real product specialists—sales engineering team, CSM team, some of the best AEs, some of the best AEs in particular regions, some of the best AEs in particular segments, all of that stuff is just like A+++ feedback. And over time, I’ve come almost to appreciate it more than what a PM is going and getting. When I think about what a PM is doing, they’re randomly reaching out to 3 to 8 people. And often these go-to-market experts have spent, you know, 100 calls in the last quarter or 2 and just have a lot more breadth, and sometimes even depth, than what a PM team can go do.

So, a lot more appreciation for all of that feedback. 

Cool. Should we open it up for audience questions? 

Identifying value drivers in 48 hours

Audience: Thank you for the inspiring story, the struggles, and everything you shared.

Tido: You’re welcome. 

Audience: I think you guys went from a lot of chaos to a lot of clarity in how you described the 25 items and then getting it down to the top 3. What kind of exercise or annual planning or rhythm did you use, or do you usually use, to get to those value drivers that you talked about? 

Joe: We used an external firm to help us build this. I think that’s always valuable because they don’t have a dog in the fight and they can help facilitate. What’s super important here is you’ve got to bring the founders, you’ve got to bring the heads of product, you’ve got to bring head of marketing, head of sales, you’ve got to bring all of the executives around the table and they’ve got to be committed to that. And then, you go through a pretty deep discussion around what is it that we sell? What problems are we trying to solve? How do we solve them? And where have we done that? Because the customer feedback is super important.

And for those that don’t know what a value driver is, I should probably explain that. A value driver is the top-of-mind concern that your customer or your buyer has that is on their mind whether you show up or not, right? Whether you exist or not. And typically, all they’re thinking about is: how do I reduce cost? How do I avoid or mitigate risk? How do I grow revenue? Or how do I accelerate time to value? Every value driver maps to 1 or more of those 4 concerns, right? And if you can’t, as a company, articulate how your product can solve those problems for your customers, you’re not going to resonate with your customers. And then what you may end up doing on the product and engineering side is just responding to, very often, poor feedback from a go-to-market team, who tell you things like,  “if you just do this thing for this customer, then we’ll close this big deal and we’ll make the quarter.” And then the next quarter comes along, and it’s another customer with another thing. And before you know it, now you’ve built a bunch of custom products for lots of different companies and your product roadmap is all over the place. And you find it very, very hard to focus and actually make progress on almost anything, right? And then you end up supporting lots of custom deployments.

And so, if you get very clear to begin with around what is it we’re going to solve, what types of customers then have those problems, and what will we say yes to and what will we say no to, then your product roadmap starts to evolve very clearly. And then where the sales leader has a big responsibility is, they’ve got to enforce discipline throughout the organization. They’ve got to stop the, you know, “I need this feature for this deal to close”-type of hero behavior. “If I sell this company that’s outside of our ICP (ideal customer profile), then we’ll be able to do a big deal there.” And it’s really hard when your sales leader saying no to that. But if you do that, you build trust with the product team, and then you can ask the product team to do things for you.

Tido: Yeah. I would just +1 how important the cross-functional thing was. Joe was very insistent on day 1 that it was a CEO, all founders, all exec team, and top performers from both the go-to-market and product org coming together for 2 days to do that. And I just think there’s so much information that gets locked up when you’re not having this free-flowing conversation between all of these parties. So that was one key thing. 

I think the annual planning process that we actually ended up running was pretty similar to every other one we had run, but it was a couple months after we had just really deeply understood what it was people were using Segment for today and what they wanted to be able to rely on it for at a bigger, more enterprise-ready scale. And so it was pretty clear to us that all of the annual planning needed to come back to this value. 

Audience: I’m just curious. The external company came up with the 3 values, right? When you did the 48-hour meeting, did they stay the same? Or did you completely change them? Or just make some changes? 

Tido: Oh, we were writing them live in that 48-hour meeting. I mean, it was two days on site. So we started with a blank template that said, “you need to fill out 2 or 3 of these value drivers.” We had a bunch of customer research and inputs and then also people from the field. But we were actually sitting there with Google Docs open, writing the value drivers.  It was an interesting process. We wrote too much and all of them kind of got a little bit bland. We said, “ugh, we need to really tighten this up.” And what’s the essence of the things we’re really trying to say?

And so it ended up being like a kind of diverge, converge, diverge, converge-type process. But yeah, it was collaborative writing, talking about customers, saying like, “does this fit what these 4 customers are doing with us?” Really trying to get to opinionated things that didn’t just sound like the least common denominator, but really something with specificity that we could go make a PMM campaign against. We could think it was really a differentiator in a sales call. And we could go to the product team and say, “Hey, this may not fully work yet, but this is what we think people want from us.” 

I think Joe had an interesting subtle point though, which is it really has nothing to do with your product, the value drivers exercise. You’re explaining problems that exist in the world that your product happens to solve really well. 

And so that was one of the key things, because my head had always been like, “what’s the feature list?” And there’s only 1 very tiny spot in that value drivers exercise that the product even makes it in. It’s called “required capabilities.” But you need to describe the problem, the before consequences, what will be true about the business if this problem is solved, i.e., more revenue, or less cost, or less risk, or whatever. And it doesn’t even come until what’s required to do it where the product even shows up. And so you’re really talking more generically about problems and solutions in the world, but they don’t know the answers to these questions. It’s locked in the heads of your go-to-market team.

How technical should sales be?

Audience: That’s good to know. And the other question that is just something I’m curious about, is: I work with different organizations and we have this org where the sales team doesn’t dig into the product too much and has the sales engineer to do the demo. But on another team, the salespeople do the demo themselves. Just wondering Joe, how deep do you think a salesperson should go on the product?

Joe: I think that depends a lot on the product and the business. I’ve sold everything from very simple solutions to very complex ERP. But I generally think that the salespeople are better off not doing demos and trying to step back and talk about business problems and trying to get at what the customer’s value drivers are. Before you ever talk about the product, you want to understand: what is the pain of the company has? What’s the impact on the company’s performance because of that pain? What would the world look like if that pain was solved? What would all the positive business outcomes be? Then, what did the company think the required capabilities are to get there? And how are they going to measure success? 

That’s a lot to do discovery on. And only then should you talk about, “here’s how our product does it, here’s how we do it differently and better than the competition, and here’s where we’ve done it before.” Right? And so, the more you can delay that point of talking about your own product and focus on the customer’s pain, the better you’ll be able to sell, the more trust you’ll build with your customer, and the better positioned you’ll be to win.

How annual planning changed day-to-day operations

Audience: Thank you for a great story. While annual planning is a good forum to build that alignment, how did this change the day-to-day operations on the ground for the rest of the year? 

Joe: That’s a really great question. Let me start on the sales side. So, once we got this clarity on who we were, what we wanted to be when we grew up, and how we were set up to sell, we started developing a, a multi-year roadmap for how the product should evolve. And in any startup, I think that’s so super critical because one of the areas that Segment got itself into trouble was it ended up going upmarket way before it was ready to do so.

And I think we landed a bunch of enterprise deals really early on that were very big. And we then assumed, “hey, we’ve got product market-fit in the enterprise with these giant deals.” But what we had was false signal. We had product-market fit in a very, very small part of a huge market. And it wasn’t going to be for years until we could do things in the product like, build machine learning into it, build marketing automation, journey orchestration, that we would truly be able to address the needs of the enterprise. And I’ve seen this happen at every company I’ve ever been at.

So that was the first thing I think we got really tight. And we both knew that we had a responsibility to evolve both the product roadmap and the go-to-market motion in tandem, because it’s not just about the product that you can deliver for your customers. It’s also about how you sell that product. Because you sell in the enterprise in a very different way than you sell in SMB. And in our case, our SMB customers didn’t need any help to get it implemented. But with our enterprise customers, we were probably part of $100M digital transformation project run by Accenture. And so we needed to build professional services and an SI relationship, a whole bunch of different things, to just to be able to sell and make those customers successful. So that’s the first thing.

The second thing I think, day to day, we just got way more customer-focused. I think both teams have been very inward looking previously. And to Tido’s credit—and I’ll give him all the credit for this—he drove a program called Lighthouse, which I’ll let him talk about. 

Segment’s Lighthouse program

Tido: Yeah. Lighthouse was, I don’t know if it was my program, but, between us and the customer success team, we would, highlight 2 or 3, customers that were either having trouble or, sometimes, we’d do a positive one on a huge expansion opportunity. But we would bring to a weekly meeting 2 or 3 customers. The go-to-market team would prepare an awesome, maybe 10-minute presentation of what’s going well, context on why it was purchased, what problems we were hired to solve, context on what the needs were—either from the product side or sometimes the needs were actually more from the professional services side. Sometimes they needed an SE assigned to the account. It could be a lot of different things, but it was a forum that the account team, and sometimes there was a product manager working with the account team, could bring to product leadership, me, sales leadership, Joe, support leadership, this awesome guy named Steve DeVito. And this was the chance to discuss all of the most miserable and tough situations. And that was the way that, if we did need to do a shift to product planning for the quarter or for the month or for the week or for the day because some emergency was happening, we would funnel everything through Lighthouse.

What I loved about it is it really got the account team to be thinking very critically and strategically about what the status was, why we really need this thing. And then it let all of leadership together, not in separate meetings where separate things are happening, analyze and commit to a solution.

And so it wasn’t that we never deviated from those 3 annual planning things ever, ever, ever. It was that the volume of those things was much, much, much less. 

If you’re not doing something like that today for your most challenging customers, your biggest upsell opportunities, I would highly recommend a program like that as the entry point for getting on the same page in a more weekly, tactical point of view.

Reorging to deliver on new product priorities

Audience: My question is: when you decided on these 3 goals, did you have to reorganize the organization to align to delivering? How did you reorganize your team? And also, how big was your team and how big was the company at that time? 

Tido: Yeah, great question. I had a policy that I talked about with my team, which was: we’re going to do a reorg every February. Because we’re going to get the annual plan locked in by the end of January, and we’re just not going to have perfect alignment. I would say my goal with those kinds of reorganizations was to try to touch as few manager-report relationships as possible because I wanted as much continuity for the engineering team and engineering leaders to have similar reporting structures. I would say on any given year, it was usually about 10% to 20% of people would actually switch managers.  This year was probably a little bit higher because it was a little bit more of a tectonic shift, but it probably wasn’t higher than 30%.  

Yeah, the team was probably about 200, 300 at the time, in terms of like eng, product, design, security. And then sometimes it was like, we’ll take this whole team and give them just a slightly different roadmap and purpose. And that was always the hardest thing because you’re canceling the thing that they were working on for a while, and it requires some finesse to explain why this other thing is even more important. One of the things I found, though, is once people really understood the vision that Joe and I had forged for the next year or 2 and how this specific team connected to that value driver—which was so important for the 2-year future—people were pretty malleable and pretty excited to go work on that thing.

The last thing I’ll say about once a year is that I was at another company where like it felt like there was as soon as a reorg ended, there was always another reorg starting up. It just gives the employees a ton to talk about and worry about and think about. I think just having a cadence, I think about once a year for like series B through D, is about the right time to revisit things. It helped prevent some of the distractions that I had experienced at other companies. 

And not being afraid to do it is the other thing. I mean, if the company has a strategy and the team is not supporting that strategy, you should not be spending $20M, $30M, $50M a year on slightly wrong strategy because it’s uncomfortable to reorg. It took me a while to appreciate that, but I did get there eventually.

The role of engineering in developing the product roadmap

Audience: Thanks out for the lovely discussion. So how much were the engineering leadership involved during your, annual plan? It sounds like it was mostly between GTM and product. Maybe product played more of a bridge role, but how were the engineers involved? 

Tido: Yeah, engineers quite heavily involved.

I mean, as we had those 25 things that we were thinking about, we had engineering leadership heavily involved in sizing all of those things, giving us not an incredibly precise, but a rough swag of, comparative sizes. As Joe and I were talking about those and it became more clear that actually these 3 key goals to support this key value driver and this move into the enterprise was actually the thing, before I committed to anything, all of the engineering leaders needed to take a pretty good look and figure out exactly how long this was going to take. Their numbers came back a little bit longer than my own gut intuition was and what Joe really needed. And so part of my role was helping figure out ways to bridge the gap through reorganization or thinking about the problem differently or pushing on the eng leaders to get a little bit more aggressive with the timing, 

But I would just say, more than anything, it was a lot of iterations. So it was like a conversation between me and Joe, and then it was like iterating on a first pass of like, “hey, let’s just see what we can come up with for 2 hours of brainstorming.” Let me show that to Joe quickly. Joe would be like, “oh, I don’t actually care about this and this, what I really need to be able to say is this in the positioning message.”

And so I thought of it as 20 iterations, where each iteration was 30 to 60 minutes of thinking about it. And then occasionally the eng team would be like, “okay, well, we need to really run down what it’s going to take to migrate these 50 services.” And so that was a little bit more time intensive. I would say it was about a month of planning, and we probably did about 20 iterations on this until all parties were comfortable. But I think the antipattern here is having eng go into a room for a week and figure something out without checking with the sales engineers.

Leading a platform initiative 

Audience: Thank you for sharing such an authentic story. I work in a SaaS company and that really resonated with me. My question is a little bit of a follow up about your effort to build a platform. It’s easier said than done. I feel the pain of that already taxing my engineering team. Can you share a little bit more about the strategy and how committed the leadership needs to be to make that happen? Thank you.

Tido: These kinds of platform investments are always tricky. 

One of the things I found is, when you’re really leading a true platform initiative, it kind of needs to be a “stop the world” moment One of the platform initiatives–and this isn’t actually the one Joe and I were just talking about—but we wanted to basically make it possible that anything you could do on the website, you could also do via API. We wanted a full control plane API. And that was just a tough one where I had to insert a top-down mandate that 1 of these 2 quarters—you could either do it Q3 or you could do it Q4—you needed to go follow the spec against the control plane spec, and you needed to build out all of your functionality to match that API.

For those kinds of initiatives, I like to lead with a really strong core team that goes and does it for the first couple product teams so that they really understand, almost as the customers of needing to use the API patterns they’ve set up. And so usually, you can get the core team to do about 40% of the work. But then at some point, you’ve got to go insist top-down from the rest of the product teams to go fill in some of that work. So those kinds of broad platformizations I found to be particularly challenging, and they needed to ladder up into those kind of year-long missions. Otherwise, it just felt like extra work no one could take on.

Maybe the other learning from the one that Joe and I were talking a little bit more about was having an internal customer. And so, first, having his sales engineering team, and then it was his professional services team, as the first customers was so powerful because what was happening was that some of our biggest logos had always come to my team to go build a couple of random integrations into whatever services. They could now go to Joe’s team. Joe could charge them $200,000 a year, and we would have a customer paying for the platform development against our own API, and all of that was happening internally. Obviously, we were very motivated if it was, like, Nike or whoever, to support both the 7-figure ARR contract, and then also sometimes the 6- or 7-figure services contract. And all of that was happening with Joe’s team acting as the customer into my team doing the platform stuff. And so as much as you can set up that kind of situation, which comes from having an awesome go-to-market leader who really is not afraid to ask customers to pay for the things that are not part of the vertical offering, but are things that they should be paying for. That was really the unlock for that sort of functions project that we were talking about. 

Audience: That’s all the time we have for questions today. Thank you so much to our panelists for a very engaging session.

Tido: Thanks for having us.