Adam Nash holds degrees in computer science with a focus on human-computer interaction, an MBA from Harvard, and has spent 25 years working at the overlap of engineering, design, and finance. His read: the best product work isn’t about solving rational problems — it’s about designing around the ways humans reliably behave irrationally. He built that argument across eBay, LinkedIn, Wealthfront, and now Daffy — where every feature exists to close the gap between what people want to do and what they actually do.

About forty minutes into our conversation, Adam Nash confesses something I believe to be the crux of our conversation.

“The anxiety I have alone — still, I don’t know how it is — I am almost 50 years old,” he says, “my anxiety in a hotel room of accidentally moving one of those items in the minibar and being charged for it is not rational. But it’s somehow very deep-seated.”

I almost laugh. Not at him — with him. Because Adam Nash is, by any reasonable measure, the person you’d least expect to be intimidated by a hotel minibar. He teaches a Stanford class called Personal Finance for Engineers. He ran Wealthfront. He was VP of Product at LinkedIn through the IPO. He was CEO of a fintech company that managed billions of dollars on behalf of its customers. If anyone on Earth should be able to glance at a $9 Toblerone and shrug, it’s him.

Instead, he tells me he gets nervous about it. And the way he tells me is what I keep thinking about. He doesn’t dress it up. He doesn’t make it a metaphor first and a confession second. He says it the way you’d admit to a friend at a bar that you still get butterflies before flying. The point isn’t that minibar anxiety is interesting. The point is that even Adam — the guy who has designed financial products for two decades — still has it. And that’s the entire thesis of his career.

We’ve been talking about Daffy, the company he founded in 2020. Daffy stands for the Donor Advised Fund For You, and it’s exactly what it sounds like: a tax-advantaged account for charitable giving. You put money in. It invests tax-free. Whenever you’re inspired to give, you go in, pick a charity, send the money. The wealthy have had access to this product for decades — Fidelity, Schwab, and Vanguard all offer one — but most people have never heard of it.

That gap, Adam tells me, is the entire opportunity. And the gap exists not because the math is hard, but because of something much stranger: people are not rational about money. Especially their own.

“Money is very rational,” he tells me. “Dollars and cents, right? You know, the math adds up. Like it’s either a good return or a bad return.” He says it the way someone reads aloud from a textbook they don’t fully agree with. Then he pivots. “But in the end, what’s the money for gets back to people — and people have feelings about money. They have feelings about what they’re doing with it, how they earned it, how they spend it, et cetera.”

This is the move that runs through everything he’s built. He stages the rational view first — the one MBAs are trained on, the one accountants live inside — and then he pulls it apart. Not because the rational view is wrong. Because it’s incomplete in the only way that matters: it doesn’t account for the actual humans who use the product.

I ask him how that lens — the irrationality lens — got into his work. He goes back to the early days of his career, when design was treated, in his words, “as almost an accessory marketing function — like make it pretty. Um, oh, make sure the brand is correct, the colors and text.” He’s not bitter about it, but you can hear something in the cadence — a person who watched an entire discipline be miscategorized for years and decided, at some point, to fix it where he could.

When he got to LinkedIn, he sat down with Reid Hoffman and made an argument that the company needed a horizontal design team — a team whose responsibility was the end-to-end experience, not any single page or feature. He’d spent his eBay years watching Web 1.0 products turn into “a library of pages and not really a product, not really an experience.” He didn’t want LinkedIn to become that. The team he built is still there.

But the more interesting story, to me, is what happened earlier. The career detail he drops almost as a footnote.

“I actually started,” he says, “I thought I was interviewing at a company called NeXT, but it turns out Apple acquired them in the middle. So I was there when Steve came back.”

He says this the way some people mention their college roommate. He worked on Rhapsody, which became Mac OS 10, which became the operating system most of us spent the next two decades using. He was there for the moment when Steve Jobs walked back into Apple and the entire trajectory of consumer computing changed. He’s not bragging. He’s setting up a different point. The Apple culture he watched — and later the Pixar culture he studied through Ed Catmull’s Creativity, Inc. — taught him that great products are made when designers, engineers, and operators don’t fight each other for primacy. They take each other’s instincts seriously.

“If they came up with an idea, there must be a good reason for it,” he says, paraphrasing the Pixar engineering team’s posture toward design. “Let’s figure out how to make that real and make that as excellent as possible.” And vice versa. It’s the win-win posture, he says, that makes a team transcend its parts.

I’ve worked at companies where this happens and at companies where it doesn’t, and the difference is night and day. He doesn’t romanticize it. He’s quick to point out the failure mode. “There’s a hubris that can set in with different roles,” he tells me, “where people decide that — no, engineering is the most important role, we can’t do this without it. Design is the most important role. And of course, product folks — product is the most important role.” He pauses, like he’s actually testing the claim against his own memory. “I think it misses the big picture.”

The big picture, in Adam’s telling, is that no one function ever shipped anything beautiful by itself. Beautiful products require people who can hold multiple frames at once. And the highest-value frame, in his career, has been the one that takes irrationality seriously.

I want to know how that frame translated into Daffy. So I ask him about a feature I noticed — the auto-deposit. You can have money debited from your account every week, every month, into your Daffy fund, before you ever decide where to give it. To me, that’s the whole product. You’ve already mentally separated the money from your life. By the time you sit down to give, the friction is gone.

He nods. This is the move he’s most proud of, I can tell, because his whole tone shifts. He starts using the word “we” more — the team voice. And he starts walking me through what he calls the most important insight of the company.

“Giving involves not one, but two hard problems for most people,” he says. “One is how much can I afford to give? And two, who do I give the money to? And the worst thing about the transactional system that we currently have is that you get hit with both of those problems.”

I have to stop and write this down, because it’s the cleanest articulation of a pattern I’ve watched fail thousands of people in dozens of contexts. Every donation page on the internet asks you both questions at the same time. Pick a charity. Pick an amount. Right now. Most people stall on one or the other and end up doing nothing. Or they default to the easiest option — give five dollars to a friend’s GoFundMe — and feel vaguely guilty that this isn’t what they meant by “I want to be generous.”

Adam tells me about the customer research he did before founding Daffy. He went around the country, talking to people about their giving. The thing that struck him wasn’t the diversity of opinions — though there was plenty of that. It was the consistency of one specific moment.

“You ask them how much they think they should give to charity every year — most people have an idea of what that is. But you ask them, did they hit their goal? And they all end up with this pregnant pause of no, you know, life got in the way, it got busy.”

The pregnant pause. He says it like he heard it dozens of times and stopped being able to un-hear it. Everyone had a number. Almost no one hit it. And the gap between intention and action — what he calls the Generosity Gap — wasn’t a values problem. It was a design problem.

This is the moment in our conversation when I realize what he’s actually doing at Daffy. He’s not trying to convince anyone to give more. He’s trying to remove the design friction that keeps generous people from acting on their own intent. The same way a 401(k) doesn’t make you save more — it just removes the moment of decision that you would otherwise fail at.

“It turns out with money, with finance, automating these things gets you to your goal more reliably and faster,” he says. “If we can do this with saving and investing, why can’t we do this with giving?”

He keeps coming back to this. The rational thing — the thing the textbook would say — is that adults should be able to set a giving goal and meet it through willpower. But adults can’t. And not because they’re bad. Because the system is built against them.

We get into the part of his thinking that he wrote about more than a decade ago, in an essay he called Finding the Heat. He tells me about being in marketing meetings where everyone wanted to talk about the brand’s positive attributes — hope, security, control. He’d push back. “We look at half the problem,” he tells me. “The world isn’t just filled with positive feelings.”

The negative emotions matter just as much. Maybe more. Fear. Anxiety. Embarrassment. The fear of messing something up. The fear of being charged for the minibar item you didn’t actually take. He’s not being cute when he tells me this — he’s giving me the same example he probably gave a marketing team a decade ago. Money has heat. If you design as if it doesn’t, you’re missing the actual problem.

And this is the place where his framework finally lands for me. Designers, when they’re doing the job at full strength, are behavioral economists. They’re not arranging pixels. They’re studying the predictable ways humans fail to do what they say they want to do — and then designing around it. The button isn’t bigger because bigger is prettier. The button is bigger because there’s a moment of doubt that you have to walk the user through. The default is opt-in because the literature on defaults is conclusive. The deposit happens before the decision because the research on pre-commitment is overwhelming.

Adam doesn’t say it this way. He doesn’t have to. The whole conversation is the proof.

I bring up Rory Sutherland — the Ogilvy executive who’s spent his career arguing that most things fail because we apply rational solutions to emotional problems. Adam smiles at the framing. He partly agrees. But he wants to add a wrinkle.

“I don’t know if you’ve met rational humans,” he says. “Please let me know. I know there are 8 billion on the planet. I’ve not met all.” He’s joking, but the joke has teeth. The framing of “rational vs. emotional” is itself a category error. There aren’t two camps. There’s one camp — humans — and they all have feelings about money, even when they’re trying not to. Even Adam. Even in a hotel.

We talk about Daffy Campaigns, the feature that lets members fundraise for causes and offer matching donations. He tells me about a member whose parent — a teacher — had passed away two decades earlier. On the anniversary of the death, the member ran a campaign to raise money for students. “That kind of story is not going to come out of a marketing team,” Adam tells me. “That kind of story is not going to come out of a corporate kind of process. These are personal stories that people are telling.”

He says it quietly. We’ve been talking for over an hour and the energy in his voice has settled into something I’d call admiration — for the people using the product more than for the product itself. He keeps saying “we” when he talks about Daffy, but when he talks about the campaigns, he says “they.” The members. The givers. The teacher’s child. The company is the scaffolding. The campaigns are the building.

I ask him to wrap things up however he wants. He doesn’t pitch. He doesn’t ask anyone to download anything. He says one thing that I’ll keep returning to.

“It really does feel good,” he tells me, “to realize that some of the benefit of your skill, of your work, of your life, could benefit others.”

Then, almost as an afterthought, he tells me what people say after they’ve used the product for a while. It’s not that they saved money on taxes. It’s not that the interface was nice. It’s that the product made them feel good about how they were teaching the next generation.

Which is, I realize after we sign off, the most behavioral-economics thing he could have told me. The product’s measurable outputs — dollars donated, accounts opened, charities funded — are not what closes the loop with the user. The feeling does. The story they tell themselves about who they are when they use it. The image of their kid asking what the donation is for, and them having an answer.

That’s the gap that was always there. Adam built a product that closed it. And the only reason he could see the gap in the first place is that he never bought the premise that designers are decorators. He understood, going back to NeXT and Steve Jobs and Reid Hoffman and the Generosity Gap, that designing for humans is the same job as designing around their irrationality.

Giving isn’t a values problem, it’s a tooling problem.

When it’s a tooling problem — it’s a design problem.

About Adam Nash

Adam Nash is the Co-Founder and CEO of Daffy, a donor-advised fund platform revolutionizing charitable giving. Rising to prominence in the 2010s as a product leader across Silicon Valley’s most influential technology companies, Nash became known for scaling platforms to hundreds of millions of users and pioneering new categories in fintech.

Previously, as Vice President of Product & Growth at Dropbox from 2018 to 2020, Nash led the teams responsible for growth, product strategy, product management, and product analytics for a platform serving over 600 million registered users with responsibility for approximately 90% of all company revenue in 2019. Before Dropbox, he served as President and CEO of Wealthfront from January 2014 to October 2016, where he championed the creation of automated investment services and grew the company’s client base by over 60x while scaling assets under management 45x from less than $100 million to over $4 billion.

His career highlights include serving as Vice President of Product Management at LinkedIn, where he led the company’s Platform & Mobile products including the launch of LinkedIn’s open developer platform and native applications. Nash founded LinkedIn Hackdays, a program instrumental in driving the company’s innovation culture, and led search, cloud efforts, and user experience design teams. Earlier in his career, he held strategic and technical roles at eBay and Apple.

As an angel investor since 2011, Nash has invested in over 150 seed-stage companies including Figma, Gusto, Opendoor, Firebase (acquired by Google), and Boom Supersonic. He has served as an Adjunct Lecturer at Stanford University since 2017, teaching CS 007: “Personal Finance for Engineers.” Nash holds BS and MS degrees in Computer Science from Stanford University and an MBA from Harvard Business School.

Hey,

Thanks for reading this. I mean that. There's a lot of content out there competing for your attention, and you spent some of it here. I hope it was worth it. Even better, I hope it prompted you to think about something differently enough that you'd share it with someone who'd get something out of it too.

I started this podcast because tactics never stuck with me. What stuck were stories — business biographies, autobiographies, the decisions people made and why they made them. The principle only clicks once you know the story behind it.

So I built the thing I wanted to read. Every week I have two conversations with people who build in technology and product. Then I write the essay I wish I could find — one that puts you inside the conversation, through my eyes. What caught me off guard. What I kept thinking about after we hung up. Where the principle actually lives once you strip away the jargon.

I make this for myself first. If you read the way I do, you’ll want it too.

PS — If you want to pitch coming on the show, or you know someone I should talk to, shoot me an email at caden@hey.com with "January752" in the subject line so it gets past my filters. I'm not optimizing for famous guests. I'm optimizing for interesting conversations, even from people who aren't LinkedIn influencers.

He asks me to wait.

“Hang on, hang on,” Pete Hunt says, right before we start recording. “Let me spin down these agents I have going on so I don’t mess up the recording quality.”

I stop and register what he just said. Not put my phone on silent. Not close some tabs. Spin down his agents. The CEO of Dagster Labs — a venture-backed company building AI-powered revenue forecasting — has to actively wind down the AI workflows running in the background just to free up enough bandwidth for a podcast. In March 2026, this is what preparing for a meeting looks like.

I mention it when we start. He doesn’t elaborate. He doesn’t need to.

Pete Hunt is not someone who traffics in hype. He comes from an engineering background — he was an early member of the React.js team at Facebook, one of the most consequential open-source projects in the history of the web. He’s been in the startup world long enough that he doesn’t need to perform enthusiasm. What he does instead is tell very specific stories about very specific moments where something stopped making sense.

The thing that stopped making sense — for a long time — was Salesforce.

I come to this conversation with history. I’m a product designer who spent years inside the machine, in organizations that had Salesforce and couldn’t make it work. I’d watched rev ops teams fail not because the concept was wrong but because the implementation always seemed to require someone saying “five to six digits of implementation spend” before you could even get the thing to do what you needed. There’s a multi-billion dollar consulting industry built entirely around one software product. That’s not a feature. That’s a confession.

Pete understands this. The rev ops function — the people responsible for clean forecasts, accurate data, and the infrastructure to actually sell — matters more than most startups realize, he says. Pre-sales engineering, too. Most of the startup playbooks he’s seen skip both. They tell you to hire a great head of sales, hire reps at the right velocity. What they leave out is the foundation underneath.

“You know what I would always get back?” he says, describing his own forecast meetings at Dagster. “This is what it’s gonna be because Salesforce says so. Then it would always be wrong.”

He says it without heat. Not frustrated, just describing a pattern he’d seen enough times that it stopped surprising him. The pretty dashboards would say one thing. The salespeople on the ground would say something different. Every deal was a snowflake. You couldn’t get an aggregate view. And when you told the team to create pipeline, they would put pipeline into the CRM — because that’s what you asked for. Not because the deals were actually going to close.

“If you tell your sales team to create a pipeline,” he says, “they get happy ears and they put stuff in the pipeline and they defend it even when maybe it shouldn’t be defended.”

This is the data problem that eventually built Compass. And it started, improbably, on a plane.

Pete was flying to Snowflake Summit. I keep returning to this detail — the particular absurdity of a CEO of a data company going to a major data conference while being completely unable to trust his own company’s pipeline data. He’d gotten fed up. Not with rev ops as a concept, but with what it cost to get to the truth. “We’re not a huge company,” he says, “but it was going through two or three layers of people to get to the truth. It was kind of ridiculous.”

So on the plane, with nowhere to be, he did something with the kind of casual ambition that only makes sense in retrospect. He exported his opportunities from Salesforce as a CSV. He opened Cursor. He had the DuckDB command-line tool, which lets you run SQL queries against a flat file.

“I said, hey Cursor, I’ve got this CSV of my pipeline. Can you forecast my next quarter for me?”

What happened next is the reason we’re talking.

“It did a way better job than any other tool that we had.”

He was able to ask follow-up questions in plain English: why is this opportunity low likelihood? And Cursor would reason through it — this deal hasn’t had activity in thirty days, deals that sit in eval too long tend to be zeros, this one’s probably not going to make it to negotiation. Something shifts in the way Pete describes this moment. It reads less like excitement and more like recognition — the feeling of having looked for something in one place for years and finally finding it somewhere else entirely.

“The models had gotten really good,” he says. “Sonnet 3.5 at this point. And I was like, man, this is incredible. I want this now to run my business.”

He had to build it himself first. A crude command-line tool that produced bar charts as files on disk. Primitive. Dagster ran its business on that crappy system for a while. Then his data analyst looked at what Pete had cobbled together and said: you should make this a Slack bot.

“We gave it to everybody at the company,” Pete says. “It caught fire like crazy. Everybody started using it every week, or every day even.”

Then investors. Then customers. Then a product.

The arc from “guy with a CSV on a plane” to “CEO building an enterprise AI product” is shorter than it sounds when Pete tells it. What he’d stumbled into wasn’t a technical breakthrough — Cursor was already there, the model was already capable. What he’d found was a question that nobody’s existing tooling could answer. Not in real time. Not conversationally. Not without going through layers of intermediaries who were, in some sense, incentivized to defend the data they’d already entered.

I’d spent years in product. I knew exactly what he was describing. When I first found out what rev ops was actually supposed to do — forecast revenue, give you a clear view of pipeline, tell you if you’re qualifying the right leads — I wanted it. And every implementation I’d seen failed to deliver. Not because the people running it were incompetent. Because the infrastructure they were working with was designed for a world where getting to the truth required going through someone.

“AI isn’t taking jobs away,” I tell Pete at one point. “It’s taking away excuses.”

“Hmm.” He sits with it. “Yeah. Like, my first question when somebody has a question about the codebase is, did you ask AI about that?”

This is not what change management looks like in a workshop. Pete is explicit that mandates didn’t work. He tried nudging, encouraging, expensing tools. Some people got on board, some pushed back, some tried it and walked away. The people who were most resistant — who genuinely disagreed with the direction — he sat them down individually.

“Listen,” he told them. “This is an agree-to-disagree situation at this point. I respect you as a professional and you’re good at your job. But this is a place where we disagree.”

Some of those people became enthusiastic users of the AI products they’d resisted. Others went somewhere less AI-oriented. He says it without judgment. The thing that actually moved the organization wasn’t the memo or the mandate or the lunch-and-learn. It was the staff engineer who got religion on it and started unblocking big initiatives, faster than anyone expected. The domino effect — when someone everyone looks up to quietly starts doing things differently — that’s harder to ignore than any policy.

“That very opinionated staff engineer that everybody looks up to gets religion on it,” Pete says, “and then they start to really drive the authentic bottoms-up change throughout the organization.”

What Dagster is building now is, in some ways, the formalization of Pete’s plane experiment — with better infrastructure and a deliberate theory of behavior underneath it. The reason dashboards fail isn’t data quality. It’s access friction.

“If you put the M&Ms on the kitchen counter,” he says, “you’re going to eat the M&Ms. And if you make it really hard to access data, you’re never gonna look at the data. It doesn’t matter if your boss says you should be data driven.”

Compass is built around this idea. Make data fast and easy and fun. Pete describes the product’s personality — without apology — as what you’d get if you “hired a sassy Gen Z data scientist, locked them in a basement, and made them analyze data all day.” Something shifts in his voice when he describes it, like he’s relieved someone finally asked. The product drops memes when your pipeline is off track. It pushes insights before your sales calls. It reads like a personality, not a tool.

“When it’s fun and when it’s easy to use,” he says, “way more people use it and way more people ask questions of it every day.”

He frames the larger goal through the OODA loop — observe, orient, decide, act — the decision-making framework developed by Air Force strategist John Boyd and since borrowed by everyone from venture capitalists to sports coaches. The insight is simple: the faster you cycle through observation and action, the more likely you are to win. Compass is an attempt to speed up the observation step for go-to-market teams. Not just for the data analyst or the rev ops person. For every stakeholder who needs to know what’s actually happening in the pipeline.

“If you do more of those loops than your competitors over a given timeframe,” Pete says, “you’re gonna win.”

It’s a different frame than what most people use for revenue operations software. The standard frame is tooling: which CRM, which dashboards, which reports. Pete’s frame is metabolic. How fast is your organization processing reality?

I leave this conversation thinking about the plane. Not because it’s a good origin story — though it is — but because of what it required Pete to already believe. To export your pipeline as a CSV on a flight and ask an AI to forecast your quarter, you have to be willing to accept that what you’ve paid for isn’t working. You have to have run out of patience with the thing that was supposed to solve the problem.

