2025-02-12--t06-12-03pm--guest275742--jeff-wharton
===

[00:00:00] 

Jonathan: Test. Test. Test.

Jeff: Test, test, test.

Yeah, uh, and here we are. How's that? Is that better if I'm kind of talking in a bigger voice? Okay, cool. I tend to laugh really loud, John, so we have to protect the microphone against me breaking it.

Jonathan: Got it. Okay. Yeah. Sounds good.[00:01:00] 

Jeff: Give me five seconds. I just want to get one thing up on the screen so I have, um, this here.

Okay, cool. Thank you. Oh, good. Yeah, I, I, I pulled up John, uh, your LinkedIn just in case I have need to reference a year point at which you were at one of the roles. Hey, John, welcome to the show, man. Thanks for joining us.

Jonathan: Yeah. No, thanks for having me. Excited to be here.

Jeff: Yeah, this would be, this would be an interesting one because I think you and I have a little bit of parallel to some time there, you know, [00:02:00] looking back, you're, you're at Blue Conic now, which was just acquire, you know, acquired Jebit where you were. Uh, for quite a while, but before that you were across a whole bunch of kind of companies at the forefront of programmatic ad tech.

You were at AT& T Adworks and started out at Yahoo, um, which, you know, maybe despite where they've ended up now, uh, really did a lot of really interesting things to push. programmatic ad tech forward back in the day. Um, and that really shaped like a lot of the, I guess, definitely a lot of early career, probably for both of us in different ways, but, uh, the kind of world we live in now of advertising the tech that lies behind it.

Um, so maybe we just start there, right? Like you, you started out at Yahoo, but, but you were not in product or even an engineer, you started out in CS. So maybe tell us a little bit about that.

Jonathan: Yeah. Yeah, absolutely. I love talking about my Yahoo years. This was, uh, this was prime Yahoo. And it was, you know, neck and neck with [00:03:00] Google and search had major market share and Um, yeah, so I started out Yahoo in a customer success kind of role. Um, most of my time at Yahoo actually spent on the right media side of the business, which was the first programmatic, um, ad exchange.

Um, it was an acquisition that Yahoo made back in 2006, 2007. Um, at the time, this was the forefront of ad tech. Um, it was the first time that media was was actually bought on an exchange. Um, in real time, customers were bidding on it, and each impression had a set value. That was an entire paradigm shift for the ad tech industry in that moment.

Up until then, most ads were just sold direct on publisher, you know, sponsorship on site, certain amount of ad impressions. Um, so it was, it was a, um, you know, uh, industry shifter for sure. Um, what was really interesting about that experience wasn't only the, the innovation at that time in the ad tech space, But the technology is way ahead of the market.

So when right media was, uh, you know, came to the forefront still, you know, 90 percent [00:04:00] of the ad spend was just in traditional buying impressions. So trying to convince brands and agencies and other players in the ad tech system, ad tech ecosystem to leverage these programmatic technologies, um, was a pretty big shift.

And it had me think about, um, really talk about like the customer benefits, um, the reasons for the shift, the efficiencies, the direct benefits, uh, you know, conversions and, you know, lifetime value and all these things that were very tough to measure, um, in the, in the old way of doing things. So, yeah, that was my start.

I was at Yahoo for a really solid good five years, um, but that was, that was the beginning.

Jeff: So one thing I found really interesting besides the fact that you had like a front row seat. It's just the rise of this programmatic ad world that we live in now is how, I mean, maybe this is my opinion. Maybe I'm getting this wrong and a little revisionist history here, but it seems like how the skills you built here were such a foundation for a successful move into product at a time when.

Product was not what it is now. Like, I [00:05:00] mean, I know there's a lot of, there's a big push now to like, you know, there's programs in college to learn product and it's a great sexy title and everyone wants to be like a product manager at a fang company or something like that, but this is back when, I mean, if you remember the movie office space, uh, the, the guy who kind of gets angry at the bobs about running between, you know, my job is to run between the engineers and the customers and I, you know, yelling.

Indiscriminately, I have people skills. Like that was the view of a product manager back then, but it's changed a lot. But like you got this great education, like you said, in CS and how to ask customers important questions, how you discern what they need. You moved into more of like a technical solutions engineering role or solution selling role and got exposure to the tech side.

You built the fundamental skills that became so, so vital to product. When product was a different thing, capital P product was different, but you, you, I don't know if it was on purpose or accidental, but you, you built this great skillset that really primed you for like this move into what product became and to really help move companies [00:06:00] forward.

Was that on purpose? Was it intuitive? Was it just kind of, you know, you did it and it was fun and it turned out to be useful.

Jonathan: Yeah, so it definitely didn't start out intentional. I think, yeah, when I

Jeff: None of us do.

Jonathan: When I started at Yahoo, um, I, I'm sure I didn't even know what product management was. Um, but I felt like that experience of customer success really helped me hone in on my skills. And I discovered where product management was.

