Want this content delivered right to your inbox?

Subscribe to the Newsletter

A conversation with Daniel Elizalde, VP of Product and Technology at ReUp Education

“Before we can ask how fast a team can ship, we really need to understand how fast your customer can adopt whatever you are shipping. Because without that, you’re not going to be improving on the business numbers and it’s just development theater.” – Daniel Elizalde

In this episode of the New Friction series from the Facilitation Lab podcast, host Douglas Ferguson interviews Daniel Elizalde, VP of Product and Technology at ReUp Education, about why faster AI-powered building doesn’t automatically produce business results. Daniel describes the “speed fallacy” in B2B, where long sales cycles, security reviews, and limited customer attention cap how fast products can be adopted. He explains how he now treats product and engineering as a portfolio, pausing roadmaps and moving teams to wherever the real bottleneck sits, anchored by a shared company vision that his team communicated through an AI-generated video. The conversation covers misaligned incentives in sales and marketing, the risk of everyone vibe coding their own tools without a shared data layer, and the standardized agents and skills his engineers use with Claude. Daniel closes with the F1 analogy that a faster engine means little if the rest of the car and the track can’t keep up.

Listen on Apple Podcasts
Listen on Spotify
Watch on Youtube

This episode is part of the Facilitation Lab Podcast. See all episodes

Show Highlights

[00:00:00] Welcome and Introducing Daniel Elizalde
[00:01:00] The Speed Fallacy in B2B
[00:04:00] Capital Allocation and Portfolio View
[00:06:00] Re-Teaming Around a Shared Vision
[00:10:00] Rethinking Backlogs, Roadmaps, and Invisible Work
[00:14:00] Incentives Across Sales and Marketing
[00:18:00] The F1 Analogy and Customer Attention
[00:23:00] Vibe Coding, Governance, and Semantic Layers
[00:27:00] Changing How Engineers Work With AI

Daniel Elizalde on LinkedIn
The B2B Innovator’s Map

About the Guest

Daniel Elizalde builds new products and platforms inside established companies. As VP of Product and Technology at ReUp Education, he leads Product, Engineering, and Design and is building an agentic AI platform that helps adult learners return to college and graduate. He previously served as VP and Head of IoT at Ericsson and built the product function at Stem, the AI-powered energy storage company. He is the author of The B2B Innovator’s Map, has taught over a thousand product leaders at Stanford Continuing Studies, and previously hosted the Enterprise Product Leadership podcast. He lives in Austin, Texas.

Transcript

Douglas Ferguson: Welcome to New Friction. I’m Douglas Ferguson. AI just made execution almost free. So why are organizations still stuck? Because the friction didn’t disappear. It moved and it multiplied. It’s no longer in building. It’s in deciding what to build, how to align, and how to move forward when the path isn’t clear. That friction, the human side of change, is what this series is about. Each episode, I sit down with leaders who are living it, navigating the real challenges of AI transformation, not the tools, the people. The task that took two weeks now takes two minutes. The work isn’t the bottleneck anymore. The conversation before the work is. That’s the work this show is about. Today, I’m with Daniel Elizalde, a VP of product and technology at ReUp Education, where he’s building an agentic AI platform. He previously led IoT innovation with Ericsson and product at Stem, wrote The B2B Innovator’s Map and has taught over a 1,000 product leaders at Stanford. His view, “AI initiatives rarely fail on the technology.” Welcome to the show, Daniel.

Daniel Elizalde: Thank you, Douglas. Very excited to be here. Thank you for having me.

Douglas Ferguson: Yes, it’s great to have you. Looking forward to chatting more today. I guess, we can get our start here. The series is about the new friction that is emerging, as we’ve discussed in the past, the friction is not always new. It might be showing up in new ways or resurfacing or getting amplified in new ways by AI. I’m curious, when you heard the name of the series and saw that intro, were there any particular frictions that jumped to mind immediately? Like, “Oh, this just happened today.” Or, “This has been on my mind.”

Daniel Elizalde: Yeah, there’s a few of those that are happening, like we mentioned, all at the same time. My focus has always been on B2B and have been lucky enough to be in roles that allow me to see the breadth of the business. So some of the things that I am seeing are around how the speed is there and it’s important, but the impact on the business might not be there. What I’m seeing is that more features don’t necessarily mean more revenue, but adoption is what really moves revenue and margins. So where I try to focus is on the adoption of the products, and there’s a lot of challenges with adoption. And one of the main frictions that I’m seeing is the speed fallacy, especially in B2B, where you have sales cycles that might be six months long, you have security reviews, you have procurement, you have all these different things, before you can actually recognize some of that revenue. And those processes, those teams, they haven’t changed. I work in heavily regulated industries. I’ve worked in energy and telco and education, and sometimes the money comes from the government and it’s even slower. And so all of a sudden … Yes, you can put products faster, but if they’re not landing, the customer doesn’t have the capacity to adopt them, and in six months you’re going to have maybe 10X the products, but you’re not able to close one contract. The impact of the business is not there. And so that’s a really interesting perspective that I’m seeing today.

