Listen to this episode on Spotify or Apple Podcasts

Paul Glover spent 30 years as “Mad Dog” — a Chicago trial attorney who would do whatever it took to win. That instinct carried him into 33 white-collar felonies and five and a half years in federal prison. He got out in his 50s with no law license and no network. Today his largest coaching client is a billion-dollar distribution company.

“I’m also a recovering lawyer,” Paul says, maybe thirty seconds into the call.

He lists it the way you’d mention a hobby. “I practiced labor law in the city of Chicago for 30 years. I’m also an ex-felon. I went to prison for five and a half years for committing white-collar crimes.” Then he keeps moving, smooth, like the prison sentence was one bullet on a résumé he’s read aloud a hundred times. “Got out in 2001 and decided, since I could no longer practice law, to start a coaching business.”

“Wow,” I say. And then again, because the first one didn’t cover it. “Wow.”

I’d come in with the question I usually save for people who’ve made a hard pivot — the one about limiting beliefs, about what they had to unlearn. I start to ask it. Paul cuts the frame out from under me before I finish.

“When you talk about limiting beliefs, I have a different term for it,” he says. “I call it blind spots.”

The distinction matters more than it sounds. A limiting belief is something you hold. A blind spot is something that holds you, and you can’t see it doing the holding.

“Everybody has blind spots,” Paul says. “They’re called blind spots because we don’t see them, but everybody else does. And every blind spot has a trigger attached to it, and if you don’t know what your trigger is and you don’t know what your blind spots are, you are primed to be manipulated by the world. You will not be able to choose your own course because somebody else will choose it for you.”

His own blind spot was the size of a courtroom. “I had an extraordinarily large ego. I truly believed I was the smartest guy in every room.” He’s not bragging when he says it — he’s diagnosing. The ego came from winning, and the winning came easy, and that was the trap. “Once you become successful, you start to live in your own echo chamber, and people will surround you in that echo chamber doing exactly that, continuing to tell you how good you are. At some point, you’ll believe it. Once you believe it, then you start to fail.”

At trial, they called him Mad Dog. “I would do whatever was necessary to win,” he says. “Unethical behavior was fine with me. I just looked at it differently.” He was good. He was also bored. A trial lawyer, he tells me, is an adrenaline junkie — a performer in a room with a referee and an opponent, and he loved the performance. The problem was everything between performances. “When you’re not at trial, when you’re doing preparation, that’s not adrenaline, that’s drudge, and I hated it. So I started to seek adrenaline, and I got it from my clients, who were not nice people, to be kind.”

They were criminals. Good ones. “Good grifters, they find your blind spots and your triggers immediately, and they pressed mine right away.” What they found was a man from a broken home who wanted to belong. They gave him a group. “But the initiation fee,” Paul says, “was committing crimes.”

He paid it 33 times.

There’s a scene he tells next that I keep turning over after the call ends.

Two trials. The first ended in a hung jury. The second convicted him. He’s standing in front of the sentencing judge, looking at seven years, and the judge offers him a deal — a way to cut the sentence by twenty percent. A year and a half, maybe two years, back. All he has to do is two things. Admit he committed the crimes. And help the prosecutor go after the men who committed them with him.

“And my answer to both of those was no,” Paul says.

He’s already convicted. He’s already going to prison. The math is not subtle — two years of his life, free for the taking. He turns it down anyway, and he tells me exactly why, and the why is the whole man in two sentences. “First, I could not admit I was wrong and got caught. Second, I could not give up the people who were in my group.”

The ego that made him a felon followed him all the way to the chair in front of the judge. The blind spot doesn’t care that you’ve already lost. It just wants to keep you from saying the words.

What broke it wasn’t the sentence. It was the traffic.

For the first two and a half years inside, Paul ran revenge fantasies. He was going to get even with everyone who put him there. He’d accepted no responsibility for any of it. And then he started noticing the men who’d already served their time and walked out — coming back. Returning. To prison.

“That shocked me,” he says, “because why would anybody wanna come back to prison? It’s a terrible place.” He’d watched freedom get taken from him without understanding what it weighed until he saw other men volunteer to lose it again. “When they started coming back, I realized that if I did not change, I was going to become a career criminal, because I would return to exactly the same situation I had left.”

He has a theory about this now, built from the inside. “If you have blind spots and triggers, something has to break the pattern, because otherwise there’s no reason for you to change.” For most people the something never arrives, and they stay the same until they die. For Paul it arrived as a turnstile of returning men, and it was enough.

Here is the part that should not work and somehow does.

A 50-year-old ex-felon walks out of federal prison with his law license revoked — thirteen years before he can even apply to get it back. He has, by his own accounting, narrow options and a personality that has never played well with others. So he reaches for the only tools he kept: he can tell a story, and he has failed at the highest possible level and survived it.

He decides to coach. But coaching, as it’s usually sold, makes him wince. “The concept of coaching, to me, always felt too soft,” he says. “And that’s not who I am, and therefore, that’s not how I could coach.”

What he reached for instead, he found in a book he read in prison. In medieval courts, the king was anointed by divine power, which meant challenging the king was heresy, which meant death. “The one exception to that was the fool,” Paul says. The jester in the gaudy outfit, jumping and dancing at the foot of the throne — we remember him as entertainment. He was something else. “Because they were seen as being crazy, they had an exception to the rule of being able to tell the king the truth. So that psychological safety allowed them to tell the king when they were behaving badly or making a bad decision.”

That, Paul decided, was the job. “I’m going to present myself as that person that cares enough about you to give you the gift of truth.” The branding wrote itself. The No BS Executive Coach isn’t a slogan about being blunt. It’s a man who spent 30 years living inside an echo chamber appointing himself the one voice in the room allowed to puncture someone else’s.

His first proof that it might work came as a reference, or rather two of them. Within two years of getting out, Paul asked a client to vouch for him. The client offered a choice. “He said, ‘The first one is, Paul’s an acquired taste, like cyanide.’” Paul laughs telling me this. “I said, ‘I don’t think I’m gonna use that one. Give me the second one.’”

The second one became his entire philosophy. “Paul is a Sherpa. He will get you to the mountaintop, but he will not carry your pack.”

He means it structurally, not just spiritually. Paul puts half his fee on the outcome. A one-year contract, goals set together, and if the year ends without those goals met, he collects only half his compensation. “I believe I have to have skin in the game,” he says. “If I don’t have skin in the game, then I’ll let you off the hook. If my money’s at stake, I’m gonna put my boot up your tail if you’re not doing what you’ve agreed to do.”

I tell him this is, whatever else it is, excellent positioning — clear about who he’s for and unbothered by everyone else. He agrees without flinching. “If you don’t like the taste, I’m okay with that. It’s not gonna work, I don’t wanna take your money, and I don’t wanna waste my time.”

He is not a life coach. He says this twice, in case I miss it. “I’m a performance coach. I get hired to improve performance, and I will push you to the edge. I will not accept mediocrity.” His clients are already successful — that’s the point, he says, that’s how they can afford him. The work isn’t getting them from struggling to fine. “Everybody can be high-performing,” he says. “That’s no longer the goal. The goal is you wanna be world-class. World-class requires a much different set of requirements and effort.” Most people stop short, comfortable, well-paid, respected. He calls that the comfort zone and tells them, gently, that they’ll never get better inside it.

I ask him what he actually sees when a new executive walks in the door. The answer comes fast, like he’s been waiting for the question.

“They are trying to do too much too soon to make that impression that they believe is necessary to convince the person who put them in the position it was the right choice,” he says. They don’t breathe. They don’t listen. They invent problems so they can solve them. Paul has a 90-day program he runs new executives through, and the first instruction is always the same: slow down.

“Start to talk to the people,” he says. Mine what’s already there before you decide what to build on top of it. Most new leaders got promoted for being doers, and now they’re suddenly supposed to lead — a different skill set entirely. The instinct to do more, faster, is the very instinct that will bury them.

Then he gets to the part I don’t expect. He talks about sleep. About exercise. About family time. “If you’re not gonna take care of yourself physically and mentally, I don’t want you in my program,” he says. He runs a monthly audit — a full 24-hour walkthrough of how his clients spend their time and energy. He wants to know where the hours go. Travel, he tells me, is the worst productivity suck in corporate life. And family gets sacrificed first, always. “People who are promoted sacrifice family first, and that is a short-term — just a — it’s an ignorant way to look at it,” he says. “Your family is your support base outside of work. They are the ones that you should care about more than the job, so don’t shortcut them.”

He advocates for two phones — work and personal — and for turning the work phone off. “That freaks people out,” he says, and something in his voice suggests he enjoys the freaking out. “There’s this thing called voicemail. You’d be shocked how it works.”

The mechanism underneath all of it is the same one that saved him in prison. Something has to matter more than your ego. Something has to break the pattern. “If you’re still self-centered, there’s no reason to change,” he tells me. “It’s when you suddenly realize the impact you’re having on others that gives you the necessary strength to break the pattern.” For his clients, that something is usually their family. For Paul, it was the men coming back through the gates.

I ask him why the people at the very top — the ones who answer to no one but a board — are the ones who hire coaches. He gives me the line that reframes the whole conversation.

“The more successful you are, the more you need a coach.”

Then he reaches back across two thousand years for the picture. A conquering general gets his parade through Rome, the loot and the prisoners marched in front of him, the general himself in a gold chariot behind six white stallions. And riding in the chariot with him, the entire length of the procession, a slave. The slave has one job. “To continually whisper in the general’s ear,” Paul says, “’You are but a man.’ Because that type of success will overwhelm you and start to convince you that you are more than a man, and that means you think you’re infallible.”

That’s the chariot Paul rode for 30 years with no one whispering anything. The echo chamber had no slave in it. Everyone in there told him he was the smartest man in the room, and eventually he believed them, and then he committed 33 crimes and told a judge he’d done nothing wrong.

So he built the thing he never had and rents it out by the year. The man who could not say I was wrong to save two years of his own freedom now makes his living saying it for other people, before the parade, while there’s still time to climb down from the chariot.

It’s an acquired taste. He’s the first to tell you. He’s also, somehow, the only one in the room allowed to.

Guest Bio: Paul Glover

Paul Glover is the No BS Executive Workplace Coach at Paul Glover Coaching, where he works with C-suite leaders and high-performing executives across the United States on performance, accountability, and organizational resilience. Rising to prominence over more than two decades of coaching work following a complete professional reinvention, he became known for a performance coaching model built around blind spots, outcome-contingent fees, and a refusal to allow clients the comfort of self-deception. His largest active client is a billion-dollar distribution organization.

Previously, Glover spent 30 years as a labor employment trial attorney in Chicago, earning a reputation as an aggressive courtroom litigator. His legal career ended in 1995 when he was indicted on 33 counts of white-collar crimes — including kickbacks, bribery, and tampering with government witnesses — and subsequently sentenced to federal prison. He refused to cooperate with prosecutors to reduce his sentence, and served approximately five years before beginning what would become a second career launched from scratch in his fifties.

Released in 2001 with his law license revoked and ineligible for reinstatement for 13 years, Glover rebuilt entirely as a coach, eventually building a national practice. He structures his engagements as one-year contracts with 50 percent of his fee contingent on clients achieving mutually defined goals — a model designed to give him skin in the game and eliminate the incentive to let clients off the hook. His coaching approach draws directly from his own reckoning with ego, echo chambers, and the moment accountability finally broke through.

Glover is the author of WorkQuake™, a book on surviving and thriving in the Knowledge Economy, praised by executive coach Marshall Goldsmith as agitating “the business status quo.”

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

I ask Joshua Altman what the first ninety days look like when a company hires him, and he does something I don’t expect. He doesn’t talk about audits or deliverables or brand guidelines. He tells me to get a piece of paper.

“Divide it into story, narrative, brand,” he says. “Write that stuff down for your company.”

He makes it sound simple. Three columns. But then he starts explaining what goes in each one, and I realize the exercise is a trap — the kind of trap a good diagnostician sets, where the patient discovers the problem by trying to describe it.

Story, he tells me, is what you tell your friends at the bar. It has characters, setting, situation. A beginning, a middle, a present — not an end, because “we’re still telling this story.” It’s largely unstructured. This happened, then that happened, and on the way there someone got a phone call. Story is the stuff.

Narrative is harder. Narrative answers questions. “What are we saying about who we are? How do these events connect to our themes? And what should people conclude from our connected stories?”

He lets that last one sit. What should people conclude. I write it down because it sounds like the kind of sentence that reorganizes a company if the founders actually try to answer it.

And brand — brand is everything else. “It’s logos, it’s the website, it’s social media handles,” he says, and then he keeps going past the things I expected. “Your product packaging is part of your brand. If you’re a physical retailer, the music you play is part of your brand.” Giveaway pens. Customer interactions. The whole surface area of contact between a company and the people it touches.

The framework sounds clean when he lays it out like that — three layers, each building on the one below it. But the reason companies call Joshua is that they’ve been building from the top down.

“People call us at the brand stage when they really haven’t figured out the story and the narrative yet,” he says. He’s not frustrated when he says it. He’s diagnosing. “Which makes it much harder to effectively communicate that brand, because if narrative is connecting things to our theme, it’s what people should conclude — brand builds on that.”

I think about all the startups I’ve worked with. The ones that came to me with a polished deck and a hollow center. They had logos. They had color palettes. They had a website that said all the right things in all the right fonts. And when you asked what people should conclude from the company’s existence, you got a silence shaped exactly like the one Joshua is describing.

He tells me about the second framework, the one he layers on top of the first. He calls it the Four Languages Model. “What people read, see, hear, and experience.”

Read is intuitive — text on a page. See starts broader — visuals, video, infographics, signage. Hear is where it gets interesting. “It’s that in-store audio experience where they’re putting a lot of investment right now,” he says. “It’s if you do a branded podcast, if your leadership goes on podcasts.” And then experience, the one that trips people up.

“People tend to think it means big experiential events,” he says. “It does. That’s one part of it. But then there’s also how people experience what they read, see, and hear.”

He gives me the example that makes it click. “We are having the same information,” he says, meaning this podcast, this conversation. “We’re listening to the same conversation, but we have two very different experiences.” Someone listening while walking the dog. Someone watching the video. Same words, different encounter. He extends it to product: “Mobile versus desktop interactions, or app, native app, versus the web browser version on a phone. Two very different experiences with the same product.”

I come from product design and management, and I recognize this immediately — it’s user experience thinking applied to communications. But I’ve never heard anyone frame it as a language. Not a channel, not a medium. A language. The implication being that each one has its own grammar, its own rules for how meaning gets made.

I want to see what happens when the framework meets a real company, so I ask him to walk me through a client engagement. He doesn’t give me a name, but he gives me the pattern.

“Most have to wrestle through it a little bit,” he says, “because they haven’t really thought about it as much.” The problem he keeps encountering is a gap between intent and perception. “What we might be saying, people are coming in cold, we don’t know about your company yet. What we conclude might be very different than what you are intending for us to conclude.”

And then the harder version. “Especially when we’re dealing with founder-led companies,” he says. “It might actually be called Smith Corp., where that founder really has a strong tie to it. There could be a lot of pushback. It’s their baby.”

I can hear the diplomacy in how he phrases that. He’s describing a situation where he has to tell someone that the thing they built — the thing they named after themselves, the thing they’ve been explaining to investors and friends and their mother for two years — is sending a message they didn’t intend. The narrative they think they’re telling is not the narrative people are receiving.

“Narrative is the hardest part of the whole structure,” he says, “because it has to answer questions.” He pauses. “People can go and AI themselves a logo. You can pull a website off the shelf of a template, and even now, AI fill in the blanks for me, make it look pretty. Narrative’s a lot harder. It requires you to really look internally at what you’re doing, because you’re asking to make connections, and that becomes a lot harder.”

This is the sentence that earns the headline. The reason most companies call at the wrong stage is that brand is the layer you can buy. Story is the layer you already have, whether you’ve articulated it or not — it’s the stuff that happened. But narrative is the layer you have to build, and building it means sitting with questions that don’t have comfortable answers. What are we actually saying about who we are? Not what do we wish we were saying. What are we saying.

He uses Apple to show me what it looks like when a company has done the work. Not the obvious Apple — not the keynotes or the product launches, though he gets there. He starts with a detail I’ve never heard before.

“The direction the Apple logo appears when the laptop is closed and facing you,” he says, “was a huge debate within Apple.”

I know he can tell I’m interested, because he keeps going. “That might sound inconsequential, but it’s actually very important, because once you flip the screen up, that’s what everyone in the world sees if you’re sitting in a coffee shop.” The logo serves two audiences. Toward the user when closed, it tells you which way is up. Toward the public when open, it’s an advertisement. Apple went back and forth on this “over periods of product release.”