And essentially, there was a lot of overlap. It was understanding customer pain points. It was trying to understand how to take technology and optimize a customer's business or strategies and how to use product to do that. Um, in the case of my role of customer success, it was deploying people onto the right media technology in ways which match with their goals.

And, um, through the process, I just always found myself thinking about. What product changes could we make to make their lives easier and better? And that's how I kind of discovered product. Um, I was lucky enough that I got some really great mentorship all at Yahoo from some product members there, which I shadowed.

It also helped that my older [00:07:00] brother moved into product management role. So I kind of got the front seat there from a personal perspective. Um, but I learned about it over the way, um, over time. And, um, it's not easy to just like make the leap from customer success into product management, particularly at a big company like Yahoo.

Um, typically they'll, they'll hire MBAs or maybe people with engineering that are then interested in the business, but it was a tough foray into there. So as you mentioned, I did move into a solutions engineering role, which helped me refine some of my technical skills. Um, some front end code, um, you know, leveraging SQL and being able to access data directly in the database, uh, build proof of concepts and then, um, take those things and message them to an engineering team.

So it was a nice little middle ground before getting into product for sure. But I was still in that role, able to, um, still able to go deep directly with customers, still have that direct customer touch point.

Jeff: So I think that brings up a good point is right. You gather these skills over a myriad of roles. Um, now I think one thing that [00:08:00] has stayed similar about product and probably crosses over product and marketing is this idea of like, there are some functions where you just need to be really good, but those are the functions where you kind of need to be like T shaped.

You need to be deep in one area or maybe even two, but you need to be wide across a lot of things. I think that's one way, you know, product. And marketing tend to be similar is you need to have a couple areas of strength, but you need to really understand a lot of different disciplines. Um, and this background in, you know, kind of getting to this point via Yahoo and being deep in a couple areas, right?

Getting technical experience, experience asking customers the right question. And like you said, how do you create the solution that's going to move them forward in the best way? Um, seems like from, from conversations we've had to have informed all the way forward to now, like let's just skip a whole bunch of years and jump straight to Jebit and how you manage teams at kind of a startup and stuff.

I guess does that play into like that kind of strength focusing when you [00:09:00] are managing a team of product folks at a company like Jebit, which is growing fast and you know, was more of a startup.

Jonathan: Yeah, absolutely. I think to be a successful PM, particularly a successful PM leader. You have such a broad swath of information that you need to know. You have to understand the customer success or you have to understand support, what's the pain that they're going through the customers. Um, you have to have a really good, um, pulse on company goals.

Like what kind of growth are you looking for? Is it new business that are buying new sexy things or is it retention? And, you know, listen to current customer requests. Um, is it plate ways to expand the product you should through expansion? So you have to understand those business goals. Um, obviously you need the interaction, the technical skills, um, and just ways of working with engineering.

So there's just so many marketing as well. What's our go to market strategy? How, what channels are we going to put this out in? Um, so like you really are interacting with every team. So you do have to have that T shaped, um, you know, knowledge, as you mentioned, but you also need to go really deep in certain areas.

Ultimately how product is built. You need to [00:10:00] ask the right questions, identify the right pain points, and then work with the team to come up with the right solutions and you're going deeper than anybody with those solutions. It's leveraged based off of the data, the inputs from the different teams and coming up with the right thing that works and the rollout strategy.

So, um, product is definitely not like a, you know, a siloed function role. You need to have mastery to some degree, um, of everything around it. As you mentioned.

Jeff: Yeah. So, uh, one commentary and then one question, but I think one thing I've greatly appreciated over probably, you know, seeing software evolve in the past 20 years is I do think, uh, companies have gotten better about understanding these parts have to play together, right? You can't, can't build something in engineering that you don't have to go to market for or the sales for, or the, you know, the product understanding for, um, similarly though you can't sell something you don't have.

And I've really enjoyed, I think, seeing just. The understanding that these things can't operate in a silo, but they operate, um, together. And, and, you know, we had, um, Jason Penketh men on a while back, but just [00:11:00] kind of, we're revisiting some of the stuff recently. And he has this idea of like a four in a box meeting where you're bringing all those stakeholders together once a month to understand, you know, how are we going to ship the right thing?

How do we have support for it? Marketing wise, sales wise. And I think just, we've gotten all so much smarter about this. Um, that it almost you look back and you're like, we were crazy not to. Not to be as aligned back then. Um, but from a more actual tactical standpoint, like looking at your team at Jebit right now, or I guess over the years it's evolved.

How have you actually, you know, broken that up and how have you divide that team to kind of take advantage of strengths and weaknesses or Is it generally more, does it kind of peanut buttered across

Jonathan: Yeah, uh, I wouldn't say peanut butter. So I think like pragmatically, there are ways that you divide up the product and then you staff them in that way. And I think that, that makes sense. You look at the different product modules, how the different engineering teams will operate within them, what parts of the co base they touch, but in terms of strengths and weaknesses.

