Lessons From Three Product Leaders Living in the Future

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:

Firecrawl: Power AI agents with clean web data—Use code: THESKIP to get 10,000 free credits today.

---

For the first half of the year, the advice in every AI conversation — mine included — was some version of get hands-on: open the tools, build something, feel it. It worked, mostly. But then a crop of harder questions surfaced as theatrics took hold, tokens got more expensive, and the ROI conversation arrived. Who should actually be building? How should information move through a company in the AI era? What’s the role of PM at a company with real constraints? Is all of this adding value — or just satisfying leadership, or an itch?

We started tackling those questions last month with Inside Stripe — a look inside a company that put AI in its teams’ hands earlier than most. This month goes a step further out. I sat down with three CPOs who have installed and repositioned product management inside their companies to drive value and avoid the theater: Sharmeen Chapp, CPO at Midjourney and the company’s first-ever product hire; Jiaona Zhang — JZ — CPO at Laurel; and Henrik Berggren, who runs product and design at Mutiny. Their product teams are tiny on purpose: two PMs and one designer at Mutiny, three people at Midjourney, nine across product and design at Laurel.

Don’t mistake small for reckless. These companies carry years of history, paying customers, enterprise contracts, and teams that predate the AI wave — not the frictionless blank slate that “AI-native” suggests on social media. That’s what makes their lessons useful: they iterate faster than anyone, so the questions above landed on them first. And the answers aren’t just for PMs — they’re about how products get built and who builds them, at companies of any size. Here’s the map — this year’s conventional wisdom, and what the teams a year ahead are doing instead:

---

Make the Whole Company Understand the Customer

Sharmeen showed up at Midjourney as the company’s first-ever product hire — a research-led company that was new to product management, and unsure it needed it. Her move was to go back to the oldest tenet of the job: understand the customer better than anyone. The difference is what came next. In the past, that understanding was the PM’s to hold; now everyone is building, so the problem to solve is opening the gate — making customer understanding live across the whole company. Her mechanism: user calls several times a week with engineers in the room, because nothing teaches like watching “a new user stumble through the experience for the first time.” Her reasoning:

“If anyone can ship and everyone is building, the most important thing you can do is make sure that everyone has the judgment to build the right thing for the user.”

Henrik runs the same play at Mutiny with better plumbing than he’s ever had: customer calls flow straight to the engineers building that feature, a recorded call becomes a company-wide artifact in minutes — and the engineers with product instincts make the product decisions themselves, sometimes shipping what the customer asked for without a PM translating in between.

PM used to start at a company by solving an inside-the-building problem: move information around, run the process, keep the machine coordinated. AI makes that dramatically easier now. The problem that grows is outside the building — as a customer base scales, truly knowing the customer gets harder every year — and bringing that signal inside is worth far more than another process improvement. Understanding the customer was always at the top of the PM’s list. The gatekeeping was never intentional — information simply had to travel through one person, because that was the state of the art. That part is over.

Engineering Is No Longer the Gatekeeper

Think about how a bug fix used to happen. A support rep, a salesperson, or a PM heard about an issue — and the issue began its long walk through the org: written up, handed off, translated for engineering, then weighed in prioritization against everything else on the roadmap. Most issues never survived the walk. If something affected only a handful of customers, it died in the queue, no matter how much it mattered to them.

Now that anyone can build, the walk is disappearing. The person who understands the issue best attempts to fix it — even when it affects rather few. Laurel’s customer success managers ship admin changes live within 24 hours — when they can understand and reproduce a customer’s problem themselves, there’s no reason to route it through layers of the org. At Mutiny, anyone on the team can ask Cursor to investigate a customer-reported bug — engineers review the PR, Cursor announces the merge, and since bigger customers share Slack channels with the team, the “it’s fixed, try again” follow-up lands almost immediately. Sharmeen was mid-user-call when her user hit a bug; she messaged Midjourney’s internal agent — this screen, this behavior, here’s what should have happened — and a pull request was waiting for engineering review before the call ended.

“The concept of backlogs just doesn’t even exist anymore.”

It’s the second gate to fall: customer understanding opened to everyone, and now building has too. Two things keep it honest. Shipping rights follow understanding, not availability — a PM grinding through typo fixes is doing work an agent fleet does better, while the customer success manager shipping the change only she understands is the entire point. And it only works where the codebase is ready for it — making your surfaces legible to agents and humans alike is the transformation work.

JZ’s version of that work is zoning the codebase like a garden. Some beds are mid-landscaping: core engineering is re-architecting them, and nobody else plants there until the new layout is in — you don’t drop a random tulip where the irrigation is going. The manicured garden is the re-architected admin — clean beds, labeled planters — where even non-technical people plant freely; it’s where customer success ships those 24-hour changes. The weeds are the corners nobody plans to tend for months: plant whatever you like, since the testing guardrails keep bugs from reaching production either way.