Douglas Ferguson: Yeah. I always like to say if we were making bad product decisions, AI is only going to help us make those bad product decisions faster. It actually might create more of a problem because you talked about more features not actually driving revenue. It actually might reduce revenue because if folks are already frustrated and unclear on how to use things. There’s just friction in the application and we throw more at them, it might slow them down even more because now they’re even more confused.

Daniel Elizalde: Yeah, exactly. And if we take a pure product management centric approach, where we’re trying to solve a problem from the customer, and sometimes a feature set is enough to solve that particular problem. We have to remember that we are not the center of the world of our customers. We are one vendor with one tool to help them do their job. And there’s a few things here, more features might not help them in that path. In fact, I’ve had complaints in the past where it’s like, “Wait, your software was fine and now these other things are here and I can’t find them or I can’t use them.” Or they break something. So that’s a reality that I think of product and technology a little bit more from capital allocation. If you are a company and you’re thinking about … In my case, you’re driving product and engineering,. Well, it’s not only about, can my teams develop these things faster? Which I know we can, but will that really advance the business or should I just say this product is good enough as it is, it serves its purpose, and now I should deploy my engineering team over here, over here, over here, because those are the real problems that the customer has next. It’s an interesting change in perspective of how we have to operate at a different level, thinking about the bottom line of the company and us technology leaders as stewards of that product.

Douglas Ferguson: Yeah. Have you found that you’ve adjusted your decision making or the lenses that you’re using to make the decisions around how you allocate the capital?

Daniel Elizalde: Yes, I have. I am taking a holistic view about our overall platform. We have a couple of products at my company today for universities and some others, for the learners that we’re serving, and then we have an actual platform that connects everything. And so we have pods that resemble that, that make, but this is where the allocation comes into play because a pod is dedicated to a particular product line, and if that product line is serving their purpose and more features is not going to result in either more adoption or more revenue or more margin or more retention. Then I can take a step back and say, “You know what? The roadmap stops here for two quarters, until the customer is able to catch up with that adoption. And in the meantime, I’m going to move this engineering team to accelerate this other piece.” So it’s a portfolio view. And in the past, years ago, I used to be more driven into my pods and this product is going to be continued to evolve forever and it’s always a roadmap and it’s always features. But when you can do the feature set of three years in six months, then all of a sudden you have to be smarter about, “Okay, I’m not going to go three years at this speed.” Because again, looking at the bottom line, if it’s not moving the needle on the business, then it doesn’t matter. You’re wasting that allocation.

Douglas Ferguson: Yep. You wrote a book on B2B innovation, and you’re making me think about some of the innovation principles around organizational structure and the classic story of … And I’m a big believer in this, that Kodak’s issue was the structural one. The head of product was a chemist. So the thought of innovation from a chemistry lens, not a technology or software certainly, or digital photos were not chemistry. And so to your point, if you’ve got an org structure where these squads or teams are focused on products and that’s how they do their work and that’s how they think about providing value. They’re going to continue to push on something that doesn’t need to be pushed on. So this idea of being willing to re-team and redistribute the resources and reorganize people on a regular basis. So to your point, to align to this portfolio planning or portfolio view. So I’m curious, have you developed any new rituals or processes or cadences for thinking about how to realign the teams and make up and the focus that they’re driving toward?