Um, I really like to tap it there. It's like I mentioned before, it's so wide ranging the skill set you have as a product [00:12:00] manager. Some people are really love the research and are passionate about it and love the customer facing aspects of their really thrive with the project management, the execution, um, others get, you know, are really good at the go to market and the positioning.

Maybe some people really like the QA and getting the thing out the door and all the little edge cases. So nobody's going to be amazing at every single part. So sometimes it's just shaping the team to put them in a place so they could, um, not only like capture the essence of their core strengths, but also grow toward towards being more complete product manager.

Um, so when I look at my team, I think, I think about putting them in position. So not only benefits the whole team and we get the best of everyone, but also set them up for goals to, you know, get better at the areas and perhaps where they're weaker.

Jeff: nothing? It's always right. It's always the split of how do we get, you know, as leaders, how do we get, well, we need to accomplish the big organizational wide goals, but how do you also set people up for growth and success and getting to where they need to go and it's [00:13:00] great when it aligns perfectly, but sometimes it's a little more effort and like, you know, I think there is a duty to, even though there's not like there's a duty to help people move forward, but even beyond that selfishly.

If we're not helping them do that, they're going to go find someone who will potentially. So, um, no, good way to look at it.

Jonathan: yeah, I think it's also natural for people to gravitate towards their strengths or at least interests really go all in, in that one area. So it's really, um, I think as a product, a manager of product managers, it's important that it's not just about what you're really good at, but that there's.

Product is just more, way more, um, wider reaching. And you can, if you're very into like solutioning and coming and working with UX to come up with something, but you, you're not thinking about what happens after launch V2, looking at the data, there's going to be a big mess on outcomes. So you really need to focus on each part of the, um, you know, product development process.

Jeff: It's funny how, um, I was talking about this recently on an episode, the way that product thinking kind of permeates the whole world. And maybe this is a construct of, of, as [00:14:00] I think about things more this way, I see it more or just, it's true, but. Complete aside, but on the point of people tend to go towards things they're already good at.

Um, I literally had that exact same conversation this morning, walking my son to school about why people do certain things. Um, and it's, but it's probably thinking at some level of how do you org, you know, org design, uh, team structure, how do you build great products? And part of it is like people go towards the things that they're naturally good at.

And that's true in real life. That's true in product. And I think that's one of the things generally. I've seen over the time doing this is a lot of team design, a lot or design, a lot of product thinking comes back to how do things operate in the real world? How do things operate outside of software? And we can take a lot of lessons from that.

So.

Jonathan: Yeah, exactly. If your goal is to find an easy job, it's not, it's definitely not the right career.

Jeff: Right. No, no, that's, it's, it's generally not the, not the best role. Um, cool. So let's maybe is, is, you know, as much as I could dive into maybe like how you've broken all your team [00:15:00] down and go through that. And I think I probably learned a lot here in the audience. Would, um, one thing I want to shoot back towards, and we're just kind of hopping back and forth through time right now.

Um, you came up again through that kind of like rise of programmatic advertising and Yahoo obviously has a very storied. Past in that. Um, and I think it's undeniable what they contributed, but maybe something a little bit less known is, um, AT& T took a stab at this as well. And I think this is a good way to kind of dig into how do companies that are big and undeniably successful, but maybe don't have.

the natural extension point into something when they try and do that, like, what can go wrong? What can go right? How does it work? And what do you as a product person need to do to help them kind of do something really, really net new. Um, and you had a first row seat into that. Like you really helped them kind of take your Yahoo experience and try and move forward with this programmatic advertising piece.

So maybe, maybe we dive in there real quick.

Jonathan: Yeah. Yeah, absolutely. Um, just provide a little bit of [00:16:00] context on my transition from Yahoo Yahoo to AT& T. Um, AT& T AdWorks was founded, um, in around 2010, 2011. It was a division of AT& T, and the goal of the division was to leverage all of AT& T's owned and operated data assets. You know, they're hundreds of millions of subscribers.

They owned a TV operating system. They had all of this data on users, um, and unique touch points to the user for one unified profile that they would have, but leveraged that for third party advertising. So actually selling advertising solutions to any brand, say Nike or Coca Cola. Um, so they hired me in actually as one of the first PMs.

Um, I, I probably, it was my first like formal PM role. Um, so I'm probably wondering like, how did I get it? And I actually landed it actually because of my, my domain expertise in ad tech, which was really, really deep. Um, I knew about all the players in the ad tech value, um, uh, ecosystem and like the value chain, I knew about how the technologies work.

So I got brought in, um, to grow that team. It was also the first time in my career where I was managing a group of other PMs. Um, as you mentioned, AT& [00:17:00] T is a, is a telecom, right? So them going into ad tech is kind of a new thing, a paradigm shift for them. Um, so actually this is a great opportunity for me to kind of rethink.

Uh, the way that I was thinking about product from what are the pieces of the tech stack and what we're solving, um, to customer benefits. And when I was thinking about that context, explaining customer benefits to people that are trying to sell the solution, trying to people that are by the solution, as opposed to actual, um, uh, solutions themselves.