What I hear in that story is a company where brand decisions go all the way down to the hinge. That’s what happens when narrative is resolved — when you’ve answered the question of what people should conclude. Every subsequent decision becomes easier, because you have a principle to decide against. The Apple logo debate wasn’t about a logo. It was about who the laptop is for in the moment it’s being seen.

I bring up David Bowie, because Bowie is the version of this I think about most. A musician who made a chart-topping album every decade by intentionally reinventing himself. Different look, different sound, different era — but always, unmistakably, Bowie.

Joshua takes the example and turns it corporate. “You can’t get too far ahead, you can’t be too far behind,” he says. The trick is knowing “where to inject yourself as a company, as a business. You don’t have to be on, talking on every topic, because you can’t.” He tells me brands do periodic refreshes the same way Bowie did reinventions — deliberate, timed to the culture, but rooted in something consistent underneath.

“These things can change over time,” he says. “What you’re saying was your narrative when you started two years ago might not be the exact same narrative today, because it will change. It should change if you are doing things right.”

I ask him the thing I suspect a lot of founders are afraid to hear: does that mean abandoning what they started with?

Not quite. “Those core things might not change,” he says. “But a lot of what you do and what people might need to conclude will, and that’s just a natural part of your business growing and being more successful.”

He gives me the Amazon version. “When Amazon was just selling books, he was selling books out of the trunk of his car and putting them in the mail, no one was asking him about the gas mileage of his car.” Now they run Amazon Logistics, and environmental stewardship is something a lot of people care about. The story changed. The narrative had to change with it. The brand followed — not led.

Near the end of the conversation, I try to name the through line back to him. “There’s a ton of things that happen before brand,” I say. “Branding gets a lot easier when you’re very clear on how you’re positioning yourself, how you’re deciding to show up.”

He agrees, and then says the thing I think a lot of companies need to hear but won’t find in any branding deck.

“Sometimes you just have to get something live. It has to go up. You have to start somewhere. And it might not be the prettiest, it might not be the best, but it’s getting something out there.” Fifty percent of what you want, he tells me, is fifty percent more than nothing. “You can always change it. You can grow, you can iterate.”

And then: “We say all the time, there’s no content police.”

He means it literally. There is no authority that will penalize you for experimenting in public, for changing your colors, for posting more or less, for trying something and pulling it back. The only people who can tell you whether your narrative is working are the people receiving it, and the only way to find out is to put it in front of them.

I tell him it reminds me of comedians testing material. The hour-long Netflix special where every joke kills — nobody sees the thousands of hours in dive bars that got it there. “They’re testing out their jokes,” Joshua says. “They’re seeing what works, because the only way to do it is in front of a live audience, because they need to know — does this bomb?”

He’s describing narrative development as a live process, not a boardroom exercise. The comedian doesn’t write the special and then perform it. The comedian performs fragments, reads the room, rewrites, performs again, and the special assembles itself from what survived. That’s what narrative work looks like for a company too — if the company is willing to do it in front of people instead of waiting until everything is perfect.

The piece of paper Joshua told me to get at the beginning — story, narrative, brand, three columns — is still sitting in my head. I think about how many founders would fill in the brand column first, because brand is visible and concrete and feels like progress. How many would leave narrative blank, or write something that sounds like narrative but is actually just story wearing a suit. And how the ones who do the hard work of filling in that middle column — what are we saying about who we are, how do these events connect, what should people conclude — end up with a brand that doesn’t need to be explained. Because the explanation is already built into the structure underneath it.

Joshua started as a news producer, carrying fifty pounds of gear into assignments that a phone handles now. He left journalism thinking he’d go back. Instead he found companies that needed what he’d spent years learning to do — not the gear, not the software, but the ability to look at a set of facts and decide what story they tell, what narrative they support, and what the audience should walk away believing.

The tools changed. The question didn’t.

Guest Bio: Joshua Altman

Joshua Altman is the Founder and Managing Director of Beltway Media, a Washington, D.C.-based communications firm that provides fractional chief communications officer services to technology companies and startups. Rising to prominence over more than two decades in strategic communications, he became known for his Story-Narrative-Brand framework and Four Languages model, which help organizations align what people read, see, hear, and experience into a coherent communications strategy. His client roster spans scrappy startups to federal agencies including the U.S. Department of Justice and U.S. Department of Commerce.

Previously, Joshua served as a multimedia journalist at The Hill, where he covered federal policy across energy, healthcare, immigration, defense, and criminal justice, and reported from the front lines of multiple high-stakes election cycles. His background as a news producer — shooting, editing, and cutting four to five videos per day — gave him the operational reps and editorial instinct that now underpin his consulting work.

Joshua holds an M.A. in Communication, Culture and Technology from Georgetown University and a B.A. in Journalism and Mass Communications from The George Washington University. He is a member of The Telly Awards Judging Council and publishes The Comms Chief on Substack.

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

Adam Spector has a wonderful executive assistant. He wants me to know that before he tells this story, because the story sounds ruthless if you don’t know that part first.

“I have a wonderful EA,” he says. “She — I’ve gone through a lot of EAs ‘cause I’ve had a lot of bad EAs, but I have a great one now.”

The great one does a lot of work that involves pulling data from a few different places and centralizing it so Adam can see what his day looks like — meetings, messages, the information a founder needs to absorb before the morning gets away from him. Copy, paste, organize, surface. Useful work. Work that keeps things running.

And Adam told her he was going to automate it.

“I told her a long time ago,” he says. “’I’m gonna probably automate this because it’s something that I don’t think you need to do. It’s a low quality use of your time.’” He didn’t fire her. He didn’t even reassign her. He just built the thing. Had an AI pull all his messages and information and move it to the right place. The work she’d been doing by hand, done by a system he created himself.

Then he says the sentence I keep turning over for the rest of the conversation.

“I would argue she should have built that herself.”

He doesn’t say it with cruelty. He says it the way a coach says you had the open lane and you didn’t take it. The opportunity was visible. She knew the roadmap — he’d told her what was coming. If she had built the automation before he did, she would have owned the product. It would have been her system, running on her logic, something Adam depended on without fully understanding how it worked. Instead, he built it, and now the work is off her plate permanently.

“This is sort of the creative destruction — disruption theory, right? You need to disrupt yourself before your competitor does.” He pauses. “The moment I disrupted it for her, that’s now off her plate, and it’s not gonna come back because I’ve now built it. I’ve disrupted her.”

I ask him to hold that thought, because I want to understand where this intensity comes from. A man doesn’t build a company called Chore — a company that literally does other companies’ back-office work for them — unless he’s been burned by the alternative.

He has.

Adam Spector is a four-time founder who has invested in over two hundred companies. He was a product manager at Twitter. He hosts the Entrepreneurial Excellence Podcast. And when I ask him why he started Chore, the answer isn’t a market thesis. It’s a confession.

“That’s literally why Chore started,” he says. “I experienced this pain myself.” In his previous companies, the pattern was always the same: his technical co-founder went to build the product, and Adam was tasked with running the business. Payroll. Compliance. Taxes. “Or,” he says, “I could spend my time making sure our go-to-market is flawless, making sure we’re getting more customers.”

He couldn’t do both. Nobody can. But the trap is that the operational work feels productive — you’re checking boxes, filing things, keeping the lights on — while the strategic work feels risky and uncertain. So you do the safe thing, and your company dies slowly because nobody’s selling.

I tell him my own version. I tried to run a consulting side hustle and decided I could recreate the accounting software myself. Before AI, even — just stitching tools together. “I ended up spending most of my time doing bookkeeping, and it was distracting from sales,” I say. “That’s the reason that business failed.”

He nods, but he wants to reframe it. “I would actually put it differently,” he says. “You can’t save your way to the future. You need to invest in things.”

He gives me the financial version: money in a bank account versus money in the S&P 500. One earns effectively zero after inflation. The other compounds at ten percent a year. Saving feels responsible. Investing feels risky. But the saver’s money is shrinking, and the investor’s money is working. “It’s the same thing when I invest in spending it on making my podcast better or making my team better,” he says. “Don’t be penny-wise and pound-foolish.”

This is where the conversation turns from operations advice into something sharper. Because Adam isn’t just talking about founders who do their own bookkeeping. He’s talking about employees — specifically, the ones who think their job is to wait for instructions.

“If you wanna sit back and have your manager tell you what to do,” he says, “show you someone who’s gonna be unemployed soon.”

The line lands hard enough that I want to push on it. He pushes further.

“If that is the mindset that you have, would anyone ever promote you?” he asks. “Why do you think you’re owed some promotion ‘cause you’re able to sit in a seat and do some work?” He’s talking about product managers, specifically — I’d mentioned that I hear PMs say it’s not their job to understand how their product works. He says it like he’s stating something obvious. “This is why you won’t have a job in a year.”

What he’s describing is a world where curiosity is no longer optional. Not curiosity as a personality trait — curiosity as a survival mechanism. “The more curious you are, the more questions you ask, the better you will do,” he says. “The more the company will say, ‘This person’s critical for our business.’” And the tools to act on that curiosity are free. He calls Claude Code “the best product managers of all time” and means it literally — a PhD in your pocket, ready to solve whatever you point it at.

“All I need is to have curiosity and a willingness to spend some time to do it,” he says, “and I can get anything I want out of it.”

I bring up the cost of agency. There’s a framework I’ve been thinking about — the most valuable commodity shifts across eras of human history. In the Middle Ages, it was security. During the Industrial Revolution, it was capital. In the information age, it was data. Each era had a ruling class built around whoever controlled the scarce resource. And now the price of agency itself has collapsed. You can exercise agency for free. Ask an AI to explore a problem, get a first draft, form a point of view — all before your manager even knows the problem exists.

Adam takes that and sharpens it. “There is no excuse to say, ‘Hey, I already did my own version of this and I checked it. Here’s what I think is the right choice,’” he says. The old workflow was receive problem, pass it to a teammate, wait for the answer, relay it upward. The new workflow is receive problem, take a first pass with AI, arrive with a recommendation. “My manager’s gonna do the same darn thing,” he says. The implication is clear: get there first.

He tells me about an article he read that morning — a factory in Connecticut shutting down, the last manufacturing plant in a town that used to be built around these factories. Moving overseas, cheaper labor, better technology. His take isn’t sentimental. “There’s no reason why you can’t manufacture great things in America,” he says, “but you need people with the right attitude and mindset to go do it.” The workers, he suggests, were protected by unions and fought change instead of asking the harder question: how do we get better at this than the alternative?

“If you are fighting progress,” he says, “you will lose in the end.”

I sit with that because it’s blunt in a way that most people in my world won’t say out loud. The version I hear in product circles is gentler — we need to upskill, we need to adapt. Adam’s version doesn’t have the padding. Learn the new thing or lose. Adopt the tool or become replaceable. There is no third option where you get to keep doing it the way you’ve always done it and everything turns out fine.

“It’s imperative to have a point of view,” he says near the end of our conversation, and this is the line that reframes the whole thing for me. It used to be expensive to have a point of view. Before AI, forming a strategic opinion on something outside your core job meant not doing your core job — and if you were wrong, you were exposed. Now the cost is nearly zero. You can build a prototype instead of scheduling a meeting. You can run an analysis instead of requesting one. You can arrive with a recommendation instead of arriving with a question.

“If you aren’t bringing your unique perspective,” Adam says, “then why don’t I just have AI do it? What am I paying you as a human for?”

The EA story keeps coming back to me. Not because it’s cruel — Adam kept her on, moved her to higher-value work, made clear he wasn’t replacing her. What makes the story stick is the missed window. She knew the automation was coming. He told her the roadmap. The system she could have built and owned, the system that would have made her irreplaceable, was sitting right in front of her. Someone else built it instead.

“The people who disrupt themselves,” Adam says, “will be the ones who stick around long term, because they’ve now owned a key product that I didn’t build.”

That’s the offer and the threat compressed into a single sentence. Build the thing before anyone asks you to. Own it before someone else does. The price of curiosity has never been lower, which means the cost of not being curious has never been higher.

Guest Bio: Adam Spector

Adam Spector is the Founder and CEO of Chore, a back-office operations company that handles HR, finance, compliance, and equity for venture-backed startups. Rising to prominence as a 4x founder and investor in more than 200 startups since 2011, he became known for his conviction that founders should spend zero time on undifferentiated operational work. Under his leadership, Chore has grown from 7 to more than 40 team members, serving hundreds of venture-backed companies across the United States.

Previously, Adam co-founded AbstractOps, which raised approximately $10 million from tier-one venture capital firms before pivoting in 2022, with its operations arm spinning off to become Chore. Across his earlier three venture-backed companies, he raised a combined $30 to $40 million in funding, with one company acquired for $400 million. He also served as a Product Manager at Twitter before turning full-time to founding and investing.

Adam holds a JD/MBA and a degree from Vanderbilt University. He co-founded the Autopilot Fund, an investment vehicle focused on AI-related data sets, and hosts the Entrepreneurial Excellence Podcast, where he interviews founders on the operational realities of building companies.

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.

Steve Jobs Became a Billionaire Through an Animation Studio

He bought a small graphics company from George Lucas for $10 million and poured in close to $50 million more — over half his net worth at the time. What made Pixar work wasn’t the technology; it was years of relentless pre-production before a single frame got animated. Jobs carried that operating model back to Apple, and it’s the same one quietly running the most valuable companies today.

In November 1995, Toy Story opened, Pixar went public, and by close of the first trading day Steve Jobs was worth about $1.17 billion on paper. I don’t think people realize that Steve became a billionaire through an animation studio. Not a computer company. Not a software play. An animation studio he’d bought from George Lucas for $10 million a decade earlier and then poured close to $50 million more into — over half his net worth at the time.

It’s incredibly hard to become a billionaire in tech. Harder in the movie industry. And that detail reorganized how Jobs spent the rest of his career.

Ten years earlier, 1985. Jobs is thirty, freshly exiled from Apple, sitting on a hundred-million-dollar windfall from selling his shares. He starts NeXT. He buys a small computer graphics division from Lucasfilm. The graphics company bleeds money for years. But something else is happening inside it.

John Lasseter, a former Disney animator disillusioned by the waste of the big studio system, placed an intense focus on relentless iterative pre-production before a single frame was animated.

The method was called a story reel — rough cuts of the film voiced by the animators themselves to test narrative with their peers.

Lasseter called the process “story reboarding” because they didn’t do it once. They did it over and over, screening every few months for a brain trust of senior creatives who gave candid feedback. If the narrative wasn’t working, they went back to the script.

This could take two or three years. Before a single actor was hired for a multimillion-dollar retainer. Before a single frame was animated by Ed Catmull’s engineering team.

It turns out it’s cheaper to make prototypical movies with a small staff of elite creative talent over many years than it is to jump straight into the cost of a six-month production with a bad script.

Jobs stayed mostly out of the day-to-day operations, but by watching Catmull and Lasseter he witnessed a completely different approach to creating world-class products. The principle was simple and non-negotiable: you don’t start production until the narrative is undeniable.

That company became Pixar.

So in 1997, when Jobs returned to Apple as its CEO — ninety days from bankruptcy — he immediately tears everything down and rebuilds how decisions get made. The operating style looks remarkably similar to how he and the team at Pixar worked. And honestly, if I made a billion dollars working this way, I would do it at every company I went to.

At Apple, they didn’t debate ideas. They debated artifacts.

Getting in a room and selling your idea wasn’t part of the culture. Every major feature started as a demo, and for a demo to be useful it had to be concrete and specific.

The iPhone keyboard — they used a device called a Wallaby connected to a Mac to test out the autocomplete function. Just enough to test the interaction and get signal.

When demos went poorly, there was the same stream of constructive criticism, but there was never finger-pointing. The expectation was that there would be a follow-up demo, and the new demo would include a response to the feedback from previous demos. The one essential demo expectation: progress. (Ken Kocienda)

“We always started small, with some inspiration. We made demos. We mixed in feedback. We listened to guidance from smart colleagues. We blended in variations. We honed our vision. We followed the initial demo with another and then another. We improved our demos in incremental steps. We evolved our work by slowly converging on better versions of the vision. Round after round of creative selection moved us step by step from the spark of an idea to a finished product.”
— Ken Kocienda, Creative Selection: Inside Apple’s Design Process During the Golden Age of Steve Jobs ​

Tony Fadell said each team used internal heartbeats — aggressive prototype deadlines to force learning cycles. Tight deadlines force focus. It’s hard to make an end-to-end complicated workflow when you’re given two days to make the next demo.

The demos went through multiple rounds of review and phase gates, progressively moving up the org chart until a final gatekeeper — usually a VP — decided if it was ready to be shown to Steve.