Daniel Elizalde: Yeah, we’re starting again … Like you said at the beginning, this is very new for everybody. And so one of the interesting challenges that I’m facing right now is just that what you said. I’ve been in technology for 25 years and I’ve run product and engineering for a long time, and this is something new. At this stage of my career, I have to figure out now, how do we run teams in a completely different capacity? So some of the things that I’ve been experimenting is trying to think about the holistic product and engineering team as the overall product and engineering team. And yes, they are assigned to pods, but it’s more because of the work that needs to be done right now. So everybody is really well aware of the company vision. We’ve made efforts to crystallize what that vision is, where we’re going to be in three, five years. We actually use AI. One of my engineers used AI to create an amazing video of that vision for the future that helped us a great communication mechanism, both with leadership, the rest of the departments and engineering. And so now everybody knows where we’re going and they should see their work reflected in that vision. And so with that in mind, it is easier to say, “You know what? This part of the vision is the one that is the bottleneck now. Let’s realign the pods, so that the capacity goes and moves that.” I love the energy and electricity, so some of the challenges that the grid has today. The source exists, you can create a lot of code, the destination exists, the customers, but then sometimes the pipes, the grid itself is where the bottlenecks are. And so I see as myself, as a leader of the organization to try to untangle those and see, “Okay, for the outcome to flow, we need to remove this bottleneck right here. So team, we’re going to focus on this because it unstuck this part and now this part and now this part.” And because everybody understands the overarching vision, we’re starting to get a lot of buy-in because everybody says, “Yeah, I understand that my role here is not to build this widget or this API or this whatever. We’re building towards that vision and that’s what’s needed of me right now.”

Douglas Ferguson: Yeah. I’m able to smooth the path to our ultimate victory. And if people can understand how their contributions fit into something bigger, it’s easier for them to do what’s needed, but also not go beyond. Because sometimes folks in their effort to excel build things that just require extra maintenance and it’s not necessary. So that’s another reason why strong purposes can be such a valuable North Star because it helps us understand what not to do or what’s just enough.

Daniel Elizalde: Yeah, exactly. And I try to be very business focused even with my engineering teams, particularly with my engineering teams, so that they can understand the impact. And we actually have these conversations about the investment and the money. A good friend of mine and mentor, Rich Mironov, wrote this book, Money Stories. And I gave it to everybody in my team because that’s the language of business that we need to talk about. And so when they propose that we need to do this new module, new service, new feature set.. It’s like, “Okay. Well, let’s tie it back to the business. How are we going to monetize it? And yes, this could have this impact, but if we unstuck the pipe in this other way, we can actually improve performance overall.” Right?

Douglas Ferguson: Yeah. Mm-hmm.

Daniel Elizalde: And we’re coming up with prioritization frameworks that actually have those notes and saying, “Well, does this thing that you’re proposing has a point solution impact or does it have a platform impact?” And so that way people can see, “Okay, this serves the bigger picture, this thing is smaller in scope, so yes, I can move.” A change that I didn’t expect is that the actual teams of implementation, product design and engineering, they’re actually more excited about this because they feel like they are contributing to the true impact step by step, as opposed to be working on this thing that’s doing its thing, but it might not be contributing directly. So they feel more empowered. That’s the goal at least.

Douglas Ferguson: Yeah. The thing that comes to mind for me there is the video that you’re talking about someone making. Not only did the organization take the time to clarify that vision, that North Star, but also it was communicated in a way that even inspired engineers to go build a video to help amplify that. Any other things that might be helpful for the listener to understand the dynamics there and what made that possible? Because some of that’s y’all realizing it was important and investing the time. Part of it’s the AI tooling that allowed for him to do that more provocative storytelling. All of that were precursors as well to this situation where people feel bought in and feel supported and working in these re-teamed squads, if you will.

Daniel Elizalde: Yeah. That’s a really good point. And it’s a good example of making sure that you have a vision and you can drive it forward. I credit our CEO. She said, “Well, we need to present this vision not only for the next quarter or the next year, but we’re in the middle of this transformation, not only within AI, but AI is helping us accelerate that transformation. And so we need to be able to articulate where this is going to end up.” And so we actually did an executive retreat. We traveled to San Diego, spent a week with the executive team and whiteboarding and all of these things. We had several things. For example, I had a product strategy that says, “Okay, this is where we’re going,” but there were pieces. And so we were able to come up with a narrative. And then with that narrative, the request from the CEO was how can we make others really feel this vision? It’s like a document won’t do. So the idea of the video came up. So I created a storyboard, so to speak, and one of my engineers is very well versed with AI, so she took it on. It’s like, “Yeah, I can create a video.” And it’s like, “Well, okay.” In three days with Claude, she was able to create this incredible 10-minute video of the overall journey from our customers, of what it would be in the future. And we did a few iterations, just of the power of AI in that sense … A video like that 10 years ago would’ve costed $50,000. And now we’re able to do that in a week, refine it. We’ve been using that video to say, “This is where we’re going.” And it’s been incredibly well received because people can see not only in engineering, but in marketing, in part of success, in our learner services, they can see themselves as like, “Oh, I can see where this is going.” And for some folks it’s like, “I can see how my work maps to that.” Other folks is like, “I can see how my work is going to change significantly, so let’s talk about it.” But at least we’re all having the same vision and the same idea. And so from there now, I can put together the pieces for the roadmap and the prioritization framework. It’s like, “Now what we’re building there is … And the reason why I’m moving this spot from here to here is because we’re building this piece of the vision and that’s what’s coming in Q4.” So it’s been a really interesting way of working that we hadn’t had before, and it’s worked really well for us and for our company.