It was actually a really nice framing for me to rethink these things. If the people that are selling it around me, the people that are managing the accounts or thinking about it in customer benefits. And that's how I'm thinking about the product that helped really drive the whole motion forward. Um, so that, that was different.

That, that muscle was not entirely there at, um, at Yahoo. Cause the people that we were working with were a little bit more savvy within ad tech, uh, but totally new domain for AT& T.

Jeff: Yeah. And, and so I guess running through that, um, clearly there were a lot of data advantages and probably something maybe looking [00:18:00] back as they taken it now and attempting now there's probably a lot of like, right. There's probably a lot of benefits that would have been had right now that they'd tried it again, right.

With the TV operating system and a lot of other things where there's a lot bigger networks to plug into. Um, but you, you ultimately kind of moved on from there, I guess, what was it just. Um, the, the initiative around AdWorks never quite got off the ground or what, I guess, what drove kind of your next move there?

Jonathan: Yeah, Adworks actually had pretty significant growth. It's also nice when you have, um, owned and operated assets, you could grow revenue pretty quickly. Um, they did pivot a couple of times along the way, but, um, I, I really moved. My main reason was, um, personal reasons. I had a family. I moved from New York to Boston and, um, with that move at that time, I left at t and at that point I moved into the startup world and I've never lived since.

So first half of my career was at large Yahoo. Large, uh, companies like Yahoo to at t and since 2012, 2013, I've, I've, uh, pivoted my focus to, to [00:19:00] startups.

Jeff: Nice. And that is, uh, I think maybe we'll say not, not always the easiest, uh, move to make. I got an important question though, before we move on from there, uh, Yankees or Red Sox.

Jonathan: Oh. Or Red Sox. I'm a, I'm a Boston raised, born, born and raised guy. Yeah,

Jeff: Okay. Yeah. We can keep going then. So I was a little bit worried for half a second there, but, uh, no, but New York's a great place to live for a little while.

Um,

Jonathan: yeah. Go Socks and Celtics and Pats

Jeff: right. We can keep going. This is great. Okay. Now, now we're safe. Um, um, so you moved on to startups and, um, you know, I think. Oftentimes, one of the, the ways people kind of look at startups or romantic view people take is you look at these successful startups and you know, they start at like seed round and two or three people in a garage and they end up, you know, way up here and the narrative or the book written post, right, is like up into the right straight line, [00:20:00] right?

You think about, you know, people think about Airbnb and it's just like they started, they had a little hiccup figuring it out. They made cereal boxes. South by Southwest happened, bam, multi billion dollar company. And yeah, and that's, I mean, that's how it was a Jebit too. Right. It's just like pure up into the right, but people often, you know, I think in wrongly, so gloss over a lot of the friction that people went through and the work people put into to not just overcome.

Maybe, uh, what is next thing you do or how to create the right product, but the problems that arise with the whole thing. Um, I think it's something we've keyed in on generally is like, you face a lot of challenges in product and it's really how you respond to those things that go wrong that define, I think that comes with a company.

Um, so, you know, looking at the move into ad tech for AT& T and some things went right, some things went wrong and ultimately they did pretty well. Um, moving to Jebit, it sounds like. You know, maybe there was some, you know, generally things have gone really well. You guys had a great exit and by the way, congrats on, uh, the semi recent acquisition there [00:21:00] by blue conic.

Um, but early on, I think there's a story about some of you guys built that was just dead on wrong. And, and I understand why you did it and it just ended up not going right. And maybe we can dig into that real quick and like why and what happened.

Jonathan: Yeah, no, for sure. If you're somebody that, you know, wants to always win, um, startups, most of the times isn't the, isn't the right place, uh,

Jeff: It's a bad area. If you can't stand losing.

Jonathan: particularly when you join a company, you say pre product market fit, or it's a new market category. Like, like Jebit was when I joined. Um, there's just a lot of ups and downs the experience, but honestly, the it's all about the learnings. Um, you're, you're not always winning, you're learning and you're adapting.

And I think that's key for any, any role at any company with a startup, but particularly products. Um, uh, specifically, if you want to talk about a particular, say, like product launch that failed, um, I could talk about, um, there's, there's a whole number that come, come, come to mind. Uh, there's lots of different

Jeff: We all have a lot of them

Jonathan: Yeah. There's a whole bunch of different reasons why, why product [00:22:00] failures could happen. Um, generally speaking, uh, something that I think I learned, uh, earlier in my career is get engineering involved early. Um, sometimes the product and UX will be so far ahead of engineering that you get to the point where you want to implement.

And there's tech feasibility problems that you run into, and you're dictating the how, but engineering should be involved. So that's something that definitely advocate for anybody that is working within an engineering team. The model has always worked when you keep the engineer, the product and UX involved at at all times at different levels.