“Number one,” Pete says, describing what the experiment taught him about AI, “it became accurate enough to be useful. And number two, I began to be trained to kind of expect some level of inaccuracy, and that was actually fine.”

That’s the real shift. Not that the model was perfect. That Pete had recalibrated what he expected — and what he was willing to accept — and found that the new standard was better than the old one. Humans and AI systems meeting in the middle. Each one adjusting to what the other can do.

The forecasts are still not perfect. They never were. But at least now they can tell you why.

About Pete Hunt

Pete Hunt is the Chief Executive Officer at Dagster Labs, the company behind the open‑source data orchestration platform Dagster and its commercial Dagster Cloud offering. Rising to prominence in the early 2010s, he became known as one of the early leaders of the React.js project inside Facebook and as a key engineering voice at Instagram during its hyper‑growth period. Today he is widely regarded as an influential figure at the intersection of data platforms, infrastructure, and developer experience, helping teams modernize how they build and operate data‑intensive systems.

Previously, as Head of Engineering and then CEO at Dagster Labs, Hunt helped guide the organization from its early identity as Elementl, founded in 2019, to a commercial data orchestration leader with the launch of Dagster Cloud and the introduction of Software‑Defined Assets in 2021. After joining the company in early 2022, he assumed the CEO role in November 2022 and has since focused on turning Dagster’s open‑source traction into a scalable business with a repeatable go‑to‑market motion. Under his leadership, Dagster Labs has grown into a well‑funded, small but highly specialized team shipping infrastructure that supports thousands of data assets across modern data stacks.

His career highlights include a formative stretch at Facebook beginning around 2011, where he was a founding member of the React.js team and helped drive its transformation from an internal experiment into one of the most widely adopted front‑end frameworks in the world. After the Instagram acquisition in 2012, Hunt became the first Facebook engineer embedded into Instagram, led the instagram.com web team, and built Instagram’s business analytics products as the company scaled to hundreds of millions of users. In 2014 he co‑founded abuse‑fighting startup Smyte, serving as CEO for roughly four years until its acquisition by Twitter in 2018, where he then worked on Trust & Safety and infrastructure during a period when the platform handled hundreds of millions of daily active users. Across these roles he has consistently operated at the point where new infrastructure—React, Instagram’s web stack, Smyte’s anti‑abuse systems, and now Dagster—becomes robust enough to support global‑scale products.

Outside his operating roles, Hunt has built a durable reputation as a conference speaker and educator, giving talks at events such as OSCON 2014 on how instagram.com works and sharing practical lessons on React, data platforms, and engineering leadership. Through long‑form interviews and podcasts, he documents the transition from individual engineer to founder and CEO, making him a widely referenced voice for engineers moving into executive roles.

Hey—Thanks for reading this. I mean that. There's a lot of content out there competing for your attention, and you spent some of it here. I hope it was worth it. Even better, I hope it prompted you to think about something differently enough that you'd share it with someone who'd get something out of it too.

I started this podcast because tactics never stuck with me. What stuck were stories — business biographies, autobiographies, the decisions people made and why they made them. The principle only clicks once you know the story behind it.

So I built the thing I wanted to read. Every week I have two conversations with people who build in technology and product. Then I write the essay I wish I could find — one that puts you inside the conversation, through my eyes. What caught me off guard. What I kept thinking about after we hung up. Where the principle actually lives once you strip away the jargon.

I make this for myself first. If you read the way I do, you’ll want it too.

PS — If you want to pitch coming on the show, or you know someone I should talk to, shoot me an email at caden@hey.com with "January752" in the subject line so it gets past my filters. I'm not optimizing for famous guests. I'm optimizing for interesting conversations, even from people who aren't LinkedIn influencers.

Yaron Schneider, CTO of Diagrid and creator of the Dapr open-source project, makes the case that technical design documents — upfront planning, architectural thinking, written specs — are now more valuable than programming. The engineers who figure this out first are going to look very different from the ones who don’t.

The best engineering team I ever worked with had a rule that drove everyone else crazy.

Before a single line of code got written — even for a small feature — you had to produce a technical design document. Not a ticket. Not a Slack summary. A written plan, down to the GraphQL queries, with architecture diagrams at level zero, level one, level two. The whole thing reviewed by staff engineers who would tear it apart and send you back to rethink your approach.

It added one to two weeks to every project. Sometimes a month for bigger features. As a product person, I wanted to scream. We could’ve just been coding this thing.

But when they shipped, it worked. Every time. Within tight timeframes. With almost no rework.

They moved slow to move fast. And at the time, that felt like a luxury — a high-performing team’s eccentricity that most organizations couldn’t afford because the opportunity cost of not shipping was too high. If we’re not building, what are we missing?

Then AI got good. And the thing I didn’t see coming is that it didn’t make that team’s approach obsolete. It made it universal.

I’m talking with Yaron Schneider about this — CTO and co-founder of Diagrid, creator of Dapr, five years at Microsoft building open-source infrastructure before starting his own company in 2022. He’s been watching the same shift from the other side, working with enterprises deploying AI agents at scale.

“Most software doesn’t work the way intended it to do because you skip the design stage or the architectural phase,” he says. “And so if you invest more in that, then it doesn’t matter who gets the job done, whether it’s AI or human, the job will be better.”

Whether it’s AI or human. That’s the line I keep replaying. Because the implication is that planning isn’t a step in the engineering process. It’s the engineering process. Everything after the plan is execution — and execution is increasingly something you delegate.

“This is now the central job of the software engineer,” Yaron says, “who hands over the work to an automated machine.”

He says it matter-of-factly. Like he’s describing something that’s already happened, not something that’s coming. And in the companies he works with, it has. The engineers who are thriving aren’t the fastest coders. They’re the clearest thinkers. The ones who can write a spec that an AI system — or a junior, or a contractor, or an offshore team — can execute without ambiguity.

But there’s a problem with this picture, and Yaron doesn’t shy away from it.

“Microsoft’s Mark Russinovich released a paper on it,” he tells me. “And what they’ve come up with is that junior developers are essentially no longer needed.” He lets that land. “And that’s a very harsh reality statement that came from them.”

I ask him to keep going.

“Well, now you need senior engineers to oversee AI because someone needs to write the prompt. Someone needs to guide it, someone needs to provide guardrails. And all of that is extremely needed.” He pauses. “But how are you gonna get senior engineers if there’s no junior engineers anymore?”

This is the question nobody has a satisfying answer to. The entire career ladder in software engineering was built on a progression: you start junior, you write a lot of code under supervision, you develop taste and judgment through repetition and mistakes, and eventually you become senior. The junior years aren’t a formality. They’re the training ground where the skills that matter — critical thinking, architectural intuition, the ability to foresee downstream consequences — get forged through thousands of small decisions.

If you remove the bottom rungs, the whole ladder collapses. Not immediately, but inevitably. You end up with a generation of senior engineers who age out and nobody behind them who learned the craft by doing it.

Yaron sees a path through it, but it requires rethinking what a junior engineer’s job actually is.

“I think historically we expected junior engineers to be able to churn out code really fast and produce a lot of it,” he says. “And now I think it’s gonna get flipped on its head where junior engineers are gonna be measured on their ability to adapt to new skills and learn really quickly.”

Less outputting and more inputting, he says. Juniors won’t be valued for how much code they produce. They’ll be valued for how quickly they can absorb context — reading documentation generated by both humans and AI, synthesizing it, building mental models of complex systems, and then translating that understanding into clear instructions for what they want to achieve.

“They have access to tools that can 20x what they do manually and also explain things to them in a very concise way,” he adds. And he’s right — the same AI tools that threaten to make juniors obsolete are also the best mentoring resources those juniors have ever had access to. In a world where team leaders are overloaded and senior engineers don’t have time to explain architecture decisions, an AI that has access to your entire codebase, your commit history, your past design documents, can drive context to a junior in minutes that would have taken weeks of hallway conversations and Slack threads.

The bar goes up for everyone. But the floor goes up too.

I’ve been living this shift myself. I started my career as a designer, moved into product management because the strategic work I wanted to do was too expensive to justify as a designer — the execution ate all the time. Then AI got good during my PM tenure, and everything inverted. The schlep work evaporated. Meeting notes wrote themselves. Decision docs assembled from context I fed in. I could plan at velocity for the first time.

And then I realized my job was constraining me. I could plan and execute now. So I went back to design.

The thing that changed isn’t that execution got easier — it’s that planning got cheaper. Not in quality, in friction. I used to rough out two or three concepts and pick the best one. Now I’ll do a hundred concepts because I have what amounts to a junior designer running variations while I think about the strategic framing. The idea I eventually hand off to engineers isn’t a guess anymore. It’s been stress-tested against a hundred alternatives.

“The idea that I’m handing off to engineers — it’s fucking proven,” I tell Yaron. “It’s steelmanned. We thought through everything at that point because I’ve had time to plan.”

He nods. “Resonates with me.”

And that’s what makes this moment different from every other wave of tooling that was supposed to change how software gets built. Low-code didn’t do it. Agile didn’t do it. DevOps didn’t do it. Those were all execution optimizations — ways to make the building part faster or cheaper or more predictable. But they never touched the planning part. They never shifted the identity of the engineer from someone who builds to someone who thinks.

AI does. Not because it’s a better tool, but because it makes the building so cheap that the only remaining competitive advantage is the quality of what you decide to build. The plan becomes the product. The spec becomes the artifact that matters. And the engineer who can write a plan so clear that any execution system — human or machine — can implement it without ambiguity becomes the most valuable person in the room.

Yaron’s company exists because he understood this at the infrastructure level. Diagrid doesn’t build agents. It builds the reliability layer that lets agents execute plans at enterprise scale without crashing, without losing state, without starting over. The whole business is predicated on the idea that execution is delegatable — and that what matters is the system that makes delegation trustworthy.

But the insight applies everywhere. Every engineering team, every design team, every product organization is going to have to answer the same question: if execution is no longer your bottleneck, what is?

The answer is the plan. It was always the plan. We just couldn’t afford to admit it when building was expensive.

Guest Bio

Yaron Schneider is the Founder and Chief Technology Officer at Diagrid, where he leads the development of distributed systems platforms that power durable workflows and AI agents for cloud-native teams worldwide. Rising to prominence in the late 2010s through his work on cloud infrastructure at Microsoft, he became known for co-creating the CNCF projects Dapr and KEDA, which today serve tens of thousands of organizations building microservices and event-driven applications. As Chair of the Workflows Working Group at the Agentic AI Foundation, he is widely regarded as an influential figure in defining how large-scale agentic systems are orchestrated and operated in production.

Previously, as Principal Software Engineer on Azure Container Apps at Microsoft, Schneider helped design and ship a serverless platform that enabled customers to run containerized microservices and event-driven workloads without managing Kubernetes directly, driving adoption across thousands of production clusters and multi-million-dollar cloud accounts. In earlier roles on the Azure CTO Incubations team, he focused on high-scale distributed systems and developer platforms, work that culminated in Dapr’s acceptance into the Cloud Native Computing Foundation in 2021 and its graduation to top-tier status in 2024, alongside Kubernetes and Prometheus. By 2025, the Dapr ecosystem was engaging over 40,000 companies across finance, healthcare, retail, and SaaS, and more than 90% of surveyed developers reported measurable time savings when building distributed applications with the runtime.

Schneider’s career highlights also include serving as Division CTO at ironSource from 2013 to 2015, where he led engineering for high-throughput advertising and monetization systems processing billions of events per day across mobile and desktop. Earlier, as a software architect at SuperDerivatives and a hands-on architect at Ness Technologies, he worked on low-latency, mission-critical platforms in financial technology and enterprise software, gaining the deep distributed-systems experience that later shaped his open-source work. Through Dapr, KEDA, and Diagrid’s Catalyst platform, Schneider’s contributions have helped standardize patterns such as workflow-as-code, event-driven autoscaling to and from zero, and durable agentic workflows across Kubernetes and multi-cloud environments.

Hey,

Thanks for reading this. I mean that. There's a lot of content out there competing for your attention, and you spent some of it here. I hope it was worth it. Even better, I hope it prompted you to think about something differently enough that you'd share it with someone who'd get something out of it too.

I started this podcast because tactics never stuck with me. What stuck were stories — business biographies, autobiographies, the decisions people made and why they made them. The principle only clicks once you know the story behind it.

So I built the thing I wanted to read. Every week I have two conversations with people who build in technology and product. Then I write the essay I wish I could find — one that puts you inside the conversation, through my eyes. What caught me off guard. What I kept thinking about after we hung up. Where the principle actually lives once you strip away the jargon.

I make this for myself first. If you read the way I do, you’ll want it too.

PS — If you want to pitch coming on the show, or you know someone I should talk to, shoot me an email at caden@hey.com with "January752" in the subject line so it gets past my filters. I'm not optimizing for famous guests. I'm optimizing for interesting conversations, even from people who aren't LinkedIn influencers.

Listen to this episode on Spotify or Apple Podcasts

The year is 2001, and Ben Johnson is standing in a room with good AC racking and stacking servers.

“We built a data center in the middle of West Texas,” he tells me, the way someone might tell you about a cabin they once built with their hands. There’s no nostalgia in his voice, exactly. More like the calm of a man taking inventory of what got him here. “2001, we are racking and stacking hardware. We’re configuring white box servers. We have 250 white box servers in a room with good AC.”

Two hundred fifty white box servers. I let that number sit. In 2001, that was an infrastructure commitment. That was capital expenditure, board approval, floor space, cooling, cabling, and a founder with a vision specific enough to want it all within driving distance.

“The founder wanted to do everything hyperlocal,” Ben says. “And this place happened to be located in the middle of West Texas.”

The company was called One Travel. It was part of the first wave of online travel, right behind Travelocity and Expedia. Before One Travel existed, you booked a flight by walking into a brick-and-mortar travel agency, sitting in a chair at a desk, and watching someone clack on a green screen terminal to arrange your airfare. Ben was part of the team that moved all of that onto the internet. But in order to move it to the internet, someone first had to physically build the internet — or at least their little piece of it, in the dry heat of West Texas.

This is the first key frame. I’ll come back to that word, because Ben and I end up using it as a kind of shorthand. Key frames. The moments where the picture changes, and everything between them is connective tissue.

Ben Johnson is the CEO of Particle 41, a fractional CTO service that has launched 94 products to market. He has co-founded five companies from start to exit. He’s been building software businesses for over two decades, and the way he tells the story, each chapter arrives with a new set of tools and a familiar set of choices. The tools change. The choice doesn’t.

Here is the second key frame.

“I’m in an online media company in 2013, and we can’t buy hardware fast enough for the amount of data we’re collecting,” Ben says.

Twelve years after West Texas. Twelve years after 250 white box servers and good AC. The world has shifted underneath him. AWS exists. Cloud compute exists. And Ben is sitting inside a company that is drowning in data and running out of physical capacity to process it.

“The cloud was a huge change,” he says. He spent eight years in online advertising, a domain that generates data at a scale that makes physical hardware look like trying to catch a river with a bucket. “I’m an early AWS adopter. I’m able to go get compute from AWS to run a big data platform to analyze ad traffic. And all I had to do is go learn about distributed data processing, fire up some hardware on the cloud.”

All I had to do is go learn. He says it like it was simple. And for him, maybe it was. But the sentence carries weight if you know what came before it — twelve years of building data centers by hand, understanding networks at the physical layer, knowing what it felt like to rack and stack your own servers. The learning wasn’t starting from zero. It was translating an entire career’s worth of hard-won context into a new language.

In 2015, Ben started a company that automated LLC formation — the process of going online to a Secretary of State website and filing the paperwork to start a company. In 2018, he sold that business to LegalZoom.

“I ended up selling that business to LegalZoom in 2018,” he says, and then immediately pivots back to the structural point. “And really the advancement in the cloud was significant. I didn’t have to go to the board or investors and ask for a hundred thousand dollars worth of hardware. I could just say, hey, let’s get started.”

That’s the thing about Ben. He doesn’t linger on the exits. He moves through them like they’re mile markers, not destinations. What interests him is the shift itself — the moment when the ground changes and you have to decide whether you’re going to change with it.

Which brings us to the friend.

“One of my good buddies that I still talk to — I talked to him yesterday — so he’s been a friend of mine for 25 years,” Ben says. “He was the gentleman, I was responsible for all the software at One Travel. He was responsible for all the hardware.”

The friend. The hardware guy. The one who was racking servers in West Texas right alongside Ben. What happened to him is the part of this story that matters most, because it’s the part that proves the thesis isn’t theoretical.

“About 10 years ago, he and I started talking about DevOps,” Ben continues. “Or writing code that represents infrastructure in the cloud. So he had to transition from an old school system administrator to a senior DevOps engineer. He went through a bit of a career shift.”

I want to pause on what that shift actually looked like, because from the outside, “career shift” sounds clean. It sounds like a LinkedIn update. But what Ben is describing is a man who spent the first half of his career with his hands on physical hardware — managing drives, monitoring storage, troubleshooting networks at the cable level — who had to learn to do all of that same work by writing code. The drives didn’t go away. The storage didn’t go away. The networks didn’t go away. But the interface changed entirely.

“He did quite well for himself,” Ben says, “shifting from — because now that he has all that contextual knowledge about system administration, the DevOps stuff is almost easier for him.”

Almost easier. Because he knows why. He doesn’t just know the syntax of infrastructure-as-code. He knows what a misconfigured drive looks like. He knows what happens when you run out of storage at two in the morning. He knows the physical reality underneath the abstraction, and that knowledge makes him better at the abstraction, not worse.

“He has both the context and the new skill of representing infrastructure as code,” Ben says.

And then the quiet part.

“People who didn’t make that shift had a rougher time of it.”

He doesn’t elaborate. He doesn’t name anyone. He just lets the sentence land. People who didn’t make that shift had a rougher time of it. It’s the kind of understatement that contains an entire population — the system administrators who saw the cloud coming and decided it was someone else’s problem, the hardware specialists who bet that physical infrastructure would always need physical hands, the engineers who looked at the new tools and felt something closer to threat than opportunity.

I ask Ben about what this looks like today. Not the cloud shift. The current one.

“Our job is to build the enterprise software factory and to operate the enterprise software factory,” he says.

He talks about Particle 41’s current work the way a factory foreman might describe a retooled assembly line. He has a front-end agent. He has a back-end agent. He has a DevOps agent making sure everything deploys correctly and the infrastructure is represented as code. He has a design agent. Each one has a defined scope of work, a set of inputs it expects, a set of outputs it produces.

“I still have to supply these agents with information,” he says, “and I still have to make sure that they’re all doing their job correctly.”

He catches himself gendering the robots — “his job is that, or I don’t want to gender these robots ‘cause they’re like genderless, but I make this mistake of gendering them” — and the moment is small but telling. The agents are close enough to colleagues that the pronouns slip. They’re real enough in the workflow to earn a possessive.

What he describes is not a replacement of engineers. It’s a reclassification of what engineers do. Before the agents, his engineers were writing syntax, pushing pixels, taking orders in the form of user stories and translating them into code, line by line. Now his engineers are overseeing a process. They’re governing. They’re asking whether every line of code has a test, whether the architecture supports what the client actually needs, whether the design patterns hold up under load.

“I do believe web development is dead,” he says. “Web development can be easily delegated to AI. But software engineering is now more important than ever.”

I push him on the distinction. What does he mean by “actually become engineers”?

And he gives me the answer that every CTO who has ever cut corners on testing already knows. “Oftentimes when you’re working with a company that’s 10 million to a hundred million in revenue,” he says, “things like test-driven development are optional.” He means: companies under pressure to ship skip the tests. They ship code without corresponding tests. Customers find the bugs instead of the engineering team. The product is functional but not properly engineered. And it was always a trade-off — the tests take time, and time costs money, and the board wants the feature by Friday.

But now the math has changed. The agents write the tests. The agents write the code. And the engineer’s job is to make sure the whole thing holds together — to think about architecture, about scale, about what happens when the product has ten thousand users instead of ten.

“Nobody’s losing fingers in the manufacturing process because they missed a semicolon,” he says.

The metaphor is deliberate. Ben keeps returning to manufacturing. The Ford assembly line. The Tesla factory. The Model T with its hand-wrenched bolts. He sees the history of software development the same way a manufacturing historian might see the history of auto assembly — a long, slow progression from manual labor to robotics, with each step making the work safer, faster, and more expensive to ignore.

I tell him about my own experience. I started as a designer, moved to product management because the cost of being strategic felt incompatible with also doing the work of design. Before AI got good, the hybrid PM-designer role nearly broke me. Now I’m back to doing both, because the agents handle the concept generation, the specification writing, the rote production work that used to eat my weeks. I’m an editor-in-chief now. I make editorial decisions. The junior-designer agent produces the drafts.

He nods at this. Not because it’s surprising, but because it’s the same pattern. The same story his friend lived. The same story he lived, three times over.