Douglas Ferguson: Yeah. And how has … I can maybe take a guess here, since you’ve been talking about taking a more portfolio view of things and whatnot and some of the shifts around just pausing something for a moment because you’re at that point, but how has it impacted how you think about backlogs as well as roadmaps?

Daniel Elizalde: Yeah, that’s a really good point. In the past, with agile and just typical product factory, you have this never-ending backlog. And I’m moving to the point where it’s like, “Yes, in the past we have this principle where the backlog never gets done and always prioritize the top things.” But now I am finding a lot more useful to say, “Do quarterly planning.” And say, “In this quarter, we’re going to build this piece of division. And so how do I need to organize my infrastructure team, my systems engineering team, my application team, my design team to build that piece?” And it’s coherent and it’s cohesive. And so that way you are able to advance towards the vision clearly, basically following the video And it’s like, “From this quarter we’re going to do this and therefore the roadmap for this portion is this.” And what has helped us a lot is that that has helped us surface the invisible work. Right?

Douglas Ferguson: Mm-hmm.

Daniel Elizalde: Engineering leaders will relate with me, tech debt, infrastructure. It’s really hard to sell at a business level, but when you have that vision that everybody understands, it’s a lot easier for me to say, “Well, yeah. Our AI agent strategy sits here, but for that to run, we need this infrastructure and this pipelines and this services and the warehouse needs to be like this, so therefore we’re going to build those things.” And so all of a sudden it’s not invisible work, it’s not tech debt, it’s really infrastructure work that is needed to power the vision. But without that understanding of that vision, it’s very abstract and it’s really difficult to sell. And my company’s not particularly technical, so they don’t really … Outside the engineering teams, we can’t really talk services or architectures. That’s my job to translate. But anchoring in that vision really, really helps to sell what is needed. And so what in the past could have looked like, “You spent the whole quarter and you didn’t produce much. Well, we did, but it’s this invisible work?” To now, we’re doing 70% infrastructure work and that is the core to power the vision. So it’s a big mindset shift. It’s months in the making, but I think it’s resonating now. It’s really powerful.

Douglas Ferguson: Yeah. I’ve heard a number of folks taking an approach that’s, again, more portfolio-based, holistic in our thinking around, “What do we need to accomplish? How’s that aligned with the vision?” And then dynamically re-teaming as needed. A cadence can change based on the organization, but the quarterly is fairly popular I’ve seen, where that’s once a quarter look and say, “What are our big rocks, if you will, and how do we need to organize a team to follow along with those?” And then the number is dictated by a healthy understanding of what our work in progress limit should be because we don’t want to jam through too much stuff in the system. But then to your point, these roadmaps and backlogs and things, what’s their purpose in the future if we’re operating these ways? In fact, I’ve heard some folks talk about backlogs going to zero because effectively with AI, we should operate zero technical debt because the whole thesis around technical debt is we need to maintain that just because it’s too costly to build the things right out of the gate. And a lot of that trade-off goes out the window now.

Daniel Elizalde: Yeah, to some extent. I’ve always thought of roadmaps more as a strategic tool because I think that if you use it as themes or business needs or strategic initiatives, then it’s a way to prioritize and catalog, should we do this against this versus this? And it becomes, again, that allocation problem than the tech debt, regardless of what goes underneath. So I think that product owner mentality, the stealing the stories, and that’s your backlog is pages and pages. Yeah, I don’t think that makes a lot of sense. The speed is different, so you can do a lot more, a lot faster, but you still need that idea of the trade-offs and what advances you to the vision to protect that investment, because otherwise it’s very easy to get it pulled off to other things. Right?

Douglas Ferguson: Yeah. And it comes back to something you were saying earlier about you were developing some different mechanisms for prioritization. so I was curious to learn a little bit more about what you tried there, what you found is working.

