What Joel Cloralt's Impressive Versus Valuable Framework Reveals About Where to Spend Limited Engineering Resources Today

Every engineering organization now has more AI options than it has engineers to pursue them. The demos are landing, the vendor decks are convincing, and the budget still has to go somewhere specific, but the leaders getting real returns have started applying a filter before the resourcing conversation begins. This separates the work that impresses a room from the work that changes how someone gets their job done.

Joel Cloralt has spent fifteen years building products across companies where that distinction carried real consequences. He is Director of Product at Smartcar, the connected vehicle API platform serving roughly 20,000 developers, where he owns product, design, and data analytics. His path there ran through a software engineering role at Yammer before its acquisition by Microsoft, product work at Dropbox, a year living in Tokyo, and product leadership at Vault through its pivot and acquisition by Acorns, followed by some time at Netlify.

He also keeps four apps in the App Store and built Smartcar's MCP himself, which is a deliberate bet against the assumption that senior product leaders drift permanently away from building. Joel joined our CEO, Stephen Koza, for our latest episode of TechPod Talks to discuss what that vantage point teaches about AI investment decisions.

Continue reading to learn more about the test Joel applies before committing resources to an AI initiative, the reasoning behind Smartcar's developer-facing MCP, and the organizational friction most leaders are underestimating as engineering roles change.

Impressive and Valuable Are Different Bars to Clear

The first AI move most platform companies made was the obvious one, which Joel describes plainly as figuring out what AI tools to hand developers. Smartcar started in the same place, and the early learning arrived quickly. The ability to chat with a bot proved genuinely interesting but fell short of being genuinely useful because conversation is rarely about how developers actually work.

"There's a lot of impressive things, but impressive and valuable are very different. It's amazing when you have both."

The gap between those two bars is where most AI budget disappears now. Joel's test for the valuable side is specific. He asks whether the thing being built actually changes how someone works, either by producing a more productive integration or an easier one. A capability that clears the impressive bar alone generates a demo, a press mention, and very little durable adoption.

However, the commodity problem sharpens the point. Joel notes that adding a chatbot has become table stakes, since AI has largely solved the building part and everyone can now ship one. A capability that any competitor can replicate over a weekend carries no strategic weight, which pushes the real differentiation into the problems a platform chooses to solve and the quality of the solution underneath.

The MCP Decision That Started With a Resource Question

Smartcar built an MCP, and the interesting part is which one. Joel ran a trial on a consumer-facing version, and the concept had obvious appeal, since talking to your car is exactly the kind of idea that photographs well. He also identified it as a novelty and reasoned through what pursuing it would actually cost.

The constraint drove the call because Smartcar is a startup, meaning that the resources behind any initiative come directly out of something else. Joel weighed a substantial investment against the possibility that people simply want to tell a chatbot to lock their car doors. His read was that the market sits ahead of that behavior, so the team shipped the developer-facing MCP and aimed it at the pain their customers actually feel.

That pain for this integration was speed, since Smartcar's customers want their applications out the door quickly with minimal time spent thinking about the integration itself. The team pointed AI at that friction, made the documentation AI-powered, and built toward a world where an agent can go stand up an integration on a developer's behalf. The decision reads as a resource allocation call, which is what most AI tooling decisions actually are once the novelty is set aside.

"What problem are you trying to solve and the resources you put behind it?"

For a VP of Engineering or CTO, this is the reusable part. The consumer MCP would have worked technically and would have consumed the capacity required to solve a problem customers were already paying to have solved. Both paths were buildable, which is precisely why the resourcing question does the deciding.

The Accuracy Layer Behind an AI Integration Is the Real Heavy Lift

Joel is direct about where the actual engineering effort lives once a team commits to an AI capability. Building the integration has become the straightforward part, and making sure the agent responds accurately is the work that consumes the schedule.

That reframing matters for anyone budgeting an AI initiative. Streamlining SDKs, making documentation agent-friendly alongside human-readable, and validating that the system returns correct answers under real conditions form the substance of the effort. Joel calls accuracy the piece people miss most often, noting that the integration's engine carries the heavy lift.