I bring up the instance model — something Ben warns about with the clarity of someone who has seen the trap being set in real time. Companies are vibe-coding bespoke solutions for customer one, duplicating them for customer two, and calling it a product. The investment market looks at the revenue and assigns a multiple. Maybe they get acquired for 50, even a hundred million.

“It’s hard to say that they did it wrong because it’s successful,” Ben admits. “So how do you say that?”

But then he lays out the math. Each instance is a separate codebase. Each customer’s version diverges from the next. The management overhead compounds. What looks like a product is actually a service wearing a product’s clothes, and at some point, the seams show.

“At some point that model cannot be duplicated,” he says. “And it won’t scale.”

This is the distinction that matters to Ben. Not whether you use AI — everyone is going to use AI. The question is whether you use it to engineer something real or to produce something fast. Whether you build a foundation or dig a hole.

We’re near the end of the conversation when he finds the image that ties all of it together. West Texas in 2001. The cloud in 2013. The enterprise software factory in 2025. Three eras, three sets of tools, one recurring choice.

“It is a bit of a battle royale right now,” he says. He leans into it, not flinching from the urgency. “People have put lasers on the battlefield and if you don’t go pick up a laser, you’re in trouble.”

I think about his friend. The hardware guy who became a DevOps engineer. The man who picked up the laser. And I think about the people Ben mentioned only once, in that single quiet sentence: the people who didn’t make the shift. The ones who had a rougher time of it.

The technology changes every decade. The tools change. The interfaces change. The abstractions pile up higher and higher, and the physical layer recedes further and further from view. But the choice — the one that separated Ben’s friend from the people who had a rougher time, the one that separated the early AWS adopters from the people still requesting hardware budgets, the one that right now, today, separates the engineers building software factories from the ones hoping the whole thing blows over — that choice has been the same in every era.

Pick up the new tool. Learn what it does. And bring everything you already know with you.

That’s the through-line. It was never the technology.

It was always the willingness to change with the market.

About Ben

Benjamin Johnson is the Founder and CEO at Particle41, where he leads a global software consultancy that has operated for more than 12 years across remote teams in the Dallas–Fort Worth metroplex and beyond. Rising to prominence in the 2010s, he became known for building high-performing engineering organizations that ship end-to-end digital products, from cloud-native platforms to AI-ready application modernization. As a fractional CTO and podcast host, he is widely regarded as an influential figure for founders seeking to scale technology capabilities without sacrificing speed or reliability.

Previously, as Chief Technology Officer at DOCKWORKS INC, he architected a web-based marine management platform that grew to serve more than 100 marine businesses in roughly 2 years before being acquired by DockMaster in 2023. In this role he led work order management, vessel tracking, and billing capabilities that helped streamline operations for small marine shops and boatyards while overseeing a full product and engineering organization. He also guided the post-acquisition integration, ensuring continuity for customers and enabling a combined product roadmap across two brands.

His career highlights include serving as Director of Software Engineering at LegalZoom, where he revamped the company’s Robotic Process Automation strategy, created excellence in document automation, and developed a company name-check algorithm that achieved approximately 98% state acceptance prediction accuracy for new business names. Earlier, as Co-Founder and CTO of Legalinc Corporate Services Inc., he helped grow the enterprise legal automation platform from zero to a successful exit to LegalZoom in about three years, building a one-of-a-kind legal filing API that secured partnerships with platforms such as Stripe Atlas, Yahoo Small Business, and Amazon. At IntelliCentrics, he managed DevOps for roughly 125 servers across three data centers, implemented auto-scaling and continuous delivery, and upheld a 99.9% uptime promise while training teams to independently extend automation.

As host of the Particle Accelerator podcast, he interviews technology and business leaders on strategic problem-solving, digital transformation, and leadership at scale. Through this work and frequent guest appearances on other shows, he continues to shape how founders, CEOs, and engineering leaders think about modern software development, DevOps, and AI-enabled growth.

Hey,

Thanks for reading this. I mean that. There's a lot of content out there competing for your attention, and you spent some of it here. I hope it was worth it. Even better, I hope it prompted you to think about something differently enough that you'd share it with someone who'd get something out of it too.

I started this podcast because tactics never stuck with me. What stuck were stories — business biographies, autobiographies, the decisions people made and why they made them. The principle only clicks once you know the story behind it.

So I built the thing I wanted to read. Every week I have two conversations with people who build in technology and product. Then I write the essay I wish I could find — one that puts you inside the conversation, through my eyes. What caught me off guard. What I kept thinking about after we hung up. Where the principle actually lives once you strip away the jargon.

I make this for myself first. If you read the way I do, you’ll want it too.

PS — If you want to pitch coming on the show, or you know someone I should talk to, shoot me an email at caden@hey.com with "January752" in the subject line so it gets past my filters. I'm not optimizing for famous guests. I'm optimizing for interesting conversations, even from people who aren't LinkedIn influencers.

Listen to this episode on Spotify or Apple Podcasts

Karl Simon tells me he walked into a Barnes and Noble, picked up Ralph Kimball’s Data Warehouse Toolkit, and taught himself database management overnight so Oracle could ship orders same-day. That was three decades ago. The man has been solving logistics problems with data architecture since before most of us knew what a data warehouse was.

I bring up an old maxim I’ve been turning over: amateurs worry about tactics, professionals worry about logistics. It’s been pivotal in how I think about senior IC work. Second-time founders obsess over distribution for the same reason. When the army doesn’t have food, you get Napoleon’s Russia campaign. And what Karl did at Oracle — going to a bookstore to close a knowledge gap on his own — that’s the kind of high agency I find rare and magnetic.

“The cost of agency is going down,” I say at one point, riffing on an insight from a prior episode. Karl stops me.

“Can I actually quote that?” he says. “’The cost of agency is going down.’ Love that quote because it should, first of all, it’s true. And then secondly, that should de-escalate any level of fear of AI taking over.”

Something clicks for me in the way he says it. Not as a platitude, but as a structural observation. I start pulling the thread of history out loud — feudalism hoarded protection, the Industrial Revolution broke that pattern and capital became the thing to hoard, then technology reduced the cost of making things over the last few decades, and now what they’ve been hoarding is agency. The ability to work the way you want. To think strategically. To have autonomy over your process.

Karl nods and extends it: “The opportunity for increased agency, being able to actually perform within more of an unbounded way, as long as you again, roll up and align to company goals... you’ve never had more freedom than you’ve had now to show who you are, how you like to think, and what you represent to the company.”

This is the core tension of the episode for me. I’ve watched people I respect — smart, capable people — get labeled as “low agency” at work. But they’re not low agency. They have fascinating hobbies they’re trying to master. They just couldn’t access that mode at work because the system wasn’t designed to let them. I had to dedicate years of extra work outside of my day job to speed the learning curve and rise high enough that I could work the way I wanted to work. And I don’t recommend that path to anyone. It’s a path of zero hobbies and fanaticism to craft. It’s just what I chose to do.

Karl’s work at Subatomic is interesting because it attacks the problem architecturally. When I ask him to explain knowledge graphs for non-technical listeners, he uses my podcast as the example. Caden runs a podcast. The podcast is named Way of Product. The podcast focuses on timeless considerations in product management. You keep going down the tree of relationships — categories, subcategories, themes — and you get an ontology. A map of how things relate.

I push the idea further: “If you show me someone’s data graph, you’re showing me the business logic. You’re showing me the strategy of the business.” Because you don’t want your graph to look like your competitor’s. That’s where the edge lives — in the architecture itself.

Karl agrees and then takes it further. It’s not just about representing what is. It’s about encoding how you think. Graph RAG — retrieval augmented generation built on a knowledge graph — lets you embed reasoning patterns into the system. A wealth advisor’s philosophy about when to prefer merger arbitrage over bonds given certain macro conditions, for example. That reasoning gets pulled at runtime, checked against ground truth, and then evaluated over time so the system can self-improve.

“Having a very good data graph is no different than having a well-written SOP document for a human,” I tell him. If your mental model of how operations should work is vague, humans churn. Same with AI. Precision leads to capability.

What surprised me most was how personal the unlock feels. I tell Karl about my own workflow — I have a prompt improver that I dictate to in natural language, and through memory, the AI has learned that I usually look back five days for certain records. I said it offhand once. Now the system self-filters its plans to that window without being told. It’s learning like an intern would.

“The unlock is that you get to do things the way you best work,” Karl says. “The way you optimally come to conclusions, decisions or outputs that you need to deliver.”

And that’s what I keep coming back to. The weird personal outcome of all this? I read physical books again. Actual paper. Because I don’t feel guilty about it anymore — the busywork that used to fill my time has been abstracted away. The data collection, synthesis, communication memos that used to be the entire job of everyone below middle management — AI handles that now. And it means everyone, not just executives, can operate strategically.

Agency used to be expensive. You had to earn it through years of proving yourself, navigating politics, building leverage. Now the ceiling is broken. The question isn’t whether AI will take your job. The question is whether you’ll use it to finally do the work you always wanted to do.

About my guest & how to find them online

Karl Simon is the Co-Founder and CTO of Subatomic AI, an enterprise AI Co-Worker Agent platform that deploys customizable agents adapted to client workflows, philosophies, and reasoning patterns. Rising to prominence in the 2010s as a data and engineering leader across retail, healthcare, and life sciences, Simon became known for building globally distributed data organizations and modernizing legacy platforms to support AI and machine learning at scale. Subatomic, co-founded with CEO Sam Sova and backed by a $7 million seed round in October 2025 led by Vantage Financial, focuses on high-stakes verticals including wealth management, legal, and manufacturing.

Previously, as a senior technology leader at Hudson’s Bay Company — the retail conglomerate that housed Saks Fifth Avenue, Lord & Taylor, Gilt.com, and other brands now consolidated under Saks Global — Simon led all engineering, business intelligence, and AI/ML functions across the company. Before that, he served in data engineering and analytics leadership roles at Komodo Health, Accenture, and Genentech, building AI-enabled decisioning platforms and modernizing source-to-target data pipelines across healthcare and life sciences.

Earlier in his career, Simon joined Oracle in manufacturing distribution, where he self-taught data warehousing from Ralph Kimball’s Data Warehouse Toolkit before applying those techniques to improve same-day order fulfillment insights. That formative experience established his approach to grounding AI systems in well-architected data foundations — a philosophy he has carried through more than three decades of digital transformations spanning mobile, big data, and generative AI.

Hey,

Thanks for reading this. I mean that. There's a lot of content out there competing for your attention, and you spent some of it here. I hope it was worth it. Even better, I hope it prompted you to think about something differently enough that you'd share it with someone who'd get something out of it too.

I started this podcast because tactics never stuck with me. What stuck were stories — business biographies, autobiographies, the decisions people made and why they made them. The principle only clicks once you know the story behind it.

So I built the thing I wanted to read. Every week I have two conversations with people who build in technology and product. Then I write the essay I wish I could find — one that puts you inside the conversation, through my eyes. What caught me off guard. What I kept thinking about after we hung up. Where the principle actually lives once you strip away the jargon.

I make this for myself first. If you read the way I do, you’ll want it too.

PS — If you want to collaborate on the show, or you know someone I should talk to, shoot me an email at caden@hey.com with "January752" in the subject line so it gets past my filters. I'm not optimizing for famous guests. I'm optimizing for interesting conversations, even from people who aren't LinkedIn influencers.

“No one could ever take this over,” Jake says. “If he left or somebody else had to manage it, no one knows what’s going on here.”

Jake Stauch tells me a story about a CFO and an expense report, and it changes the way I think about no-code tools.

The CFO had a simple request for his IT team: when someone submits an expense report, get approval from an M5 manager or above, go up the chain, but if you reach the CEO you have gone too far -- drop down to the closest manager for review. One sentence. Clean logic. Makes perfect sense.

Then the IT leader pulled up Okta workflows to show Jake what he had built. “He has to scroll and scroll and scroll,” Jake tells me, “because there are hundreds of nodes and connectors and if-this-then-that and error handling.” Two months of work for a one-sentence business rule. The IT leader was proud of it. He should have been. It was technically impressive. But Jake saw something else entirely.

This is the dirty secret of every no-code workflow builder. They are supposed to make automation accessible to non-technical people, but the moment the logic gets even slightly complex, you end up with a sprawling visual spaghetti that is too technical for the business users who wanted a simple solution and too constrained for the engineers who could have written the code in a fraction of the time.

“It’s too technical for non-technical users,” Jake says. “It’s not technical enough for the folks that really want to get in the weeds.”

The worst of both worlds. I feel this in my bones. I spent two grand hiring someone to teach me how to wire together Airtable and Zapier for podcast production. The planning phase was the hardest part. You have to know what the tools can do before you can design the automation, and once you build it you are managing 20 interconnected flow charts that will break in ways nobody can debug.

I ask Jake what Serval does differently, and his answer is architectural, not cosmetic.

“Everyone who’s ever approached automation has started with this idea of a drag-and-drop workflow builder,” he says. “Every generation of these systems has basically said, okay, we’re gonna build a better workflow builder. They make the UI better, they make it easier to configure, but they fundamentally don’t change the structure.”

Serval changed the structure. Their insight: if AI can write code from a natural language description, then the code is the source of truth, not the blocks. And if the code is the source of truth, the visual layer -- the flowchart the user sees -- does not need to map one-to-one to the underlying logic.

“The block is not real,” Jake says. “It’s just a visual representation of what the code’s doing.”

I stop him. This is the line I keep coming back to. Every no-code tool in history has assumed that the visual representation is the logic. The blocks are not just a display layer -- they are the actual mechanism. Move a block, and you change the code. Add a connector, and you create a dependency. The visual and the logical are fused. That fusion is what creates the spaghetti.

Serval severed it. The AI writes concise, efficient code that handles all the branching, looping, null checks, and error handling that would stretch into hundreds of visual nodes in a legacy tool. Then Serval generates a clean visual summary that makes the workflow easy to follow -- but the visualization is an abstraction, not the system itself.

This is the equivalent of what happened with iOS design. I bring up the Jony Ive story -- how early iOS used skeuomorphic metaphors like green felt and Rolodexes to teach people what a touchscreen could do. Once users understood the paradigm, Ive stripped the metaphors away. The training wheels came off.

Jake’s customers went through the same transition. In the early days, they would see Serval’s interface and reach for what they knew. “You could see they almost missed the old way of doing it,” Jake says. “They’re like, well, what if I wanna click into that block and change the configurations?” And Jake had to say: there is no block. Just chat with the system. Tell it what you want changed.

“I think in the early days, that was an unfamiliar user action,” he tells me. But consumer AI moved the culture. Enterprise buyers go home and use ChatGPT. The expectation of a chat-based interaction went from unfamiliar to obvious in about a year.

The compression of build cycles is staggering. What used to take weeks or months now happens in a conversation. An IT team member describes an onboarding workflow. Serval writes the code. Generates a visual representation. The whole thing is live. If the business process changes -- and it will -- you just tell the system what to change. No scrolling through hundreds of nodes trying to find the right branch to modify.

I think about this in the context of Mike Tyson’s line: everyone has a plan until they get punched in the mouth. Every legacy automation is one business process change away from obsolescence. The two-month Okta workflow is already out of date by the time it ships because the CFO changed the approval threshold. With Serval, the CFO changes the requirement and someone on the IT team tells the system in plain language. Done.

Jake tells me that the really cool part is what happens next. The IT teams that start building with Serval become evangelists. HR wants in. Finance wants in. Legal wants in. IT transforms from ticket processors into what Jake calls an automation center of excellence.

“The block is not real” is not just a technical insight. It is a liberation. Twenty years of workflow tools built on the wrong assumption, and Jake Stauch had the nerve to throw it out.

About Jake Stauch

Jake Stauch is the Co-Founder and CEO of Serval, an AI-native platform that automates enterprise employee support through natural language-to-code workflow generation. Rising to prominence in the mid-2010s as a founder and product executive at the intersection of hardware and enterprise software, Stauch became known for identifying friction bottlenecks in IT automation and building infrastructure-first AI systems before the underlying technology fully matured. Serval, co-founded in April 2024 alongside CTO Alex McLeod, reached a billion-dollar valuation within 18 months of founding after raising $125 million across three rounds led by General Catalyst, Redpoint Ventures ($47M Series A), and Sequoia ($75M Series B).

Previously, as Director of Product at Verkada from 2019 to 2024, Stauch spent five years conducting customer discovery with enterprise IT departments across physical security hardware and software. There, he identified the automation paradox that would become Serval’s founding insight: despite a growing landscape of automation tools, most IT requests were still handled manually because the friction of building workflows exceeded the cost of doing the tasks by hand. His product work at Verkada spanned new product lines in physical security cameras, access control systems, and alarm hardware sold to Fortune 500 IT departments.

Earlier, Stauch founded NeuroPlus, a brain-sensing hardware and cognitive performance software company, which he led as CEO from 2012 to 2019. He was recognized on the Forbes 30 Under 30 list in 2017 for this work, which included a patent for an EEG-based neurofeedback system. He holds a degree from Duke University.

Radhika Dutt is the author of Radical Product Thinking, a product leadership movement and book that has been translated into multiple languages, including Chinese and Japanese. Rising to prominence in the 2010s and 2020s, she became known for codifying a vision-driven alternative to iteration-led product development used by teams across industries from fintech to government. She currently serves as Advisor on Product Thinking to the Monetary Authority of Singapore (MAS), where she helps steer digital transformation and user-centric product delivery at one of Asia’s most influential financial regulators.

Previously, as Author and Speaker at Radical Product Thinking starting in 2017, Dutt built a global practice around a five-part methodology spanning vision, strategy, prioritization, execution and measurement, and culture. Her work equips organizations to diagnose and cure “product diseases” such as feature bloat and metric-driven drift, enabling leaders to align teams around a clear, shared change they seek to bring about in the world. Through keynotes at conferences like Productized and client work with startups and large enterprises, she has trained thousands of product practitioners and executives on how to translate vision into a repeatable operating system for innovation.

Her career highlights include founding two companies that were successfully acquired, contributing to a total of five acquisitions across broadcast, media and entertainment, telecom, advertising technology, and robotics over more than 20 years in product. As an MIT-trained engineer with an S.B. and M.Eng. in Electrical Engineering and Computer Science from the Massachusetts Institute of Technology (1995–2000), she has applied product thinking to domains as varied as consumer apps, government services, and even wine, demonstrating the portability of her framework across sectors measured in billions of dollars of market value. She is widely regarded as an influential figure in the product management community for shifting organizations away from purely metric- and OKR-driven roadmaps toward what she calls “vision-driven transformation.”

Discover the root cause analysis methods and narrative-driven measurement that prevent feature factories while maintaining innovation velocity.

“It’s bullshit statements, right, that are slim on the details.”

Radhika Dutt doesn’t hedge when describing most product visions. Twenty-five years after founding her first startup at MIT with a vision to “revolutionize wireless,” she can admit what most product leaders won’t: she has no idea what that meant. The company had five co-founders, dorm room origins, and all the trappings of a Silicon Valley success story. What it didn’t have was clarity about the problem they were solving.

“I don’t even know what we meant by that,” she says, and something shifts in her tone. The polished product consultant gives way to someone examining an old wound. “But it was this idea of just being big, scaling. Now, you know, even today when you look at so many Silicon Valley startups, that’s sort of the mistake you often see, right?”

She calls these mistakes product diseases. Not problems or challenges—diseases. The language is deliberate. Diseases are things you catch without realizing it, things that spread through organizations, things that require diagnosis and systematic treatment rather than quick fixes.

The disease at that first startup was hero syndrome: the obsession with scale and growth without understanding what problem needs solving. But Radhika discovered something worse during her subsequent career across five acquisitions. Most product teams suffer from multiple diseases simultaneously, creating what she now recognizes as an epidemic of confused priorities and wasted effort.

“And I call them product diseases because it’s just so ubiquitous and we need to talk openly about these product diseases. ‘Cause you know, it’s just so easy to catch.”

The solution she developed—radical product thinking—starts with a fill-in-the-blanks approach to vision setting that forces teams to confront what they’re actually trying to accomplish. Not the aspirational version, not the pitch deck version, but the detailed, actionable version that can guide daily decisions.

“So today, when amateur wine drinkers want to find wines that they’re likely to like and to learn about wine along the way, they have to find attractive looking wine labels or find wines that are on sale. This is unacceptable because it leads to so many disappointments and it’s really hard to learn about wine in this way. We are bringing about a world where finding wines you like is as easy as finding movies you like on Netflix. We are bringing about this world through a recommendations algorithm that matches wines to your taste and an operational setup that delivers these wines to your door.”

She pauses after reciting this vision for her wine startup, which she founded in 2011 and sold in 2014. “Now this is a radical vision because I hadn’t told you anything about my startup, and yet hopefully when I shared this vision, you knew exactly what we were doing and why we were doing it.”

