This podcast is a live conversation I hosted for Skip Coach, a community of senior product and tech leaders navigating career transitions together. Members get access to live sessions like this one, including real-time Q&A, before the content is shared publicly. If you’re a product or tech leader looking to maximize your career, apply to join Skip Coach — it’s free — to access this content and other exclusive resources.
Listen on YouTube, Spotify, and Apple Podcasts
Brought to you by:
Stripe Wants More Than a PM Who Can Build
At Stripe, a new PM gets the full stack on day one — the latest models, the internal coding agents, real data. One of the first onboarding exercises: ask an agent a question you’d normally ask a person. Building isn’t a differentiator there, and it isn’t a nice-to-have either. It’s a prerequisite for the job — and the best companies are converging on the same bar.
I sat down with Kevin Yien to ask what Stripe wants from PMs beyond that. Kevin runs merchant experiences at Stripe — the dashboard, the mobile apps, the new agentic Console announced at Sessions — and he’s one of the clearest product thinkers I know; his Lenny’s Podcast episode is worth the detour on its own. This is the second conversation in our Inside PM series, after June’s look inside Meta. That episode was about the org — how reviews, status, and decisions get rebuilt around agents. This one is about the job.
For two years the message to product people — including from me — has been: become a builder. Get hands-on, prototype your own ideas, stop waiting for engineering. Stripe took that seriously earlier than almost anyone, and it worked. Which is why the conversation inside Stripe has already moved on. When an engineer can spin up fifty agents overnight, why exactly is a PM proud of shipping pull requests?
The harder question — the one this episode is about — is the right way to do this job when the tools are everywhere and the business still needs you to move it.
Kevin is unusually qualified to answer, and the answer changes how you should shape your PM career over the coming year. One reassurance before we start: adoption inside Stripe is uneven too — “an uneven Gaussian distribution,” Kevin calls it, and he thinks that’s healthy. If your company is still mid-adoption, this isn’t a report card. It’s a preview.
Kevin’s answer keeps coming back to one word — judgment — and it starts with an engineer telling him to knock something off. The six moves below are the spine. The episode goes deeper on every one of them, in Kevin’s own telling — worth your time.
Hand Your Old Floor to the Machine
Kevin got addicted to shipping fixes with agents. An engineer told him to knock it off — and he was right.
Kevin came up as a builder, so when Stripe gave PMs access to Minions, its internal coding agent, he dove in headfirst. Suddenly he had what felt like “magical powers” — “I can fix all these bugs myself.” He’d spot a bug, drop a description and a screenshot into a public Slack channel, and a pull request would come back ready to hand to an engineer on his team. “I got high on just shipping a bunch of fixes.” Visible, countable progress, several times a day.
Then a close engineering friend pinged him.
“I can trigger ten, 20, 50 agents at a time to go fix all those things… Why are you wasting any of your calories on fixing this localization string when what I need from you is to figure out the directional five-degree shift that we have to make as a business in the next one, two, three years?”
Kevin knew what his honest answer was — because it’s interesting, because it’s fun — and the engineer’s point stood anyway. Anyone can fix the typo now. What the team could not get from anyone else was the direction call: the five degrees that determine where three years of compounding effort lands.
Notice who pushed whom. Six months ago, the badge of a modern PM was shipping pull requests. Here an engineer told the PM to stop — and pushed him toward opinion, not output. Kevin’s frame for the whole shift hangs on this moment. Skip the “which role dies” debate, which he’s watched go in a circle: “PM’s dead, and then design is dead, and then engineering is dead.” What’s actually happening: “It’s not one function eating another. It’s every function collectively moving over so that we can all actually get more done.” Everyone hands their old floor to the machine and moves up a level.
The shift has teeth, though. The lines between roles were never clean, and now “there are gonna be designers or engineers that fully lap PMs that are static… you will get lapped, you will get replaced.” That’s a career fork. Some PMs will realize the part they loved was the building itself and go back to engineering — a legitimate move, not a demotion. The rest shift deeper into the strategic and judgment work, into what Kevin calls uncharted territory. Either direction works. Static is the only losing pick.
Ten Prototypes, Zero Users, Zero Point
Exploration is fine. Performance isn’t. The new bar is the first dollar.
Kevin’s pet peeve, in his words: things that get celebrated “with absolutely no impact on our users.” The exchange he described has probably happened at your company this quarter. A PM proudly reports ten prototypes built last week. How many users saw them? Zero. How many decisions did they influence? Zero. Did you develop conviction in a direction? No. Then what was the point?
He’s careful about what he’s not attacking. Messing around with the tools to learn them is, in his words, awesome — that’s how you find novel things. The problem is promotion theater: output volume standing in for conviction. It’s the same trade the engineer forced on him — calories belong on decisions and direction, and a prototype that changed no decision spent them on applause.
So where does that leave PM builders? Two things changed. First, a small team can win real customers without the overhead of the main product. Stripe Projects — one of the hits of this year’s Sessions — started as “two and a half people” building for a few weeks, validating with five to ten trusted users, then earning more investment as the customer pull showed up. What keeps a bet that size honest: “the willingness to kill your darlings,” and keeping the blast radius small for as long as you can. Second, an early release can be feature-rich, not anemic. The old dogma slimmed first versions down to the bone; Kevin’s teams now go the opposite direction — “you can just go much wider and move much faster.” The same test applies to anything you build on your own as practice: a real problem, a real user, and “that first dollar” — getting paid is the proof you made something people actually want.
For your own career, Kevin turns this into a practice regimen. A decade ago someone asked him a question that stuck: “What’s the equivalent of piano scales for a PM?” His answer used to be writing — not writing for its own sake, but forming an opinion on the page — and it still is. The new scale is learning the agent itself, the step almost everyone skips and the one he calls “a complete untapped learning opportunity.” As it builds, ask what decisions it’s making and why. When the first version doesn’t feel beautiful, take a screenshot of your favorite app, put it next to the screen the agent made, and have it walk you through the difference. “You will develop a new vocabulary you didn’t have before” — the vocabulary that separates slop from “high grade and really freaking good.” Nobody can hand you that vocabulary. You earn it one comparison at a time.
Your Writing Now Has Two Audiences
Persuasion for humans, pseudocode for agents — and the machine still can’t do the first one.
On Lenny’s Podcast two years ago, Kevin planted a flag: writing is clarity at scale. I pushed him on whether LLMs have knocked it down. His answer: “further validated.” What’s changed is that writing split in two — “there’s writing for other humans/yourself, and then there’s writing for your robot friends.”
Writing for humans is no longer about information transfer. “The robots can do that just fine.” What’s left is the part that was always hardest: persuasion. Getting another person to hold the same belief you do. However good the prose an LLM produces, Kevin keeps hitting the same wall — “do the relevant stakeholders believe it?” A perfect document nobody believes moves nothing. Writing for agents is the opposite discipline: precise instruction, “almost pseudocode, but in natural language.” Two audiences, two crafts, one skill underneath — knowing what you think.
Which is why his take on the tools runs against the current mood. “It’s funny you mentioned that LLMs are getting really good at writing. I actually think they suck.” They synthesize, they distill, they repeat — what they don’t do is produce something genuinely new from your half-formed thinking. He’s built a personally tuned tone-of-Kevin skill, and even that is garbage in, garbage out. The failure mode he sees everywhere is “the fantasy of one shot” — the hope that the perfect prompt yields the perfect strategy doc.
“What you actually want is low shot, and you want to have a very specific, refined conversation with an agent that understands the thing you’re trying to get to.”
A low-shot conversation only works if you bring an opinion to it. “You have to force an opinion onto whatever agent you’re using for it to produce the thing that you want, and that’s what you hold.” That’s the career advice of the episode — a practiced skill, not a fact you learn. The PM who can force an opinion into the machine and get a room of humans to believe the output owns something no tool subscription provides.
Build the System That Builds the Product
A team brain gives your engineers a glimmer of your judgment — if you feed it judgment, not transcripts.
The mindset shift Kevin would send back to his two-years-ago self: your job stops being “use the tools to do your work” and becomes building the system that then builds the product. What survives untouched is the oldest part of the job. “You are the arbiter of context” — gathering it, distilling it, pushing it to the right people. What changed is the audience. Your context now has to reach your teammates and your agents, and it has to work when you’re not in the room.
He’s watched the same evolution in pocket after pocket of the industry. Everyone built a personal knowledge corpus — Claude Code plus Obsidian, notes wired into an agent. Then everyone hit the sharing wall: a repo someone forks, versions drift, the whole thing rots. The working answer sits at the team level: a shared knowledge repository where every customer call, every insight, every support ticket lands.
What you feed it decides what you get back. Pipe in raw transcripts and you’ve built a search engine. Kevin’s bar for every entry is the “hop, skip, and a jump” — what they said, what they meant, and then what you think, given what the company cares about and where the product needs to go. It’s the same forcing of opinion as the last section, aimed at your team’s memory this time. What you’re building is a record of what good looks like to you. The judgment layer is the work.
Build that, and the payoff shows up at 2 AM. An engineer picks up a bug and, instead of pinging you, asks the agent sitting on the team’s brain — and gets “the close enough thing… a glimmer of the same judgment.” Engineers and designers start making product calls without waiting. Your judgment scales without your calendar. Read it against the fork in the first section: the static PM gets lapped, but the PM whose recorded judgment answers questions while they sleep is the opposite of static. A team brain with your opinion in it is evidence of seniority that doesn’t depend on your title.
The Deep Generalists Are Winning
The edge is the opinion you point your agents at — and it comes from somewhere real.
Kevin’s bar for entering product hasn’t moved in a decade: come with “a basis of beliefs” earned somewhere real — engineering, design, sales, support — not “I’ve read the top 10 books on product management.” What the AI era changed is which beliefs pay. Non-technical PMs from sales, strategy, and ops “can be extremely successful — that has always been true, and I think it’s especially true today.” (His honest Stripe caveat: when your customer is a developer, technical depth still matters. Calibrate to what your product serves.)
His name for the winning profile is the era of the “deep generalist.” The deep half is earned experience, not domain facts. Anyone can ask an LLM about payments. What it can’t supply is what years inside a domain leave behind — the lessons, the subtle nuances, the feel for why the obvious idea fails there. That’s “the point of view that you can point your agents at.” The generalist half is refusing to be confined by the job spec — pushing its edges “not because they have to own more, but because they believe they can do more.”
This is the second time this series has landed here. At Meta, Jagjit told me his economics and physics PhDs were outperforming classically technical PMs, reasoning from first principles instead of from the architecture. Kevin arrived at the same screen from a completely different company. Your unfair advantage in this market is not tool fluency. It’s what you’ve lived that the model hasn’t.
Start With One Friend and a Text File
Best practices reset every two to three months. Build up — don’t work backwards from someone’s golden setup.
If your company is nowhere near any of this, Kevin’s on-ramp requires no budget and no permission. Don’t pilot a knowledge system with fifty PMs. “Why don’t you just start with a friend?” One peer, or one or two of your directs. Plain text or markdown — “the thing that is most malleable” — no schemas, no database, no tooling decision that takes a quarter. Then the habit that carries the whole thing: a daily friction log. “Write down the points of friction as you go through that process day in, day out,” and knock them down one at a time.
One warning: don’t work backwards from a golden artifact. The influencer’s Obsidian vault, the perfect setup thread — by the time you’ve copied it, it’s stale. “The best practice changes every two to three months right now,” so building up from your own frictions beats installing someone else’s conclusions.
Stripe’s version of this has more horsepower — tools on day one, onboarding that routes you to the internal agent before you can ask a human, leadership demoing its own workflows because “leaders have to lead, and carrots work better than sticks.” But you don’t need any of it to start. One friend, one text file, this week.
Your Next Twelve Months
Six things worth acting on from the conversation:
Pick your side of the fork. Everyone shifts left. If what you loved was the building, going back to engineering is an honest answer. If the strategic and judgment territory pulls you, go — it’s uncharted. The only losing choice is standing still while someone laps you.
Retire the demo as your unit of progress. Count users touched, decisions changed, conviction earned. A prototype that moved none of those was theater — and run the full cycle at least once, all the way to the first dollar.
Practice both writings. The persuasion doc that makes stakeholders believe, and the natural-language pseudocode that makes agents precise. Low-shot conversations, never one-shot fantasies — and the opinion you force in is the part that’s yours.
Start the team brain small. One friend, plain text, judgment layered onto everything you pipe in. A system that answers like you when you’re not in the room is the new evidence of seniority.
Go deep somewhere real. Domain insight is the one input your agents can’t generate. Pair it with the nerve to push past your job spec.
Friction-log your way forward. Ten minutes a day, one knocked-down friction at a time — and ignore the golden setups, which expire quarterly anyway.
The thread under all six: the tools stopped being the differentiator the moment everyone got them. When everyone can build, the edge is the opinion you force into the machine — and that’s what you hold.
Have your own career question? Get personalized guidance at Nikhyl.AI. It’s where the questions keep coming, and where I’ll keep sharing what I’m learning.