Um, specifically, uh, an example of a failure. Um, so my earliest day at Jebit, one of the, one of the big pain points we heard from our customer success team, um, was being able to show ROI for our clients. In the actual platform itself. So the idea, um, in, uh, in nature was to create a dashboard where customers can go in and enter their goals and values.

And therefore we have goals to kind of measure ourselves against. And, um, the problem with that is it takes an operational. [00:23:00] If there's operational friction for them to enter those goals, and sometimes they don't even know what those goals are to begin with. And it's a moving target. They have to continuously update.

So what ended up happening was the product got very little usage or it was outdated data and it wasn't used in a practical way. Um, there's actually a series of those kinds of failures. And if you look at them in totality, we're trying to do is we're trying to productize the operations of our customer success team, which is always a moving target.

And, uh, that's, that's sometimes not the, it's not the smartest thing to do build, uh, you know, build value and benefit for end customers, not internal stakeholders. Um, and that was something I think we learned, um, early on, we did end up solving the problem by integrating with other data sources, like attribution vendors and whatnot, pull that data directly into Jevit, go directly to the source system, as opposed to a manual order entry system.

So that was just an example of a product and featured just a general way of thinking. Which, uh, which did not work out well.

Jeff: Yeah, um and just kind of for everyone's [00:24:00] benefit jebit right what you guys do is basically help create uh Experiences for your customers where you where they can use that to gather user data Um, and, and use that right,

Jonathan: Exactly, first party data. It's a first party data collection tool, um, through these interactive, engaging experiences.

Jeff: right. And so kind of, it sounds like you found yourself looking at how are we solving this problem that our internal team is having? Um, and the outcome kind of is it didn't solve customer needs very well. Uh, cause you weren't really, maybe weren't looking at them as closely as, as you were looking at the CS team themselves.

Um, how did kind of the second solution, I guess, better serve customer needs there, or is that what ended up happening?

Jonathan: Yeah, so in this particular case, when you're talking about ROI, and in this case, it's the impact Jebit has on some sort of conversion on your website. That's the use case we're talking about right now, in particular. Um, us integrating directly with like a, like a Shopify, like, so we work, we have a Shopify app, for example, um, integrating directly with Shopify and getting the actual [00:25:00] order data back into our system, um, and being able to attribute it that way is directly from the source.

There's no order entry. There's no friction at all. It just kind of works integrating directly with, um, you know, like a Google, like a Google analytics. So the direct integrations while maybe a larger up, you know, um, lift upfront to get that in place, but it scales much better. And frankly, customers have way more trust in it, uh, let alone the usability and operational, um, efficiencies.

Jeff: Yeah. And so if I'm understanding right, the first focus was more around how do you, um, gather those ROI numbers for the CS team to come back to their customers? And kind of talk about that way,

Jonathan: in theory it makes a lot of sense. If you think about, you know, say a customer success person is setting up a QBR, the customer and wants to go through the metrics and, and share the, the case study, you know, share the stories and use it as a case study. It makes a lot of sense why you'd want that data.

Um, having the customer enter it and have that as part of the onboarding process, um, is kind of a moving [00:26:00] target. And it's just, it was really hard to get, um, adoption of that tool.

Jeff: right? Um, looking at how you guys kind of, uh, you know, did discover around this and kind of came to, uh, you know, goals for, you know, we'll call it phase one and phase two. What, what did it look like kind of doing the research to put together, you know, a project plan that led to the kind of first piece where you were asking customers to manually enter the goals they had and then that kind of thing.

Jonathan: Yeah. I mean, I think, well, this was, this was the phase one, phase two of the product that failed. But, um, we did do, we did do adequate research because the need, the need was absolutely there. The, it was the right problem. It was just solved in a way which was not, um, yeah, which was not scalable and didn't work.

Um, but you know, I, I took that and that wasn't the only time we filled in that arena of like trying to operational product highs, like operations, but over time we got, we, we, we unfortunately, we learned from our failures in a series of those. And we have a bunch of things to go back. The requests keep coming in for those kinds of [00:27:00] solutions.

And now we have, Hey guys, this doesn't work. Uh, let's try to find another solution.

Jeff: Right. I mean, I think at some level there's the famous quote from, um, what is it? Uh, the, the inventor, um, oh yeah, sorry. There's the famous quote from Thomas Edison about, you know, when he discovered, uh, tungsten is the element that worked really well for the light bulb for the filament. You know, I don't think this is a real thing that happened, but it seems like a nice.

Allegory of generally what happens like, you know, reporter asked him, you know, how does it feel to fail 99 times before you succeeded? And his answer was, I didn't fail 99 times. I successfully found 99 things that didn't work. Um, and I think people under count the value of what we learned from these things and, and the contribution to basic research that you can apply later and later and later, if you keep track of your losses and don't count them as like, Oh, we lost and we messed up or we learned something important here and let's move on, right?

In this [00:28:00] case, you had the right problem to solve. It was customer ROI and attribution. Um, and maybe the first attempt at solving it, you know, you're the right thesis, but the wrong, maybe micro execution, but it sounds like the very, you know, kind of the next step you guys took at it was very successful and you were able to solve it by, right.