The contrast with “revolutionize wireless” is stark. One vision contains a specific customer segment, their current painful experience, why that experience is unacceptable, the desired future state, and the concrete mechanism for achieving it. The other contains marketing language that could apply to any telecommunications company.

But even teams that develop clear visions struggle with what Radhika calls the second product disease: hyperemia. The obsession with moving numbers up and to the right, regardless of whether those numbers drive long-term value.

“You know, the moment I say this, people are usually like, oh yeah, I get it. We have it. Hyperemia is this obsession with moving numbers up and to the right. Having all sorts of wonderful dashboards that all look green. But those are not even necessarily the right metrics. And sometimes they may even be the right metrics, but they drive you in the wrong direction.”

The dating app industry provides her favorite example of hyperemia in action. When Tinder launched swipe left/swipe right in 2013, user engagement metrics exploded. Every other dating app copied the mechanic because the numbers looked incredible. User engagement up, time on app up, all the key performance indicators trending toward success.

“So, you know, everyone was thrilled with these metrics, but what was happening if you looked at the longer term effect? The more they gamified intimacy, it was creating a toxic dating environment, the more it was dehumanizing interactions. And so what it created in the long term was user fatigue.”

The result: dating app backlash, mass user deletions, and in 2025, Bumble laying off 30% of its staff. The entire industry fell into a slump because short-term metric optimization destroyed the long-term value proposition. The numbers looked great right up until they didn’t.

“So my point is, hyperemia is one of these diseases where you can do fantastic and making numbers look great. And genuinely they may be the right numbers, but that’s not necessarily good for your product or good for your business in the long term.”

This is where most conversations about metrics and OKRs devolve into tactical debates about choosing better numbers or preventing gaming. Radhika thinks those discussions miss the fundamental issue: goals and targets create perverse incentives regardless of how carefully they’re designed.

“Even when someone doesn’t have malicious intent and they’re not trying to game metrics, the subconscious incentive you have is to show you’re a high performer and therefore focus on the numbers that look good, that show OKRs to be green, as opposed to focus on numbers that, you know, OKRs aren’t even measuring, but that are indicating a problem and that say, hey, there’s something off here.”

She illustrates with her experience at Avid, the company behind video editing software used for every Oscar-winning film in Hollywood. The numbers looked fantastic—sales targets consistently hit or exceeded. But underneath the green dashboards, a different story was unfolding.

“If you just looked under the hood, you would see a different scenario. The way we were hitting our sales targets was by moving further and further into the high end because our low end was being eroded by Apple and Adobe.”

The company was achieving its goals by retreating upmarket as competitors commoditized the lower tiers. The sales numbers stayed strong, but the strategic position was deteriorating. Instead of asking why the low end was being eroded or how Apple and Adobe’s business models differed, leadership focused on maintaining the metrics that made them look successful.

“The incentive is I wanna show that I’ve hit those goals and targets things are working. I wanna prove that our, that things are going well.”

This dynamic—prioritizing the appearance of success over understanding reality—is what legendary Intel CEO Andy Grove meant when he said leaders are the last to know. When you set goals and targets, everyone wants to tell you the good news. Bad news gets buried because it threatens the narrative of progress.

The alternative Radhika proposes isn’t better goal-setting. It’s puzzle-setting. Instead of declaring what numbers teams should hit, leaders should define what problems need solving and create frameworks for teams to investigate those problems systematically.

“So what I am working on in this next book. And what I advocate for is a mindset shift instead of goals and targets. It’s a mindset of puzzle setting and puzzle solving. And then the way you measure people is how well are they solving this puzzle? Are we making progress towards solving this puzzle?”

Her framework for puzzle-setting uses three O’s: Observation, Open Questions, and Objective. The observation captures what’s actually happening, not just what the metrics show. The open questions identify what the team doesn’t understand about the observation. The objective summarizes the puzzle that needs solving.

For Avid, the observation would have been: “Our low end is getting eroded by Apple and Adobe in the mid-tier. This is what’s happening. The market is getting eroded. The way we’re making the numbers is by going further into the high end.”

The open questions would probe deeper: “What is happening on the low end? Adobe and Apple are successful there. What is their business model? Can we fight this business model in a different way? Is there something we can offer that can be a complete workflow for the low end where even if Apple and Adobe are giving away the editor, people will want it and want to pay for it?”

The objective becomes: “Figure out what do we do in our video editing business. Do we invest in it, do we not, or how do we invest in it, so that we can continue to either be successful in the video editing business, or we choose to move on and adapt our business?”

This is puzzle-setting. It creates space for teams to investigate reality rather than optimize metrics. But puzzle-setting only works if teams have the skills and safety to solve puzzles effectively.

That’s where puzzle-solving comes in: three questions that teams answer as they work on the puzzle. How well did it work? What did we learn? What will we try next?

“Notice how this question, it’s not binary, did you or didn’t you hit this target? It’s not just putting you on the spot, making you feel like I have to prove something. It’s genuinely inviting the good and the bad. This is how as a leader, you’re not the last to know you’re inviting the good and the bad.”

The second question—what did we learn—requires narrative synthesis, not just dashboard reporting. Teams have to look at all their data and tell the story of what’s really happening with users, markets, and competitors.

The third question—what will we try next—forces strategic thinking based on actual learning rather than predetermined roadmaps.

“I can really tell based on working with a team who is thinking deeply and how well they’re solving the puzzle based on their answers to what have we learned and what will we try next? That’s how you can evaluate people, not just based on ta-da, I’ve hit my numbers.”

The transformation this creates in team dynamics is profound. Instead of competing to show green dashboards, team members compete to solve interesting problems. Instead of hiding bad news, they compete to surface the most important insights. Instead of gaming metrics, they compete to design better experiments.

But this approach requires a level of psychological safety that’s rare in most organizations. Teams have to be willing to admit what’s not working, leaders have to be willing to hear it, and everyone has to be willing to change direction based on what they learn.

“Did you know that he didn’t keep a corner office? He used to have a cubicle, same size cubicle as everyone else because he wanted everyone to challenge his ideas and to feel like they could speak up. Very few leaders want people to speak up and tell them this is not working.”

The Andy Grove reference isn’t accidental. Grove understood that organizational hierarchy creates information distortion. The further you are from the work, the more filtered your information becomes. Physical proximity—sharing the same kind of workspace as everyone else—was one way to counteract that distortion.

Most leaders won’t give up their corner offices. But they can start role-modeling the kind of reflection and transparency they want from their teams. Taking time in meetings to discuss what didn’t work in past initiatives. Sharing their own learning and uncertainty. Creating space for teams to investigate puzzles rather than just hit targets.

“You can role model for your team, the psychological safety and sharing the good and the bad of what didn’t work, what you learned from it, what you’re going to try next. You can role model this so that you can invite the team to solve puzzles like you are.”

For individual contributors stuck in goal-driven organizations, Radhika recommends starting small. Take a past feature release and work through the three puzzle-solving questions privately. Look at the data, but focus on the narrative: what really happened with users? What did the numbers mean in context? What would you try differently next time?

Once you’ve practiced this approach yourself, try it in one-on-ones with your manager or conversations with peers. Create small bubbles of psychological safety where honest reflection and learning can happen.

“Instead of just chasing OKRs, you’re working on puzzles. Puzzles are so much more fun. We are all energized by puzzles. Instead of just focusing on OKRs, think about what puzzles you’re solving for the company. That in itself will energize you for your work.”

The energy difference is real. Goals feel imposed—something you have to hit to prove your worth. Puzzles feel intrinsic—something you want to solve because the solution creates value. The shift from external validation to internal motivation changes how people approach their work.

But the business results matter too. Radhika’s recent consulting engagement provides a concrete example. A company stuck with stalled sales in 2023 doubled sales in 2024, then doubled again in 2025 after switching from goal-setting to puzzle-solving. Customer churn dropped from 26% to 4%.

“We did all of that by puzzle setting and puzzle solving instead of being driven by OKRs.”

The transformation didn’t happen overnight. It required leaders willing to let go of familiar frameworks, teams willing to embrace uncertainty, and everyone willing to prioritize learning over looking good.

The alternative—continuing with product diseases like hero syndrome and hyperemia—leads to the dating app outcome. Short-term metrics that mask long-term erosion. Features that optimize for engagement instead of value. Teams that hit their numbers while slowly destroying what they’re trying to build.

“Or are we all doomed to just constantly learning from these failures, making mistakes and having to learn the hard way?”

That was the question that drove Radhika to develop radical product thinking in the first place. After watching team after team catch the same diseases, make the same mistakes, and suffer the same consequences, she wanted to understand whether systematic approaches could prevent predictable problems.

The answer is yes, but only if teams are willing to diagnose their diseases honestly and treat them systematically. Most organizations prefer to treat symptoms—choosing better metrics, writing clearer requirements, running more experiments—rather than address root causes.

The root cause is the gap between great ideas and great products. Steve Jobs called it out in his lost interview: most people think the idea is 90% of the work when it’s actually 5%. The other 95% is the systematic translation of vision into strategy, strategy into priorities, and priorities into daily activities.

“And I think filling that gap is exactly what I talk about in terms of systematically translating a vision for change into action, into everyday activities. And that’s how we close that gap.”

Product diseases spread when teams try to shortcut that translation process. Hero syndrome emerges when teams skip from big vision to scaling without defining the problem. Hyperemia emerges when teams skip from activities to metrics without understanding the connection to long-term value.

The systematic approach isn’t glamorous. It requires detailed problem statements, clear frameworks, consistent reflection, and honest measurement. It requires admitting when things aren’t working and changing direction based on learning rather than predetermined plans.

But it’s the difference between revolutionary wireless and amateur wine drinkers who can’t find wines they like. One vision launches a company that doesn’t know what it’s doing. The other launches a company that gets acquired because it solves a real problem in a specific way.

“Now this is a radical vision because I hadn’t told you anything about my startup, and yet hopefully when I shared this vision, you knew exactly what we were doing and why we were doing it.”

That clarity—knowing exactly what you’re doing and why—is what prevents product diseases from taking hold. It’s what enables teams to choose long-term value over short-term metrics. It’s what transforms abstract strategies into concrete progress.

The vision template is just the beginning. The systematic framework for translating vision into action is what makes the vision matter. And the puzzle-solving approach is what keeps teams connected to reality as they execute against the vision.

Twenty-five years after revolutionizing wireless, Radhika has learned to revolutionize something more specific: how product teams think about the problems they’re trying to solve. Not with better tools or processes, but with better questions and frameworks for finding answers.

The questions aren’t complicated. What problem are we solving? Why does it need to be solved? How will we solve it? How well is our solution working? What are we learning? What will we try next?

The complexity comes from creating organizational conditions where teams can ask those questions honestly and act on the answers systematically. Where puzzle-solving is rewarded over performance theater. Where learning from failure is valued more than hitting arbitrary targets.

“Puzzles are so much more fun. We are all energized by puzzles.”

That energy—the intrinsic motivation to solve interesting problems—might be the strongest antidote to product diseases. When teams are genuinely curious about the puzzles they’re solving, they’re less likely to settle for bullshit statements that are slim on details. They’re more likely to demand the clarity that prevents revolutionary wireless from becoming just another failed startup story.

Subscribe to the wayofproduct.com for more in
depth guest profiles that are worth the time to read.

Subscribe now

Saurabh Sharma is the Chief Product Officer at You.com, where he leads product, design, and research for AI agents that power critical business workflows across search and enterprise use cases. Rising to prominence in the 2010s through work at Google, he became known for scaling applied AI, search and discovery, and trust and safety systems to hundreds of millions of users globally. He is widely regarded as an influential figure at the intersection of AI assistants, consumer products, and infrastructure for large-scale machine learning.

Previously, as Head of Search Products at OpenSea, Saurabh led a multi-product portfolio spanning search, discovery, trust and safety, and core web and mobile platforms during the 2022–2023 NFT market cycle. He became known for steering product strategy in a period when OpenSea supported millions of users and billions of dollars in NFT trading volume annually, focusing on safe discovery and high-intent search in a volatile, web3-native marketplace. His leadership aligned search quality, fraud prevention, and creator-centric experiences in an ecosystem that operated 24/7 across global markets.

His career highlights include an 11-year tenure as a Group Product Manager at Google, where he led teams of more than 12 product managers and 100 engineers building AI-powered experiences in Google Assistant, Search, Maps integrations, identity, and monetization from 2011 to 2022. At Google, he helped ship and scale products such as Google Assistant’s AI search integrations, Family Link and Google Accounts for kids, Google+, and Gmail, each serving hundreds of millions of monthly active users and operating across more than 100 countries. Earlier, as an Advisory Software Engineer at IBM from 2005 to 2010, he developed core AIX UNIX kernel infrastructure for virtual memory, including Active Memory Expansion and Large Segment Aliasing, contributing to enterprise systems that powered thousands of high-availability servers worldwide. He pairs this low-level systems background with an applied AI product lens shaped by dual BS and MS degrees in Electrical and Computer Engineering from Carnegie Mellon University.

In addition to his operating roles, Saurabh has invested in and supported early-stage voice and AI startups through Google Assistant’s strategic investment programs, including seed and Series A bets in companies such as Instreamatic, Voiceflow, and Slang Labs. As a member of the Skip Community, he collaborates with a network of current and former heads of product who collectively bring hundreds of years of leadership experience across AI, fintech, cybersecurity, e-commerce, and renewable energy, shaping best practices for how modern product organizations are structured and scaled.

Learn how a CPO at a billion-dollar AI company is rethinking what “good” looks like for PMs — prioritizing strategic thinking over feature-building as software commoditizes.

“You gotta be laser sharp about where you can really add value versus what’s being rapidly commoditized.”

Saurabh Sharma, CPO at You.com, doesn’t deliver this line as career advice. It’s operational reality. When AI can generate user research insights in minutes and prototype features faster than most teams can write specifications, the entire foundation of product management value shifts. The skills that made someone a great PM five years ago might make them unemployable five years from now.

“Where is there a compounding advantage? Where is there a value creation that will be hard to commoditize?” he continues, and I can see him working through the implications for his own hiring decisions. “And that’s a lot of what I think about at the company. That’s a lot of what I try to help my team think about as well.”

This isn’t abstract strategy. It’s survival math. You.com processes over a billion web search API queries per month for companies including DuckDuckGo, Windsurf, and Harvey. They raised $100 million at a $1.5 billion valuation. At that scale, every hiring decision carries weight. Every capability they build internally has to justify itself against what they could buy or automate.

The question Saurabh faces daily: when AI can handle most IC work, what human skills become more valuable rather than less?

“I think what’s really changed is you gotta be laser sharp about where you can really add value versus what’s being rapidly commoditized,” he explains. “And so I think what we’ve seen at You.com is that there’s a continuous focus on where is the value really being created versus where will the value be rapidly commoditized.”

The math is brutal but clarifying. If anyone can build a basic SaaS product with AI assistance, then building basic SaaS products isn’t a differentiating capability. If anyone can synthesize user research or analyze competitor data with AI tools, then those skills command lower wages and less organizational influence.

But here’s what Saurabh has observed: some capabilities become more valuable as their supporting infrastructure gets commoditized. Strategic judgment becomes more important when you can test more strategies. Pattern recognition becomes more critical when you have more data to parse. The ability to choose which problems are worth solving becomes essential when solving problems gets easier.

“And I think it does change how you hire, in that you want people that are able to think that strategic line more so than, well, here’s this cool feature I wanna build.”

The hiring implications ripple through every product organization. The PM who excels at writing detailed PRDs and coordinating feature launches might struggle in an environment where PRD writing is automated and feature quality is determined by rapid iteration rather than upfront specification.

But the PM who can identify which customer problems create sustainable advantage, who can spot market opportunities before competitors, who can build conviction around directions that don’t yet have validation—those skills compound as the tactical work gets easier.

“Well, the cool feature—the customer might be able to replicate it themselves in a way that’s even more fit for them,” Saurabh continues. “It’s more about where is there a compounding advantage? Where is there a value creation that will be hard to commoditize?”

I push him on this. How do you interview for strategic thinking? How do you distinguish between someone who talks strategically and someone who thinks strategically? Most product candidates can articulate frameworks and principles. Fewer can demonstrate judgment under uncertainty.

“I think that taking that more strategic approach, what separates a middle manager from an executive,” he responds, drawing a connection I didn’t expect. “Nobody told me that I should spend more time with the sales team. But what I noted was, first of all, sales likes having product on road trips with them. It helps customer conversations. But the other part of it was it helps me. It helps me build my worldview. What my roadmap should be.”

The example crystallizes the difference. Strategic thinking isn’t about having better frameworks or more elegant presentations. It’s about making connections that aren’t obvious, taking actions that aren’t prescribed, developing conviction through firsthand exploration rather than secondhand analysis.

When Saurabh decided to spend more time on sales calls, he wasn’t following a playbook. He was following a hunch about where his learning edge was. That hunch—and the willingness to act on it—represents the kind of judgment that becomes more valuable as tactical execution gets automated.

But this creates new tensions in how product teams operate. When strategic judgment becomes the scarce resource, how do you structure teams to maximize it? How do you delegate the increasing scope of work that AI can handle without losing touch with the details that inform strategy?

“None of us are gonna be ICs anymore,” Saurabh says, quoting You.com CEO Richard Socher. “We are all gonna be managers in the future. Some of us will continue to manage people, but your traditional IC will now be managing a fleet of agents that’s doing a lot of work for them.”

The transition from IC to manager isn’t just about career advancement. It’s about cognitive load distribution. When AI can handle research, analysis, and initial synthesis, human intelligence gets freed up for higher-order work: choosing which questions to ask, interpreting ambiguous signals, making bets on uncertain outcomes.

But managing AI agents requires different skills than managing humans. Humans can fill in context, interpret vague instructions, escalate when they’re confused. AI agents do exactly what you ask them to do, which means the quality of your instructions determines the quality of their output.

“Many of the emails I write, I will pass through AI to help me with tone or help me think about the way I want to get to a particular objective in a given customer situation,” he explains, describing his own evolution. “That is essentially an example of offloading something that we all know how to do. I could write that perfect email to a customer to diffuse a complex situation, but it might take me an hour to really think through it and get it right. What I found is that email is now five minutes away working with AI.”

The email example is tactical, but the implications are strategic. When routine communication becomes effortless, you can maintain relationships at scale that were previously impossible. When difficult conversations can be crafted quickly, you can engage in more of them. The scope of what one person can manage expands dramatically.

This expansion creates competitive advantage for individuals and organizations that adapt quickly. But it also creates new forms of inequality. People who learn to manage AI agents effectively can take on exponentially more responsibility. People who don’t learn these skills find their scope of influence shrinking as AI-augmented colleagues outpace them.

“Some people will use the time that they get back with AI to just do more of what they already know, and that’s gonna be fine,” Saurabh observes. “But you’re gonna have other people that are able to—I sometimes think about Maslow’s hierarchy. Some people that are able to, okay, great, I got shelter and food under control. Now I can go to self-actualization.”

The Maslow reference isn’t casual. It’s how he thinks about organizational development in an AI-augmented world. Some people will use AI to get better at their current job. Others will use AI to access entirely different kinds of work. The first group maintains their position. The second group expands their influence.

But this creates new challenges for team composition. How do you balance strategic thinkers who can direct AI agents effectively with craftspeople who can execute at high quality? How do you maintain institutional knowledge when so much tactical work gets delegated to machines?

“There are exceptional middle managers that that’s what they love to do. That’s what they’re good at, and that is great,” Saurabh says when I ask about the career implications. “And then there are exceptional middle managers that graduate naturally to be exceptional executives. And that is good as well.”

The key insight: both paths remain valuable, but the skills required for each path are changing. Middle managers will increasingly manage hybrid teams of humans and AI agents. They’ll need to be excellent at coordination, quality control, and tactical execution within defined boundaries. Executives will set those boundaries, choose which problems deserve attention, and build conviction around uncertain directions.

But the boundary between these roles is becoming more porous. When AI handles routine analysis, middle managers can engage in more strategic work. When strategic insights can be tested rapidly, executives can stay closer to tactical details. The rigid hierarchies built around information scarcity start to flatten when information becomes abundant.

“Where is that compounding advantage that creates value for the customer and also creates potentially a competitive moat for us as well,” Saurabh concludes, returning to the core question.

The answer, increasingly, isn’t in what you can build. It’s in what you choose to build and why. The technical capability to create software is becoming commoditized. The judgment to create the right software at the right time for the right customers remains scarce.

Companies that hire for execution speed will compete on efficiency. Companies that hire for strategic judgment will compete on alpha. Both approaches can succeed, but they require different organizational designs and different definitions of performance.

The retailers who miss the next pickleball trend won’t be the ones with outdated technology stacks. They’ll be the ones who couldn’t distinguish between signals worth pursuing and noise worth ignoring. Who couldn’t move fast enough from insight to action. Who optimized for doing more of the same instead of doing something different.