Daniel Elizalde: Yeah, it’s been a journey there because every company’s different and we’re trying to figure out this roadmapping process that is from … It’s funny. I would say it’s from a different era, from four years ago, but it doesn’t feel as natural as it should be. I struggle with, what do I present to leadership? How do we prioritize? How do we do that? And then in our company, we had the opportunity to work with an external contractor that has been really, really smart and really, really helpful in having a third-party perspective. And so really what we’re trying to solve is a portfolio allocation prioritization challenge. Therefore, it’s not about the huge backlog, it’s about the three to five big things that will move the needle in a particular quarter. And so that’s how we moved. And of course, we still have Jira and we have all those things, but those are more for the actual execution. The roadmap truly goes back to one slide that gets approved be the board, which is very interesting because … As much as I love the product management tools that are out there that are fantastic for roadmapping, I’m starting to find them a little bit like, “I don’t know that I need something like that, as complex.” Maybe for much bigger teams because we’re a small company. All these things are changing and we’re just learning a ton as we go.

Douglas Ferguson: Mm-hmm. Yeah. And I’m curious, what shifts you’re noticing across the roles and functions? You kind of alluded to this too, where it’s like some folks see the vision and know exactly what’s expected of them. Some people see the vision and they’re like, “Oh, I’m not sure. We need to discuss what this means for me.” But also, in addition to just how am I aligned to the mission that’s just like, “Hey, if the rituals and practices are evolving, how is my role even shifting as well?”

Daniel Elizalde: Yes, we definitely have those conversations about what is the role within my teams, product or designer or a systems engineer or a DevOps engineer. But what I’m seeing that I’m finding more interestingly is outside the technology teams, how that alignment and those roles should change. And what I mean is that what I’m seeing … And I wrote this in my book, it’s not necessarily new, but I’m seeing it accelerated, that when you’re doing something new, either a new product, new initiative, or something just much faster. Then you have to have alignment across the various department, not just technology. And it comes down really to incentives, not technology. And so what I mean by that is that in the past, companies have had this very well-structured NPI process, new product … NPI. So new product introduction process, development, engineering does this, gets handoff to maybe operations. There’s a sales enablement, there’s sales and there’s marketing, but now all of that has changed significantly. And so what I’m seeing is that the receiving teams, whether it’s go-to-market, customer success, sales market, et cetera. Might not be ready to take on these new products. And it goes down to incentives. I had this anecdote that I remember from some time ago in a previous company, where we created this very innovative product working with customers. It was a really good problem for a … A very good solution for a strong problem. We launch it to market and it wouldn’t sell. Nobody would buy it. And after we did some digging and some analysis, the culprit was that the sales team could meet quota without this product. So they were not incentivized to even show it. So that caused a change in structure from sales and quota, and all of a sudden, guess what? The product started flying off the shelves and it became super, super successful. And so I’m seeing this, but at a different pace. We see here in the technology, we can put out a new brand new product and say, “Here it is.” And marketing would say, “Wait, I have my OKRs. I’m not ready for this. I don’t have capacity for a new product.” Sales would say, “Wait, I already have my targets and my quota. I don’t know what to do with this.” And so it works both as you try to deploy that product, but also as you try to build this product in a more iterative way. Sometimes you’re going to need interaction end-to-end. For example, if you have a PLC type of product that needs to route traffic to do something. Well, marketing needs to be involved early to test. Well, they are going to have to work at the speed that you’re able to develop, and they might say, “Well, we don’t have the resources right now. This is not in our plan.” And so it comes down to a leadership challenge of looking at the organization, and you have to have the right incentives in all the departments. You can’t just say, “Tech team, move faster. Here’s licenses of Claude or whatever, deliver at 10X.” You can’t be the only group with that incentive and with that mandate, because then whatever you produce just hits a wall with the rest of the organization. And that’s a big friction that I’m seeing. So executive leadership has to understand that when you empower a team to work 10X, that’s going to have to ripple some X’s in all the other departments, so that investment actually produces something.

Douglas Ferguson: Yep, totally agree. And also too, another thing that I was thinking about from something you were sharing around … Part of the prioritization process is identifying where the bottlenecks are. So in the case here, this is not just a bottleneck in product adoption, this is a bottleneck in operations and how we function as an organization. And we have to look at both because if we’re just looking at how users are behaving, it’s only part of the picture. And so in this case, you talked about the bottleneck being incentives for the sales team, but I’m curious, what other bottlenecks have you noticed in the recent few months as things have been shifting around your approach to teaming and setting priorities and even the speed of development?