The payoff is cultural as much as operational: the whole company starts to own the product’s quality and relevance, customers feel software that responds in hours instead of quarters, and the PM’s job becomes making sure everyone who understands a problem is equipped to fix it.

The Transformation Was Built, Not Mandated

None of this happened overnight, and none of it came from leaderboards or vanity metrics — Henrik writes off the token-maximization trend as “a blip in time,” like measuring lines of code. Most leaders reach for carrots and sticks to drive AI use, then worry about overcorrecting — pushing too hard, spending too much, never seeing the ROI. These leaders did something different: they treated the transformation as a product and cultural problem, and built what amounts to a new operating system for the company. The highlights:

• Treat employees as users. JZ ran adoption the way she’d run a launch: watch what people actually use, track the value it creates, and when adoption lags, fix the product instead of blaming the people.

• Engineer the first win — and make the wins visible. JZ put a cash bonus on the first go-to-market feature shipped to production; people raced to land their PRs from the TSA line. Henrik wired a Slack channel at Mutiny that pings when a customer does something meaningful — an upgrade, a first try of a new capability, a complex automation built — so the team wakes up to a feed of the product being used, and momentum does the motivating.

• One shared skill per job, pruned hard. “Three people create a bunch of skills, and then the rest have to figure out which ones to go adopt” (JZ). Sharmeen’s version: one shared research skill turns a 30-minute user interview into takeaways and highlight clips posted company-wide within 45 minutes — everyone uses the same one.

• Measure time, not tokens. Write down where you believe people’s time should go — less documentation, more building with customers — then check whether the shared skills get used. When adoption stalls, the numbers tell you where.

• Expect people to step over the line. Henrik’s counterweight to rulemaking: “the only way of knowing that you’re close to the line is that you’re sometimes stepping over it.” Mutiny accepts that some releases will go out half-polished rather than putting a review in front of every change — resilience in the team beats a gate in the process.

• Run AI in public, inside the tools people already use. Midjourney’s agent lives in a shared channel where the experts teach the whole company — hallucinations get caught in real time, and skeptics convert by watching value land. JZ’s rule: “you gotta put AI into where people are” — her agents live inside Slack, with a filing-cabinet emoji that files every correction into permanent memory.

• Pair AI-native hackers with tenured leaders. Laurel’s AI Operations team matches new-grad tinkerers with functional leaders: the leader knows the outcomes, the hacker has the cycles for every model drop. Neither transforms anything alone.

One reason they can live this close to the edge: these are growth companies racing to extend a lead and expand their product lines. They have more to gain from pushing hard than from playing it conservative to protect momentum — at a larger company, the same playbook applies with the zones drawn tighter. And none of it is theater. These companies aren’t doing AI to satisfy leadership or an itch; they’re chasing real competitive advantage — and pulling it off took dozens of changes across product, culture, org structure, and skill base.

---

Additional highlights

A few more insights from the conversation that I found notably helpful — especially if you and your team are working out how to get the most from AI:

• Lean is the new career northstar — manage a fleet, not an empire. “The leaner your team, the more attractive it is.” Titles, headcount, and scope stopped being the currency, and for people who love managing, JZ offers the reframe: “you have infinite interns that you can spin up at any time.” Sharmeen’s calendar shows the trade — 7am–5pm meetings at Stripe, 20–30% now, the rest spent building.

• The side doors into product management reopened. New grads used to face a catch-22: you needed the PM title to land a PM job. Now they can enter through AI operations or on-site customer-building roles, shipping real solutions from day one. Worth remembering when you’re hiring or mentoring early-career talent.

• The strongest leaders of the next decade are making this shift now. Engineering saw it first: CTOs with big organizations are going back to being hands-on ICs. Henrik’s bet — “the people who are making this shift now will emerge as the absolute strongest leaders in the next five to ten years.” And in his words, we’re still in the first inning.

• Sprint when the tools jump; rest on purpose. JZ calls it cheetah speed: when a new capability lands, go hard — she spent ten straight weekends building — then deliberately recover and consolidate. The tools improve in leaps, so running flat-out all the time is the wrong strategy.

• Filtering is the new prioritization. AI makes output cheap, so the discipline shifts from choosing what to build to filtering what you’ve already produced — “or you’ll start looking at slop instead of what’s really valuable.”

• Expect to reinstall some process — deliberately. Midjourney ran on almost no coordination until the seams showed; Sharmeen is now adding back “the healthiest amount” — enough that teams stop colliding, not enough to slow anyone down. The pendulum swings partway back — add the process deliberately, before a mess adds it for you.

The thread through all of it: the product org is turning inside out. Customer signal flows in from the people closest to it; judgment flows out until everyone can build the right thing; and the product leader runs that exchange instead of sitting in the middle of it. None of this is a prediction — it’s how three real companies with real constraints operate today, maybe a year before the rest of us. The full conversation is in the episode, and it’s worth your hour.

---

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.