Every feature would eventually make it to him. And he decided which features got greenlit to go to production.

Within two years, this operating model put Apple back in the black. Within the next ten, they became one of the world’s most valuable companies. What had worked for a small animation studio — don’t start production until the narrative is undeniable — now ran the largest corporation on earth.

At Steve’s memorial service, Jony Ive eulogized: “Steve loved ideas and loved making stuff, and he treated the process of creativity with a rare and wonderful reverence.”

The principle had scaled. Not because Steve was a genius who couldn’t be replicated, but because it was an operating model. The creative process treated with reverence. Artifacts over arguments. Pre-production before production. An operating model can be copied.

Brian Chesky heard a version of this story and it reorganized his company.

Before the reorganization, Airbnb was already in trouble. The brand was being tarnished by poor customer experience, random features, and a fractured narrative. Chesky had been doing things the “right way” — the product model, empowered teams — and it wasn’t working. The more people they hired, the more projects they ran, the less the product actually improved, and the more the cost went up.

Chesky had the privilege of being mentored by Jony Ive. One day, while venting to him, Jony showed Brian that Apple was run like a studio. Small number of focused bets. One roadmap of focused products. Designers as architects. A CEO who treated the company itself as a design problem.

Brian said: “I had forgotten about the magic of this design renaissance that Steve Jobs had created at Apple. Everything I was taught about how you run a company was opposite of how Steve ran Apple.”

He made his decision. He wasn’t going to apologize anymore for wanting to operate his company his way. He spent the following years reorganizing Airbnb around these operating principles — principles that treated the creative process with reverence and gave space for the best ideas to surface. One lineage. One idea about how the best creative work gets made. The first movie they greenlit was rebooting the core Airbnb experience. They divested from everything else. No more multiple roadmaps, no more each executive owns their own thing.

By 2025 they reported $12.2 billion in revenue, $4.6 billion in free cash flow. Brian said that’s more free cash flow per dollar earned than Apple or Google — and they did it by not trying to make money. They did it by focusing on the core experience and focusing on one thing: narrative.

This isn’t a personality cult. It’s an operating model. Operating models can be copied.

But I’m not running Airbnb.

Back in 2023, I attempted to operate this way before AI made it cheap. I was doing hybrid design and PM work. I reported to the CTO, and I gained a reputation for getting big projects done and quickly building trust with engineers. But I was doing two jobs, and it was brutal.

Eventually I threw in the towel. I told my CTO I was open to making the switch to one of the full-time roles, and because I wanted to stay strategic and support the design team, I switched to PM full-time. At first it was great — suddenly I had more time to be on top of my responsibilities. But over time, the job became mostly blocking and tackling. Alignment meetings. Decision docs. One-pagers. PRDs. None of these meetings led to meaningful outcomes. Nobody was reading the docs.

I was depressed, and I discovered firsthand that getting in a room and talking it out isn’t a strategy.

Then Claude Sonnet 3.5 came out. AI suddenly got really good at writing, and I started experimenting. I set up a project instruction that said, “You’re my ghostwriter. Don’t make up content. Just interview me, then write the one-pager.” In a tenth of the time, I was creating memos that gave clear descriptions of my intent. I started using Granola for meeting notes, and my mental bandwidth freed up. Suddenly I had time to work the way I wanted to work — to craft my own narrative of what I thought the product should be.

So I immediately started making demos and getting them in front of stakeholders and customers.

One day I was shadowing another PM on a customer call. His demo was not going well. The customer was in the wrong segment. The prototype had nothing to do with her job. The interview was dying. I messaged the PM on Slack: “When you’re done, can I have a few minutes at the end?”

I spent the next five minutes pulling up that customer’s actual data and loading it into my prototype. He hands the mic over to me. I send her a link and she opens it.

“This is nice. Wait — is this my data? Are these my customers? I can see all these invoices? Yeah, this is what I’ve been asking for. When are you gonna make this?”

The customer sold herself because the prototype had her data, her workflow, her problem. The narrative was right, I understood the problem, and the artifact proved it. From that moment on, I knew I was never going back.

AI didn’t change the game. It changed who could play.

Making demos at the volume and speed required to discover the right narrative used to be psychologically and operationally brutal. It involved overcoming apprehensions about committing time and effort to ideas you aren’t sure are right, exposing rough work to colleagues who level pointed criticism, knowing that almost all demos fail in the dead-end sense. Remember when it took two weeks to make a janky Figma prototype just to test one idea?

It isn’t anymore.

I did five full prototypes of an AI-native workflow in five weeks — with backends and everything. The first three, I couldn’t get them to work. Threw them away, and it didn’t hurt to throw them away because AI did the grunt work to set them up. By the fourth, I was getting interest.

By the fifth, two VPs were offering me engineers. Developers were asking to join. target users sold themselves mid-demo. My demo was greenlit and officially on the roadmap. Not a single PRD written. It wasn’t talked about in an off-site. It happened because you don’t need to ask permission to do this kind of work.

The artifact argues better than you ever could. Leadership just means you have followers. As long as it works and it’s exciting, people will follow you.

There’s one objection left, and it’s the real one.

“That’s great, Caden, but you’re technical. You know how databases work. How am I supposed to make demos if I studied graphic design?”

So let me tell the story of Jeremy Fry.

Fry made his fortune selling motorized valves for industrial pipelines. But he was not a pipeline man at heart. He was a builder of things that didn’t exist yet. He discovered a promising young talent from a local university and took him under his wing.

One day, the young man went to tell Jeremy about his amazing idea — likely looking for advice, maybe fishing for a compliment, secretly hoping to impress his mentor. Jeremy didn’t ask for a plan. He didn’t ask for a sketch. He pointed to the workshop. “You know where it is. Go and do it.”

At some point they needed to weld something. The young man didn’t know how to weld. He asked if they could hire a welder. Jeremy didn’t blink. He pointed to the welding equipment. “There’s the welder. Go weld it. Figure it out.”

He suggested they bring someone who knew about hydrodynamics just to be sure. Jeremy pointed at the lake. “The lake’s down there. The Land Rover’s over there. Take a plank of wood, drag it through the water, and look at what happens.”

The young man Jeremy took under his wing was James Dyson.

Dyson studied art. Not engineering. Not physics. Art. His first cyclonic vacuum cleaner was built from cereal packets and masking tape. He didn’t fully understand the physics behind it yet. He built it first and learned second — roughly ~5,000 prototypes over five years, before the internet, before AI. And now he owns one of the world’s most impressive engineering companies, employing over ~4,000 engineers and designers.

The credential did not make the invention. The obsession with the narrative did.

Dyson said: “After the idea, there’s plenty of time to learn the technology.”

The companies and the people in these stories share one operating principle. They didn’t start with the best tools. They didn’t start with the right credentials. They started with a narrative they believed in and then iterated relentlessly — in pre-production — until the narrative was undeniable. Then they let the artifact argue for them.

AI has given everybody a camera. It can write the PRD, make the design, ship the code at the median professional level. So why is success still concentrated? Because the best filmmakers spend their time on everything that happens before the camera turns on. The concept. The framing. The narrative. The sequencing. By the time they go into production, the movie has already been made on paper.

It was never about the camera. It was always about the person willing to stand away from it long enough to find out what the story was.

Diagram: My AI Native Design Process

About: Caden Damiano

Caden Damiano is a software designer and product manager who has spent his career untangling problems in industries most people overlook — tertiary finance, real estate technology, working capital for agriculture, and financial operations for small and mid-size businesses. He hosts Way of Product, a podcast and Substack newsletter where, over eight years and 180+ episodes, he has interviewed designers, PMs, and engineers about how good work actually gets done.

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.

I ask Adam a hypothetical, the kind that almost always gets a hedged answer.

Could he have started Pentane — his profitability operating system, three years in, used by e-commerce founders to figure out whether they’re actually making money — if he hadn’t spent the decade before it running BottleKeeper?

“Absolutely not,” Adam says. “No way.”

No throat-clearing. No “well, probably not, but you could argue.” Just the flat refusal. He says it the way you say something you’ve already considered from every angle and stopped re-litigating. The certainty is the kind that only comes from having tried to imagine the alternative and failed.

Pentane is a profitability OS. The phrase sounds modular and abstract, the kind of thing pitched at a SaaS demo day. But the actual product is something simpler than that: it answers the question most e-commerce operators don’t have a clean way to ask, which is whether the next ad dollar makes them money or loses them money, and why.

Adam built BottleKeeper from 2013 onward — a beverage insulator brand that grew from zero to $60 million in total sales and exited via private equity. He lives in Montana, does hard physical things in the woods because he believes adversity is a muscle you have to train deliberately. He’s been on Shark Tank. He has the operator’s posture of someone whose CV is mostly stories about the hours nobody filmed.

The Pentane thesis is that he could not have built Pentane any other way. Not on a whiteboard. Not from market research. Not from talking to other operators. Only from being the operator who’d run out of answers.

“I was CEO of a company with no employees doing $8 million a year,” he tells me, and the line lands without performance. He isn’t bragging. He’s establishing the conditions. “I literally did everything — all the customer service, all the paid ads, built the campaigns, spent millions in ad budget, did the creative, built the website.”

He qualifies it a beat later. “My cousin and I — he was my partner, he did most of the finance and shipping and fulfillment and things like that.”

Two people. Eight million in revenue. The math of that is the whole story.

The Facebook video ads moment came in August 2014. Adam shot a video of the product in action — the kind of thing that, in retrospect, was the inflection. Revenue went from two thousand a month to forty to sixty to eighty to a hundred and fifty.

“We sold out of product and we just chased that for years,” he says.

In those first three years he didn’t need systems. He couldn’t spend the ad money fast enough. The growth was hosing him down. WordPress, then WooCommerce, eventually Shopify. The systems were unnecessary because the problem was unaddressed.

Then 2016, 2017. CPMs going up. Returns coming down. He saw it the way anyone in paid media that window saw it — the loose-attribution years closing, the spreadsheets getting more honest. He was about to hire his first team member. The slack in the business was disappearing.

“I needed to get a much better handle on the decisions I was making around what to spend, how much to spend, where to spend it, how it needed to return in order for us to be profitable,” he says. “’Cause we had to be profitable. And what happened if we ran a sale, or what happened if I increased prices — which is something we did really aggressively. And then as we hired people, how was I going to ensure that our customer acquisition and revenue was built in a way that could pay for those people, so we weren’t just spending into a hole.”

The math didn’t exist anywhere he could find. So he wrote it. In spreadsheets, for himself, as the CEO who had nowhere else to send the question. He was answering questions, he tells me, that he “couldn’t find answers to anywhere else.”

That’s the part most product-origin stories skip. Adam didn’t start by trying to solve a market. He was trying to not run out of money. The spreadsheets weren’t a product. They were a way of staying alive.

The company sold. A year after the acquisition, he got bored.

“I went to companies I had invested in and asked if I could help,” he says. “Realized they had the same problems. They just didn’t have the system to help solve the problem and answer the question. So I just rebuilt what I had already done in them and it completely changed them.”

That’s the moment the survival math became a product. Not because he had a vision. Because three founders he respected were drowning in the same way he had been, and his hand-built thing pulled them out.

“I built the thing because I had to,” he says when I ask him to describe Pentane’s actual genesis. “Because I had companies that were using it and it dramatically impacted their net profit outcomes.”

The genesis is causal, not creative. He didn’t have an idea. He had a discovery.

He keeps coming back to the way finance and marketing speak different languages — that gap is where companies bleed. Pentane lives in the gap. The math is provided by the system; an AI layer applies Adam’s mental framework to the operator’s specific situation. The equations don’t come from the model. The model isn’t allowed to invent them.

“It can do math really well,” he says of AI, “but it’s freaking awful at creating the equations if they’re not entirely logical.”

This is the technical detail that doubles as a worldview. You don’t let the AI decide what to measure. You let the operator who’s lived the problem decide what to measure, and you let the AI execute against that decision faster than the operator could.

Three years in, Adam is at a different point on the curve. He’s rebuilt the Pentane product three times by now. V1 was the dev shop he handed fifty thousand dollars to, with a spreadsheet and an instruction: make this. It took the money and produced functional software that made perfect sense to Adam and no sense to anyone else.

V2 took nine months. Better, still not great.

V3, the one his customers are testing now, he built in a weekend.

“I just recreated our entire platform in three days,” he says, and his dev team’s response was “holy hell, this is incredible. They’re fully in support of it.”

He showed it to a customer the day before our recording. The customer’s response, verbatim: “Holy shit, this is so much better. Can I have this now?”

I tell him about the equivalent moment in my own work — pulling a client’s data into a prototype, sending them the link, watching them realize they’re finally looking at the thing they’ve been describing for months. The feedback loop collapses from quarters to minutes. The fidelity arrives at conversational pace.

But Adam frames the speed in a way I don’t want to lose. The reason he can rebuild Pentane in a weekend isn’t the AI. It’s the two and a half years of trying to build it and getting it wrong.

“I don’t know what to tell the AI to do unless I have the last two and a half years of breaking it and screwing it up,” he says.

The acceleration is real. The acceleration is downstream of the operational pain that came first. AI didn’t compress his timeline. His timeline compressed his AI.

Near the end of the conversation we’re talking about something else — DoorDash, whether a logistics platform could vertically integrate into restaurant management software now that the tooling exists — when Adam reaches for an image that I think is the real thesis of his career, and the real reason Pentane exists at all.

“DoorDash probably can spin up that vertical,” he says, “but only because they’ve spent the last 15 years with the people at the top of that company chewing on glass. Almost failing over and over and over to get the product to where it is today.”

Chewing on glass. The verb is grotesque on purpose. It’s the part of the operator’s experience that doesn’t make it into the case study, what gets sanded off when the story gets retold for the press release. And it is, in Adam’s worldview, the only reliable source of product taste.

There is no shortcut to it. There is no AI that can simulate it. There is no consultant who can bottle it.

You eat the glass, or you don’t get the taste.

I think about what that means for everyone now standing at the edge of vibe coding with a copy of Cursor open, building the thing they always wished they had. The tools are there. The math is cheap. The aperture is enormous.

But the question is the one Adam started with. Have you lived the problem? Have you sat at a kitchen table at 2 a.m. trying to figure out whether the next thousand dollars in ad spend is going to pay for itself? Have you watched the CPMs climb and felt the slack in the business disappear?

If you have, the AI is a multiplier on something real.

If you haven’t, it’s a multiplier on a guess.

Adam built Pentane because he had to. The mental model he was selling was the one he’d needed in order to survive. He didn’t get the taste from a book. He got it from the years.

The rest was just figuring out how to put the years in a box.

Guest Bio: Adam Callinan

Adam Callinan is the founder and CEO of Pentane, a profitability operating system for e-commerce and direct-to-consumer brands. Pentane emerged directly from the decade Callinan spent building BottleKeeper — a beverage insulator he co-founded with his cousin in 2013 — from zero revenue to $60 million in total sales and a private equity exit, running customer service, paid advertising, creative, and the website almost entirely himself. The core insight behind Pentane: most e-commerce operators are drowning in dashboards but can’t answer the one question that matters — are we profitable, and why — because no one has codified the right equations for them.

BottleKeeper’s growth was neither gradual nor accidental. In August 2014, when Facebook launched its video ad platform, Callinan shot a clip of the product in motion and watched monthly revenue spike from $2,000 to $40,000 to $60,000 to $80,000 to $150,000 in a matter of months. He spent the next several years doing it almost entirely himself — handling customer service, paid advertising, creative, and the website — while his cousin managed finance and fulfillment. The company appeared on Shark Tank before eventually selling to a private equity buyer.

Callinan lives in Bozeman, Montana, where he pursues hard physical experiences outdoors as deliberate mental conditioning — a framework he traces directly to resilience under business adversity. He actively mentors founders and business owners.

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.

Eric Ries helped invent the playbook a generation of startups used to build fast. Incorruptible is what he learned in the years he spent watching many of those companies become unrecognizable — and the governance structures founders can put in place to prevent it. Your can get your copy here

We’re a few minutes into our conversation when Eric tells me a story about a founder he was advising.

The founder was in earnest. He wanted to know how to bind his company so the technology they were developing, something serious, something medical, would only ever be used to cure people — not kill them. It was the kind of question you ask when you’ve already imagined the version of yourself that wouldn’t ask it.

Eric had been listening. But he had to wrap; he was due at an event in honor of a different founder, a man he’d advised for 10 or 15 years. The young founder was curious. What kind of event?

Eric watched people stream in. A retirement, sort of, he said. Look — there are people at this event who this founder had to fire. They’ve come back to celebrate.