You said the direct kind of integration with other tooling. And that really. So, you know, move the needle for your customers and it's easy to kind of get locked up in this first loss. But I think important to kind of follow on like, how do we, you know, if this important, if this project is important to solve, let's keep going and find the right answer.

Jonathan: Yeah, exactly. And I think, you know, my goal is not a hundred percent success and zero failures, like even today. Um, if you get learnings and we were big on postmortems, um, even, even if, even if it's a successful launch, even if like operationally and execution wise, there's some improvements. We always do postmortems, find ways to get better.

Um, the expectation is not, um, you know, you're going to hit it out of the park every single time. I don't see that as the, you know, the north star.

Jeff: It's [00:29:00] funny. I worked at a company years ago. Um, and I proposed that, you know, we would, we would go through regularly kind of these wind reviews, like what do we do well, how do we win? And this was more a sales focus, but like, how do we win? Um, why did we win and it was a big I understand the cultural piece of like the rah rah celebrate the win Um, but I proposed at one point.

Well, let's even do maybe a quieter loss review and the feedback I got from an executive there was What are we going to learn from when we lost? Like, why did we go look at that? We didn't, you know, we met, we didn't do it right. So why we, and here, um, actually a shared friend of ours, uh, John Levis, who, who used to work over at Jebit and now is, uh, over here.

We've had the good luck of working with him for many years now. Um. He brought forth this kind of loss review project that has been really, really helpful. And going through that and understanding the systematic reasons why, you know, we, you know, I think we went a lot in sales, but you know, no one wins every time and reviewing that systematically and getting to the root cause and aggregating, aggregating those together.

We've been [00:30:00] able to build those kinds of fundamental learnings of, you know, ways that we are going to push a product team forward, ways that we're going to push our sales team forward and build better things and communicate it in better ways. But we'd never have that. If we didn't look at these small losses that were on the path to the right way.

Jonathan: Right. I, I totally agree. Um, close. First off, big fan of closed loss analysis and really understanding to the root of what, why we're losing deals. But for, for my team, um, I think that we have a real thirst for understanding client pain points. So when we go to a session with a client, we want to understand feedback.

Um, it's great if we get good at great anecdotes about what they like about the product, but it's like, let's get to the real meat, what's bothering you. And I think that that really fires us up. Um, it, you know, even if we lose a deal to a competitor or something like that, really understanding the why behind that.

Um, is very actionable and only makes us all better. So,

Jeff: Yeah. Um, so kind of, we, we can continue on this theme. Cause I think back to, um, learning, you know, how we learn, how do we kind of focus in on where the areas for innovation, how do [00:31:00] we move the product forward or other pieces of company forward? Um, you guys kind of have a couple of approaches that I found really interesting to how you, I guess, how you view innovation or how you kind of drive this and one is, you know.

Early on, it sounds like you recognize the potential value for AI, um, and you kind of split off a team focused on researching how that would apply into the product and how you could help your customers do better and get more value out of a platform that way. But also in general, you have this kind of like concept of a managed service component and you have a certain set of customers that are maybe a little bit more manual, a little bit higher touch.

And while some would view this as potentially like, you know, a risk in that, you know, obviously there's, there's cogs hits and, and margin hits and stuff like that, but you all have been able to really use that as a way to be more hands on and really get a lot of these learnings and, and kind of figure out the innovations that maybe don't scale right now, but you can figure out how to [00:32:00] do it.

If only they work and they're worth pursuing, um, I think this kind of pursuit of learning in two really focused ways has been interesting and really enlightening. Can you maybe walk us through like why you do it this way, what the inspiration for this was, and maybe even some things have sprung out of this.

Jonathan: yeah, absolutely. And I'll just provide the background on how this all started. Um, when I joined Jebed in 2018, we were essentially a, um, we were essentially like an agency like managed service with a platform. We had technology. We also had great brands in the platform and give them credit. Um, at the time, um, over the coming years, when I, when I joined, we got 80 percent of our clients onto our platform, self serve, building experiences themselves, using the tools themselves.

We still kept that 20 percent as managed service. Part of that was just to be frank, it was just market. Um, some of the largest enterprise brands don't want to do anything themselves, or they have custom requests that they, that they want, that the platform can't do out of the box. And we didn't look at that.

I understand the point around. You know, pure ARR, no managed [00:33:00] service is better for, you know, valuation, um, in, in higher margins. But we actually looked at that managed service as a, as a innovation center for us. For one, it helped us really hone in on our ICP because we kept seeing the same requests over and over again from the same types of clients for the same types of use cases.

It was great to really help us validate what it is that we should build and productize. Um, it, it helped us, uh, yeah, I mean, they kept pushing the needle on custom work. Um, templatizing some of that custom work and doing it time and time again. And it's like, Hey, what are the top requests that the managed service team is building on behalf of our clients?