Daniel Elizalde: Yeah. One thing that I want to point out that I’ve seen talking about this new speed, a bottleneck that I’m finding is that customer attention is a scarce resource. We can’t just say, “Hey, in the past, we need to be very customer-centric. We need to do discovery. We need to put prototypes in front of the customer, and it takes time.” And that’s the right still way to build products because you need that input from real users. But especially in B2B, those customers are busy running their business and they have very limited time to look at discovery with you or to see your latest demo or to see your latest thing. And it needs to be orchestrated with sales. And so all of a sudden, you want to be in front of your customers with 35 new prototypes that you created this week. I mean, it just doesn’t work. There’s an exhaustion from favors you can ask from customers and people to understand that. That is different. So how do you make sure that you’re building the right thing with the right inputs without having to burn all your favors and balance that speed? A main message here is that with AI, you can accelerate your own clock, but you can’t accelerate things that are not in your control. You can’t accelerate the speed of adoption. You can’t accelerate the attention span of the customers. You can’t accelerate grants and things like that. So how do you do it? I’ve had some discussions with other leaders about like, “Well, maybe you just slow down some of the things.” Maybe you say, “We’re not going to produce things as fast because they can’t be consumed by the market, so what’s the point?” So those are philosophical things we’re wrestling in the product and engineering world. Right?

Douglas Ferguson: Yeah. I mean, it’s interesting you talk about … There’s kind of a thread here around … There are some things that can move insanely fast, but then there’s some things that are governed by laws of physics that require … There’s a built-in speed limit. The speed of light is a constant and we can’t go over it. And so we have to be mindful of those. And that’s where … This is something we talked about in the pre-show chat, taking a systems approach is so critical because if we’re not taking a systems approach, we don’t notice those incentives that are biting us in sales. We don’t notice that there’s this speed limit that we’re not accounting for. We’re just throwing stuff through. And to your point, we can build tons and tons of prototypes, but if we don’t have enough people to look at them, then we can’t get the feedback because the prototype’s invaluable. I mean, a prototype is just a tool to answer a question. If there’s no one there to answer that question for us, then the prototype’s of little value. There’s a similar thing, I don’t know if you’ve seen this, but there’s a similar problem where … This hits more on the business side, I think. But I guess even on the product side, people are generating so many artifacts that those that are reviewing the artifacts are just overwhelmed. Take your example of building 53 prototypes. We certainly can’t necessarily show that to the users because we’d overwhelm them, but even the team having to … Who’s the person that’s going to review those and decide which one we do put in front of the user?

Daniel Elizalde: Exactly.

Douglas Ferguson: That’s a whole nother body of work that didn’t exist before.

Daniel Elizalde: Yeah. And just to keep your speed limit analogy, I’m a huge car fan and a big F1 fan. And the way I think about this revolution is that if you have an F1 team and then all of a sudden the engine mechanics figure out how to do engines 10X as fast. Not just by putting the engine in the car, that’s not going to make it 10X faster. The wheels are not designed for that and the suspension is not designed for that, and you’re going to burn your fuel like that. And then you take it outside your team. Well, the tracks are not built for that speed and the pit stops are not built for that. So all of a sudden the suspension team is going to say, “Okay, we’re going to update the suspension for this new engine. Wait, I have three other new models of engines that I created during the weekend.” And it’s like, “It doesn’t work like that.” And so for the team owners, they’re like, “We’re not necessarily going any faster. We’re not winning any races because yes, we have one part that is faster, but it has to work as a whole and the whole is not adapting as fast. And the market, the track in this case is not adapting as fast either.” There’s lots of physics there, right?

Douglas Ferguson: Yep. When you mentioned that, I immediately went to the pit crew and how tuned that has to be. And to your point, if you over optimize one thing, it actually might make things go slower because now the whole … That system is dysregulated.

Daniel Elizalde: Exactly. And you see it even … I don’t know if you follow F1, but you see teams doing an upgrade to the engine and all of a sudden there’s a lot of vibration or it turns out that the brakes are not calibrated the same. And so they actually go slower, instead of faster.

Douglas Ferguson: Yeah, yeah.

Daniel Elizalde: So we’re seeing the same thing. And I don’t know that … Going back to business, the rest of the organization can work at that speed. And so I think there’s going to be a recalculation of what it really means to drive technology in a company because that exponential output that we’re able to create, if it doesn’t have a home to go and drive the rest of the business. Then it doesn’t make sense. Yes, you can do it. I’ve heard some people talk about, “Well, instead of having two pods with six developers, you’re going to have the PM builder and you’re going to have 12 people, each one of them doing their own product and you’ll have 12 products.” And it’s like, “That’s crazy.” As a company, how do you absorb 12 products? How do you sell them? How do you market them? It’s just not realistic. So it’s really interesting. I’m really curious to see where this is going to land, so that we can balance the rest of the car and the rest of the team to truly provide more value to the customer, which is what this is all about.