“I think what we’ve seen at You.com is that there’s a continuous focus on where is the value really being created versus where will the value be rapidly commoditized.”

As AI makes more capabilities available to everyone, the companies that thrive will be the ones that focus obsessively on the capabilities that can’t be commoditized. Not because they’re technically difficult, but because they require the kind of human judgment that compounds over time rather than getting automated away.

The question for every product organization: are you hiring people who can do the work, or people who can choose the work? The first skill set has a shrinking shelf life. The second becomes more valuable every sprint.

Anya Cheng is the Founder and CEO of Taelor, an AI-powered menswear rental and styling platform at the intersection of fashion, data, and artificial intelligence. Rising to prominence in the 2010s after leading product teams at Meta, eBay, Target, and McDonald’s, she became known for scaling digital products that touched hundreds of millions of users while bridging consumer behavior, growth, and personalization. Today she is widely regarded as an influential figure in fashion tech and serves as faculty at Northwestern University, translating operating experience into curriculum on integrated marketing and product strategy.

Previously, as a senior product leader at Meta, eBay, Target, and McDonald’s, she owned global initiatives that drove measurable business outcomes across eCommerce, food delivery, and retail. At McDonald’s she helped lead the global rollout of mobile ordering to thousands of stores, transforming how customers interacted with a brand serving more than 60 million people per day. At Taelor, her team has raised approximately $2.3 million in pre-seed funding, achieved over 10 million marketing impressions with zero ad budget, and earned recognition such as Inc.’s 2025 Best in Business – Best Startup category and Webby Award honors.

Her career highlights include award‑winning marketing campaigns at Sears and Kmart, scaling cross‑border digital commerce at eBay, and driving omnichannel experiences at Target that combined stores, mobile, and online into a unified customer journey. As founder of Taelor, she has built an AI-driven styling engine that mixes acquired competitor data, human stylists, and feedback loops from thousands of garment rentals to improve recommendations and reduce fashion waste. Along the way she has been named to Girls in Tech’s “40 Under 40,” delivered a TEDx talk on perseverance, and built a following of more than 28,000 professionals who track her work across AI, circular fashion, and consumer technology.

As a book author, startup advisor, and frequent podcast guest, Cheng documents the path from Taiwan to Silicon Valley and distills lessons on resilience, go‑to‑market execution, and human‑centered AI. As a teacher at Northwestern University and a sought‑after speaker at industry events like NRF and SF Tech Week, she helps the next generation of founders and operators understand how to turn data, storytelling, and product intuition into enduring companies.

The framework Meta uses in PM interviews to separate great product thinkers from idea generators.

“Nobody used the feature besides a product manager,” Anya Cheng tells me. “Why?”

She’s describing a project from her time at Target. The team wanted to build store GPS—beacon-powered navigation so customers would never forget an item on their list. They spent six months and millions of dollars mapping every item location in stores with different layouts and footprints. They geo-fenced the shelves. They built the feature. They launched it.

“Come on,” she says. “Mom is going to a Target store to get lost. They want to go to a store wandering around and buy stuff.”

The Target moms didn’t need efficiency. They needed escape. The Starbucks inside is the feature. The cup holders on the cart are the feature. The permission to wander for an hour away from noisy kids is the feature. The team had solved the wrong problem perfectly.

Anya Cheng is the founder and CEO of Taelor, an AI-powered menswear rental subscription. Before founding Taelor she was Head of Product at Meta for Facebook and Instagram Shopping, Head of Product at eBay for Latin America and Africa, led mobile and tablet e-commerce at Target, and was Senior Director at McDonald’s launching their global food delivery apps. She teaches product management at Northwestern and has won 20-plus industry awards. The Target GPS story is one she uses to teach the most important lesson she knows: the quality of your execution is irrelevant if you’re solving the wrong problem.

“If you are taking away the value prop,” she says, “then your product is just not going to be popular.”

Target’s value proposition isn’t convenience. It’s discovery. It’s the opposite of a GPS. The beacon team understood the technology. They understood the implementation challenge. They just didn’t understand why moms go to Target.

I ask Anya how she avoids the same trap. How she decides what to build and—more importantly—what not to build. Her answer is a framework she’s used at Meta, eBay, McDonald’s, and now Taelor.

It starts with the Facebook PM interview question: if you’re the product manager of X, what feature would you launch? She’s been on both sides of this question hundreds of times. The candidates who fail are the ones who answer it.

“Two types of person,” she says. “One type will be out of the interview loop right away. The other will at least get to the second level.”

The first type jumps to solutions. I’d build this, I’d build that. Ideas are cheap. ChatGPT can come up with ideas. That’s not the job.

The second type starts with personas. She gives me the birthday product example. Three personas: the birthday person who wants to be surprised, the close friends who want to organize and are afraid of forgetting, and the acquaintances who just want to say happy birthday. Each has distinct pain points. Each pain point sits on a spectrum of severity, frequency, and relevance to Facebook’s unique position.

“Then you come up with selecting criteria,” Anya says. “Which pain point is more painful? Which pain point has more people with that pain point? Which pain point is Facebook more relevant to solving versus other people?”

The criteria filter the problem space before you ever touch solutions. Then when you do generate solutions, you filter again: which solution solves the problem best, which takes fewer engineering hours, which fits the direction of the business?

“Up to here,” she says, “I haven’t told you anything about the solution.”

She brings up the same framework when she tells me about Google Shopping versus Facebook Shopping. Same goal: sell things online. Completely different products. Google’s mission is organizing the world’s information, so Google Shopping became price comparison. Meta’s mission is bringing the world closer together, so Facebook Shopping became community commerce—friends selling bicycles from their backyard, influencers sharing product recommendations.

“Exactly the same goal,” she says. “But totally different product because it’s different mission of the company.”

The mission is the highest-level selection criterion. It determines which problems are yours to solve and which aren’t. The Target beacon team forgot this. They selected a problem—moms forgetting items—that was real but irrelevant to why people went to Target in the first place.

Anya’s own origin story follows the framework precisely. At Meta, she was dealing with imposter syndrome—a Taiwanese immigrant surrounded by Ivy League engineers. She needed to look good. She tried Stitch Fix (had to buy everything), Rent the Runway (had to browse 100,000 garments). She realized fashion companies designed for fashion lovers, not for people who wanted to get ready and get on with their day.

So she did product 101. Interviewed people. Found that her real persona wasn’t women like her—it was busy men. Sales guys, consultants, pastors, executives. People who didn’t care about fashion but cared deeply about the outcomes fashion enabled: getting a job, closing a deal, landing a date.

The MVP was a Shopify landing page with a stock photo of blue shorts. A realtor from San Diego put his email in, waited two months, found Anya on LinkedIn, and called her. They bought clothes from Macy’s during a Christmas sale and shipped from the post office.

“Became our first customer,” she says. “The MVP still worked.”

It worked because the hypothesis was right. The problem was real. The selection criteria—not the solution—validated the business. Everything that followed—the 150 brand partnerships, the AI-augmented styling, the circular fashion model—was built on the foundation of understanding what the customer actually needed.

She tells me about another failed product: eBay’s AI-powered listing tool. Snap a photo of a bicycle, AI writes the description. Built it. Shipped it. Nobody used it. Small sellers on eBay have sentimental attachment to their items. They want to write their own descriptions. Efficiency wasn’t the pain point. Pride was.

“If you don’t deeply understand the customer persona, the insider psychology, the job to be done,” she says, “it’s just very hard to build a great product.”

I bring up vibe coding—the trend of PMs building functional prototypes with AI tools on weekends. Her intern did exactly this: came back with three working features built in a weekend. Her response was blunt.

“This is how exactly at Meta we don’t hire people.”

The features might have been good. But they were selected by enthusiasm, not criteria. The intern skipped the framework—the personas, the pain points, the filtering—and went straight to building. AI made it possible to skip the hard work. And skipping the hard work is exactly the failure mode that produces Target store GPS.

“In the old time,” Anya says, “you have three ideas and you have to go convince your engineer and designer. And they will challenge your logic. But now you can skip all of this.”

The challenge was the quality filter. Removing it doesn’t make you faster. It makes you wrong more efficiently.

I ask Anya what she wants product leaders to take away from all of this. She doesn’t hesitate.

“We are all problem solvers,” she says. “Go to the meeting. Forget that you are a designer, forget that you are PM, and really focus on thinking about what problem can be solved.”

The solutions will come. They always do. The hard part—the part that separates a Target beacon from a Taelor, a failed eBay listing tool from a 10-million-impression marketing flywheel—is choosing the right problem in the first place. Not the coolest one. Not the most technically interesting one. The one that actually matters to the person on the other end.

Selection criteria over ideas. Every time.

Maxine Anderson is the Co-founder and Chief Product Officer at Arist, where she helps build what is widely regarded as an emerging default enablement system for large enterprises. Rising to prominence in the early 2020s, she became known for transforming text-message learning experiments into an agentic enablement platform that operates directly inside Slack, Microsoft Teams, and SMS. Under her product leadership, Arist has evolved from simple SMS-based courses to an AI-driven “enablement team in your pocket” that automates needs analysis, content creation, and delivery for distributed workforces at scale.

Previously, as Co-founder and Chief Product Officer at Arist, Anderson helped expand the company’s initial seed funding to $3.9 million in 2021 and later raise a $12 million Series A round to fuel rapid enterprise adoption. Her work turned an early Y Combinator-backed idea into a venture serving over 20 Fortune 500 organizations, with pricing starting around $1,000 per month for enterprise deployments. She became known for shipping AI-powered tools such as Creator and the Enablement Agent, which process thousands of complex documents, translate into 100+ languages, and generate ready-to-deliver programs in under eight minutes while proving impact through end-to-end analytics.

Her career highlights include co-founding Project W, a student-led organization launched in 2021 to foster interdisciplinary collaboration among women innovators and entrepreneurs across the Babson, Olin, and Wellesley (BOW) colleges, which built an online community of more than 300 members and incubated Project Pods for high-level ventures. As a founding member of College Ventures Network and VP of Marketing at eTower, Babson’s premier entrepreneurial living community whose alumni companies have generated more than $3 billion in combined valuations and over $50 million in funding, she honed a model for building tight-knit entrepreneurial ecosystems. Graduating magna cum laude from Babson College in 2022 with a focus on entrepreneurship, she combined academic honors with hands-on leadership roles that emphasized measurable impact and community scale.

Outside of her primary operating role, Anderson serves as a Board Member at Delphian School, bringing startup execution and product thinking back into the education system where she was once Student Council President and a three-time state champion cheerleading captain. Through ongoing advisory work and public writing on enablement, AI agents, and performance diagnostics, she has become an influential figure for operators building the next generation of enterprise learning and HR technology.

How Arist navigated seven years of positioning iteration in an undefined category and why shared conviction about the game you’re playing gives product the agency to say no.

“We are a new category without ever having created or yet created a category, which is hard to sell,” Maxine Anderson says. There’s no frustration in it. Just the accumulated weight of seven years spent explaining something that doesn’t have a name.

Maxine is the co-founder and CPO of Arist, a platform that delivers employee training through Microsoft Teams, SMS, and WhatsApp instead of video-based learning management systems. She started the company at Babson College with two co-founders after they each independently discovered that text-based communication drove behavior change in ways traditional mediums couldn’t.

The student in Yemen who could only learn via text. The public speaking coach who sent WhatsApp reminders before talks. Maxine’s own financial literacy programs on Native American reservations where classroom formats failed completely. The insight was simple. The seven years that followed were not.

I ask her about positioning, and the answer is a catalog of pivots. They started as a consumer marketplace—Masterclass over text, basically. Learn from professors at Harvard via your phone. “That model was just really hard to distribute,” she says. “Marketplaces are just really difficult, to be honest. Not really good for a medium that people didn’t already believe in.”

A former chief learning officer told them about the billions spent on corporate training that drove zero results. They pivoted to corporate learning. Spent two years selling to HR. Got traction—then the market shifted. Enterprise budgets contracted in 2021 and 2022, and HR was the first department cut.

“It was kind of a forcing function for us to find a better buyer,” Maxine says.

They started selling to operational leaders. Sales directors. Frontline manufacturing managers. People whose bonuses depended on whether their teams improved. The product hadn’t changed much. The positioning had changed completely.

I tell Maxine this is the part of product strategy that I think most product leaders miss. It isn’t about filling up a backlog and deciding which features will close deals. It’s figuring out what game you’re playing. There’s a great piece—I think it’s an a16z blog—about how the market is the most important thing. You can change your positioning and your target segment and sales go up. You don’t have to add more features.

“Yeah,” she says. “We’ve had to iterate on our positioning a lot.”

She describes what it’s like to sell without a category. Not just positioning on a macro level—telling the market a new way of thinking about employee enablement—but positioning per account. Every conversation is a custom pitch. Every buyer needs to understand something that doesn’t map to any existing line item in their budget.

“For a while it was hard to lead product,” she admits. “We’re selling all these different use cases yet we don’t want to productize those pathways. We’re not a sales enablement tool. We’re not trying to compete with HighSpot directly. We’re really good for this part of sales enablement, this problem that’s not solved.”

I bring up Figma as a parallel. How long it took for Figma to convince designers to switch from their existing tools. How category change requires not just a better product but a change in default behavior.

“It did take a long time for Figma to get traction,” she agrees. “They had to change people from their default behavior of going to other tools as a solution.”

The conversation moves to roadmap, and Maxine lights up. “There’s this quote that I love,” she says. “Plans are useless, but planning is useful. And I feel like that’s really true in a startup.”

She describes the trap she sees product managers fall into: optimizing for delivery. Presenting a roadmap, hitting dates, feeling the satisfaction of shipping what you said you’d ship. She says the feeling of executing on a plan is seductive—and often wrong.

“A roadmap often becomes a ton of things people ask for instead of what you’re trying to build towards over time,” she says. “Some of our best features have been where it doesn’t feel good. We shipped this a little too early, or we shipped this to see if we could market it. Or we marketed this five months early and built it in a funny way.”

This is the part where most product conversations would veer into framework territory. Maxine stays concrete. She describes how she segments her roadmap into three buckets: what they’re working towards building, what they’re trying to build to convince people, and what they’re building because it’s literally blocking adoption at scale.

“Those are the customer requests I take,” she says. “Literally, we would have five times volume if we shipped this feature. Not—oh, I would really love it if you could add this to a course.”

She confesses they fell into the feature parity trap early. Customers would compare Arist to existing LMS products. The team spent six months adding features that mapped to what learning management systems already had—instead of building the fundamentally different thing they were supposed to be building.

“What we’re building is fundamentally so different,” she says. “I have the agency in meetings with executives to say—that’s actually not our perspective. This is what we’re trying to build. This is what enablement should look like in five years, trust us. And it makes them back off a little bit.”

That agency comes from conviction. Not confidence—conviction. Knowing what game you’re playing well enough to explain why certain features will never be built. Maxine tells me she spent significant time enabling the entire company on Arist’s vision. Not just the product team. Everyone. So that when a salesperson gets a feature request in the field, they can explain why Arist won’t build a one-on-one coaching product, and here’s why, and they will never build that, and here’s why.

“Them being able to say those things is super valuable,” she says. “Because then you don’t get all these incoming requests of product to manage.”

I ask whether finding the right buyer helped with breathing room for product.

“Market is everything for product,” she says. Four words. No hedging.

Finding the right buyer improved retention, simplified the roadmap, reduced internal pressure. It did what no process improvement or planning framework ever could: it gave product permission to build the right thing.

Her co-founder, she tells me, is the one who holds the macro stance. “It’s very easy in a business to just really want the wins and explain things in ways people understand,” she says. “It takes a lot of positioning iteration to stick to the macro.”

She mentions other companies in adjacent spaces that built text-message learning tools but positioned them as utilities for learning designers. They don’t see that learning designers won’t exist in their current form three years from now. They’re solving for today’s buyer in today’s category. Arist is building for a category that doesn’t exist yet.

“It does require someone who takes the right macro bets,” Maxine says. “Which you need someone who can do that well.”

I think about Linear’s five-year slide—year one is friends, year two is small startups, year five is enterprise. The CPO who defaults to no on dashboard requests because they’re counter-positioning against Atlassian. The clarity that comes not from better planning but from sharper conviction about who you’re building for.

Maxine and her co-founder have that clarity. It took seven years of positioning iteration, a near-shutdown, a global pandemic, and the courage to walk away from the HR buyer. But they have it. And the roadmap, as she predicted, is taking care of itself.

Richard Yu is the Chief Product Officer at LucidLink, where he leads product strategy for the company’s cloud-native file system used by distributed creative and enterprise teams worldwide. Rising to prominence in the 2010s as an enterprise SaaS product leader, he became known for building mission-critical platforms that turn complex workflows into scalable, repeatable systems. He is widely regarded for his focus on outcomes over output, pushing organizations to measure success by customer impact rather than feature volume.

Previously, as Chief Product Officer at Formstack, he oversaw a no-code workplace productivity platform adopted by over 35,000 organizations across healthcare, financial services, and education. Under his leadership from 2022 to 2024, the company expanded its automation footprint across forms, documents, and e-signature workflows, helping customers digitize key processes end to end. He became known for driving cross-functional execution between product, marketing, and go-to-market teams to accelerate subscription growth and retention.

His career highlights include serving as Senior Vice President of Product at Litmus, where he led a four-year stretch of category leadership that earned multiple G2 and TrustRadius awards for product adoption and customer satisfaction. Earlier, as Vice President of Product Management and Head of Product Management and User Experience at Marketo, he guided one of the world’s largest marketing automation platforms through a period when thousands of B2B organizations relied on it to orchestrate multi-channel campaigns. Across these roles, he has spent more than 25 years building teams, products, and businesses at the intersection of SaaS infrastructure, marketing technology, and data-driven customer engagement.

Learn how LucidLink’s “invisible product” design philosophy connects to Marty Cagan’s high-integrity commitments framework and why the best product strategies are testable assumptions, not finished artifacts.

“We have users who experience it for the first time and kind of call it magic,” Rich Yu tells me. “So it is a bit magical, but obviously there’s no magic in technology. It’s just technology.”

He says this with the calm of someone who’s heard the word magic a hundred times from customers and has learned to take it as engineering validation rather than compliment. Rich is the Chief Product Officer at LucidLink, and his product makes cloud-stored video files act as if they’re sitting on your local machine. You open your Finder, there’s a mount point, and the files are just there. Editors on The Bear scrub through footage with zero latency. No syncing. No downloading. No waiting.

The company just won a technical achievement Emmy for this. And Rich’s philosophy for what comes next is to make the whole thing vanish.

Richard Yu has spent 25 years in product and marketing leadership—Formstack, Litmus, Marketo—before landing at LucidLink, a cloud storage collaboration platform headquartered in San Francisco with an engineering office in Sofia, Bulgaria. The company powers post-production workflows for major streaming shows and found its product-market fit during COVID, when media teams went home and discovered that collaborating on large files remotely was, in Rich’s words, “just not tenable.”

LucidLink solved that with streaming technology that caches intelligently enough to make remote files behave locally. The result is a product whose ideal user experience is one you don’t notice.

I ask Rich what “it just works” actually looks like from the inside—because from a product design perspective, aspiring to be invisible is a strange thing. We spend our careers building interfaces, flows, and experiences that demand attention. Rich is trying to do the opposite.

“We’ve really aspired to become invisible almost in the user experience,” he says. “I know that sounds ironic because as creators and builders of products, we always talk about what’s the user experience and what’s the UI look like.” He holds the irony for a beat. “But ultimately, if we’re thinking about the core value proposition—making large files stored in the cloud act and behave as if they were local on your machine—that’s something that should just happen.”

I tell him about the declining weekly active users problem. A previous guest worked on translation software and discovered that as the product got smarter, people used the app less. For most teams, that graph is a crisis. For utility products, it’s proof of success.

“Exactly,” Rich says. He gets it immediately. For LucidLink, the dashboard exists so administrators can manage permissions and check billing. But the actual value—the streaming, the speed, the absence of friction—that lives underneath everything. The best interaction is the one where a user opens a file, does their work, and never once thinks about the infrastructure making it possible.

We drift into strategy, and Rich surfaces the question that shapes how he approaches product decisions: Are we building outcomes, or are we building outputs?

He’s careful to credit the framework to others—”folks have blazed the path before me”—but the way he deploys it reveals conviction earned through experience. Early-stage companies need outputs. You need to ship the MVP, get it into market, learn. That’s the job. But once you have adoption and momentum, the game changes.

“The value is what is typically called the outcomes,” he says. “Are users really using your product? Are they happy? Is there a community that’s excited and engaged? And then ultimately those outcomes are also company or business outcomes. Is the company growing and successful as a result of the customers being successful?”

This connects to something else Rich is thinking about: the danger of high-integrity commitments.

I bring up Marty Cagan’s framework—the idea that product teams should avoid locking into hard delivery dates unless the situation is truly existential. We’re going to lose this customer if we don’t ship. The business is under threat. Those are the only moments where committing to a specific scope by a specific date makes sense.