“Mad respect,” the young founder said. “That’s so rare. That’s the kind of company I want to be.”

“You’re not hearing me, man,” Eric said. “This isn’t a party. It’s a wake. He doesn’t work there anymore.”

There’s a beat in Eric’s telling where he says, “He’s like, what?” — and you can hear him reaching for the right way to land what comes next. Because what he had to say was the bridge from one founder’s career to the question he gets asked every week now.

“Yeah,” Eric said. “Even though he made all this money for all his investors, they wanted more, and they ousted him.”

“Is that gonna happen to me someday?” the founder asked.

“Yeah,” Eric said. “That’s what I’ve been trying to tell you this whole conversation. This whole system, by default, unless you take the protective action early — this is what happens to you.”

The founder put it to him this way: Is it possible to build an incorruptible organization?

“Good news, bad news,” Eric said. “Yes. I will tell you how. But you’ve already taken some of the steps in the wrong direction.”

That’s the line that won’t leave me.

Not because it’s clever. Because it inverts every assumption I had about how good companies go bad. I had assumed corruption was a thing that happened to companies later — at some inflection point, after the IPO or the acquisition or the second growth round. That if your founder was good, your culture was strong, and your values were clear, you’d be fine until then. That you could see it coming, the way weather comes from a long way off.

The first chapter of Incorruptible is about Sol Price, who built FedMart and mentored Jim Sinegal of Costco, and who was eventually ousted by his own board, who didn’t want to operate the company the way he wanted to operate it. They wanted to extract value. The system rewarded them for it. What Eric will show you over the rest of the book is that this isn’t a story about one bad board. It is a story about a default state.

Eric Ries has been at the center of the startup movement for 15 years. The Lean Startup made the Minimum Viable Product a household term among the kind of households that have whiteboards in them. He went on to found the Long-Term Stock Exchange, a registered U.S. exchange built for companies that want to opt out of quarterly thinking. A startup law firm. An AI research lab with Jeremy Howard. He has had a particular vantage on the last decade and a half.

“I’ve seen the good,” he tells me. “And I’ve seen the value that’s been created. And I have seen the dark underbelly too. Companies that are being destroyed of their own success.”

He says it the way someone reports something they’ve watched too many times to be surprised by anymore.

He tells me about going to dinner with a group of friends two nights in a row. Two different cities. Both restaurants highly recommended.

First night, the friend who’d picked the place took one bite, set down his fork, and asked the table: “Did private equity take over this restaurant?” Someone pulled out a phone. Yes. The new owners had bought it some months back.

Second night. Different restaurant. Different city. Different recommender. Same first bite. “Is this the same damn private equity firm?” Different firm. Same taste.

“We’ve all had this experience,” Eric says. “Companies that get acquired, that go public, they get bought out — where they just lose that special spark. What made them worth backing and trusting in the first place.”

You can taste it. That is what’s interesting. The thing that’s happened to the company shows up in the food.

The mechanism is what Eric is interested in. Not the symptom. He wants you to understand what changes between the moment a place is good and the moment it isn’t — because the same thing happens at every scale, in every industry, and almost none of the people inside it know it’s happening to them.

To show me how it works, he takes us back to the 1940s. Robert Wood Johnson II, the second-generation owner of Johnson & Johnson, is planning to take the company public during World War II. He’s worried about what that will do to the company over time. So he writes a document, the Johnson & Johnson Credo, that lays out the company’s fiduciary commitments. Patients first. Then doctors and nurses. Then employees. Then communities. Investors last.

The exact opposite of what we now teach as the corporate governance best practice.

He worries people will forget. So he has the credo carved into 10-foot-high limestone blocks and installed in corporate headquarters, where they still stand today. Every person who works there walks past the credo on their way in and on their way out.

For 40 years, executives walked by those blocks. During the same window, the company’s marketing leaned heavily on the credo and MBA case studies held it up as exemplary. Johnson & Johnson also knowingly sold baby powder mixed with cancerous asbestos. And tried to cover it up.

“We know that they tried to cover it up,” Eric says, “because of course these things always come out in litigation. And now we have the internal documents.” A pause. “The same people who put asbestos in the baby powder and tried to cover it up walked by the credo every day.”

The values were carved in stone. The incentives moved. The values lost.

This is where I expect Eric to land on a moral argument. Where he tells me what those executives should have done.

He doesn’t.

He says the executives almost certainly believed they were in compliance with the credo. That they assumed someone at a higher pay grade had worked out how the metrics they were chasing aligned with the values on the wall. That the system they were operating inside had quietly collapsed the distinction between the two.

“This whole modern business philosophy that we’ve all come to live in,” he says, “that puts investors first, that preaches an extraction of value rather than the creation of value — I think that whole way of doing business is corrupt. And I think most founders agree.”

He’s not arguing the executives were bad. He’s arguing they were operating inside a system that produced this outcome by default. The credo was a sign. It was not a structure. And a sign cannot hold a roof up.

The young founder Eric was advising — the one trying to figure out how to make sure his technology only ever cured people — had assumed his good intentions were the structure. That because he meant well, the company would mean well. Eric’s argument, the one that landed so hard, is that this is exactly backward. Good people do not protect organizations from misaligned incentives. They are the ones eaten by them.

The corruption is not a betrayal. It is what the default settings produce.

So when Eric says “you’ve already taken some of the steps in the wrong direction,” he doesn’t mean the founder has done anything wrong. He means the founder has signed a standard incorporation, accepted a standard investor structure, agreed to a standard board composition, and quietly assumed those defaults are neutral. They aren’t. Each of them is a bend in the road. Each of them tilts the company, by a few degrees, toward the wake at the end of the founder’s career.

“Build something worth protecting,” Eric says, “and then actually protect it.”

The corollary is this: there are other defaults available.

Eric tells me about a couple named August and Marie Krogh, who lived in Denmark in the 1920s. August had just won the Nobel Prize. Marie had been diagnosed with diabetes — at the time, a death sentence. They were on a lecture tour of North America when, at one of the dinners, a scientist mentioned to Marie that someone in Canada had figured out how to synthesize insulin.

They went to Canada. They worked out a license to bring the technology back to Denmark.

And then they did something specific. They built the new venture, which they named Nordisk Insulin Lab, as a nonprofit foundation that owned a for-profit subsidiary. A structure called an industrial foundation. They did it because they were worried about pricing power. About what would happen, years from now, if someone realized that a lifesaving drug could become power over the people whose lives depended on it.

That structure is still standing. It’s why Novo Nordisk exists. It is the structure behind Ikea and Hershey, behind several companies you’ve interacted with without realizing the bones underneath were unusual. And here is the part Eric saves for last: companies with this structure are six times more likely to last 50 years than conventionally structured companies.

A founder hears this and asks his lawyer. The lawyer says, oh, no — that’s an old-fashioned thing from Denmark. We don’t do that anymore. We have a much better set of best practices.

Eric, to me, with a small dry smile in his voice: “These advisors may indeed be very smart. But are you sure you’re smarter than a Nobel laureate?”

What I’ve come away with isn’t a list of governance structures. It is a recalibration.

I had been thinking of corruption as a thing companies fell into. A late-stage problem. Something that arrived with the wrong investor, or the wrong CEO, or the wrong acquirer. Eric has me thinking about it the way he thinks about Minimum Viable Products — as something the system produces by default unless you intervene. The intervention isn’t a value statement. It is structural. It is something carved into the company’s bones before the pressure arrives, because once the pressure arrives, there is nothing left to carve into.

This is what the headline means, the one Eric keeps trying to land on the young founder in his office: corruption isn’t the inevitable price of scale. It is a choice you make before you know you’re making it. Every founder who hasn’t architected against it has, by the silence of that omission, chosen it.

Eric ends our conversation the way he ends his book.

“Build something worth protecting. Then actually protect it. So when the pressure comes, when the temptation comes, when the rain comes — the roof is still there.”

That’s the line I keep coming back to. Not the credo on the wall, not the values in the deck, not the founder’s intentions — the roof.

Guest Bio: Eric Ries

Eric Ries is the author of The Lean Startup (2011), The Startup Way (2017), and Incorruptible: Why Good Companies Go Bad, and How Great Companies Stay Great (May 26, 2026). The Lean Startup — which introduced the Build-Measure-Learn feedback loop and the concept of the Minimum Viable Product — has been translated into nearly 30 languages, became required reading at Y Combinator, and established the dominant framework for product development and entrepreneurship for the better part of fifteen years. Ries co-founded IMVU, the social avatar platform, in 2004 with Will Harvey, where he first developed and applied the customer development practices that would later become the methodology.

In 2011, Ries outlined the idea for a fundamentally different kind of stock exchange inside The Lean Startup. He spent the better part of a decade making it real: the Long-Term Stock Exchange (LTSE) received SEC approval as a national exchange in 2019 and launched trading in September 2020, designed expressly for companies committed to long-term value creation over short-term shareholder extraction. He has since co-founded Answer.ai with Jeremy Howard of fast.ai — an AI research lab focused on practical applications — and founded Virgil, a startup law firm designed around founder needs rather than billable hours.

Incorruptible draws on more than 200 years of case studies — from Johnson & Johnson and Costco to Novo Nordisk and Ikea — to argue that the governance structures most companies adopt by default are engineered to destroy the values that made them worth building. Ries’s thesis: companies that last aren’t those with better culture decks, but those whose founders protected the organizational structure before they lost control of it.

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.

Tyler has six agents running at once.

He’s walking me through it. There’s a 36-inch monitor in front of him, and on it: Conductor, a desktop app he tells me a team built in Rust. Inside Conductor, his repo. Off that repo, multiple Git worktrees, which he describes as parallel clones of the same codebase. In each worktree, a Claude Code instance. One is building a feature he’s been planning. Another is cleaning up tech debt. A third is on research. A fourth is doing new work he wants to fold in before he comes back to the first. And in another window, almost as an afterthought, a chief of staff agent managing his email, his calendar, his Slack operations channels.

“I want that thing running as often as I can get it running,” he tells me, by which he means his $200-a-month Claude Max account. “I want it running 24/7.”

He’s not bragging. He’s stating a budget logic. If you’ve already paid for the compute, the question is what fraction of the hour the compute is actually doing work. Most people, he implies, gently, are running maybe ten percent. He is running it like a small factory.

Tyler Wells spent 25 years in engineering. Skype, Microsoft, Twilio, where he stayed for seven and a half years and left as a Senior Director. He oversaw large engineering organizations and stopped writing code somewhere along the way. He went back to building in 2021 because he missed it. He is now co-founder and CTO of BrainGrid AI, three people total, and one of those people is, by his own description, running fleets of agents as a normal Tuesday workflow.

I ask him about the economics. Not the cost of compute, which is the obvious version of the question, but the cost of not using compute. The cost of the alternative.

He has a clean answer.

“I mean, I think it’s way more expensive now to talk about it, right?”

There’s a small beat after he says this, like he wants to make sure I heard it the way he means it.

“It’s — yeah. Think of two Silicon Valley engineers and a PM sitting in a room discussing what they want. That’s an expensive burn.”

He sketches the alternative the way someone draws a stick figure.

“Whereas the PM could’ve just sat there with, hey, I’ve got this idea, let me go prototype it. Boom. Oh no, that doesn’t quite work. Okay, let me fix it. Oh okay, there it is. Great.”

There’s a way to hear that as glib. I don’t think it is. The “boom” and the “okay” aren’t doing rhetorical work. They’re doing time-compression work. Tyler is telling me that the loop between have-an-idea and see-the-idea-running used to be measured in weeks at the absolute fastest, more often in months, and now it’s measured in the time it takes to type a paragraph and wait for the agent to finish a build.

This is the part of the conversation where the economics flip in your head, if you let them.

For most of the history of software, the expensive thing was building. Engineering was the biggest line item on the P&L because building took the most time, the most specialized people, and the longest feedback loops. Talking was cheap because talking was triage, a way to figure out what you should be building before you spent the expensive thing on it. Meetings, whiteboards, spec docs, pitch decks: all of these were optimizations on the build budget. You talked so you wouldn’t build the wrong thing.

Tyler is saying that ratio has inverted.

Now talking is the thing with the highest cost-per-unit-of-outcome, and building has the lowest. Which means the structures we built to optimize for the old ratio, the planning meeting, the executive review, the “let’s circle up on this next week,” the three-engineer-and-a-PM whiteboard, are now where the budget is actually leaking.

I tell him about a smaller version of this I noticed in my own work. I edit podcasts. AI tools have become a multiplier on what I can process. When I run out of monthly credits, I spend $20 to get more.

“I just spent $20 on lunch,” I tell him. “My brain burning calories to think is more expensive than this.”

He’s with me on this. He keeps saying yeah.

The full sentence is: I probably have to eat multiple meals to get the calories needed to edit this many podcasts with my brain. Or I just spend $20 and get the same amount of podcasts processed. Talking’s way expensive. Don’t just talk. Do more creative stuff and planning.

What I’m describing in that moment is the same economic flip Tyler is describing about software, just dragged into the much narrower context of a single creator’s monthly content output. It’s the same shape. The build budget got cheap, and the talk budget, which used to be the cheap one, now looks comparatively absurd.

I want to push him on one thing, though.

The story Tyler is telling sounds, on its surface, like the same story technologists have been telling for years about every new tool that lowers the cost of building. Faster computers, better languages, more frameworks, lower-friction deploys. Every cycle gets a “this changes everything” claim. Why is this one different?

His answer is in the workflow on his monitor.

The earlier productivity gains, he implies, never broke the bottleneck that talking-about-building represented. You could build faster, sure, but the rate-limiter on a product team was never the coding speed of a senior engineer. It was the rate at which a team could agree on what to build, decide what to ship, review what got shipped. The talking layer was the bottleneck. Faster compilers didn’t fix that. Better languages didn’t fix that. More frameworks didn’t fix that.

What agents fix, in Tyler’s telling, is the entire chain from intent to implementation. You don’t need to align five humans to ship a feature anymore. You can describe it once, hand it to an agent, and check on its progress while another agent does something else. The unit of decision shrinks from a team to a person. The unit of time shrinks from sprint to afternoon.

“I’ve heard people talking about — hey, I had this idea, started on Friday night,” Tyler tells me. “By Sunday I was giving friends the URL so they could use it.”

This is the part you have to sit with. Not because the timeline alone is new. People have always built things on weekends. The difference is that the thing being built has, almost imperceptibly, gotten substantial enough that the weekend prototype is now what the team used to ship after a quarter of planning.

Friday-to-Sunday is not the new sprint. Friday-to-Sunday is the new quarter.

And if Friday-to-Sunday is the new quarter, then most of what used to happen in the quarter, the planning meeting, the spec review, the architecture debate, the “let me get back to you on that,” is the thing that’s actually too expensive.

There’s a corollary I keep returning to. It’s about ego.

Pre-AI, there was a real cost to opening your work to critique. You’d spent weeks or months — capital, time, attention, political will — getting the thing into a state where someone else could look at it. If they said it was bad, that wasn’t just an aesthetic loss. It was a credibility loss. You’d been wrong, expensively. You’d talked to a team about something that turned out not to be worth talking about. Egos protected themselves from this by getting cautious about what they showed.

Execution’s cheap now. So the cost of being wrong is small. Talk is cheap, so we should talk more. Execution’s cheap, so we should execute more. That’s the inversion of the Spotify line I keep coming back to. The expensive thing in the new economy isn’t the failed experiment. It’s the un-run experiment that the team is still discussing.

This is the change Tyler is actually pointing at when he calls his workflow what he calls it. He doesn’t say parallelization. He doesn’t say agent orchestration. He uses the language of running something, I want it running 24/7, because the basic ethical posture of his workflow is that compute is sitting there idle and that’s the waste. Not the wrong experiment. The unstarted one.

When you talk to product people right now, there are two camps. The first camp is treating AI like a productivity tool. They are getting faster at building specs, faster at writing emails, faster at producing artifacts that look like the artifacts they used to produce. The second camp, Tyler’s camp, is treating AI like an economy change. They are reorganizing their entire week around the idea that the constraint they grew up under has moved. The bottleneck isn’t engineering anymore. It’s the meeting that was built to optimize engineering.

The first camp will look back, three or four years from now, and find that they made themselves slightly more efficient inside a structure that was about to become obsolete. The second camp will already be operating on a different time horizon.

Tyler is in the second camp. He doesn’t make a big deal of it. He just describes his Tuesday afternoon. Six things running at once, two on agents, one on his chief of staff, one on his own attention. And the implication of the description is that the version of you about to ask “should we have a meeting about this?” is the version that lost time it didn’t have.

We end the call. He has, by his own count, several things running. The agents kept building while we talked.