One, it's really innovative because it's, it's custom. It's out of the box or it came directly from the client's mouth. And two, you know, just the repeatability of it makes us want to productize it. Like there's validation in itself. The hypothesis doesn't necessarily need to be proven. It's already being done in a managed service capacity.

So bringing that together, I would say for a solid, I guess to this data, some degree, um, I would say we put. A solid a quarter of our roadmap, just productizing the things that [00:34:00] are managed service team. They're, they're, they're called studio. They're great. The things that that team does. Um, it's a real differentiator for us because not only because we have that managed service component, but we're, we're working with the largest brands.

We're really targeted on our core ICP. They're doing the work for them and it's just honing in more and more. And we're able to grab more and more market share for our target audience through the, through the innovations.

Jeff: Yeah, I mean, I think that's one of those things that people are always want to pursue anything that has, they don't want the whiff of professional services or anything like that ever near them because they think it's going to hurt, you know, valuations because, you know, this idea around like margin hit.

But I think it's easy to. Can it downplay the, the positive to innovation if you're doing it right, right? Like if you're just doing manual stuff, wrote and not paying attention to it, probably not gonna be super, super helpful, but if you are looking at it, like you said, as an innovation center and to kind of move the company forward and how do you generally, you know, uh, improve the product and, and where can you take repeatable things are being asked for again and again and again.[00:35:00] 

And product has it, it can more than make up for any, you know, margin that you're making. Um, yeah, I guess, do you have examples of places you've run into, you know, things have come out of that? Or is that too like hush hush?

Jonathan: Right. No, it's all right. I mean, like some of the early custom implementations, um, the more custom it is, the more breakable it is. Um, so not only just campaigns breaking, cause it's written in custom code, but also just triaging, let's just say there's an issue. Now you have the support team going into code.

I mean, we are, our support team is, uh, you know, very competent, but it's a heck of a lot easier triaging something that's self service custom. Um, when you think about rolling things out, you have to think about how's this going to impact the custom campaigns. Versus, you know, a self serve code base. So every, and then, you know, how do you do automated testing and everything along that lines, you have to think about this other unit of the business.

So definitely it does introduce tech technical debt. We found mechanisms to limit that. So backwards, compellative compatibility isn't an issue. [00:36:00] Um, but, uh, yeah, over time we've certainly run into challenges. I will say though, like the more, the, some of the managed services work. Particularly around whether you're building an experience or some sort of custom integration, it's sometimes really sticky to, um, the fact that the client is willing to work with you to get this integration done, say, and integrate with your API.

Or go back and forth on some design changes that are really intricate. It's sticky. They put in that work, that upfront work. And now they probably, if not, you know, have really higher attention, we'll, we'll expand. Um, so that, that's worked really well for us while, while it is lower margin, it's actually had, um, you know, it's helped our NRR in certain regards.

Jeff: Right. And I mean, that adds to from a just company standpoint. Right. Like looking at the big picture here, it can definitely be value out, even from a valuation standpoint, like you say, if it adds to NRR, if it adds to retention, or, you know, if you're seeing that you can do, you know, roll out features maybe that are going to be really, really sticky because you're building like hyper specific features for a group of, you know, a group of more than one customer, that's really valuable.

Jonathan: One of the [00:37:00] biggest wins when you take one of these managed service clients is particular clients, particularly for a very large brand, and then they become self serve that that is a huge win for the business.

Jeff: Right. Yeah. I mean, I think there's always the features right that that are there are features that are good marketing features that maybe not even everyone uses or not everyone uses for forever, but it gets people in. It helps you your win rate and your capture rate. And then, you know, over time, you can either a throughout the sales process show that maybe they can use the higher margin item and it's better for them or be like you said, they can migrate off of the kind of more boutique into the self serve platform because it's been kind of configured Better over time for them.

Um, it's what we actually had. Um, a woman named Susan Stavitsky for who's over at CarMax on a while back. And she talked about like, this example where they were trying to, uh, move forward during COVID when, you know, car sales were just going wild. They were trying to make that process a lot more automated because it took the human out of the loop and made it easier for the person, uh, higher margin for [00:38:00] CarMax.

Um, but the beginning of it was literally, they built a form that kind of prototyped for people to kind of check in and run and do these valuations for their car on. But in reality, it was just sending kind of via webhook over to this other spreadsheet that they were seeing. And they really just manually, literally three of them behind a curtain, manually typing stuff in, um, to a computer as they prototyped it.

And, and objectively that's way more expensive than the old way of just having one, you know, local clerk kind of come over and help, but that allowed them to kind of move into a much more automated, faster turnover situation where they were able to process more cars with lower touch and, you know, that higher.

That kind of more boutique higher touch temporary hit actually led to a lot, you know, a lot more efficiency, a lot higher margin gain for them in the long run. So, um, cool. So one piece I'd love to touch on is maybe looking at the, the boutique work and the customer work is great. Um, but that does always lead into tech debt and how are you as a [00:39:00] team, how do you guys look at servicing and managing and prioritizing, you know, maybe the needs and asks of.