Douglas Ferguson: Yeah. Yeah, I agree. I also think too, there’s … Other products is certainly one direction that things can go, but also, how are engineers supporting the rest of the organization? Because we’ve never been in a point in history where it’s so easy to build your own tooling for things that … And our need for tooling is probably going to increase dramatically, to your point as the other parts of the organization need to function well beyond what they can today. And so instead of new product lines, what about carving folks out to think about decision making tool frameworks? All sorts of things that we might need and internal admin dashboards. If we’re perplexed on where the bottleneck is, do we need to build a tool to analyze the bottlenecks, rather than just assume and go build, let’s make some scaffolding, so we can understand the business better, understand the user better. These kinds of things.

Daniel Elizalde: Yeah, definitely. And that is an interesting conundrum that I’m also seeing as big friction, when it is so easy for non-technical folks to create solutions, thinking about outside product engineering, anybody can vibe code an application. If you think about the history where we’re coming from, organizations grow when you have legacy systems that took 5, 10, 20 years to fold and now they’re a mess and you have to do a lot of maintenance and that. And so if all of a sudden everybody in the organization can vibe code their own thing, that legacy, that rat’s nest of tools and information and all that becomes accelerated. There’s a big importance on understanding what those applications are using for getting their information. So data pipelines, semantic layers, those things to make sure that, “Okay, if you’re going to allow people to build their own things, the maintenance is hard, but at least they’re all reading from the same data.” And those are the kind of things that are invisible engineering, and you have to come in to the executive team and say, “For us to enable to do this, if we’re going to let everybody in the company vibe their own apps, they’re not going to cross my infrastructure line. I’m going to have to give them a layer that they can poke into and that’s going to take resources to build.” But after that, we’re enabling this vision that more people tap into that. And if you don’t have that initial governance or those discussions, it becomes a free for all, and then everybody has their own data, it becomes a mess. That is organically how companies evolve, but you can get there in six months these days, right?

Douglas Ferguson: Yeah. Yeah. People talk a lot about governance and what’s needed to have safe and reliable and responsible AI use. I think it’s conversations like these around, what semantic layer are we going to provide? How are we firewalling people off, so they can’t do things that are unintended? Just being really thoughtful about these guardrails that we put in place, so they can experiment freely and almost feel unencumbered because they’re hitting the bumpers that are necessary and we can trust those bumpers are where they need to be and will withhold whatever they throw at them.

Daniel Elizalde: Yeah. And I feel like that is one of the frictions because all of a sudden you have this tension of speed. “Hey, technology team. What do you mean you need six months to build a solid semantic layer with services on top so that we can run, I don’t know, agentic analytics or something? When I can just take Claude and vibe code this thing in five minutes.” “It’s like, “Yeah, but that doesn’t scale.” There’s a lot of things that … You don’t want to be the bottleneck either. So you have to say, “Well, if I don’t have the capacity to solve those business problems right now, what are the potential solutions?” You can build them yourself with AI, but it has to be some layer of guardrails and governance, otherwise it becomes a mess. And building that layer both in terms of rules and actual software takes time. So there’s a paradox, like a push and pull of, “Yeah, this should be easy. We can do all these things now. Yeah, kind of.”

Douglas Ferguson: Yep. One of the things we’ve been talking a lot about is what we call friction discernment. It’s often a treacherous path to go just try to assassinate all friction because A, to your point, is solving that friction going to provide business value and how do we prioritize which friction gets attention? But also just because something feels slow and frictionful doesn’t necessarily mean it’s a bad thing. And so being able to acknowledge it like, “Actually that friction is a feature and maybe we leave that in the system.”

Daniel Elizalde: Yes, I think that’s a really good point, understanding what things are better slowed down, especially in my case working with regulated industries. Well, we’re going to take longer, but we’re going to analyze and make sure that nobody can access personal identifiable data or governance around something else. It’s better to take some time on that than the consequences.