That’s the part that stays with me.

Building stayed cheap. Talking is what cost us the hour.

Guest Bio: Tyler Wells

Tyler Wells is the Co-founder and CTO of BrainGrid AI, a planning-layer platform that acts as an AI product manager and tech lead before a coding agent writes a single line of code. Founded in 2025 alongside co-founder Nico Acosta, BrainGrid takes a plain-language idea and converts it into structured product specifications, task breakdowns, and implementation blueprints ready for tools like Cursor and Claude Code — targeting the domain experts, operators, and non-developers who have ideas they’ve never had the capital or technical background to build. The company emerged from the collapse of Wells’ prior startup, which he and Acosta wound down in late 2024 when they realized that the planning layer they were building for themselves was the product.

Previously, Wells spent seven and a half years at Twilio, ascending from individual contributor to Senior Director of Engineering before departing in 2021. At Twilio, he oversaw large engineering organizations and was responsible for cloud infrastructure operations — the environment where he first watched runaway AWS and Snowflake costs become six-figure surprises and developed the discipline around inference limits and cost management that now shapes BrainGrid’s architecture. Earlier in his career, he held engineering roles at Skype and Microsoft, accumulating more than 25 years of professional software engineering experience across the stack.

Wells is also the host of the Data Chaos Podcast and previously co-founded Propel Data, a prior analytics venture. He returned to individual-contributor engineering work when he co-founded BrainGrid — a deliberate choice to get back to building after years in senior management — and now operates a three-person team shipping product with parallel agent fleets across isolated Git worktrees.

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 says “check it out” the way you say it to a friend, not a customer.

We’re about half an hour in when Artem Koren tells me the SOC 2 story. His company, Sembly AI, is an AI meeting intelligence platform — Sembly, S-E-M-B-L-Y, not to be confused with AssemblyAI, which is a separate company that does speech-to-text infrastructure. He’s careful about the distinction. “We’re actually related, we partner on a few things, but completely independent. Evolutions of name just so happens, so it’s a little confusing.”

That out of the way, the story:

“I did something where, you know, we are a SOC 2 type two compliant organization. And so our auditor was on the call with us and I said, check it out. I’ll show you something funny.” The pitch is half its appeal. “I basically took all of our auditor sessions that we also had on Sembly, because Sembly attends all of our auditor sessions. And then based on all of our auditor sessions, I asked it to compile the SOC 2 type two report. Like what our auditor takes like two, three weeks to do by hand — I just asked Sembly to do it based on those sessions and they did it in a few minutes.”

A few minutes.

I want to react to that the way I’d react to seeing a magic trick — with the slight unease of not being sure how it was done. Then I remember: Artem and his co-founder, Gil Makleff, started building Sembly in 2019. Pre-ChatGPT. Pre everything. They didn’t fall sideways into AI when the wave broke. They were already underwater.

I realize the layout — the part most software founders won’t tell you — only after the conversation turns to what it cost.

“We started Sembly AI before AI was cool,” he says. “So 2019, not too many people were talking about AI. It was a very different AI landscape at that point. It was machine learning and data science.”

I’d somehow forgotten what “machine learning and data science” meant in 2019. Not a wrapper around an OpenAI API. Not a fine-tune. Custom models for everything. He runs through it without theatrics: “We had to build a bunch of custom models for detection of different items across meetings, for being able to interrogate meetings in natural language. So all of that we built before GPT was a thing. We also actually had to build our own transcription engine because at the time, the transcription engines, even from behemoths like Google and Amazon and Microsoft were just not up to par.”

Behemoths. His word, not mine — and the framing carries: the giants existed, they just weren’t good enough.

“They were just not as good as they needed to be for the quality of results that we needed to achieve. So we had to build that. And we got a very sharp engine that was rivaling the best transcription offerings in the market, but only for the English language at that time.”

Then a smaller line, almost an afterthought, that I can’t shake later:

“We also had to build infrastructure and the whole platform to attend meetings.”

He means: Sembly had to invent a fake meeting participant. Software that joins your call the way a person joins your call. “We have our own proprietary platform that basically simulates a user who will join a meeting with you. That user simulated for all the meetings that Sembly is present on.”

This is the part that matters. The thing under the surface. Sembly’s whole 2019-to-2022 buildout was a tunnel — a long, expensive, mostly invisible tunnel — to the same place that, by late 2022, you could parachute into for free.

“Then the end of 2022, early 2023 revolution happened with GPT and we had to step back and rethink the ways in which we approach some of our architecture and technologies and kind of revamp Sembly to take advantage of all the new AI stuff that’s coming up.”

That’s the mild way of describing a moat becoming a floor.

I ask the version of the question I came to ask. “What was the hard question you had to ask yourselves to reposition the company? You mentioned that you guys had to step back. Like what changed?”

Artem doesn’t get cute about it. He doesn’t say “we had a dark night of the soul” or “we re-platformed.” He gives the answer that I think tells you most about him:

“With the introduction of modern LLMs, what it did was it kind of raised the base watermark for what’s easy or what’s very achievable to do in technology. So pre-LLM, the kinds of features we had on our platform, basically no one had and would be very challenged to put together. There was really a lot of hard innovation baked in.”

The watermark rose.

I want to think about that line for a second. There’s a default founder pose around moments like this — wounded, defiant, prove-the-doubters-wrong. Artem doesn’t do it. He frames it as a tide condition, not a war. The water came up. It came up for everyone.

“With LLMs coming to the fore, suddenly you can create a basic version of what we’re doing fairly easily. And so there was a proliferation of these AI note taking apps of all different kinds of flavors.”

He runs through what they don’t do — privacy, SOC 2 type 2, geography, accuracy, mid-track language switching, speaker disambiguation — almost as muscle memory. Not bragging. More like a checklist someone goes through when they’ve been the only one in the room who has to think about these things.

Then the actual answer.

“Note taking in and of itself was not a big challenge. And so we had to step back and say, okay, note taking was the low hanging fruit for post-meeting value. What would be kind of the next leap? And we thought that giving AI the ability to work with your entire meeting set would create a lot of power. And that’s basically the direction we went into, and continue to go into.”

I keep pushing the metaphor — partly because the metaphor is doing real work for both of us. “Just because the tide has risen, you still have to keep your head above water. Ideally, it’s like you’re doing it through a boat. And like, hopefully the boat’s rising with the tide. And I’d imagine like when this new disruptive technology came up, it started creating some leaks in the boat. We’re like, oh shoot. We have to fix the direction of the boat, fix the leak, and then how do we build and improve the boat now that this technology is freeing up a lot of capabilities.”

He doesn’t disagree, exactly. He restates the problem in his own register, which is calmer than mine: the meeting note isn’t going away. They’ll keep maintaining a best-in-class meeting intelligence product for their existing customers. But the new product — the one that’s going to matter — is going to be built on top of an idea about what kind of organization actually needs Sembly.

Professional services.

“It’s, we’re kind of midway in realizing that strategy change because once you reach a certain level of momentum as a company, you can’t just pivot on a dime.”

Midway. That’s the most honest word a founder can say about a transition. Most pretend they’re done before they’ve started. Artem says they’re midway and you can hear that he means midway.

The professional services pivot makes sense in the way good positioning makes sense — quietly, after a few sentences. Consultants live in meetings. Meetings produce information that goes nowhere unless someone manually extracts it. Consultants also have clients, and clients have projects, and that two-level hierarchy is the difference between a tool and a system that understands your work.

Artem describes the agentic version: “Whereas when we started it was open-ended — it was very ChatGPT-like, where you can just go in and ask for anything you want. We are starting to create very agentic centered experiences where the agents are very specialized in creating certain kinds of materials and output.”

Then the example that reframes the whole product category for me.

“Imagine being able to on-demand generate case studies that are specific to a particular client situation. So you’re a professional service organization. Maybe you’re selling marketing or you’re selling technical services or maybe selling HR services, whatever it is. You have clients and then the client comes to you and says, okay, we’re considering you as a vendor, we’re also considering these other vendors. How cool would it be if you had some discovery calls with that potential client and then you can generate a case study that showcases that you’ve done something similar to what the client is asking for another customer.”

He keeps going. “That’s something that most agencies can’t afford to do. Like that’s a long and difficult process. Only the biggest agencies can really invest in doing something like that.”

The case study — the real one, the kind a Bain or a McKinsey would produce — on demand, for the conversation you’re already in. Not a generic one-pager. The artifact that wins the deal.

I get a question back that he says he’s been getting all the time lately: but can’t they just go into Copilot or Claude and ask it to generate a case study? Upload some documents. Press the button.

“This is super interesting because there’s kind of like a completeness factor to the output.”

Then the line I write down twice:

“If you’re using Claude, it will help you, but it will take you like 15 to 20% of the way, and you’re gonna need to spend another 80% on making that presentation real, usable, client-shareable. Like it’s way far from client shareable.”

Fifteen to twenty percent.

I think about what I do every week. I draft something with Claude. I think it’s done. I then spend the rest of the week massaging it into something I’d put my name on. The fifteen percent feels like more in the moment, because the page was blank and now it isn’t. But the work I’m doing after is the actual work.

“The general platforms, including Copilot, they have a last mile problem, which is they can only get you so far, but there’s specialized logic and mechanisms you need to get it to a client presentable level.”

I ask if he thinks Copilot will close that gap. He doesn’t think so. He thinks specialized companies — Gamma, in his example — own the last mile, because the last mile isn’t about model capability. It’s about completeness within a specific output format. Brand. Layout. Context. Voice. The eighty percent.

“And the reason that’s not true is because we’re so used to going down the checklist of features — does it have this feature? Does it have that feature? But it’s no longer about features. It’s about achieving goals or achieving certain kinds of experiences, and those things have more qualified metrics than just yes or no.”

This is the bigger frame underneath everything. Software is shifting from features to goals. The deliverable is no longer “does the system have this capability.” The deliverable is “did your customer attain the outcome.” And nobody’s scoreboard for that exists yet.

I push him on something else, because the language is starting to remind me of consulting more than of software. I ask if there are partners at consulting firms who are bad at delegating.

“I don’t think there’s a single partner that I’ve met that’s bad at delegating. Because once you’re a partner you’re only delegating — you’re actually not doing any of the work. And that’s part of, I think, what helps you to rise through the ranks in management consulting. Is effective delegation.”

Then the wrinkle.

“But I wouldn’t say it like delegation. I guess delegation is one way of talking about it. I think it’s more about pure communication.”

He hedges around the word communication because it’s fluffy — and says so. So he restates it sharper.

“It’s about relating to someone else in a very sharp way the idea that you have so that that person has the exact same idea.”

He keeps going. “And so this is where the metal is tested because first of all, it has to be sharp in your mind first. And I think that’s a lot. You know, sometimes that’s where things fall apart. Like if you don’t really know what you are trying to do, you’re gonna have a very difficult time trying to get someone to figure out the thing that you haven’t figured out yet that you want done, right?”

Then the phrase I cannot stop turning over in my head:

“Communicating that effectively to someone else so that they can get a twin representation of that idea in their mind.”

Twin representation. Not a copy. Not a brief. Not a spec. A twin — an idea that exists in two minds, fully dimensional in both, sharable from there.

“That includes things like providing the right kinds of context, bringing in context that would be important to understand in the given situation, providing counters like — this is, you know, we don’t want it like that, we want it more like this. And the end audience is like that, and it should have these performance characteristics and criteria.”

Context, counters, audience, performance characteristics, criteria. He’s describing what a senior consultant does to brief a junior associate on a Tuesday. He’s also describing what a good prompt looks like. He’s not pretending these are different skills.

“But ultimately you have to convey that idea in all of its dimensions to that other mind. But that other mind could be human, but today it could also be AI.”

The reframe lands sideways, the way good reframes do. I tell him I think it never was delegating. It was directing. The senior person never wanted to make the slide. They wanted the slide made to a standard they owned. The whole point of the junior analyst is that the analyst is responsible for executing to that standard. The senior’s job is communicating the standard, not lowering it.

“That’s a really nice reframe,” I say back, because what I really mean is: I wonder how many of the people complaining about AI are actually complaining about a directing skill they never built.

We go a little further. The interoperable agents future. The MCP interface Sembly is about to ship, where you can sit in Cursor and say: “That bug fix that we discussed on our call with Max, take the details of that bug fix and fix the bug that we discussed in my code.” Cursor pulls the meeting context from Sembly. It just happens. Vendor lock starts to look antique. Best-of-vertical agents talking to each other across companies. A different shape of software entirely.

But the part of the conversation I keep returning to, days later, isn’t the demo or the architecture or the pivot. It’s the geometry of what Artem is describing.

When the moat becomes the floor, you don’t try to dig the moat deeper. You don’t insist that what you built was hard, that the new arrivals are cheating. You climb up on the new floor and look at where you are. If you’re early, you’re standing on infrastructure no one else has — speaker disambiguation, mid-track language switching, the simulated meeting participant, four years of compliance and edge cases. If you’re late, you’re standing where everyone else stands.

Then you ask the question Artem asked: what’s the next leap?

The answer he gave is harder than it sounds. The leap isn’t features. The leap is goals. The leap is the eighty percent. The leap is the artifact at the end — beautiful, branded, factual, referenced, client-shareable — and the difference between a company doing real work and a company that’s added a button.

The leap, I think, is also the directing skill. The twin representation. The sharpness of the idea in your head before it leaves your head.

That part doesn’t have a moat at all. It has a floor — the same floor everyone else is standing on. The difference is what you can describe from there.

Guest Bio: Artem Koren

Artem Koren is the Co-founder and Chief Product Officer at Sembly AI, a meeting intelligence platform that transcribes, analyzes, and synthesizes professional service meetings into structured work products. Rising to prominence in the early 2020s, he became widely known for building enterprise-grade AI transcription and natural language processing systems before large language models made such capabilities broadly accessible — engineering custom models from scratch for a category that had no clear precedent. The company, which he co-founded in 2019 alongside Gil Makleff, operates across 35 languages, holds SOC 2 Type 2 certification, has raised $4.64 million in total funding, and was named in the 2025 Gartner Innovation Guide for Generative AI Technologies.

Previously, as Senior Manager and Director in the IT Capital Markets Services practice at EY, Koren spent more than a decade advising Fortune 500 clients across financial services, auto insurance, energy, and professional services sectors in North America and Europe. He was recognized as a top 1 percent performer and became known for deploying enterprise-scale work management applications — hands-on experience in the client service delivery cycle that would later define Sembly’s product thesis.

Earlier in his career, Koren served as CEO and CTO of Visual Trading Systems, where he built and distributed technology solutions for the capital and commodity markets, and co-founded Neusana, applying deep learning to digital biopsy image analysis. He holds a BS in Computer Science and Economics from Columbia University and an MBA from NYU Stern School of Business.

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.

Chris Pearcey keeps coming back to a number.

“There’s 250,000 titles,” he says, “but nothing to watch.”

He uses it as the hook for his investor pitch. He uses it on me, in our first ten minutes of conversation. It’s the kind of line that is at once obviously true and obviously unsatisfying. You can feel the dissonance. A quarter-million pieces of professionally produced entertainment, sitting one tap away on a phone, and the average person opens the streaming app and feels paralyzed.

“And that’s by design,” Chris says.

That’s the part I don’t expect. I expect the lament. I don’t expect the by design.

Chris is the founder and CEO of Deci Media, makers of Decisio — Latin root of decision, plus .media. The app is free, ad-free, and built around what he calls a patent-pending four-way swipe system. It launched January 1st of this year and has added more than five thousand users since, almost entirely through Google Ads. He’s based in Beaverton, Oregon. He spent ten years on the data engineering side of the business and ten years on the product side — including five at Nike, where he was the advanced analytics product manager for planning tools across Asia and Latin America, and where his job was to drag forecast accuracy from sixty-five percent to above ninety. His team got it to ninety-three in six seasons.

He wears the data engineer pretty visibly. Within the first ten minutes of our conversation, he tells me that he started the Decisio platform by trying to use AI for the data curation step. He had to pull movies and shows and metadata from the top ten streaming platforms — every title, every distribution status, all of it — into his own database. He fed the job to AI.

“I was getting 40% false positives,” he says.

Forty percent of the records were wrong. Titles that weren’t on the platform, returned as available. Titles that were available, returned as missing. Forty percent.

“It’s only as good as the information it gets,” Chris says. “We’re not even past the foundations period. But some people wanna put the roof on already.”

He goes back to a metaphor I now hear him use three different times.

“AI right now is like a first year medical student,” he says. “And I think many people are ready to give on the keys of the hospital already.”