You know, these kind of more custom, bigger customers, uh, maybe there's less of them, but they're bigger spend versus kind of self serve group that, uh, maybe there's more people, they're all smaller, but they need, you know, a different feature set. And how do you kind of balance the debt that accumulates as you build these things or prioritize between these two?

Jonathan: Yeah. As far as those kinds of things, like who we're building for, um, we are building for self serve. Um, the gap has definitely closed from the early days of, you know, the platform, when the platform could do less, uh, we were trying to close those gaps over time. And for our core ICP, we absolutely have closed that gap.

So after, like 100%, some of our large customers that are managed service are like, Hey, when is this coming? I want to be able to do this myself. Those things absolutely come up, but that, that gap has closed. So I wouldn't say that's necessarily a huge issue. Uh, today, as far as like general tech debt on the platform, this is something that we look really closely at, um, the way that we [00:40:00] tag JIRA, uh, so we could see what we're doing for tech debt, what we're doing for strategic roadmap, what's innovation and research and, um, what, you know, bugs we look at that, we look at the bug tickets coming in, um, is the platform not as stable as we'd like right now, or are there areas that need a lot of, you know, love and support because they're, they're old and they keep breaking, so we need better automated tests in one area.

That's something that we're very analytical about. Okay. And the pendulum does shift time to time, quarter to quarter, or maybe even year to year on how much we allocate tech debt. But it is something you have to take seriously because over time, as your company grows, as your code base grows, there's lots of warts that show up in that system.

Sometimes you need to take the time. Strategic roadmap takes a little bit of a backseat. and you're really focused on tech debt, um, and ultimately that's going to help developers, um, work faster, um, work smarter, and it will also protect GRR. If there's nobody wants to be in a platform, they don't trust. So this actually 2024, um, first half of the year is a big year of tech debt.

A lot of tech roadmap that we covered. Um, and it showed off and just like our NPS score, how [00:41:00] customers are feeling in the churn numbers. Um, so that is something that we do pay close attention to.

Jeff: no, I mean, it makes sense. Um, always something is tough. I remember we have a, we have a pretty solid growth engineering team here on top of our core engineering team. And a lot of times for how we kind of, uh, execute things in marketing or, or building things to, to help our go to market. We do weigh build versus buy.

Um, and it's interesting because there's a lot of things I think we look at as marketers, uh, and, and maybe even as a product. We'll say like, well, let's, let's build the thing that is exactly what we want. And this is not necessarily buy the thing that's 90%. Um, but it's, you know, made me kind of focus a lot more on every time you build something, this is something our growth engineering lead is, is super evangelical about everything you build adds a layer of debt that you now have to service forever for perpetuity of owning this thing.

So, you know, you're not just building the core functionality. You are also now inheriting the tech debt that [00:42:00] when you buy, you're paying someone else to deal with. So. Um, you know, I can only imagine even more. So when you're building for, you know, all the customers you guys have,

Jonathan: yeah, I think in marketing tech in particular, whatever marketing tech, uh, technology you're working on, there's so many hooks into other systems that that is definitely a, uh, consideration factor, even, even if you do integrate with another, um, vendor and the application tiers over there, that's still a integration point you have to upkeep.

And then when they do an upgrade, you have to do upgrade. And, um, there's no win either way, but yeah, you're right. This is definitely a consideration factor on, on, you know, builder spot. Yeah.

Jeff: know, John, it has been a blast having you on, um, like, like we talked about going to, it's like we have six pages of notes and I think I only covered three of them, but, uh, you know, unfortunately I don't, I don't think I can keep you all day long to keep, to keep digging in here, no matter how interesting it is.

Um, so I'm going to have to let you go, but I appreciate you joining us today. Like this was a super interesting to, you know, kind of Boston coming to Boston company, being able to learn. You know, [00:43:00] more about your kind of background and what got you here. And I think some of the background in programmatic marketing and how it kind of came to be is, uh, you know, super cool to me to hear.

So hopefully others love it too. But yeah, thank you so much for joining us. Um, if people want to dig in and ask you more, uh, where's a good spot. I know like LinkedIn is always good, but is that a good channel? Other places you prefer?

Jonathan: Uh, hit me up on LinkedIn. Uh, if you want to learn more about Jevitt or Blueconic, you know, jevitt. com, blueconic. com. Um, and, uh, I do want to make a call out. I'm a huge LogRocket fan, by the way. We are users of your platform. Um, we migrated onto LogRocket about five years ago. Not only the product team loves it.

So does the engineering team, the support team. We're all heavily in there. Love it. So Jeff didn't

Jeff: to hear that. No, I really didn't actually, I actually was not going to bring it up cause I wasn't sure. So thank you. Kind words. We really, I love to hear that. So. Awesome. Well, hopefully we can have you back on again sometime, John, because we got more to talk about. I'm sure there'll be more in a year or two anyway, so thank you so much for joining.

Jonathan: Yeah. Thanks, Jeff.