Rich admits he falls into the trap himself. “As a product leader, I have accountability to my peers, to my executives, to kind of say, okay, we are gonna ship X by Y date,” he says. “I mean, that’s sort of one of the key anti-patterns in a way—that we are trying to constantly hit very specific dates with projects and initiatives that are not deterministic in that way.”

He catches himself. “But I fall into that sort of trap myself because, let’s face it, in the business world, if we don’t have some forcing functions to get things done, work can fill up the space that it’s given.”

The nuance matters. Deadlines aren’t inherently destructive. The anti-pattern is when hitting the date becomes the only thing you’re striving toward. When shipping replaces thinking. When the forcing function forces shortcuts in discovery, in design, in engineering.

“It forces maybe shortcuts to be taken in the discovery and exploration and validation of that threat,” Rich says. “And then shortcuts taken in terms of the design and the actual engineering of the solution against the threat.”

I push further: when you do make a high-integrity commitment, you need a team that believes in it. Not just one that executes against it, but one that owns it.

“That’s where breaking down the silos across the three functions to creating this true triad ownership is critical,” Rich says. “The ownership in that high-integrity commitment is not engineering by themselves. It’s not design by themselves. It’s not product by themselves. It’s really all three.”

The conversation turns to strategy and Rich offers what might be the most honest thing a product leader has said to me in 165 episodes of this podcast.

“Any strategy, no matter how polished or how baked or how succinctly articulated—they’re just a set of assumptions and hypotheses,” he says. “Hopefully backed by sufficient data and research. But ultimately it’s a thesis. It’s a thesis until you’ve actually achieved the outcome that the strategy is trying to point towards.”

I’ve watched the anti-pattern play out in real time. A product leader presents a strategy. The team pushes back. Instead of engaging, the leader hedges: Well, it was more of a thesis. A work in progress. They were hedging to save face. But Rich is saying something different—he’s saying all strategy is thesis, and that’s not a weakness. It’s how the work actually gets done.

“I’ll go on a limb that even the smartest strategists out there, the most successful folks in technology, are probably always just running one or two steps ahead of reality,” he says. “And they’re trying to really figure things out.”

He reaches for the scientific method. Hypothesize. Test. Verify. Iterate. It sounds basic—cliché, even. But his point is that the discomfort most product leaders have with strategy isn’t that they’re doing it wrong. It’s that they haven’t accepted the nature of the work. Strategy is a hypothesis you test with product decisions. The roadmap is the experiment. The outcomes are the data.

“I really believe that strategy is formed in that cauldron,” he says. “Product roadmaps are formed in that cauldron. And great products are built using that sort of scientific method.”

There’s one more thing Rich keeps circling back to, and it might be the connective tissue between the invisible product and the hypothetical strategy.

He describes how his teams do quarterly reviews to examine the assumptions they made when deciding to prioritize, build, and ship specific features. Did we achieve the user outcomes we assumed? Did those outcomes ladder up to the business outcomes they were supposed to?

“This is hard to do,” he admits. “Because you can always say it didn’t happen because we didn’t market it correctly, we didn’t sell it well. There are lots of mitigating factors. Nonetheless, I think it’s really important for all the product triads to hold themselves accountable.”

The anti-pattern is top-down mandates. When strategy flows from a single leader and everyone else is just executing, accountability evaporates. “Oh, we built this because Rich told us to do it,” he says, narrating the dysfunction. “And then if it doesn’t work out, it’s not anybody’s fault but Rich’s or Rich’s boss.”

He calls it demoralizing and dysfunctional. But the word that sticks with me is erodes. Trust erodes when leaders mandate without inviting the team into the hypothesis. It erodes when outcomes are never checked against assumptions. It erodes when shipping is the metric and nobody asks what happened after the feature went live.

Rich Yu builds a product designed to be invisible. He leads with a philosophy designed to be the opposite—transparent about what’s known, honest about what’s uncertain, accountable to what actually happens when the hypothesis meets reality. The invisible product. The visible strategy. The thesis that never pretends to be a conclusion.

Chris Silvestri is the Founder at Conversion Alchemy, where he helps B2B SaaS teams engineer message–market fit across web, sales, and email. Rising to prominence in the early 2020s, he became known for combining deep customer research, UX thinking, and decision-making psychology into scalable messaging systems that lift conversions rather than isolated campaigns. His work positions him as a widely regarded specialist for post–Series A SaaS companies seeking clarity, differentiation, and measurable revenue impact.

Previously, as Founder & Conversion Copywriter at Conversion Alchemy, he led projects that generated up to 30% more qualified demo requests by clarifying value propositions and sharpening differentiation on 20+ core website pages and sales assets. He became known for shortening sales cycles by an estimated 15–20% by making value obvious earlier in the buyer journey and aligning messaging with actual customer priorities. His systems consistently drove 10–15% lifts in trial-to-paid conversions while improving internal alignment across marketing, sales, and leadership.

His career highlights include serving as Conversion Rate Optimizer and UX Designer at Zeda Labs LLC from 2018 to 2021, where he blended qualitative research and experimentation to improve funnel performance and user experience over 2.5+ years. Earlier, he spent nearly a decade in engineering and industrial automation, experience that shaped his systematic approach to messaging, process design, and experimentation. Since 2020 he has also contributed to Good Product Club, writing on product strategy, UX, and go-to-market for teams building in an AI-driven world.

As host of the Message-Market Fit Podcast, he helps B2B SaaS leaders understand how to translate customer insight into narratives that win deals and defend pricing power. Through his Unpacking Meaning newsletter, he publishes weekly breakdowns of SaaS messaging, UX, and buyer psychology for an audience of founders, CMOs, and growth leaders.

What a software engineer turned copywriter learned about positioning—and why 70% of the work happens before you write a single word.

“If you don’t have a process, AI is gonna produce crap,” Chris tells me. “If you have a process, AI is gonna produce good stuff.”

He says it like it’s obvious. Like the whole discourse around AI and creative work has been missing the point.

Chris Silvestri spent ten years as a software engineer in industrial automation in Italy before transitioning to copywriting. He moved to the UK, founded Conversion Alchemy, and now helps B2B SaaS companies find message-market fit. He writes for Every. He’s not worried about being replaced by AI. But he has thoughts about who should be.

I ask him to break down what he means by process.

“First do the research,” he says. “Then don’t feed all the research to AI and have it write—or sometimes they don’t even feed the research and just ask it to write, which is even worse.”

He pauses to let that land.

“Use the research, distill it into your strategy, and then use the strategy as context for the LLM. So they can actually make sense of the data better.”

This is the part most people skip. They dump raw transcripts and survey results into ChatGPT and expect positioning to emerge. But the synthesis—the actual thinking about what the research means—that’s human work. The AI can help you write after you’ve decided what to say.

“Seventy percent of the work to me is research,” Chris says. “And then the messaging and the copy almost write itself.”

I stop him. I want to make sure I understand the claim. He’s saying the writing is almost incidental?

He nods. The hard part is everything that comes before.

Chris’s engineering background shows up here. He sees messaging as a system with distinct layers. Positioning defines who you are. Messaging is how you articulate that across contexts—sales calls, landing pages, email sequences. Copy is the final layer, the actual words. Most people try to fix copy when the real problem is upstream. No amount of AI-generated headlines will save you if nobody agreed on what you’re saying in the first place.

“A lot of times different departments don’t really agree on what they do better or differently,” he says. “And so then everyone starts kind of saying different things.”

The jargon-stuffed copy that plague B2B websites? That’s not a writing problem. It’s an alignment problem.

I ask about how he approaches customer research when the data is thin. Early-stage companies often don’t have enough customers to build detailed personas.

“I think it’s useful to start with an archetype of your customers,” he says, “rather than saying, okay, this is a specific persona.”

He explains the distinction. An archetype is a representative of a group—business buyer versus technical buyer. Under the business buyer archetype, you might eventually differentiate between CMO, CFO, and procurement. Under technical buyer: CTO, data engineers, developers. But if you’re early, you don’t have the data to specify that precisely yet.

“We weren’t clear,” he says, describing a recent project with a data integration company. “So instead of crafting these ideal customer personas, we drafted these early customer personas. Business side, technical side. And from there we could move forward and get more specific.”

Personas come later, when you have crystal-clear data on psychographics, demographics, decision-making patterns. Archetypes let you start building without pretending to know more than you do.

This matters for AI workflows too. If you’re prompting an LLM to write for a persona you’ve fabricated from guesswork, the output will feel hollow. But if you’ve done the research—if you’ve actually talked to customers and heard how they describe their problems—you can give the AI context it can work with.

“The more you compartmentalize your tasks in LLMs, the better it works,” Chris says. “I don’t even use ChatGPT or Claude for writing directly. There are loads of third-party tools that let you plug into the APIs without that pre-training those commercial interfaces have.”

He’s building his own stack. One tool for finding signal. Another for working through strategy. A third for writing with his editorial style guide. Each chat stays focused. The synthesis happens in his head, not in the model.

Near the end of our conversation, I ask what led him to embrace AI when so many writers are defensive about it.

“I think first it was actually feelings of never being good enough,” he says. Something shifts in his voice. “Maybe it stems from the fact that I’m a non-native English writer. I’ve always said, what if I could be better? And then I saw AI, and now the playing field is level for anyone.”

He decided to try every tool he could find. Learn what actually works. Keep up with the changes happening every week. But what he discovered surprised him.

“Once you have a very specific and systematic process, AI can only amplify that.”

The people most equipped to leverage AI are the ones who invested in their own brains before these tools existed. They have vocabulary. They have frameworks. They know what good looks like.

Chris writes for Every now. He mentions how working with their editors makes him see things from a different perspective. The writer has one job. The editor has another. You try to mirror that same workflow when working with AI.

“The craft, the taste,” he says. “That just makes you better and amplifies your ability to do more with AI.”

I’ve been thinking about this since we hung up. The fear around AI in creative work is often misplaced. The tools don’t threaten people with strong processes—they expose people without them.

Seventy percent is research. The rest is finding the right combination of insights, framing, and context. If you’ve done that work, AI is just another tool in the kit.

If you haven’t, it’s a mirror.

Mustafa Kapadia is the Managing Director at Echo Point, where he helps product organizations use AI to eliminate operational drag and compound product velocity. Rising to prominence in the 2010s at the intersection of digital transformation and DevOps, he became known for translating emerging technologies into operating models executives could actually run. Today he is widely regarded as a leading advisor to product leaders seeking to turn generative AI into durable leverage rather than surface-level experimentation.

Previously, as Global Head of Products & Innovation for Generative AI at Google, he led efforts to help the company’s largest enterprise customers, representing roughly the top 20% by scale, build new products and experiences on modern cloud and AI infrastructure. In that role from 2019 to 2023, he built new global innovation labs, combined sales and P&L ownership with hands-on product advisory, and drove adoption of generative AI across complex, multi-billion-dollar portfolios. He became known for helping Fortune 500 executives move from slideware to shipped product by redesigning how cross-functional teams discovered, validated, and launched new offerings.

His career highlights include a seven-year run at IBM, where he grew an internal DevOps capability 3x into a market-facing advisory practice and later led the North America Digital Transformation practice. From 2012 to 2014 he built a cloud automation service that delivered double-digit growth while helping large enterprises compress infrastructure delivery from months to days. Earlier, he served on the Board of Directors at the DevOps Institute from 2015 to 2019, shaping curriculum and thought leadership as DevOps moved from niche practice to mainstream mandate in organizations managing hundreds of applications and billions in IT spend. He also co-founded Science4Superheroes in 2014, running it for eight years to introduce scientific thinking to children under five through playful, family-centric programs.

As host of the Masters Of Product podcast and author of the AI Empowered PM newsletter on Substack, he helps more than 2,000 product managers each year learn to convert AI from a curiosity into a core part of their craft. Through private workshops, public cohorts, and consulting engagements, his work routinely unlocks multi-thousand-hour annual savings per organization and resets how product teams think about judgment, speed, and quality in the AI era.

Building gets easier. Deciding what to build gets harder. Here’s how the top 1% are preparing.

“I had to figure out what I wanted to be when I grow up.”

Mustafa Kapadia says this quietly, almost to himself. He’s describing the moment two years ago when he left Google—after 20 years at places like IBM and Google, running accelerators, building consulting practices, watching digital transformations succeed and fail. And then he walked away to help product managers stop being terrified of the thing that might replace them.

I ask him about the fear. The senior engineers and PMs who’ve told me they’re just... opting out. Done. Can’t adapt. Won’t try.

“I think we have really two camps,” he says. He holds up two fingers, almost making the “peace sign”—then stops. “Well, three camps.”

Camp one: the AI-first believers. They start every task with an LLM. They use ChatGPT for one thing, Claude for another, Gemini for a third, NotebookLM for synthesis. They’ve rebuilt their entire workflow around what AI can do.

Camp three: the skeptics. They want AI at arm’s length. Afraid it’ll outsource their thinking. Afraid it’ll take their jobs. They’re the same people who resisted mobile phones, who pushed back against the internet, who had concerns about every new technology since the printing press.

And then there’s everyone else. The 60% in the middle of the bell curve, trying to figure out which way to go.

“They want to use AI,” he says of the middle camp. “But they don’t really know how. They’re doing surface-level stuff.”

Surface-level. He has a phrase for this. He calls it “using a Ferrari as a paperweight.”

Most PMs use AI for three or four tasks. Summarizing documents. Writing emails. Maybe a little brainstorming. They’ve been handed one of the most powerful tools ever created, and they’re using it to check boxes.

The top 1% do something different.

I’ve felt this myself—the gravitational pull of the easy path. Voice dictation made it so simple to just talk through everything with Claude. I found myself reaching for AI before I’d even tried to think. At some point I started looking for a “brick” for AI, the same way I use a physical lock to keep myself off my phone apps.

I tell him this. Maybe I should get my notebook out first, I say. Try to get as far as I can before—

He cuts me off. Not rudely. Precisely.

“You’re still using AI,” he says. “It’s just a matter of how you’re using AI. Depends on your comfort level.”

Some people think things through first, then use AI to refine their thinking. Others start with AI—”just give me all the options”—then choose the ones they care about, move forward with their own thinking, then use AI to refine it again. Their thought process is sandwiched between AI.

I ask him if there’s a right way.

“I don’t think there’s a right or wrong way,” he says. “I think the more important question is: does it help you become more creative, effective, innovative as a product manager? And if the answer is yes—then more power to you.”

He has a framework. Of course he does—he’s a consultant. But when he describes it, it sounds less like a sales pitch and more like a craft.

“Five keys,” he says. “Assign a role. Provide first-principle inputs. Give it instructions—best practices. Format. And then an example that ties it all together.”

The example he uses is user stories. You don’t just ask AI to write them. You prime the engine. You tell it: you’re world-class at this. You give it the problem, the user, the benefit, the feature. You tell it what a good user story looks like—customer-focused, unique, technical-free. You show it one.

“And then—” he pauses. “Even if AI gives you ten great user stories, you don’t take all ten.”

This is where it gets interesting.

“You take the one or two that resonate. You use your own PM thinking. Your own experience. Your own context.” He calls this human-AI optimization. You’re not outsourcing your thinking. You’re using AI to prime you—to surface options you might not have considered. And then you decide.

The middle 60% outsource their thinking. The skeptics avoid AI entirely. The top 1% sit in the tension between—augmented, not replaced.

The conversation turns to something stranger. Synthetic personas.

Mustafa is working with a client who has years of market research sitting on laptops and servers. Interviews. Surveys. Behavioral data. All of it gathering dust in slide decks nobody opens.

“How do you take that research and make it actionable?” he asks. “How do you give it to someone in sales, or marketing, or product?”

His answer: build a synthetic user. A simulated persona trained on all that research. Something a salesperson can practice objection-handling with. Something a PM can ask, “What would you think if we priced this at $99 instead of $149?”

“It doesn’t replace talking to a real user,” he clarifies. “But in those crazy questions you want to ask—it’s a great way to refine your thinking.”

Then he goes further.

“We have a client who’s building a synthetic competitor.”

I stop him. “A what?”

“A synthetic profile of their competitor. So they can think about second-order effects.” He’s more animated now. “If I drop my price, what is this competitor going to do? If I launch this feature—a feature they already have—how are the two comparing? What can they do to make my feature less valuable in the marketplace?”

None of this means it’s exactly what the competition will do. But it forces you to think. To make better decisions. You can run war games now that were never possible before.

I ask him about the skeptics. The 20% who won’t get on the bus. What happens to them?

He doesn’t sugarcoat it.

“The ship has sailed,” he says. “The train has left the station. Whatever analogy you want to use—it’s happening. The only question as a PM is: where do you want to be? In the driver’s seat? The passenger seat? Or in the caboose, being dragged?”

But then his tone shifts. Softer. Almost conspiratorial.

“If you’re a PM and you’re ambitious—and most PMs are, which is why I love them so much—this is the best time to differentiate yourself. Organizations are dying for PMs who can show an AI-first mindset. They just don’t know what that looks like.”

He’s not selling anymore. He’s confessing.

“I prefer not to talk about what good looks like. I prefer to show them. Because until you actually show someone what a good PM with AI can do—that’s when they say, ‘Okay. How fast can we move?’”

One client started with four or five AI use cases. After his team helped them understand what was possible—what the top 1% actually do—they identified over 250. That’s the gap. That’s the opportunity.

Near the end, he says something that surprises me.

“I think you’re going to need more PMs, not less.”

I must have looked skeptical.

“When you can build anything,” he explains, “deciding what to build becomes a much tougher decision. Building is going to get easier and easier. But figuring out what to build, what not to build, working with the business to determine what’s actually going to make an impact—that’s the job. And I think we’re going to need more people doing it.”

The order-taker PM—business decides, PM translates, engineering builds—that role is dying. What’s emerging is the PM as decision architect. The one who navigates the infinite possibilities that AI unlocks and says: this one. Build this.

He is not wrong. New computer science (CS) students are already doing this.

My engineering manager told me recently that his son is in college, doubling down on AI education instead of a traditional CS degree. The homework is mostly about giving context, setting up system prompts. “This is basically PM work,” I said.

Mustafa nodded when I told him this. It’s becoming a common observation. The engineers need product thinking. The designers need product thinking. Everyone’s developing the competency because the alternative—hiding behind tactical building, being a feature factory—doesn’t work anymore.

We sign off. He mentions a benchmarking study dropping soon—fifty or sixty CPOs, data on how the best are actually using AI. He gives me his Substack. Echo Point.

“I give away 95% of what I tell my clients for free,” he says.

I believe him. And I subscribe before the call ends.

The last thing I remember is him saying something about the middle 60%. How you don’t have to convert the skeptics. You just have to pull the middle toward the top. And once 80% of your organization is using AI for 250 use cases instead of four...

The other 20% stops mattering.

Matt D. Smith is the founder of Shift Nudge, a professional interface design training platform for working designers. Rising to prominence in the 2010s for his systematic approach to visual interfaces, he became known for turning over 20 years of interface design practice into a structured curriculum used by thousands of designers worldwide. His work on design patterns and tools has made him a widely regarded figure in modern interface design education.

Previously, as founder of Shift Nudge, he built a global program that helps designers advance their careers in as little as 8–12 weeks while receiving mentorship and support for a full year, equipping them to lead teams and ship production-quality interfaces. He became known for transforming working designers’ income trajectories, with students reporting income growth of 2x within a few years by applying his methods in typography, layout, and spacing. Through Shift Nudge, he has trained designers from leading startups and global brands, positioning the program as a modern alternative to traditional design education.

His career highlights include pioneering the Float Label pattern in 2013, a form interaction now adopted across products from Apple, Google, and countless consumer applications. He also created the interface design tools Contrast and Flowkit, Figma plugins that have reached tens of thousands of users and are used to check color contrast and design user flows inside modern design tools. Beyond product work, he has served as an adjunct professor at the University of Georgia and delivered workshops and talks at conferences including Adobe MAX, Dribbble Hangtime, Figma’s Config, Smashing Conference, and others, extending his influence from the classroom to stages across the United States.

What a decade of design fundamentals taught me about delegating to Claude Code—and why Shift Nudge was secretly an AI onboarding course before AI existed.

“I have a weird obsession with trying to get the absolute most difficult username across every platform,” Matt says, and it lands like a confession. He goes by MDS on the internet. Three letters. You can imagine the negotiations, the dead accounts, the patience required.

We’re a hundred episodes into knowing each other—he was guest number 50, and now here we are past 150—and he’s still introducing himself as someone in transition. “I’m a designer turned educator now sort of turning into a CEO trying to figure out how to run a design education business.” There’s something in how he says trying to figure out that earns the pause that follows.

I’ve watched Matt’s public work for almost a decade. I was the third beta tester to graduate from Shift Nudge back in 2020. I bought low, as I like to say. The course has appreciated since then, but so has something else—something I didn’t understand I was learning until AI came along.

