Kevin Yien on PM Career, the Decision Log, and Hiring at Stripe
Source: Lenny’s Podcast Speaker: Kevin Yien Link: https://www.lennysnewsletter.com/podcast
Key ideas
- Don’t enter product management directly. Start as an engineer, designer, salesperson, or support rep first. PM work is converting potential (teams) into kinetic energy (delivered value); people who have built, sold, or supported things understand the constraints that make that conversion possible.
- Product sense is built through documented reps, not intuition. Keep a decision log: record each decision made, the reasoning behind it, and then the outcome. Closing this loop — observing what actually happened — is the only mechanism for improving judgement with insufficient data.
- If you can’t sell or support your own product, you shouldn’t be building it. PMs who haven’t done frontline work drift toward internal stakeholder management; they lose the ground-level instincts that make product decisions reliable.
- The unsell email filters for resilience and genuine alignment. When a candidate reaches offer stage, Yien sends an email that lists every genuinely terrible thing about the role — reinforcing their own stated fears. Candidates who read it and remain equally excited are A+ hires. Those who go cold were never truly aligned.
How to become a great PM
Yien’s core argument against the direct PM path: the role is fundamentally about converting team potential into customer value, and that conversion requires understanding constraints. Engineers know what is hard to build. Designers know what breaks under user behaviour. Sales reps know what the market actually rejects. Support reps know where the product fails. Someone who comes to PM without any of that experience manages by abstraction — they speak the language of outcomes without understanding the machinery that produces them.
The decision log addresses the development problem directly. Product sense — the ability to make good calls with incomplete information — is widely treated as innate. Yien treats it as a skill acquired through feedback loops. The mechanism: document each decision and its rationale at the time it is made, then record what actually happened. Without closing the loop, there is no signal; with it, patterns emerge. Decisions that felt confident but were wrong reveal the blind spots. Decisions that felt uncertain but proved correct reveal where instincts are more reliable than they seem.
Yien’s sell/support principle pushes against the tendency for PM work to become purely internal. Stakeholder alignment, roadmap negotiation, and cross-functional coordination are genuine PM responsibilities — but they can crowd out the direct product contact that makes those responsibilities executable. PMs who have taken support calls or run sales demos carry a different mental model of the user than those who have only read research reports.
Hiring
The unsell email is Yien’s most distinctive hiring tool. At the offer stage, when a candidate has already expressed enthusiasm, he sends a message that lists all the genuinely difficult things about the job — the specific frustrations the candidate has already voiced, plus structural realities of the role. The test is not whether they can handle bad news; it is whether their enthusiasm survives an honest inventory. Candidates who read it and remain as excited as before have passed the filter. The email selects for people who want this specific job for considered reasons, not people who want a job.
The broader hiring philosophy asks: what does this person want to become, and does this role serve that trajectory? Misaligned hires — people for whom the role is a detour rather than a direction — underperform not from lack of skill but from lack of conviction.
PM–engineer relationship
Yien argues that PM–engineer relationships improve when the PM treats the engineering work as genuinely interesting rather than as a constraint to negotiate around. Meeting engineers on their terms — understanding the how, not just conveying the what — changes the nature of the working relationship. Curiosity is the mechanism; it signals that the PM sees the engineer’s domain as real rather than as a black box that produces features on request.