He builds an actual ETL pipeline. Old-style data engineering. Extract, transform, load. He pays a monthly fee for a real database API. The pipeline is deterministic, repeatable, a hundred percent accurate. The AI does not get the keys to this part of the hospital.

He used AI to help write the pipeline. “It probably would’ve taken me weeks to build these pipelines out that I got. I was able to build it in an hour because of AI.” The first-year medical student is a useful assistant. He just doesn’t get to run the surgery.

The reason any of this matters, in Chris’s framing, is that the streaming industry’s data problem isn’t a data problem.

I bait this out. “And you’re claiming that’s a data problem?”

“I absolutely —” he starts. Then he stops. “Ab, well,… It’s a purposeful data problem.”

He’s choosing his words.

“They want to overwhelm you,” he says. “When you go, when you log into Netflix, you don’t want to search. You just look at what the top 10 movies are and then you —” he mimes the click — “and all 10 of those movies make Netflix a boatload of money. But your satisfaction is probably not gonna be the greatest when you’re done with the movie. But yet it’s still in the top 10 every time.”

This is the thesis. Two hundred fifty thousand titles is not an artifact of abundance. It is a feature. The catalog is engineered to be too large to navigate, because a user who feels overwhelmed will accept the algorithmic top-ten. The top-ten is where the platform’s economics are best. Your dissatisfaction is irrelevant; you watched it, you didn’t cancel, the metric clears.

He cites a stat I have to ask him to repeat. The average person spends eighteen minutes searching for something to watch or read. Thirty-three percent give up. Of the people who do find something, eighty percent take the algorithm’s recommendation, and fifty percent are dissatisfied with what they ended up watching.

A third of the audience walks away. Half of the surviving viewers feel cheated by the recommendation. And the catalog keeps growing.

“They’re incentivized to push that they profit on,” Chris says.

He doesn’t say they with venom. He says it with the matter-of-factness of someone who used to build advanced analytics for Asia-Pacific apparel forecasting and now understands exactly how to build a system that optimizes for the wrong outcome on purpose.

What happens next is the part of the conversation where I start to see the shape of what he’s actually doing with Decisio.

It is not a recommendation engine. Or — it is, but the recommendation is not the product. The product is intent capture.

“No one’s capturing intent,” Chris says. “You know, there’s no way for AI to capture intent, or any of these sites. So I also wanted to do something where we can capture intent, because if a thousand people wanna see a new release, 9,000 don’t, I mean, that’s that Megan 2.0 last summer. That’s a perfect example.”

I watch him connect the dots in real time. Megan 2.0 was the sequel nobody asked for. The first film hit. The studio assumed the audience for the first film would translate to the audience for the second. The audience never showed up. Nobody had captured the don’t. The data they had said people liked Megan. The data they didn’t have said people did not, in fact, want a Megan 2.0.

Negative intent is a missing primary key.

“AI starting to understand what we like,” Chris says. “I don’t think it understands what we have no interest in. And that’s the key differentiator that I’m trying to also create.”

The four-way swipe is the mechanism. Left and right are the familiar Tinder gestures — like and dislike. Up and down are the move he claims as patent-pending. Up: I want to see this. Down: I do not want to see this.

Two pieces of data per card become four. Fifty swipes in about three minutes — he times it — and the system has enough signal to surface a recommendation that isn’t generic.

“You’re not getting stuck. You’re not seeing things that are outside of what you’re looking for,” he says. “You’re seeing only content. To see if you’re interested or not, or if you’ve seen it or haven’t.”

The reason this matters — and the reason it isn’t just a product decision — is that the four-way swipe is the cheapest possible way to extract negative preference from a user without making them write a sentence. Ask people to type what they don’t like and most of them will type nothing. Show them a card and ask them to swipe down and they’ll tell you, in three minutes, fifty things they have no interest in.

That signal is what every recommendation engine on the internet is missing. Netflix knows what you watched. Your algorithm knows what you liked. Neither one captures what you would actively pay to never see again.

The other detail Chris is proud of, in that quiet engineer-founder way, is the analog feel.

The cards in Decisio flip. Movies and shows present like an old VHS box. Books flip like, well, books — front cover, page-edge, back cover. The card is a deliberate visual artifact from the rental-store era.

“Especially the, the Gen X millennial folks,” Chris says, “they said, this feels like the, you know, it’s nice to have something that feels physical again in my hand.”

He smiles a bit, in that quick way he has when he’s pleased with the data. The Gen Z group is more telling.

“Gen Z in particular right now is, uh, someone said that the app feels very analog, but they love that because they are not ready for it. They’ve never had a life without AI right now, you know, in their minds.”

Read that back slowly. They’ve never had a life without AI. The cohort he’s talking about is asking for the swipe and the VHS box because the swipe and the VHS box do not require them to outsource their taste to a model that already knows too much about them.

The whole product is, in a sense, a refusal. A refusal of the algorithmic top-ten. A refusal of the chatbot recommendation. A refusal of the doomscroll. The four-way swipe is the answer to what Decisio’s users — including, he says, himself — actually want from a recommendation engine: a tool. Not a feed.

“What I’m excited about software right now,” I say to him at one point, “is that it’s a tool that you use. It’s actually a tool. It’s not some engagement slot machine anymore. It’s a — I will pay a hundred dollars a month to pick this up and put it down.”

Chris doesn’t even pause. “Yes.”

The cheaper the tool, the more engaging it has to be. The more expensive the tool, the more it has to respect the user’s time. Decisio is free. But the design philosophy belongs to the expensive-tool category. It is built to be picked up, used, and put down.

Toward the end, Chris tells me the metric he tracks for himself.

“I use the app regularly,” he says. “Right now I’m at 63 of 64 loves on the recommendations.”

Sixty-three out of sixty-four. He’s the customer. He’s the one keeping score.

“It’s never gonna be a hundred percent, we know that, but still, I’m shooting at about, you know, 98% right now. And that to me tells me that I’ve now taken a lot of my time back.”

Sixty-three out of sixty-four. The four-way swipe didn’t try to know him better than he knows himself. It just gave him a fast way to tell it what he didn’t want, and an even faster way to tell it what he did. Fifty swipes. Three minutes. Sixty-three out of sixty-four loves.

That’s not an AI breakthrough. That’s a UX bet. The bet is that the user is the algorithm. The bet is that the platform’s job is to listen, fast and structured, and then get out of the way.

I keep returning to the by design framing.

The 250,000 titles is by design. The eighteen-minute search is by design. The fifty percent dissatisfaction is by design. The streaming industry built a data problem on purpose because a confused user is a profitable user.

Decisio is also by design. The four-way swipe is by design. The VHS box flip is by design. The free tier and the no-ads are by design. So is the part that makes me think Chris is going to win this — the choice to capture negative intent, the choice to ask the user what they do not want.

The cynical version of this story is that one set of designers built an overwhelm engine to maximize platform revenue, and another set of designers is now building an intent engine to maximize user satisfaction. The fight is asymmetric. Netflix has decades of compounding capital and a fixed top-ten. Decisio has five thousand users and a four-way swipe.

The hopeful version of this story is the one Chris keeps coming back to without quite saying.

Some products are built to keep you on the phone. Some products are built to get you off the phone, into the chair, into the book, into the movie. Those two categories are running in opposite directions. The market still has not decided which one it values. But the people who are sick of the slot machine — and Chris is convinced there are a lot of them — are quietly looking for the tool.

Sixty-three out of sixty-four says they might find it.

Guest Bio: Chris Pearcey

Chris Pearcey is the Founder and CEO of Decisio.media, the company behind Decisio, a free, ad-free entertainment recommendation app built around a patent-pending four-way swipe system that captures positive and negative viewing intent across movies, television shows, and books. Rising to prominence in the mid-2010s as a data engineering and analytics leader in enterprise product organizations, he became known for applying machine learning to forecast accuracy problems at scale inside some of the world’s largest consumer brands. Since launching Decisio on January 1, 2026, the app has grown to more than 5,000 users on minimal marketing spend, acquiring customers exclusively through Google Ads.

Previously, as Advanced Analytics Product Manager at Nike, he supported planning tools for the Asia and Latin America regions and drove forecast accuracy from 65% to 93% over six seasons by introducing consumer profile modeling — one of the more precisely measured single-initiative improvements in Nike’s planning systems during that period. He also held product and engineering roles at Amazon Web Services before founding Deci Media, building the enterprise-scale data infrastructure background that informs Decisio’s deterministic recommendation architecture.

His career highlights span 20 years split evenly between two disciplines: 10 years as a database engineer specializing in machine learning and advanced analytics, followed by 10 years in product management across enterprise software organizations. Headquartered in Beaverton, Oregon, Deci Media is built on the conviction that streaming platforms’ 33% abandonment rate and 50% viewer dissatisfaction rate are not failures of recommendation algorithms — they are the predictable result of platforms optimized for engagement metrics rather than viewer satisfaction.

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.

Gal Ko opens with a number that won’t leave my head.

He’s describing a B2B SaaS company trying to acquire a customer through LinkedIn ads. The kind of company that sells, in his example, a fifty-thousand-dollar annual subscription to other companies. And he says it would cost that company “around $800 for a lead, um, just to get the demo booked.”

A pause.

“And that is like insane.”

Eight hundred dollars to put thirty minutes on a calendar. Not a customer. Not a qualified lead. A demo. The number sits there in the conversation. He’s the one who placed it.

I want to dwell on it because Gal is the kind of person who deals in numbers like this for a living, and the casualness of the figure is the part that lands. This is what acquisition costs in 2026. This is what the LinkedIn-ads-and-cold-outbound playbook costs founders right now, on the way to a demo that has not yet converted. The math broke a long time ago. We’re just seeing the receipts.

Gal is a marketing lecturer at Google and Reichman University in Portugal, originally from Israel. He has been in marketing since he was fourteen — over twenty years across product marketing, FinTech, and cybersecurity — and before any of that, he spent two years as a Navy diver, building ports and welding underwater. The path to where he sits now ran through three countries: six months in China, a year in Australia on a working holiday visa, and finally Portugal. What he does today he calls Bold PMM, or sometimes Bold Voice. He matches tech founders with podcasts, and he runs a free Skool community of hundreds of podcast hosts and B2B marketers — a place he calls Monday Matchmaking Mania — where he plays connector for a living.

The founders who hire him have one thing in common, in his telling: they’re staring at the eight hundred dollar number and trying to figure out what to do.

“Grabbing attention, it doesn’t necessarily means building trust,” Gal says. “That’s one thing that is for sure nowadays.”

He leans in. Or his voice does — the cadence tightens. “Because we got so many new companies coming up and you know, with AI, no Code Builders, anyone can come up with a new Uber, new bolt, new whatever it is. name the app, we can create it now…” A beat. “what we are lacking is trust.”

I let that one sit because it’s the whole thesis in eighteen words.

Create, review, update, delete (CRUD) Software has been commoditized. The capacity to ship a usable product has collapsed from twelve engineers and eighteen months down to a single founder and three months — Gal cites Mo Lamo, the Israeli builder who wrote Base44 from his apartment during military reserve duty and sold it for somewhere around fifty million dollars. Mo Lamo’s first hires were two months before the exit. The product, in other words, was almost an afterthought.

What didn’t get commoditized is the human on the other side of the table.

That’s the founder-led growth premise — that the durable moat now isn’t your product, because the product has become table stakes, and it isn’t your distribution, because every channel is overrun with the same cheap copy. The moat is the founder. Specifically: how much trust the founder can deposit into the world over the lifetime of the company.

I push back on this gently, because I want to know whether he’s telling me the truth or selling me his service.

“Most of distribution now is a pay to play game?” I ask.

“No. No,” he says. “Absolutely not.”

Then he names a different number. “Eighty-three percent of executives are listening around five hours a week” to podcasts. “And this is why podcast is here to stay. And I think that podcasting is not as saturated as we think.”

The eighty-three percent is the counterweight to the eight hundred. One number describes how much it costs to interrupt an executive on LinkedIn. The other describes where that same executive is voluntarily spending their attention. Gal’s entire pivot — from corporate PMM to productized service to founder-led growth strategist — sits in the gap between those two numbers.

He runs through his model the way a former product marketer would. There’s a Google framework he keeps coming back to. He calls it 7-11-4. “It says, um, that in order to become a client, one has to go through seven hours of engagement with your brand across 11 touch points in four different locations.” Seven hours of engagement, eleven touchpoints, four platforms. That’s the threshold. That’s what the trust math actually looks like.

“So we take one episode,” he says. “We turn it into a blog post. We turn it into a newsletter, we turn it to, um, three shorts that’s gonna come out, um, on LinkedIn, on x, on wherever, um, where the cost per view is lower.”

One conversation. Months of distributed proof. The podcast appearance is the seed crystal.

There’s a moment — and it’s the moment I want to dwell on — where Gal stops talking like a marketer and starts talking like someone who has watched the industry change underneath him.

The product has been commoditized. The slogan that ran the SaaS playbook for fifteen years — product-led growth, build something so good it sells itself, distribute through usage, monetize through delight — has run out of road, because the things that used to make a product remarkable can now be conjured by a founder with a Claude subscription in a weekend. Product is the floor. Trust is the ceiling. The ceiling is where the market has moved.

Listening to him, I think about Michael Bloomberg. I’m partway through Bloomberg’s autobiography and the part that keeps surfacing is what he did with Bloomberg News. He wasn’t trying to make money on the news operation. He was using the news as a product demo. Every Bloomberg News article had a Bloomberg Terminal query at the bottom, and the whole point of having journalists on staff was that every news story sent the reader back into the product. He had the unfair advantage of charging fifty thousand dollars a year per terminal, which meant the news could afford to be a loss leader for trust.

I tell Gal this and watch him track with it.

“Every conversation,” I say, “with like, if you’re a leader trying to build your personal brand, build trust with people so that they’re like, I like this person, I’ll look at their SaaS or their whatever product. That’s a product demo.” I add, almost as an aside: “I guess I’m offering human demos.”

That is what podcast guesting actually is, in his framing. It’s the modern version of Bloomberg’s strategy. A podcast appearance is a sixty-minute product demo where the product is the founder’s mind. You can’t fake it for sixty minutes. You can’t ghostwrite it. You can’t outsource it to a content manager. The medium itself is the proof.

“Posts, for example, they don’t represent any depth,” Gal says. “Once you see a thread on X or once you see, I don’t know, a post on TikTok, it doesn’t lead to depth… to resonate with you to get to know you, what your goals are.”

He keeps coming back to the word depth. I don’t think he picked it on purpose. It’s the word that does the most work in his argument.

There is a tension underneath the founder-led growth pitch that I want to name out loud, because Gal more or less names it himself.

The eight hundred dollar demo and the eighty-three percent of executives listening to podcasts are the same problem viewed from opposite sides. The cost of attention has gone up because the supply of content has gone up. AI made the supply curve nearly vertical. Every founder can publish more, faster, with more polish, in more places, than at any point in history. Which means none of it is scarce. None of it is differentiated. None of it earns a second of trust.

What is scarce is the ability to sit in a chair for an hour and say something true.

“Our conversation at the moment, it’s so human no AI can switch it,” Gal says. “so for example, podcasting, that’s something that I don’t believe that AI will replace because obviously we can listen to notebook, LLM, we can summarize books like this, and it will be beneficial, but it’s not the same thing.”

He doesn’t sell this part. He just says it. Two human voices, an hour, no script, no edits worth speaking of. That’s the medium. That’s the moat.

The reason I don’t think the AI doomers are right about podcasting — and the reason Gal doesn’t either — is that the bottleneck was never production. Production has always been hard. The bottleneck was willingness to be seen. To be wrong on the record. To follow a tangent into a place you didn’t plan to go. To answer a question that catches you off guard with something other than your media-trained line. AI can replicate the polish of a podcast. It cannot replicate the willingness.

Founder-led growth is the founder admitting that the company’s most durable competitive advantage is whether they themselves are worth listening to.

Toward the end, Gal tells me about Mo Lamo again. He wants to make sure I understood the part about community. About how Mo Lamo wasn’t a vibe-coding lottery winner who happened to ship the right tool at the right moment. About how Mo Lamo had been sitting in the same Tel Aviv builder communities Gal was in, for years, before Base44 was a thing.

“When he started the Kickstarter,” Gal says, “we’ve been there for him. And you know, when he created, just like feature and he wanted to test it. So he sent us on the WhatsApp group. Look guys, I’ve created a new feature. Can you just q and a that. And actually he is coming from an extensive background in computing and coding. That’s not his first round.”

The product was built in three months. The trust was built over years.