Joel points to a cautionary example from outside software. He recalls Taco Bell's AI-powered drive-through test, where customers deliberately probed the system into producing an order for 18,000 water cups, forcing a rollback. His read is that getting AI into the drive-through was the easy part, while the operations around it, including the reality that people will try to break anything, is where the difficulty concentrated.

Engineering Roles Are Shifting Toward Review and Coordination

Joel came into AI adoption expecting it to make engineers faster at the work they already did, and he now describes that assumption as roughly half true. What he observes among early adopters is a change in the nature of the job, not necessarily the speed.

"You kind of stop doing the work that you were used to doing, and you become something closer to a manager. You're directing, you're coordinating, you're reviewing."

The organizational consequences deserve more attention than they usually get. Joel points out that many people became engineers precisely because they enjoy building things, and telling those people their role now centers on reviewing what a machine produced lands as something other than a promotion. He floats the possibility that the resulting hesitation is a reasonable response to losing work that people genuinely valued.

That framing turns adoption friction into a manageable problem. Why? Because a leader who reads slow uptake as resistance to change will push harder on mandates. A leader who reads it as people responding sensibly to a real change in their craft can address it directly, through how roles are defined, how the new work is valued, and how the team's identity adjusts to what the job is becoming. It is the same enablement and adoption problem that determines whether any new platform capability takes hold.

Joel leans on story to build that adoption. He plays recorded customer interviews for the engineering org, letting the person who lived the problem make the case for change in their own words. He credits Storyworthy, Matthew Dicks' book on using narrative to earn an audience's attention, as the framework behind that instinct.

High-Stakes Calls Get Made at 80% Confidence

The clearest illustration of how Joel decides under pressure comes from Vault, where the team had built retirement investment access for gig workers and others the traditional system left out. The idea was sound, and the intent was genuine, and adoption lagged anyway.

The constraint was runway, and Joel describes the position bluntly, noting that limited funding and missing product-market fit remove the luxury of waiting for a good idea to become a good business, which forces a call while there is still room to act on it. Moving direct to consumer meant giving up a version of the vision the team had rallied around, and it also became the route that made the outcome possible, since the acquisition by Acorns came on the strength of the consumer business.

The confidence level is the part worth carrying into architecture and build-versus-buy decisions. Joel puts it around eighty percent, arrived at by meeting with leadership, articulating why the move might fail, reasoning through the risks they could see, and accepting the ones they could not. The remaining twenty percent could have derailed the whole thing, which he says plainly.

Knowing When to Stop Is the Real Underrated Skill

Joel closed the conversation with the habit he considers one of the most undervalued in product and engineering: judgment. Specifically, about what to leave undone. The industry rewards effort, grinding, shipping, and pushing, and almost nothing in the standard incentive structure rewards a well-made decision to say no.

"Knowing when to stop would be my answer."

The difficulty scales with the quality of the options. Saying no to a bad idea is easy, but saying no to several genuinely good ideas so the best one gets real resources is the harder discipline, which lands squarely on senior leaders setting the roadmap. Stephen connected it to a line that has come up repeatedly on the show, which is that you can't have five priorities at one time because then you're saying none of them are the most important thing. He points to The One Thing by Gary Keller as a useful frame here, built around finding the single thing that makes everything else easier or unnecessary.

How to Apply These Frameworks This Quarter

The conversation maps onto decisions engineering and product leaders are making right now. Stephen's own approach to structuring an argument, borrowed from Barbara Minto's The Pyramid Principle, applies well to presenting calls like these to leadership, since it puts the takeaway first and lets the supporting reasoning follow. Here are a few other concrete places to start now:

• Run the impressive versus valuable test before funding: Ask whether the capability changes how a user works, and treat impressiveness as a separate and lesser bar. A feature any competitor can ship over a weekend carries no strategic weight.
• Frame AI tooling calls as resource allocation decisions: A technically feasible build still competes against everything it displaces, so weigh the novelty option against the friction your customers already pay you to remove.
• Budget the accuracy layer as the primary cost: The integration is now the cheap part. Plan for validation, agent-friendly documentation, and adversarial testing before production, because users will probe anything that accepts open-ended input.
• Plan for the role change, and not just the tooling: Expect AI to shift engineering work toward directing, coordinating, and reviewing, and decide deliberately how that work gets valued and rewarded on your team.
•  Set your confidence threshold at eighty percent: Articulate why a high-stakes call might fail, name the risks you cannot see, and let runway inform the decision window, since waiting for full certainty forfeits the chance to act.

For readers working through similar questions, this conversation pairs well with our recent piece on the infrastructure gap blocking AI ROI, which examines the foundation layer that determines whether an AI initiative reaches production. Our look at what the 5% of companies getting positive AI returns are doing differently covers the same territory from the returns side, and both are worth a read for any leader deciding where to put limited engineering capacity this quarter.

Partner with EverOps to Put Your AI Resources Where They Actually Pay Off

Our conversation with Joel kept returning to one practical idea. AI decisions are resourcing decisions, and the ones that pay off target problems people already feel.

For a VP of Engineering or CTO weighing this quarter's AI investments, that translates into a short list of concrete work. Choose use cases that answer a real user problem, build the accuracy and validation layer that carries an integration into production, and prepare the organization for the role changes that follow, because none of that happens on its own once the tooling lands.

If you are looking for a place to start, our AI Opportunity Assessment identifies and prioritizes the AI use cases genuinely worth a team's time, evaluating data readiness and technical infrastructure before a single line of code is written. For teams ready to prove value quickly, our AI Quick Start engagement delivers rapid results through proven playbooks, and our AI Adoption TechPod embeds a dedicated AI engineering team for continuous delivery and scaled adoption.

Wherever your team sits on that path, if you are working through any of the questions Joel raises here, we encourage you to reach out to our team today to start the conversation.

Keep Up With TechPod Talks

Joel Cloralt joined EverOps' CEO Stephen Koza for Episode 12 of TechPod Talks. Subscribe today to listen to the full conversation on Apple Podcasts, Spotify, YouTube, or the EverOps Podcast Page now.

Follow Joel on LinkedIn and the EverOps page for more from the series.

Frequently Asked Questions

What topics does Episode 12 cover?

Episode 12 features a candid conversation with Joel Cloralt on the difference between impressive and valuable AI capabilities, the reasoning behind Smartcar's developer-facing MCP, why accuracy is the real heavy lift behind any AI integration, how AI is shifting engineering roles toward review and coordination, and how high-stakes calls get made at partial confidence.

Who is Joel Cloralt?

Joel Cloralt is the Director of Product at Smartcar, a connected vehicle API platform serving roughly 20,000 developers, where he leads product, design, and data analytics. He has spent fifteen years in product and engineering roles, beginning as a software engineer at Yammer before its acquisition by Microsoft, followed by Dropbox, product leadership at Vault through its acquisition by Acorns, and several years at Netlify. He keeps four apps in the App Store and built Smartcar's MCP.

What is the impressive versus valuable framework?

It is the filter Joel applies before committing resources to an AI capability. Impressive describes something that demonstrates well, and valuable describes something that changes how a person actually works, whether by making an integration more productive or easier to complete. The strongest AI investments clear both bars, and Joel treats the valuable test as the one that determines whether an initiative deserves resources.

Why did Smartcar build a developer-facing MCP?

Joel trialed a consumer-facing version and identified it as a novelty whose cost outweighed the likely demand, since asking a chatbot to lock a car door sits ahead of current user behavior. The developer-facing MCP targets the friction Smartcar customers actually experience, which is the time and effort required to complete an integration and ship their application.

How does this episode connect to EverOps' work?

EverOps helps technology leaders navigate the same questions Joel covers in this episode, including AI adoption prioritization, integration and accuracy work, and the operational foundation that carries an AI initiative into production. Services like AI Opportunity Assessment, strategy consulting, and embedded operations map directly to the decisions he describes.