When Claude Code got good enough to actually help with design tasks, I noticed I could delegate effectively while other people couldn’t. The difference wasn’t technical skill. It was vocabulary. Every time I’d tell Claude to “adjust the row height” or “try a card component instead of a list view,” I was drawing from a library of concepts Matt had codified years earlier. Those concepts weren’t just design rules. They were the building blocks of clear instruction. The most valuable thing I learned from Shift Nudge was the vocabulary.

When I became a design lead, I could articulate with precise vocabulary what wasn’t working in someone’s design. Subject, object, verb. The spacing is off for this reason. That precision made me good at delegating to humans. Now it makes me good at delegating to machines in the form of Skill files to AI agents.

Matt nods slowly. “Skill files,” he says, “they’re good at getting directionally correct, especially things that are like absolutely binary. Is this the way you write an HTML link or is it not? It’s definitely right and wrong.” He pauses. “Whereas design... there’s more gray area than black and white.” Capturing the nuance a missed in my observation.

He’s talking about Claude’s skill files—those markdown documents that give AI context about how you want things done. And he’s right that they work best for the binary stuff. But here’s the connection he helped me articulate: skill files are functionally identical to the Standard Operating Procedures you’d write for a junior designer.

I bring up The Defiant Ones, the documentary about Dr. Dre and Jimmy Iovine. When Jimmy was learning to be a record producer, his mentor taught him by working through him. “Adjust the reverb. What happened there? Why did that work? Why did that not work?” It’s the master-apprentice model, I say. And I think that’s where things are going with AI.

Matt leans into it. “You still need that institutional knowledge, the vocabulary. AI can adjust the reverb and adjust the echo and adjust the panning. Oh, you want five different beats? But it’s like—why? How much? When do we stop?” He lets the questions hang. “That creativity... I think there’s gonna be, you know, in the same way that there was a big resurgence of live in-person things after COVID—I think we’re all gonna be like, it’s just refreshing when I read something online and I can tell that a human wrote it.”

There’s something in his voice when he says refreshing. Like he’s already tired of the alternative.

I ask about the divergence he sees coming—who wins, who loses. He doesn’t hesitate.

“There’s gonna be a divergence where the person who doesn’t use AI is just simply not as effective as the person who learned how to use it. But then there’s also gonna be a divergence of—I’m using AI all the time and this other person is like, well, I learned a lot of things before AI existed and I use AI and now I know more than you.” He pauses. “And this other person’s just fully reliant on AI and they don’t know much.”

It’s gonna be harder to learn things, he says, because AI is so instant. “It makes it like painful to sit down and read something and actually learn it yourself.”

The irony is that the people most equipped to leverage AI are the ones who invested in their own brains before these tools existed.

Matt has a framework for mapping where you fit in all this. He calls it Pioneer, Builder, Consumer.

Pioneers are the people at Anthropic and Cursor and OpenAI—building the intelligence and the harnesses that give it to us. Builders are the developers and designers using these tools to create products. “We’re sort of converging slowly,” he says. “Designers are over here and developers over here, and some are still better at infrastructure and setup and code—like, oh, that’s why would you use useEffect here in React—and designers over here like, what does that mean? But it’s starting to be irrelevant because some of the tools are getting so good.”

And Consumers? “My mom is a good example,” he says. “She’s not choosing to have AI in her life. She’s just seeing it happen through Amazon review summaries or Google AI summaries for the things that she used to search for.”

The question isn’t whether AI will touch your life. It’s which persona you want to occupy.

I push on the vibe-coding hype. All those people on Twitter saying software is cooked because they built a Facebook clone in five minutes.

“I don’t wanna rely on your janky vibe coded app to help me,” Matt says, and there’s a dry humor in it.

I have a follow-up I’ve started using. Whenever someone says “I did this with AI”, I ask: Cool. So what’s your plan to maintain it?

They never have an answer. That’s when you realize why we pay engineers. DevOps, infrastructure, support tickets—that’s the unglamorous work that keeps the train running. Building something on your own is a lot different than supporting a hundred thousand users at once.

Near the end, Matt gets reflective about advice. “You’re gonna need your own knowledge,” he says. “Build that vocabulary through any means possible. Whether it’s asking questions from AI while you’re learning, or watching videos, or attending school. I think there’s still real value in you building your own brain.”

He catches himself. “And if you don’t want to do it—you know, maybe you change careers. I don’t know.” Something shifts. The pragmatism cuts through.

“Just kind of plot yourself,” he says. “Are you a pioneer? Are you gonna be a builder? Are you just gonna be a consumer? Because either way, AI is gonna be touching a part of your life, whether you choose to or not.”

I’ve been thinking about this since we talked. I’m reading books again—not AI books, the fire hose has enough of those. I’m building vocabulary in domains outside tech: marketing, strategy, positioning.

The cost of building has collapsed. The cost of deciding what to build has not.

Everyone with taste is not in tech right now. It’s in the humanities, philosophy, long-form content.

That’s where I’m looking.

Steph Cartwright is a Job Search Strategist and Certified Professional Resume Writer (CPRW) at Off The Clock Resumes LLC, where she helps tech and industry leaders present as confident, high‑value candidates on screen. She became known for career branding that turns complex experience into clear, employer‑ready narratives that consistently convert views into interviews. She has built an audience of more than 3,200 followers and over 500 direct connections while operating from the Spokane–Coeur d’Alene region.

Previously, as Founder and Principal Writer at Off The Clock Resumes LLC, she scaled a boutique career services practice into a specialized partner for job seekers navigating competitive roles with compensation packages frequently exceeding six figures. She became known for a structured, data‑driven intake process that translates into résumés and LinkedIn profiles optimized for modern applicant tracking systems, significantly increasing interview rates and offer quality for her clients. Through one‑to‑one engagements and digital products, she has supported hundreds of professionals across tech and adjacent industries.

Her career highlights include earning and maintaining the CPRW credential, signaling adherence to rigorous professional standards in résumé writing and career communication. She has continued to refine a distinctive positioning around “career branding that gets noticed and lands interviews with higher offers,” focusing on clarity of story, on‑screen confidence, and repeatable systems that scale beyond any single job search. By combining structured frameworks with empathy for career pivots, she has become a trusted partner for leaders who need to articulate complex trajectories in two pages or less.

Why the old keyword-stuffing playbook is dead. And what job seekers should do instead.

“I am the face behind my business and in front of my business,” Steph says, “as well as the one that does all the one-on-one work with clients.” There’s something in how she phrases it—face behind and in front—that captures the exhausting clarity of solopreneurship. She’s the product and the salesperson. The expert and the marketer. And she’s been doing it since 2014.

She started as a serial job seeker. “I am well rehearsed in job search practices,” she says, with the kind of dry humor that only comes from having lived through too many of them. Now she’s getting ready to attend another annual conference to stay current on hiring tech. The landscape, she tells me, is shifting faster than most people realize.

I ask her what current hiring practices are doing to block talented candidates.

“It’s gone beyond applicant tracking systems,” she says. “That used to be very keyword based. And now it’s not so much the worry of making sure your resume has all the right keywords.” She pauses. “AI is now adding generative and predictive analytics to this technology. It’s actually going to make it easier for job seekers because they don’t have to worry so much about the specific keywords.”

This is counterintuitive. For years, the advice was: mirror the job posting. Product development. Project management. Agile methodology. Match the strings, beat the algorithm, get in front of a human. That era, Steph tells me, is ending.

She walks me through an example. Say a product developer five to ten years ago wanted to tailor their resume. They’d add the term product development to ensure their resume would surface in searches. If someone went into LinkedIn looking for that skill, they’d pop up. “It was really important to have the right keywords, the right phrasing,” she says.

Now? “If you don’t have the specific words—the specific product development phrase—AI is going to look at your experience and it’s going to look at context. It’s going to look at, you know, predictive. If you say you’ve done this, you likely have this skill.” She lets that land. “AI is going to start making assumptions about you that will help you.”

The old systems were deterministic. You could game them if you knew the rules. The new systems are probabilistic. They infer. They read between the lines. This is good news for generalists and career changers—people whose careers don’t fit neatly into keyword buckets.

I tell her this resonates. I’ve jumped between design and product management throughout my career, and I’ve gotten direct questions: What do you actually want to do? Few people accept my honest answer, which is basically whatever the company needs and I find interesting at the time.

Steph nods. “At some point in the last ten years, the trend shifted from wanting someone with a broad range of skills to: we want a specialist, we want someone who really is an expert in this one thing.” She pauses. “But now that we’re adding in this AI element, we’re kind of going back to the original trend where AI wants to see the breadth of your knowledge and then be able to say, yes, this person has these skills, but they also have these skills, which will likely be a good fit.”

The conversation turns to how people market themselves, and Steph lands on an analogy that sticks.

“Highlighting benefits over features,” she says. “Those keywords, those skills—those were features, not the benefits. Whereas now, if you shift your mindset to: I’m going to position myself as the best fit for this job, not because of my skills, not because of the features that I bring, but because of the impact I’ve made.”

She explains how this plays out technically. “One bullet on your resume can speak to an ATS based on the keywords in it—so that one bullet may be associated with project management skills. Whereas now with AI, that one bullet, depending on how much information you give it, might register five, six, seven different skills associated with that one bullet because of the impact you had.”

The example she gives: designing a product that increased efficiency for a large enterprise. That single bullet, written with context, signals project planning, project management, design, strategy—multiple capabilities inferred from one outcome. The question isn’t What can you do? It’s What have you made happen?

I bring up LinkedIn, and how I’ve started writing narrative case studies instead of bullet points for each role. The bet is that AI will read it and extract more context to provide better evaluations to hiring managers.

Steph lights up. “Storytelling, especially on LinkedIn, is key. I used to work with clients very specifically on, let’s take these bullets on your resume and expand them as projects on your LinkedIn profile. Because that project section is also searchable. It’s also readable by the tools behind the scenes.”

She leans into it. “Tell me the full story. How it started. What was the challenge that needed to be resolved. What you did, who you impacted, what obstacles you faced, and then what was the ultimate outcome.” Each project gets 2000+ characters, she says—2000 characters the AI can read, infer from, match you to opportunities.

But the real shift in her thinking, she tells me, isn’t about resumes at all.

“If you don’t tailor your resume for this specific job before you apply, you won’t even be considered,” she says. “I am still a strong believer in tailoring a resume if you’re gonna apply online. But now, because the competition is so high, I would say it’s more important to have a full blown strategy built outside of applying for jobs online.”

What does that strategy look like?

“It’s more important to be strategic in who do I need to talk to? Who can I start relationships with—even if it doesn’t result in a job at that company—but is going to expand my reach in my targeted field or industry?”

She reframes networking as something that makes people less uncomfortable. “You can’t just think of it as networking—just getting your name out there and hoping something lands. But building professional friendships is what is going to make the difference.”

I ask her how she coaches someone who’s just starting out, someone without an existing network.

“Find a trade or professional organization that you can join and actively participate in,” she says. “One that opens you up to develop professional friendships with people you would maybe look at as competitors for different jobs, but they’re also mentors.”

She tells me about a colleague halfway across the country. “She and I just sat down and had lunch together over Zoom and just talked shop. She has sent me referrals. I have sent her referrals. I would call her a mentor, but we’re also friends.” There’s warmth in it. “I know she’s in my corner. She will never do something to jeopardize that professional friendship.”

I share a story from my own career. Five years ago, I had an offer from a company that I turned down for something more interesting. The hiring manager was a class act about it—That sounds really cool, I’m really excited for you—and he kept in touch. For five years. Then, recently, when I was looking again, an opening came up. I interviewed. It went well. Then a budget issue threatened to kill it. Another team needed to shuffle a designer internally. I waited all weekend, assuming it was over.

The recruiter called. We want you here. We have to work this out, but we really want to figure out a way to make this work. They talked to the VPs. Got budget approval. Carved a spot out for me.

“That’s best case scenario right there,” Steph says.

It’s a five-year story arc, I tell her. And it only worked because the relationship was real.

“That is the end goal,” she says. “You’re not going to find that by just applying for jobs on Indeed. You have to do that extra work. And the narrative of this is how you’re supposed to find a new job keeps people from trying.”

She pauses. “Companies are notorious for creating roles for the people they want. If you can figure out what that company’s challenges are and how you can help them solve those challenges—that’s what’s going to help you get your foot in the door at a company you’re gonna be happy with.”

Near the end, she gets reflective. “I didn’t go into this thinking we were gonna deep dive on resumes or LinkedIn. I feel like we really covered a wide range of strategy.”

She’s right. We barely talked about formatting or bullet points. We talked about the slow, patient work of being known. Of building something that compounds. Of treating your career like a series of stories worth telling.

The basics still matter, she reminds me. A solid LinkedIn presence. A resume ready to go. But the game has changed. The people winning aren’t the ones optimizing keywords. They’re the ones showing up—at conferences, in communities, in DMs—building professional friendships before they need them.

That’s the strategy that’s AI-proof.

Kasim Aslam is the Co-Founder of Pareto Talent, a boutique executive assistant recruiting agency helping entrepreneurs reclaim 40+ hours per month through rigorously trained, full-time remote EAs sourced primarily from Latin America. Rising to prominence in the 2010s as the architect behind one of the top-ranked Solutions 8 Google Ads agencies in the world, he became known for building and exiting multiple seven- and eight-figure businesses while positioning himself as a leading voice on performance marketing and founder leverage. Today he is widely regarded as an influential figure in the emerging discipline of Answer Engine Optimization and founder systems design, serving growth-focused entrepreneurs through Driven Mastermind and his briefing series The Daily Sigh.

Previously, as Founder and CEO at Solutions 8, Kasim scaled what his M&A advisor described as the largest specialized Google Ads agency in the world at the time of its sale, managing more than $100M in ad spend and growing a fully remote team of over 100 employees across multiple countries. In October 2022 he executed an all-cash eight-figure exit after nearly 18 years building the firm from a one-man web-development operation into a top-ranked Google Premier Partner serving hundreds of clients. That transaction marked his third successful exit after building six different seven- and eight-figure ventures over two decades.

His career highlights include co-founding Driven Mastermind, an invite-only growth community led alongside Perry Belcher and Jason Fladlien that brings together multi-seven- and eight-figure founders for high-velocity experimentation and scale. He also co-founded Nido Marketing, a specialist firm dedicated to helping Montessori schools grow enrollments through digital marketing programs and over 20 self-guided courses built for more than 100 school operators. Earlier, as Co-Host of the Perpetual Traffic Podcast, he helped keep the show consistently ranked among the top 10 marketing podcasts worldwide while publishing weekly episodes over four years to an audience of thousands of practitioners.

As the author of “The 7 Critical Principles of Effective Digital Marketing,” Kasim was recognized by BookAuthority among the 100 Best Digital Marketing Books of All Time and named one of UMSL’s Top 50 Digital Marketing Thought Leaders in the United States in 2020. Through his current project The Daily Sigh at DailySigh.ai, he delivers a 15-minute daily briefing distilling what actually mattered in business, AI, and entrepreneurship for revenue-generating founders, reinforcing his legacy as a strategist who converts complex shifts into practical, founder-ready decisions.

Why 20 years of watching “the best product lose” led to a radically different business thesis

“I spent 20 years watching the best product lose,” Kasim Aslam tells me. He lets the sentence land. “I spent 20 years watching the best products go by the wayside. The best kept secret stay a secret. Because they couldn’t drive traffic.”

We’re an hour into a conversation that started with him saying he builds businesses professionally—a phrase so casually delivered it took me a moment to register its weight. Kasim has built the number one ranked Google Ads agency in the world, exited to a SoftBank-backed organization at an eight-figure valuation, and accumulated a portfolio of 17 companies across digital marketing, real estate, and professional services. He’s not on the org chart of any of them. His favorite answer, he tells me, is “I don’t know.”

But before any of that, there were the failures. Over a hundred of them, by his count. Medical transcription. A furniture store. Selling purified mercury. A moving company. Baskets on Amazon. “When I went back and tried to count,” he says, “I couldn’t count every epic failure.”

Kasim was raised by a blind single mother on social security disability. At 22, he lost his job in the 2008 crash with $150,000 in debt. What he found on the other side of those hundred failures wasn’t a better product or a smarter strategy. It was a formula that most entrepreneurs get exactly backwards.

Find the traffic first. Then figure out what problem to solve.

---

The insight came from a peculiar vantage point. As the founder of Solutions 8, Kasim spent years managing $100 million in advertising spend for other people. Two hundred clients. Eighty employees. He got to see everything—what things cost, what they sold for, retention rates, competitor landscapes, what attention was actually worth.

“What’s really devastating when you start to wrap your head around what that means,” he says, leaning into the word, “is Google makes more money than you do. You’re slaving away and the traffic stores are eating your lunch. You’re working for them.”

An e-commerce company, he explains, will spend more on traffic than on cost of goods, fulfillment, operations, and customer service. Sometimes combined. The math is brutal. And most founders only discover it after they’ve already built the thing.

“So you take that and for the first day, you just spend it sitting in a bathtub of gasoline lighting matches, just mad.” He pauses. “And then, because you’re a bright entrepreneur, you think—well, gosh, I wonder if I can solve for that.”

His answer is counterintuitive. Don’t build a product and hunt for customers. Hunt for the customers first. Traffic, in Kasim’s vocabulary, doesn’t mean Facebook ads or pay-per-click campaigns. Traffic means any group of people with a shared agenda whose attention you can capture. A HubSpot forum full of users complaining about missing features. A Facebook group for Michelin star restaurant owners. A PTA meeting.

“Traffic usually looks like a bunch of people complaining about something,” he says. “It never comes beautifully packaged in a nice little gift box with a bow. It looks like a screaming mob with pitchforks and torches.”

That’s why it’s available. Nobody else wants to deal with it.

---

He tells me about Rafa. A tour guide in Costa Rica who drove Kasim and his two sons five hours from San Jose to Corcovado—the most bio-diverse place in the world—so his eldest could see it before deciding whether to become a biologist. Over 12 hours on the road together, they talked about Rafa’s business.

The problem: every tour guide in Costa Rica is competing for the same tourists, and the big resorts have shuttles from the airport. Their traffic patterns carve the paths that everyone else follows. The small Airbnbs and bed-and-breakfasts can’t afford their own transportation, so their guests never make it to the remote destinations.

Kasim’s solution was simple. Rent a van for $500 a month. Hire a driver for another $500. Then call every small property that doesn’t have its own shuttle and offer to transport their guests for free.

Now Rafa has a captive audience for 90 minutes. Twelve tourists in a van, driving past volcanoes and dive spots, listening to a guide who knows every inch of the country. If he can’t sell one high-end tour during that drive, Kasim says, he’s an imbecile. On the way back, Rafa stops at a friend’s trinket shop and takes 40% on whatever the tourists buy.

“Give Rafa thirty vans,” Kasim says. “He could be the biggest tour company in Costa Rica. Because nobody else is willing to do that.”

I think about my own parallel—the guy I met in Tulum during the tail end of COVID, when everything was closed and the ruins were blocked off. He was just sitting in his car near the roadblock, waiting for confused tourists on bikes. He offered to broker a boat tour so we could see the ruins from the ocean. It was sketchy at first. But I admired the hustle. He knew exactly where people would show up and what they’d want.

“Game recognizes game,” Kasim says when I tell him. “When you see somebody like that, especially as an entrepreneur, you’re like—alright, you win.”

---

The conversation turns to talent. Kasim’s new book, “Pareto Talent”, is the distillation of 20 years of testing a hiring thesis that makes most managers uncomfortable.

Everyone knows the Pareto principle: 20% of employees do 80% of the work. What Kasim realized is that the principle is fractal, a pattern where each small part looks like a mini version of the whole, repeating over and over as you zoom in. In a thousand-person organization, 200 people do 80% of the work. Of those 200, 40 do 80% of that work. Keep zooming in. Eventually you find that one person is doing 25% of the entire organization’s output.

“That’s Pareto talent,” he says. “And most importantly, you can index towards finding that person.”

When he sold Solutions 8, one employee out of 80 was managing 40% of his revenue. That wasn’t a failure of management. That was the Pareto distribution doing exactly what it does.

The question is whether you fight it or lean into it. Most companies fight it. They flatten hierarchies, set minimums, demand quotas. “When you flatten a pyramid,” Kasim says, “you lose the best part. The most value climbs to the top.”

His alternative: pay more. A lot more. If the market pays $75K to $100K for a role, don’t try to hire at $74.9K. Pay $110K. Or $150K.

“Winners want to win, and money is how we keep score.” He’s not selling anymore. He’s confessing. “When you pay 10% more, 50% more, 100% more—you don’t get 10 or 50 or 100% more output. You get 5x, 10x, 100x.”

The corollary is that you have to treat people like they’re excellent. The screenshot-your-desktop, clock-in-clock-out, count-your-PTO surveillance culture? He has no patience for it.