Douglas Ferguson: Yeah. We talked a bit about the strategic layer, so taking this portfolio approach, deciding what’s in, even hitting the pause button on things, just because adding more isn’t always necessarily the right business decision. And layered onto that … Well, I guess in the pre-show chat, we talked about you in your purview having to think about three layers. The business use cases of AI, how are folks across the org consuming it? We touched on that just a little bit around the semantic layer, but the second way that you’re thinking about AI is how AI is being embedded and showing up in the product and AI powering certain features and capabilities in the product. But then there’s also one we haven’t touched on yet, which you said definitely is something you’re having to think about and this three-headed beast, which is how is it empowering engineers or even shifting the development process? And so I’m curious, what have you retooled or shifted as it relates to your release train? And so beyond just the deciding what to put into it, once you’ve decided what to build, how’s the day-to-day engineer experience shifted for your team?

Daniel Elizalde: Yeah, that’s a good question. We are in the journey, nobody has fully figured it out, but the reality is that there’s a good level of adoption of tools, development tools, code in particular in my engineering team, and there’s a big amount of the actual code being written by Claude. And so we have mostly … The role of the developers of course is getting the prompts, understanding what we’re building and reviewing, but there’s a lot less of that manual coding. We have discussed a lot of the re-usability. How do we make sure that it is standardized as our operating procedures? So it’s not like this developer happens to be very senior, they use it this way versus this other. It’s like, “What are those guidelines? What are the skills that we need to do? What are the tooling that we need to build?” And my team has built really interesting tools about, this is how we do ticket refinement, this is how we do the pulls and push, this is how we test some corner use cases. So those are already either agents or skills, and so everybody in the team uses those. And so we are able to get a lot of velocity along with consistency across the teams. And that is super important for me because … Talking about this capacity allocation, I want to make sure that the engineering team members are able to perform the same with the same operating principles, whether they are in part A, part B or part C. And so that has to be standardized across. And so that’s a journey. We’re not there for sure, but there’s that understanding from my perspective that it can’t be, “Here’s Claude, have at it.” There has to be some discipline, there has to be some training, there has to be some governance in like, “This is how we use it internally.” And one of my engineering managers, she’s really, really strong and really, really good at this. So she’s setting all those principles and then training the teams and making sure that we have a true operating cadence.

Douglas Ferguson: Nice.

Daniel Elizalde: It made us very, very, very efficient and we’re able to be very productive in a way that we haven’t been in a long time. And definitely in my career, we are producing a ton of output that is solid at a pace and with much smaller teams that I’ve had managed in the past. It’s incredible. And so the challenge really is for me in the leadership seat, where do I point this newly created engine? Where is the best way to do it? Because wherever I point it, it’s going to do a lot very quickly. So I better point it in the right direction. that’s the challenge from a leadership perspective that I’m sure a lot of tech execs are dealing with. Right?

Douglas Ferguson: Yeah. It’s like having a high-powered laser versus a shotgun, right?

Daniel Elizalde: Yeah, exactly. Exactly. It’s always like-

Douglas Ferguson: You can spray a wide range with the shotgun, but it’s not going very far. But a laser, you got to be real specific, but it can go quite a vast distance.

Daniel Elizalde: Yeah, exactly. If you were kind of goofing around and you were pointing it at your feet and it fires, all of a sudden you have a crater in the floor. It can actually put you in the hole very, very quickly.

Douglas Ferguson: Yeah.

Daniel Elizalde: We have started to put a lot of … In addition to the clarity of product management and how the things we’re building fit with the mission, we’re also trying to create a strong architectural blueprint and reference, so that everything we build has patterns, knows where it fits. We can have consistency of how services and APIs and all those things work together. Just trying to make sure that if we’re going to go this fast, we better train for that. If you’re going to be an F1 driver, you better spend so many hours in the gym and learning and on the simulator, so that when you get in that rocket ship, you actually win the race.

Douglas Ferguson: Yeah. Awesome. Well, as we come to a close here, I want to leave you with an opportunity to offer our listeners a final thought.

Daniel Elizalde: Well, I think as a final thought, I think that … My main thesis throughout today is really before we can ask how fast a team can ship, we really need to understand how fast your customer can adopt whatever you are shipping. Because without that, you’re not going to be improving on the business numbers and it’s just development theater.

Douglas Ferguson: Wise words. Thank you, Daniel. Appreciate everything and look forward to talking to you again.

Daniel Elizalde: Thank you so much for the opportunity. I really enjoyed the talk, Douglas. I’ll see you the next time here in Austin.

Douglas Ferguson: Thanks for listening to New Friction. If you enjoyed this episode, share it with a leader who’s in the middle of this right now. They’ll thank you for it. And if you want to go deeper, we bring leaders together through executive dinners and virtual masterminds. To learn more about our work or to inquire about exclusive executive events, visit voltagecontrol.com. I’m Douglas Ferguson. See you next time.