That’s the part the eight hundred dollar lead doesn’t capture, and the part the seven-eleven-four formula only gestures at. The math works because the human work happened first. The podcast doesn’t manufacture trust out of nothing. It compounds the trust the founder has been quietly accumulating, in WhatsApp groups and Substack newsletters and Skool communities, in every place where they show up for a long time without expecting a sale.

The product has been commoditized. Distribution has been commoditized. Even content production has been commoditized.

The founder, sitting in a chair, talking honestly for an hour, has not.

That’s the only thing left that you still have to actually earn.

Guest Bio: Gal Ko

Gal Ko is the founder of Bold PMM and Podstar, podcast guesting practices that match B2B technology founders with established shows for trust-building and pipeline generation at scale. Rising to prominence in the early 2020s following the intersection of COVID-era layoffs and the Israel-Hamas war, he became known for productizing more than two decades of product marketing experience — across FinTech and cybersecurity — into a subscription-based distribution service built on the thesis that founders, not products, are the last remaining differentiator in an AI-commoditized market. He currently teaches marketing fundamentals, branding, storytelling, and Google Ads at Google and Reichman University, where he has lectured for more than three years.

Previously, he built a product marketing career spanning over 20 years, beginning his first marketing work at age 14 and later advancing through digital marketing roles during a year spent in Australia and six months in China studying Mandarin. His pivot into podcast strategy in the early 2020s was grounded in a specific observation about buyer behavior: following the Google 7-11-4 rule — which holds that B2B buyers require 7 hours of content engagement across 11 touchpoints on 4 different platforms before converting — a single repurposed podcast episode is the most efficient vehicle for hitting those numbers at founder scale.

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.

Tim Beattie spent 25 years inside major consulting firms and came to one uncomfortable conclusion: in the consultant’s financial interest to slow down, invent complexity, and make problems look harder than they are. He founded Stellafai to replace that incentive structure with one where the consultant only wins if the client wins.

Tim Beattie tells me about a Christmas party. Not the kind with a story attached to it — the kind where the absence of a story is the story.

He was a young graduate consultant at a big four firm, two years into the same program for the same client. The team gathered at a pub in Winchester, England — the same pub they’d gathered at the year before. He sat there with his colleagues and tried to account for the twelve months between the two parties. “What have we done?” he says. “All we’ve done was documents. We created documentation after documentation, designs, PowerPoints, high level designs, detailed designs, requests after change, requests to change the designs.” The emphasis lands hard. “Nothing had gone live. We’d barely even written any code at that point.”

Then the number. “This customer was paying like around a million dollars a day or something on consultants.”

A million dollars a day. And the output was a stack of PowerPoints and a second Christmas party in the same pub.

Tim is originally from Belfast, Northern Ireland, now based in Winchester, UK. He spent 25 years working for four consulting companies — firms like IBM, smaller boutique outfits, eventually Red Hat — before founding Stellafai, a platform built around the idea that consulting should be measured by whether the client actually got somewhere, not by how many hours the consultant billed. He wrote a book on DevOps culture and practice. He posts on LinkedIn the way some people journal — daily, compulsively, working ideas out in public. He describes the habit as “my daily therapy to get things outta my head.”

But the Christmas party stuck. Twenty-two years later, he still returns to it when I ask him where the mission started. “I was still quite a young grad, naive,” he says, “and I thought, well, you know, I guess the leaders and the partners, they know what they’re doing. But I remember thinking then — there’s gotta be a better way.”

What stayed with me wasn’t the anecdote. It was the language that came after it, when he started describing how the industry actually sees the people inside it.

“I had a resource manager,” Tim says. “And their job was to resource me like I was, you know, a tool or a commodity or something.” He lingers on the word. “Not a human being. I was being resourced onto a project and I was a resource in there.”

I’ve worked adjacent to consulting my whole career. I’ve seen the invoices, the statement-of-work theater, the way a project gets scoped at three times the complexity it needs to be. But hearing Tim describe himself as a resource — not a person, a resource — clarified something I hadn’t been able to name. The waste isn’t accidental. It’s structural. The language tells you everything. When you call people resources, you’ve already decided that the system’s job is allocation, not outcomes.

Tim gets to the structural argument and he doesn’t soften it. “It’s actually in the interests of the consulting company to go slower,” he says. “It’s actually in their interests to invent work, to create more work, to create more complexity, to make things look really, really hard.” The repetition is deliberate. He’s not theorizing. He’s describing something he watched happen for two decades.

The time-and-materials model pays consultants by the clock. The longer the engagement, the bigger the invoice. Which means every incentive in the system points toward complication, not resolution. “Then they’re gonna have to, whoa, it’s really, really hard, and now I’m gonna have to spend even more time doing this, but look, get paid more.”

I ask about the alternative — fixed price engagements, where the client locks the consultant into a number. Tim is equally skeptical. “You don’t know what you don’t know at that point,” he says. The consulting firm builds in a massive risk premium. The client writes down everything they think they need, and then reality intervenes. Every change request becomes a billing event. “The consulting company said, well, we’ll just charge for every little change they ask for, ‘cause we know they’re gonna need it.”

Both models are broken. One incentivizes going slower. The other incentivizes building walls around scope. Neither one is oriented toward the thing the client actually needed: an outcome.

The conversation shifts when Tim tells me about the voice in the back of his head. By this point in his career, he’d left the big firms for smaller, more agile shops. He was a committed agile practitioner — long-lived product teams, continuous improvement, feedback loops. He believed in it. Then the voice spoke up.

“You’re a dishonest agileist, Tim,” he says, quoting his own internal monologue. Something in his delivery changes — the rhythm slows, the words land harder. “You believe in these high performing, long lived teams, product teams. But what you do is you assemble projects and these teams come in and then they leave.”

That’s the moment he names it. Dishonest agile. The principles were real, but the practice contradicted them. He was building project teams that dissolved on delivery — the exact opposite of what the methodology called for. “I just thought, yeah, this is dishonest agile.”

It drove him to Red Hat, where the model was different. Enablement over delivery. The job wasn’t to do the work for the client. It was to leave behind a team that could do it themselves. “Leaving behind a high performing team inside the customer,” as he describes it. For the first time, he felt like the work matched the philosophy.

I bring up Christopher Nolan — the director who, when he landed any film, immediately walked to the production studio in the house behind his own so he could start pre-production months before the studio system had a chance to impose its waste. I tell Tim that Nolan’s insight was simple: if you micromanage yourself and proactively report to people, they leave you alone and give you control.

Tim latches onto it. “If I’m open and clear about this is what I’m doing, this is why I’m doing it — generally good things will happen because you get feedback of that transparency.”

The Nolan parallel lands differently than I expected. It’s not about filmmaking. It’s about what happens when you take accountability so thoroughly that the bureaucracy has nothing to manage. That’s the opposite of the consulting model, where opacity is the product.

When Tim describes how he works now, it sounds less like consulting and more like documentary production. “When I go into a room for a three day workshop, I bring my SMO cameras, I mic us all up,” he says. “Someone’s gonna say something or just gonna be this moment, which you’re gonna wanna replay or we’re gonna want to think back to. I just wanna have that digitally stored.”

He captures every workshop on video. Every call gets transcribed. His consultants journal daily — what they’re thinking, what they’re learning, what’s blocking them. All of it feeds into what he calls the brain: a repository of coaching assets, client conversations, outcomes data, and reflective notes that accumulates over the life of an engagement.

“The IP that the consultants brought has sort of got out of people’s heads and into data sets that can then feed the LLM,” he says. That’s the endgame. When the engagement ends and the consultants leave, the client doesn’t just keep a deck. They keep the brain — a system trained on everything the team learned together, able to surface patterns and insights long after the humans who generated them have moved on.

It’s an elegant inversion. Traditional consulting extracts knowledge from the client’s organization and concentrates it in the consultant’s head, where it leaves when the contract ends. Tim is trying to run the transfer in the opposite direction.

But here’s what I didn’t expect. Tim captures everything. He transcribes every call, records every workshop, feeds months of data into AI systems. He is, by any measure, one of the more AI-forward practitioners I’ve encountered in professional services. And yet he draws one hard line.

“I don’t think an AI bot, even if it’s got the most realistic human voice in the world, I don’t see an AI agent being able to do that,” he says. He’s talking about the first meeting — the initial facilitation, the moment when a group of people who don’t yet trust each other have to say what’s actually true. “There’s something about energy and feeling and facilitation and setting up the room and setting up the context to create that safety.”

He describes the facilitators he brings in as people who “make people feel safe in a room” — who can “help get stuff out of people’s heads and onto a wall on sticky notes on whiteboards with tape.” The technology comes after. The recording comes after. The AI comes after. But the act of making a room safe enough for honesty — that’s still a human job.

I think about this after we hang up. The man who mics every workshop and feeds it all into an LLM still believes the most important moment in any engagement is the one no machine can replicate. Not because the technology isn’t good enough yet, but because the thing that makes it work — the feeling of safety, the energy of a room where people decide to stop performing and start telling the truth — doesn’t transfer through a transcript.

He records everything that comes after. But the first act, the one that makes all the rest of it possible, he protects from automation entirely.

Guest Bio: Tim Beattie

Tim Beattie is the Co-founder and CEO of Stellafai, an outcomes-focused consulting platform founded in August 2022 to replace time-billed engagements with an enablement model that leaves client teams permanently more capable. Rising to prominence in the 2010s as a consulting culture leader, he became widely regarded as one of the clearest practitioners working on the gap between what professional services firms promise and what their incentive structures actually deliver. At Stellafai, which reached its first paid customer by October 2022, reached general availability in January 2023, and has reported 10x growth since launch, he leads the effort to make organizational change a measurable, auditable outcome rather than a billable activity.

Previously, as DevOps Culture Enablement lead at Red Hat across Europe and the Middle East, he helped enterprises adopt agile and DevOps as genuine operating philosophies rather than compliance exercises. He became known for identifying and naming what he called “dishonest agile” — the practice of assembling project teams that disbanded immediately after delivery, contradicting the continuity and learning loops that agile methods require. His regional scope encompassed enterprises across two continents during a period of significant enterprise digital transformation.

His career highlights include 25 years across major consulting firms, including IBM and several boutique professional services organizations, where he observed firsthand how time-and-materials billing structurally rewards complexity and delay over outcomes — a dynamic he documented in DevOps Culture and Practice with OpenShift, a practitioner guide integrating lean, agile, and design thinking with hands-on technical enablement. That book, and the framework behind Stellafai, reflect a consistent career mission: making consulting less wasteful, more accountable, and more genuinely enabling.

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.

I ask Marlena Sarunac for a story where adjusting the words moved the numbers. She doesn’t reach for theory. She reaches for a recent client.

“I can speak to maybe like a recent client that we’ve been consulting with, and they’re a very technical team,” she says. They’ve been around for a while. They were spinning out a new product, and the founder couldn’t decide if it was a feature or a product on its own.

“They were spinning out, you know, using AI, like these really complicated whiteboard images about how it works and what are all the features.” She doesn’t say what was on the whiteboards, exactly. She doesn’t have to. Anyone who has watched a technical founder run a sales meeting can fill it in: a stack of capabilities, color-coded, with arrows. Each feature is a pebble in the wall the founder is building between himself and the people writing the checks.

“I kind of forced him to step, take a step back,” she says, “and say, like, what are you actually solving for here?”

What they realized, in the room, was that the wrong audience was paying attention to the wrong things. The users of the product cared about features. The engineers who came to kick the tires cared about features. “But the people who actually were assigning the checks, they wanted to know in a high level — what does this do for me?”

Marlena and her team spent weeks with this client. Not on a logo. Not on a website refresh. On a question: what is the actual gap this product fills?

The answer, when they finally found it, was three words. Last mile gap. A phrase that a healthcare buyer could hold in one hand. A phrase that, the moment it landed in a meeting, did not require a whiteboard.

“It clicked so much quicker, and the CEO started noticing that the conversations were moving along much faster,” Marlena says. “He was getting caught up as a technical founder in these details that were glossing — you know, the buyers were glossing over.” After the phrase, the founder could finally publish content people read. He could move past the question of whether the product was a feature, an idea, a company. “He was able to accelerate from basically, like, is this a product? Is this a feature? Is this an idea? — to: no, this is a company, and we’re actually making sales now.”

I want to be clear about what just happened, because this is the kind of story that sounds, on the surface, like a tagline did all the work. It didn’t. The tagline was the visible artifact of weeks of the kind of work most people don’t see.

I ask Marlena to walk me through that. The strategic insight behind a tagline. Because when a host like me says, “they came up with a phrase,” it can sound trivial, and the marketing pros listening will groan.

“This was, uh, weeks of heads down market analysis,” she says. “Diving deep with the team. Doing workshops where we talked about the product at length.”

She tells me about the early diagnostic. An asynchronous survey her firm sends to the leadership team. Each person writes, separately, what the product does, who the buyer is, who the user is. “Nine out of ten times,” she says, “the team members differ on what they’re — what they all, how they all are interpreting the product, what it’s solving for, and who the buyer is and who the user is.”

I sit with this for a moment. Because what she just described is the actual diagnosis, the thing that is almost always true and almost never spoken: the founding team does not agree on what their company is. Marketing isn’t a wordsmithing problem. Marketing is the symptom. The problem is alignment.

“And nine out of ten times, when we start discussing the results of the survey and the inputs that they put in, they’re actually kind of realizing that’s not what they meant in words, and they need to talk it out.”

The reason a phrase like last mile gap can save a sales cycle is that, by the time the team has agreed it’s the right phrase, they’ve also agreed on something far more expensive to discover: what they’re selling, and to whom.

Marlena keeps using a baking metaphor, and I keep letting her, because it’s good. “You simply can’t skip the process of assembling the ingredients before having your cake,” she says. “And a lot of folks are like, actually, I just want the icing.” Something in her voice lands like a confession when she says it. She has had this conversation, I suspect, about thirty times.

Founders call asking for a tagline. What they actually need is the eight weeks before the tagline.

I ask how she explains this to a CEO who is paying for the work and wants something to show for it before the next investor update. She has another analogy ready. “We’ll have CEOs who are hung up on the color of the walls of the house that hasn’t been built yet.” She’s literal about it, and I think she’s literal because she had to be — at some point, a founder said something like that to her, and she had to find a way to keep him in the conversation without making him feel like a fool.

She invokes technical debt next, and the analogy is doing real work. Engineers understand technical debt. They have rituals for it. They put it in tickets. They argue about it in standups. They write blog posts about how to pay it down. “That happens in marketing and branding as well,” Marlena says. “You could start building something really great, have no brand, have no real messaging behind it. It’s gonna catch up with you, and you’re gonna have to do it retroactively at some point.”

The thing she doesn’t quite say but is implying: brand debt is technical debt with worse instrumentation. There is no compiler error when your founders disagree on what the product does. There is no failing test when your buyers and your users want different things. The cost compounds in ghost meetings and unrenewed contracts and re-architected go-to-market plans. By the time you can see the bill, you are paying interest.

I have been a designer-PM hybrid long enough to recognize this as the same conversation engineers have about prematurely scaled systems. Build it cleanly now or pay to unwind it later. The difference is that brand debt looks, to the founder, like a soft thing — like wallpaper, not load-bearing wall. It is load-bearing wall.

I ask Marlena about her own firm. She and her co-founder, Lubna Hameed, sell brand strategy alongside product design — fractional, not agency, not consulting, not the two Bobs from Office Space. When they launched The Company Advice in March 2024, they had to live the problem they solve. They struggled to position themselves.

“We thought ‘thought partners’ felt a little woowoo and loosey goosey,” she says, “and then ‘agency’ felt a little bit more predictable in a way that we are not.” When they went out to market at the beginning, “people couldn’t make sense of what we did. And we were told, it’s confusing what you do. But in our minds it wasn’t confusing. It was incredibly obvious.”

I write down incredibly obvious because I know exactly what she means and exactly why nobody else in the market did. The clearest things in your own head are the most opaque to a buyer, because the buyer hasn’t had any of the conversations you’ve had. This is the gap. This is the entire reason a fractional CMO has a job.

We talk for a while about the slow, unflashy work of moving from “scrappy startup” to “feels enterprise.” Marlena pauses on Airbnb specifically, because she remembers using it when it felt scrappy. “I don’t think that you’ve noticed that they’ve changed,” she says. “But if you look at the very first iteration of the brand to what it is now, you would definitely notice that there’s been a big difference.” That’s the discipline. The market does not feel a jump. The market feels an evolution. And evolution is just a long string of small, deliberate, internally agreed-upon decisions.

Late in the conversation, I ask her what she thinks of OpenAI’s recent commercial. The one with the actual humans on a road trip, building an itinerary with ChatGPT. She lights up. “I think whoever’s leading brand there — this is, like, a classic, incredible example of people doing their market research first before blowing through gazillions of dollars of budget.”