“What kind of peak performer wants to work in that environment? Treat people like humans. Like adults. Align your incentives. Take the question of money off the table.”

On middle management, he goes further: “Middle management is a holdover from Greco-Roman era indentured servitude. It’s ‘go watch the slaves and make sure they’re rowing hard enough, and if they’re not, whip them.’”

High-agency people don’t need watchers. They need goals, values alignment, and then you need to get out of their way.

---

I ask him for a real example. He tells me about Yvonne—a young Ukrainian man studying in Poland who started as his virtual assistant for a thousand dollars a month. Kasim used to send him every problem he couldn’t solve, every fire that landed on his desk.

“The kid was extraordinary,” he says. “He ran through walls. And if he couldn’t run through the wall, he’d tunnel under it. And if he couldn’t tunnel under it, he’d find a way around it or over it.”

Yvonne rose through the organization. Tech lead. Then CTO. Then he managed the entire exit—eight months of due diligence with Goldman Sachs and Ivy League analysts, the whole proctology exam. A 22-year-old former VA sparring with people whose job it was to find flaws.

Today, Yvonne is Kasim’s 50/50 business partner in Pareto Talent. They just crossed a million in revenue. Yvonne finds the executive assistants, trains them, manages the clients, runs the sales, handles onboarding. Kasim drives traffic to it.

“I took a kid from a thousand-dollar VA to a million-dollar business owner,” he says. “Took six years.”

I mention that I broke into product design the same way—starting a podcast not because I wanted to be a podcaster, but because hiring managers would come on a show when they wouldn’t meet for coffee. My boss for three companies was my second guest. He gave me the shot even though I wasn’t the strongest visual designer on paper. He spotted something else.

“You’re the guy waiting outside the ruins saying, ‘Do you wanna take a boat?’” Kasim says. “That’s starting that podcast. So few people do that.”

---

Near the end, he shifts register. The guy who spent the last hour talking about traffic pools and Pareto distributions starts quoting Kahlil Gibran.

“Work is love made visible,” he says. “And the older I get, the more aggressive I get with that opinion.”

I wait.

“People don’t like the word love, especially in the West. We’ve ruined it with Hallmark cards and made-for-TV movies. But love—that’s the endeavor. When you design a product, if you’re really doing it right, that’s what you’re doing. There’s love for the end user, love for your compatriots, love for yourself, love for this endeavor.”

He tells me money is a representation of the value you provide to other people. If you’re loving people properly in a functional environment, profit follows. He teaches this to his children.

“Every human is capable of being a miracle,” he says, “in the right context.”

I think about Rafa with his van. Yvonne in Poland. The guy in Tulum with his boats. The traffic pools that look like screaming mobs—until someone decides to serve them.

“If I were to make a small change in the way we all cooperate and communicate,” Kasim says, “it would just be allowing for more accessibility to that concept without it feeling weird.”

He pauses. “This is my Mr. Rogers moment, I guess.”

Kelly Price, SHRM-SCP is the Founder & CEO at ThriveHR, LLC. Rising to prominence in the 2010s as a high-impact HR and Total Rewards leader across multi-location service organizations, she became known for transforming people operations into a strategic growth engine for small and mid-sized businesses. Today she is widely regarded as a people-first operator who helps owners turn culture, compensation, and benefits into durable competitive advantage.

Previously, as Senior People Partner – Total Rewards at nbkc bank, she led compensation and benefits strategy for a rapidly evolving financial services organization during a period of tightening labor markets and accelerated digital transformation. In her earlier tenure as People Operations & Benefits Manager at nbkc, she was responsible for end-to-end HR operations for the Kansas City metropolitan footprint, supporting several hundred employees through multi-year change while maintaining compliance, retention, and engagement metrics.

Her career highlights include a seven-year rise at Samson Dental Partners, LLC, where she progressed from Recruiting Manager to Vice President of Human Resources while the organization scaled across multiple states and dozens of dental practices. During that period she built the recruiting function from scratch, hired clinical and non-clinical teams across home office and field locations, and expanded the HR organization to support rapid growth in headcount and locations. Earlier in her career, she sharpened her recruiting and talent acquisition craft at Ferrellgas and Waddell & Reed, managing nationwide and regional hiring mandates in highly competitive markets.

A graduate of Kansas State University with a bachelor’s degree in Hospitality Administration and a SHRM Senior Certified Professional credential renewed through 2027, she has also been an influential figure in the Kansas City HR community through board service with Total Rewards KC and L’Arche Heartland. Through ThriveHR, she continues to advise founders and leadership teams across Kansas City, Southwest Florida, and Houston on building resilient people strategies that scale.

The Netflix Problem

Everyone loves the Netflix talent philosophy in theory. Treat adults like adults. Pay top of market. Fire fast. No vacation tracking.

But Kelly sees the gap between billion-dollar companies and the small businesses that make up most of America. A 50-person company in Kansas City can’t offer five engineers’ salaries for one rockstar. They need B players and C players for repetitive, supervised work—and that’s not a failure, it’s reality.

“An A player can’t sit in every single role because they won’t be happy,” Kelly told me. “There are lots of different levels of work that needs to be done.”

The talent strategy has to match the business. A startup founder passionate about their product doesn’t need—and can’t afford—Netflix-style HR. They need someone to take the compliance burden off their plate so they can focus on what they love.

---

Control and Money

When I asked about return-to-office mandates, Kelly didn’t hedge: “It’s all about control. Control and money.”

She’s watched clients cling to eight-to-five, sit-at-your-desk policies despite every study proving flexibility drives productivity. COVID revealed something we can’t unsee—life is precious, and there’s more to it than work.

But that doesn’t mean 100% remote works everywhere. Some jobs require physical presence. Some small businesses can’t manage a distributed team. The mistake isn’t having people in the office—it’s treating flexibility as a perk rather than a tool.

“That is 100% a people problem,” Kelly said. “Do you have leaders in place that are holding their employees accountable? Creating an environment where they can ask questions when they don’t know what to do?”

The system—remote, hybrid, in-office—doesn’t determine success. Leadership does.

---

The Three-Tier Audit

When Kelly onboards a new client, she starts with the business fundamentals: How do you make money? What are you trying to accomplish? What type of people work best here?

Then comes the audit—every policy, every state, every compliance requirement. Hiring, I-9s, performance management, payroll, termination, offboarding. Top to bottom.

The findings get prioritized into three tiers:

**Compliance first.** “You’re gonna get sued for this stuff.” Fix what the government could fine you for before chasing strategy.

**Tactical second.** Hiring processes, performance reviews, HR systems. Are they efficient? Are the people running them trained?

**Strategic last.** Only after the foundation is solid do you ask: How can the people function support business growth?

“If you don’t have these foundational things in place,” Kelly said, “you really shouldn’t be thinking about strategy.”

---

Ask Permission

The most practical advice Kelly shared was disarmingly simple: ask permission.

“I wanna be honest with you, and I’d like permission to share my thoughts.”

She’s never had anyone say no. They might disagree afterward, but they listen. And often they come back later, having processed what was said.

It works with founders, CEOs, leaders with egos—anyone who needs to hear something they don’t want to hear. The phrase reframes confrontation as collaboration. You’re not attacking. You’re partnering.

Makoto Kern is the UX Product Strategy Design Leader at IIIMPACT, Inc.. Rising to prominence in the 2000s, he built a reputation for transforming complex enterprise software into high-adoption products, guiding clients through more than 22 years of digital transformation initiatives across energy, cybersecurity, healthcare, fintech, and logistics. He became known for driving 450% year-over-year revenue growth at IIIMPACT while helping Fortune 500 and high-growth B2B SaaS teams achieve up to 85% user adoption versus a 34% industry average, and for preventing $2.3 million in wasted spend through strategic planning workshops.

Previously, as a senior UX consultant at FROM, The Digital Transformation Agency, he led mobile and responsive web experience design for one of the largest U.S. car rental companies, a major Broadway e-commerce platform, and a top payroll provider, contributing to multi-million-dollar online revenue channels between 2011 and 2020. He became known for building cross-platform loyalty workflows across iOS, Android, and responsive web, and for introducing UX strategy practices that informed product decisions through analytics and usability testing.

His career highlights include senior UX roles at Walgreens and Humana, where he shaped e-commerce, mobile, and responsive experiences for millions of consumers between 2011 and 2014. At Walgreens, he helped optimize cross-channel journeys across Walgreens.com and affiliated sites, supporting year-over-year gains in online conversion for properties spanning pharmacy, beauty, and vision. At Humana, he led UX for member-facing mobile apps and loyalty programs, collaborating with innovation teams to move concepts from brainstorming to tested prototypes in an agile environment.

As host and executive producer of the Make an IIIMPACT Podcast, he translates two decades of product and UX leadership into weekly conversations for CTOs and product executives, growing the show to more than 80,000 subscribers and generating over 35,000 views on individual episodes in 2024. He also writes about his journey from robotics and fuzzy controllers to software leadership in essays like his Medium piece “From Broken Glasses to Building Better Software,” extending his influence beyond client work into broader product and design circles.

What happens when companies pause everything for eight months to integrate AI and discover nobody uses it.

“The moat is the user experience,” Makoto says. “The easier you make that, the better. No one cares if you’re using Claude or ChatGPT.”

We’re about twenty minutes in, and I’ve been waiting for someone to say this out loud. Everyone’s talking about AI strategy, AI integration, AI roadmaps. Makoto’s been consulting for twenty years, and he keeps coming back to the same point: nobody cares about the backend. They care if it solves their problem.

Makoto Kern started as an electrical engineer in Chicago, building software for manufacturing environments. His job was to automate systems, make them faster, more efficient. But he kept noticing something. The software was built by engineers for engineers—and the people on the factory floor weren’t engineers. They had to use it anyway.

“It kind of naturally led to UX,” he tells me. He started building websites on the side during the .com boom, taking sales calls over lunch at his full-time job, finding work on Craigslist. Eventually he quit and started IIIMPACT. That was twenty years ago.

I ask him what’s been consistent across those two decades. What survives the hype cycles?

“You still see the same problems no matter what the technology is,” he says. “You have to be hyper-focused on knowing that you’re solving someone’s problems.”

The pattern is always the same. During the .com boom, companies added “.com” to their name and watched valuations spike. With crypto, the pattern repeated. Now with AI, he’s watching it again—companies pausing critical feature development to “just integrate AI,” only to discover nobody uses it.

Then he tells me about a case study that stuck with me for days.

One of his clients decided to pause all product development for eight months to integrate an AI chat feature. Microsoft was pushing Copilot. Salesforce was pushing Copilot. Everyone wanted one. So they built one.

“Eight months later it’s integrated,” Makoto says. “We take a look at Pendo. We see a prompt, maybe two prompts during training. Nothing else after that.”

I wait for him to continue.

“So nobody’s using this. And this is exactly why you test.”

The features users had been asking for? On the back burner for eight months. The competitors who kept building those features? Now ahead. Eight months of “innovation” became eight months of falling behind.

“It’s another Clippy right now,” he says, and something in his voice suggests he’s said this before. “People are falling off after using it once or twice. They’re like, I don’t need to use this. I’m gonna go back to what I’m familiar with.”

I bring up the instinct to chase technology—how hard it is to tell a board you’re focused on fundamentals when they’re asking about AI strategy.

Makoto has a metaphor for this. “It’s like telling a kid it’s cold outside, wear a jacket. They don’t wanna wear the jacket.” He pauses. “Then they get sick.”

He says when his team goes into consulting gigs, a lot of these companies are the kid who doesn’t want to wear the jacket. You tell them what’s good process, what’s good strategy. But they’re going to do it their way. “So we go in there. Of course, I bring the jacket. I tell ‘em to put it on after they’re cold.”

There’s something resigned in how he says after.

“Have you heard of the Peter Principle?” he asks.

I shake my head.

“You’re promoted to the point of incompetence.” He lets it sit. “You get somebody who’s a great developer and they’re promoted to manager, but they can’t manage people. So they stop there.”

He’s seen product people say we don’t need to change anything, it’s working as it is. No innovation. Just following what competitors do because it’s the safe play. “If the salespeople heard about this, they’d be like, are you crazy?”

The conversation turns to vibe coding—all those people on Twitter claiming software is cooked because they built something in five minutes. I tell him I’ve been using Claude Code, and it’s incredible for setup, for gluing repositories together. But when things break, I don’t understand what I’m reading.

“Yeah,” he says. “That’s UX.”

Performance is UX. Security is UX. If your dev team creates tech debt and every button takes five seconds to load, that’s not a backend problem. That’s the experience. And with everyone vibe-coding everything, he says, you’re going to see privacy issues, security flaws. His cybersecurity clients are ready. “They’re licking their lips.”

I ask him what he does when the AI hype gets overwhelming—all the noise about automation, about making a hundred thousand dollars a week.

“I just took a step back,” he says. “This is the bubble that people are going after. Don’t pay attention to that. Just stick with the fundamentals.”

He tells me about his own experience with AI. He uses it for crunching data sets, for research, for brainstorming. But he sees the hallucinations. He questions the outputs. “Don’t use it as the end-all, be-all.”

Near the end, I ask what hasn’t been said.

“If you want to innovate, you can’t be scared about utilizing the right resources in the right way,” he says. “Because now if you don’t, it’s going to be detrimental to your company.”

He pauses.

“Don’t rely so much on technology. Always fall back on the right processes. If your product interfaces with users—like most of them do—be super hyper-focused on the user experience. Even if you have board members pushing your CEOs and your leaders into a certain direction, you have to get them to understand: are you solving a user’s pain point or not?”

If you’re not, he says, then who knows what you’re building toward.

I’ve been thinking about this conversation since we hung up. The technology changes, but the failure mode doesn’t. .com boom. Crypto. Now AI.

Same mistakes, faster.

The companies that survive these cycles aren’t the ones chasing features. They’re the ones who remember what the moat actually is.

It’s not the AI. It’s how easy you make it for humans to accomplish what they came to do.

Tom Shapland is the Product Manager at LiveKit. Rising to prominence in the 2010s by turning PhD research at the University of California, Davis into a commercial irrigation analytics company, he is now helping build an open source platform for multimodal, real-time voice and video agents used in production by developers across sectors. At LiveKit, whose open source stack launched in 2020 and underpins a cloud platform serving voice, video, and physical AI agents at global scale, he focuses on productizing ultra-low-latency infrastructure into practical tools for AI builders.

Previously, as CEO at Canonical AI, he built “Mixpanel for Voice AI,” an analytics platform that mapped caller journeys across thousands of Voice AI calls to show where and why agents failed, enabling developers to systematically improve conversion and reliability. Between 2023 and 2025, Canonical AI processed large volumes of agent call transcripts and latency metrics, giving Voice AI teams a single interface to debug failure paths and unlock additional call volume from enterprise customers.

His career highlights include founding and serving for 9 years as Co‑founder and CEO of Tule, a Y Combinator S14 company that commercialized UC Davis research into in‑field sensors that directly measure Actual Evapotranspiration (ETa) to guide irrigation decisions. From 2014 to 2023, Tule deployed research-based hardware and software across California specialty crops, with its sensors installed in commercial vineyards and orchards to quantify field‑scale water use and crop water stress, helping growers cut irrigation water use by material percentages while maintaining yields. In January 2023, CropX Technologies acquired Tule, adding its above‑canopy sensing technology to a global precision irrigation platform operating in more than 50 countries.

Rising to prominence in the 2010s as an influential figure at the intersection of agricultural science and data infrastructure, he has since translated that domain expertise into Voice AI analytics and now into real‑time multimodal agent platforms. He remains closely connected to the Y Combinator alumni ecosystem, leveraging over a decade of founder experience—from PhD research commercialization to post‑acquisition leadership—to mentor teams building the next generation of agentic AI products.

The Most Dangerous Advantage a Founder Has

Most people think that to start a company, you need experience. You want to know the pitfalls, the market dynamics, and exactly how the “game” is played. We vaunt experience as the ultimate shield against failure.

But Tom Shapland, a decade-long founder turned Product Manager, fundamentally disagrees. He argues that the most important asset he had when starting his first company wasn’t his PhD or his technical expertise. It was his naivete.

“The secret sauce I had is what every first-time founder has, and that is naivete,” Tom shared during our conversation. “You just don’t know how hard it’s gonna be. And you just think, oh, I can take on the world.”

Here’s the thing: experience is often just a collection of reasons why something won’t work. When you’ve seen a dozen startups fail in a specific niche, you stop looking at that niche. When you know how hard it is to build a sales motion in a legacy industry like agriculture, you don’t even try. But the first-time founder doesn’t know better. They haven’t been burned by the reality of the 10-year grind, so they walk into the fire with a smile.

Now, as a Product Manager at LiveKit—building the engine for the voice AI revolution—Tom brings a unique perspective. He *knows* how hard it is. He knows the luck involved. The challenge for the experienced operator is deliberately choosing to ignore those scars and find that same spirit of “delusional” confidence that made the first win possible.

We often talk about “Product-Market Fit” as a destination. But looking at Tom’s journey with Tule, it’s clear that traction isn’t just a metric; it’s an unblocker. Before he had a product, he couldn’t find a co-founder. He couldn’t find investors. He couldn’t find employees. It was only when he stopped building and started pre-selling—getting farmers to sign up for a product that didn’t exist—that everything else fell into place.

Traction unblocks the world. It’s the ultimate signal that your “side quest” is actually the main mission.

As we move into a world where we can simply talk to our computers—where English is the new terminal—the role of the builder changes. Whether you’re a founder or a PM, the job is the same: have the clarity of thought and the naive courage to ask for what shouldn’t be possible yet.

Previously, as Chief Product Officer and later Chief Technology Officer at Roblox, Lucas led the product and engineering organizations through one of the strongest multi-year growth runs in the company’s history, helping drive player and revenue expansion of roughly 300–400% year over year heading into 2016. He scaled the product organization from a single product manager and a small design and analytics group to a 30-person, data-driven team, while guiding engineering from bi-weekly releases to daily and weekly cadences across web and core client surfaces. During this period, he helped architect the platform’s shift to mobile-first growth, global game server distribution, and a more systematic approach to discovery and developer incentives, contributing to annual revenue that would later be reported in the billions of dollars as the company matured.

His career highlights include serving as Chief Operating Officer at Instrumental, an AI-powered manufacturing intelligence company where he helped the business grow its customer base across consumer electronics, automotive, and medical devices as revenue expanded by an order of magnitude in the wake of its Intercept product launch. Over two decades in technology, he has held senior roles across engineering, operations, and business, from early-stage leadership at Roblox to advisory work with startups in AI, gaming, entertainment, and enterprise software, bringing a portfolio of experience that spans platform infrastructure, creator ecosystems, and go-to-market strategy. Lucas holds a Ph.D. in Aeronautics and Astronautics from Stanford University and a Master of Public Policy from the University of California, Berkeley, a combination that underpins his analytical approach to building enduring, institution-scale teams.

As author of Impact: How to Inspire, Align, and Amplify Innovative Teams, he codifies a two-tier framework that helps leaders avoid stalled scaling, culture dilution, and loss of focus by treating culture as a system and leadership as a discipline. He now works directly with founders, CEOs, and executive teams as a trusted advisor, helping them design what he calls “engines of innovation” that can sustain compounding impact over decades rather than single funding cycles.

Listen on Spotify

Listen on Apple Podcasts

Innovative teams do not stumble into great products

They intentionally build engines of innovation in how they hire, promote, and operate day to day. Keith Lucas has seen both well run and badly run startups, and the pattern he cares about is deceptively simple:

Purpose-driven companies that adopt a long-term, institution-building mindset have a structural edge over those optimized for short-term financial wins.​

When Keith thinks about building entrepreneurial teams, he looks for five
“non-negotiables”:

1. Can this person elevate the team’s ability to create, innovate, or solve problems?

2. Do they align with the values? Do they want the same long term outcomes?

3. Do they believe in the mission?

4. Can they live with the team’s non-negotiable principles?

5. Do they meet the minimum standards of mastery and autonomy?

Teams that take those standards seriously quickly surface who needs too much handholding or who does not care enough about quality, because the realized culture will not support them.​

Here’s a practical nugget you can take from this episode today (though I recommend you listen to the whole thing, it’s one of the best episodes on leadership)

His favorite hiring and team staffing question for sussing out these non-negotiables is something I am going to steal:

The answer exposes intrinsic motivation, and great leaders use that signal to dial in roles so that enthusiasm, skill, and impact line up instead of grinding against each other.​

Underneath all of this is a simple thesis: if you want an engine of innovation, you need people who behave like mission athletes—mission driven, performance oriented, continuously growing, and elevating their peers—and you need to give them aligned autonomy instead of micromanaged checklists.

This episode is for builders who care about creating something enduring rather than chasing short-term wins, and who are willing to design their hiring, culture, and leadership practices to match that ambition.​