The point isn’t the commercial. The point is the homework. “They heard the market say, ‘this thing scares us, and it’s replacing human beings,’” Marlena says. “And so for them to run that commercial, that so humanized the benefits of the platform, in such a simple way — that was a brilliant market research connected to strategy play.”

That phrase — market research connected to strategy — is the entire job. Most companies pay for one of the two. Almost nobody pays for the connection between them.

The conversation, somewhere around the middle, takes a turn I didn’t expect. We’re talking about referrals and books and McKinsey, and I float the observation that Marlena is, structurally, a trusted-advisor brand. The hard kind. The kind where the offer is not productized, where the buyer is buying you, where the firm cannot scale without you — at first, and maybe ever. I want to know what that has cost her.

She thinks about it. “I would have a seat at the leadership table,” she says, “but I was almost always, like, the founder or CEO’s, kind of like, more like a background person. Right-hand person. My job was to elevate them, their story, the company story.” A whole career of pushing other people into the spotlight. “And so now that it’s time to turn the playbook around on myself, and put myself in the spotlight — there are moments of discomfort where you kind of have to talk about yourself and validate, you know, why you are confident in this space.”

Something in her voice shifts when she says moments of discomfort. Not heavy. Just honest.

“But it’s starting to get a little bit easier,” she says, “as the years go by. I’m like, you know what, I do know some things, and I am happy to talk about them, and I am happy for the spotlight to be on me.”

I think this is the part that the headline doesn’t quite say. The story I came in with was: she found a phrase, the sales started closing, the founder won. That story is true. But underneath it is a quieter one. Marlena has spent a career doing the unglamorous, slow, specifically-not-the-icing work of figuring out what a company actually means, and now she is doing it for her own. The cake she is baking — slowly, ingredient by ingredient — is her own brand. The spotlight she has spent fifteen years deflecting onto founders is now landing on her, and she is letting it.

The last mile gap, in some ways, is also the gap between knowing how to do something for a thousand other people and learning how to do it for yourself.

Toward the end I ask the throwaway question I usually ask, the kind of question that is mostly there so we can land the conversation, and she gives me the answer that, in retrospect, is the whole essay. We’re talking about how to become a subject matter expert. How to get to the place where people request you by name. How to earn the kind of brand where someone says, we don’t want a marketing consultant, we want Marlena.

“I think that unique contribution comes from being heads down doing the grueling grunt work for a long time,” she says, “until you completely understand the problem from the inside out. You can put a shape to the problem. So when others come to you with their problems, you can — you’ve learned to identify, like, the pattern recognition. You’re like, I’ve seen this before, and I know how to help you.”

There is no shortcut. There is no GPT-ing your way to it.

“You have to do the grunt work. You have to fail.”

She says it almost with affection. Like the failure is part of the recipe. Like the cake she’s been talking about all hour was always — at the bottom of every layer — built out of the things that didn’t work.

When we get off the call, I think about the founder with the whiteboard. The one whose sales cycle was stuck. He had a real product. He had real users. The phrase he was missing wasn’t decorative. It was the load-bearing thing. It was the proof that the room had agreed on something true.

I think most companies are operating without that phrase. I think most founders are still drawing on the whiteboard. And I think that the work Marlena is describing — the workshops, the surveys, the disagreements surfaced in plain English, the cake assembled before the icing — is the kind of work that most people will only pay for after they’ve already paid the brand-debt interest twice.

Three words. Six months of stalled sales reversed. Weeks of work nobody saw.

That’s the actual rate.

About Marlena Sarunac

Marlena Sarunac is the Fractional CMO and co-founder at The Company Advice, a women-owned marketing firm serving early-stage tech startups across health tech, insurtech, and AI. Rising to prominence in the 2020s as a growth-focused operator at the intersection of complex B2B value propositions and go-to-market strategy, she became known for turning technically dense products into compelling market narratives that drive measurable revenue outcomes. She holds a Master of Engineering in Technical Entrepreneurship from Lehigh University, where she won the Joan F. & John M. Thalheimer ‘55 EUREKA! Grand Prize in 2018.

Previously, as Vice President of Marketing at Particle Health, Sarunac led the company’s marketing function from Series A through Series B over 3.5 years, building a data-driven, analytics-first growth strategy centered on revenue outcomes, cross-channel experimentation, and A/B testing across market segments. Her work established Particle Health as a trusted, humanized brand within the health data interoperability space, spanning web design, conference presence, and content programs.

Earlier in her career, as Director of Marketing at Ideon — formerly Vericred, an API platform simplifying health insurance and employee benefits data exchange — Sarunac ran full-spectrum marketing operations including content strategy, PR, SEO, and trade show execution. She directly attributed 40% of all inbound website traffic to marketing initiatives, with an additional 40% driven by an SEO program she built and managed over two years.

At The Company Advice, she created The Healthies, the first awards program recognizing excellence in marketing, branding, and product design in digital health, expanding the firm’s footprint as a thought leadership platform for the sector.

Thanks for reading this far. 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.

Dean Phillips wasn’t a product manager — he was a ClickUp power user who got tired of waiting for someone else to fix the Docs product. He built a 25-slide deck, emailed CEO Zeb Evans, and essentially said: you should build this. Zeb’s reply was a job offer. Five years later, Dean has overseen every major ClickUp product launch without a single direct report.

It’s early 2019. Dean Phillips just been hired at ClickUp. There’s no onboarding. There’s no playbook. The company is post–Series A but small enough that the entire product organization fits in a Zoom call. Zeb Evans, the CEO, has dropped Dean into the Docs backlog and told him, more or less, to figure it out.

So Dean opens the task tracker. There are 150 ideas in there.

“I literally just went through,” he tells me. “I remember it was just like a week and hours and hours and hours of me just going through each task and reading the descriptions.”

He’s narrating this with the specific energy of someone telling a story they’ve never quite told this way before. He’s not bragging. He’s reconstructing. And then he gets to the part that, when he says it, almost makes him laugh.

“And actually finding many of the ones that I had actually written and suggested to them. You know, saying like — this Dean guy suggests this — really good idea.”

I have to ask him to repeat it. Because that’s the whole story, right there, compressed into a single recursive moment. Dean Phillips, day one of his first product job, reading through the Docs backlog and finding his own ideas in the tickets. Not because he was already an employee. Because for two years before he was hired, he’d been so active in the ClickUp community — in the company’s idea board, in the Facebook group, in DMs with the team — that the actual employees had been writing his suggestions down in their own backlog and citing him by name.

He was already in the room before he was in the room. He just hadn’t noticed.

Dean’s official job title these days is Head of Product Strategy at ClickUp. He’s based in Manchester, UK. He works alongside Zeb Evans on the strategy of every product area in the company — Docs, Tasks, Dashboards, Chat, AI. He has no direct reports. By choice. He’s a super IC, in his words. And every major product launch ClickUp has shipped over the last five years has been led by him.

What I want to know, when I get him on the call, is how this happened. Because the cold email story is the thing everyone notices — Dean built a 25-slide deck about ClickUp’s Docs product, sent it to Zeb without permission, and got hired off the back of it. That’s the story you tell at parties. That’s the LinkedIn post. But the cold email is not the actually interesting part.

The actually interesting part is what made the cold email possible.

I ask him about the email. He tells me what’s already half-public — that he wasn’t a product manager, that he didn’t even know product management was a job. He’d run a design agency. He’d been a CTO at an educational company. He’d consulted for WordPress plugin companies. He’d built websites with Adobe Muse, which I make him laugh about because I also used Muse and I had also forgotten Adobe ever made it. None of that work was called “product.” It was called freelancing. He had no title for what he was doing.

But he kept doing it. And he was a heavy ClickUp user — the kind of user who lives in your idea board and tells you what’s wrong with your roadmap. So one day he just sat down and made the deck.

“I actually put together this giant deck,” he tells me, “which was all about how I could see their docs product essentially coming together and all the gaps in the market and everything, and this was purely just from a user’s perspective.”

He sent it. Then, because he’s the kind of person who doesn’t quite trust his own initiative, he basically apologized for it.

“I was like — you should execute this. Please do this.” He pauses, almost embarrassed. “Essentially begging them to do it.”

The response was not what he expected.

“This is amazing. Do you want to come and execute it with us?”

He says it the way you’d describe a punchline you didn’t know you were setting up. Then he gets to the part that I think is more honest than the cold-email mythology gives credit for.

“I was really, really surprised, you know, when I got that,” he says. “Because as I mentioned, I didn’t even know that was something you could do.”

This is what gets me. The lore of the cold email always assumes that the sender knew what they were doing — that the strategy was the email, that the slide deck was a cover for ambition. With Dean, it wasn’t. He didn’t think product management was a real role. He thought he was a fan with too much free time and too many opinions about a productivity tool. The deck wasn’t a job application. The deck was the work he wanted to see done, made tangible. Zeb just happened to recognize what it was.

That’s the thing about cold emails that nobody talks about. They don’t work because they’re cold. They work because the sender has done the work first. The work has to exist before the relationship does. You can’t fake the deck.

When Dean joined, the job description was vague — there was no job description — and the support structure was approximately zero. “There was no, like, no onboarding at all,” he tells me. “Back then they just dropped me in and it was me just going through ClickUp the app, and they were like, figure it out.”

I ask him what figuring it out looked like, in practice. He tells me about the backlog, about the 150 tickets, about the recursive moment of discovering his own ideas. And then he tells me about the part that I think most people who give product career advice would never admit to.

“I had to go through all the tasks,” he says, “and like, secretly look at people’s product briefs and see if I could replicate them.”

He says it lightly, but it’s the most honest description of how new product managers learn that I’ve heard from anyone with his title. He didn’t take a course. He didn’t read jobs-to-be-done — well, he tried, and it didn’t fit. He didn’t get a mentor sit-down. He went into ClickUp and read what the other PMs had written and tried to figure out the shape of the artifact by inference. He literally watched what other people were producing and reverse-engineered the form.

The image I can’t get out of my head is Dean, in his office in Manchester, in the first weeks of 2019, scrolling through other PMs’ product briefs in the company’s own task management software, trying to figure out what a product brief is. There’s something perfect about that. He used the product to learn the role.

Then there’s the moment a few weeks in when he gets told the words front end and back end.

“I had to ask the engineers — like, is this a front end task or a back end task?”

He says it without performing humility. He’s not making a joke at his own expense. He’s just describing what it was actually like. He’d built websites for years. He’d done the database stuff. He just hadn’t known there were terms for it.

This is the part of the story that I think gets lost in the standard “atypical career” arc. The standard version goes: someone with a non-traditional background takes a leap, struggles with imposter syndrome, eventually makes it. Dean’s version is the same shape but with one important difference — he never seems to have been blocked by the gap. He just absorbed it. He read the briefs. He asked the engineers. He sketched things in Figma instead of writing six-page docs. He sent Looms.

“That came very, very natural to me,” he says about the visual, async style. “Where apparently that isn’t how other PMs in the company were working. They were doing these long documents.” He pauses. “I was never going to do that, because it wasn’t something I was taught.”

What he doesn’t quite name is the actual pattern. The thing he was doing — sketching, looming, sending visual briefs — wasn’t a workaround. It was the better tool. He was bringing in skills from his agency life and his music-producer life and finding that they fit ClickUp’s culture better than the traditional PM stack would have. He thought he was hiding a deficiency. He was actually demonstrating an advantage.

Six to eight weeks in, Zeb made the call.

“I’m going to do a whole relaunch of docs and you’re going to lead it,” Dean recalls Zeb saying. “And we’re going to build you a whole team around it. And you’re going to be the first person at ClickUp with a team.”

He had to ask his engineers what the difference was between front-end and back-end. And he was about to be the first PM at the company to have a dedicated squad built around him. Eight weeks. From cold-emailing the CEO to leading the team that would relaunch one of the company’s most-used products.

I ask him what made it work. He gives me a few answers, all true, none of them quite the one I’m fishing for. He talks about Akram, the designer he was paired with, who could just grasp the vision Dean wanted. He talks about how the project ran long — “ended up taking a really long time, three to four months” — because he was acting as engineering manager, product manager, and lead designer simultaneously. He talks about the Docs relaunch with the kind of pride that’s six years in the rearview now and has the warmth that only comes with that distance.

But the answer I think is actually true comes later in the conversation, when I almost throw it away as a tangent. We’ve been talking about ClickUp Chat — the chat product they shipped in 2024 — and how Dean had been writing internal docs about communication being broken since 2022. He sat on the idea for two years. He kept telling people, “put it in a task.” He waited for the right moment. The moment came when one engineer randomly built a weekend POC and sent it to him and Zeb. That was the green light.

“I really, about two years ago, wrote this document of communication is broken,” he tells me. “Here’s where, this is like what we need to do to fix it.”

I ask him how he keeps all of this in his head. ClickUp ships across roughly twelve product areas. He works with every PM. He reviews every vision document. He doesn’t have an org chart of direct reports — he just has the relationships and the memory and his own pulse on what each team is doing.

His answer is so casual I almost miss it.

“I just have a pulse on everything. That’s just kind of who I am, to be honest. I wish I had a system for tracking that.”

I push him on it. Because in my experience, people who say things like “I just remember everything” are either lying or about to confess something more interesting. Dean confesses.

“I love it,” he says. “I’m obsessed with figuring out and helping our customers. It sounds really cheesy, but I am, I’m really obsessed with just making the product better.”

He keeps going. He tells me he dreams about it. He tells me about going for walks with his partner and having to voice-memo himself an idea that just hit. He tells me — and this is the line that lands the entire arc of the story for me — “it’s always in my mind. I’m always thinking about how I want to improve certain parts of the product.”

That’s the thing. The cold email worked because Dean had been thinking about ClickUp constantly for two years before he sent it. The 25-slide deck wasn’t ambition. It was overflow. He had so much accumulated thought about the Docs product that the deck was just the part of it he could externalize. Zeb didn’t hire a stranger. He hired the most active member of his community. The cold email is the headline, but the headline obscures the actual mechanism, which is much harder to copy.

You can’t fake the deck. You can’t fake two years of obsession. You can write the email — a million people can write the email — but if there’s nothing underneath the email, the reply will be a polite no.

Five years in, Dean’s role has expanded to the strategy of every product area at ClickUp. He’s a super IC by choice. He doesn’t want the management track. He wants to keep being deep in the work, writing visions with PMs, sketching in Figma, sending Looms at odd hours. The people on his team trust him because he’s been there longest and because every major launch has gone through him. He doesn’t have authority. He has track record.

We talk about how he’s had to evolve. The thing he says he’s worked hardest on over the last twelve months is what he calls “getting the context out of my head.” He used to keep everything internal — vision, strategy, the next three moves — because to him it was already there, easily retrievable. He didn’t see why he needed to write it down.

“When you’re leading product strategy,” he says, “everyone needs to know how to get from A to B to C.”

He’s been writing more. Documenting more. Whiteboarding the vision with every PM in long async sessions. He calls it working with the garage door open — a phrase he picked up recently, the idea being that you let people see the work in progress. As a musician, he says, you’d be working on songs in your garage and people walking past could see what you were doing. They wouldn’t come in. They’d just see.

That’s the image I’m left with after we end the call. Dean Phillips in his Manchester office, garage door up, working on the next thing, voice-memoing the idea that just hit. The cold email is what got him in the door. The obsession is what kept the door open. And the willingness to leave the garage door open is what makes him able to do the job at scale.

Most career playbooks tell you to send the email. Almost none of them tell you what to be doing in the years before you send it. Dean’s answer, if you push him for one — and I did — is unsentimental. You have to actually care about the product. You have to be obsessed enough that the deck builds itself.

The rest is just hitting send.

About Dean Phillips

Dean Phillips is the Head of Product Strategy at ClickUp, where he leads the product direction for ClickUp Docs and the company’s emerging AI-powered Super Agents. Rising to prominence in the early 2020s, he became known for translating complex workflows into opinionated, high-leverage product systems inside a platform used by millions of users worldwide. At ClickUp, he currently oversees strategic initiatives that connect document creation, task management, and AI automation into a single unified experience.

Previously, as Head of Product Strategy and Product Manager at ClickUp, he helped scale the product organization through more than five years of rapid growth, serving in core product roles from December 2020 through at least early 2026. He became known for shipping multi-quarter initiatives that spanned Docs, collaboration surfaces, and workflow automation, partnering closely with engineering and data teams to improve productivity at scale. Before ClickUp, he served as Chief Technology Officer at The Pattern Trader, where over four and a half years he led full-stack product and technology efforts for a trading and analytics platform.

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.

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