Build First, Then Product Manage: Kevin Yien's Unorthodox PM Playbook

Kevin Yien discourages people from going straight into product management and instead points them toward engineering, design or sales. He defines the PM practice as converting a team's potential energy into realized customer value, with as little loss as possible. When a product is just starting, the people who should do that conversion are the people building it, because they sit on the smallest loop and get the most direct exposure to what it takes to make something good. That foundation, he argues, later lets someone take on the PM role with a more useful and unique perspective.

He extends the argument beyond individual careers: not every team needs a product manager, but the activities a PM would drive still have to get done. Companies often cite successful firms that had no PMs, yet those firms were frequently building for themselves—Stripe and Twilio for developers, Figma for designers—so the builder could also be the customer. Snap is another example he cites, waiting until roughly 200 people before hiring its first PM because other people were already doing the prioritizing, clarifying and aligning. The question is whether designers or engineers want to do that work and are good at it; if not, the need for a PM eventually appears.

For people who do want to become PMs, Yien recommends starting in one of the foundational three roles: engineer, designer or salesperson, ideally the role whose responsibilities the PM would be taking over. Sales, he notes, is often misrepresented as quota-chasing, while the best salespeople are great listeners who understand the customer's problem and translate it into an offer. He also rejects the framing that someone becomes a PM because they are not world-class at engineering or design. A better framing is that they may be okay at those things but potentially world-class at product, so they should double down and see how it feels.

Yien calls writing clarity at scale and says clarity is central to the PM job both internally and externally. Many PMs become too internal, focused on stakeholder influence and alignment, but he insists that crisp PRDs are only part of the job. A PM should also be able to write compelling messaging in the voice of the person the product serves. His test is blunt: if you cannot sell or support your own product, he does not trust you to build it.

He describes writing as a two-stage act: first it translates a half-formed thought into something the author can actually understand, then it needs additional revisions so other people can consume it properly. That second stage is the extra mile many people skip, and it matters because a PM's job is to unlock the team's potential and keep everyone aligned behind a clear sense of what is being done. A Joan Didion line captures the first stage for him: he does not know what he thinks until he has written it down.

To become a better writer, Yien recommends consuming as much compelling writing as possible, not just reading PRDs, support articles or other PM artifacts. He borrows an Anthony Bourdain idea: to make good food you have to eat a lot of food and be willing to have a bad meal now and then. Paul Graham's essays are a model of succinct, clear thinking, and Yien suggests finding specific voices whose longer essays or posts contain their crisper thinking. He also values cadence—intentionally varying short and long sentences—and points to Several Short Sentences About Writing as a useful guide.

At Square, Yien joined a new point-of-sale product line with three engineers and three designers, an unusually design-heavy ratio that he credits with raising the quality of the work and thinking. The team already had designs and was unsure what a PRD was for, so he described the PM role as drawing the perimeter of the problem space. Engineers and designers could go as crazy as they wanted inside that box, but the constraints made their creativity productive. He also favors putting a concrete draft in front of people—a tuning fork—rather than asking abstractly what they think, because people react better to something real.

He warns against the opposite failure too: a PM who is only a strategy person in the clouds and does not care whether value reaches the customer. In the restaurant point-of-sale example, the team obsessed over the animation that opened a menu group, because bartenders with muscle memory and first-time workers both had to feel the interaction was fast and obvious. Yien and a designer spent a week tuning milliseconds and testing prototypes with servers and bartenders, watching where they hesitated. He says a PM cannot define a requirement, hand it off and say the details are someone else's job; the PM has to be involved in those details.

Creating space for that kind of craft took explicit tradeoffs: the team had a strict launch date and Yien pushed it out three times because the team believed what they were shipping mattered more than an artificial external GA date. He says PMs also need to spring-clean their calendars and ask how much of their busy internal work actually gets value to a customer. Charlie, the CEO at Mutiny, repeated 'keep the main thing the main thing,' and Yien notes that team DNA matters—a team that prides itself on prescriptive fast shipping may require change management if quality is the priority. The PM has to read that DNA and either exploit it or intentionally change it.

The perimeter is made of constraints, and Yien recommends adding as many reasonable constraints as possible so engineers and designers can be more creative inside them. For the point-of-sale product, that meant deciding whether the customer was a sit-down restaurant with a 200-item wine list or a taco truck, what job they were trying to do, which platforms mattered and what principle should win when tradeoffs collide—for example, speed over real-time data consistency. The goal is to remove decisions from the team's path, because the best decision is often the one nobody has to think about. He also advocates silent document reviews: a scheduled meeting where people read and comment in real time, so the author can answer immediately and shorten the feedback loop.

Yien keeps two kinds of decision logs: one inside PRDs so decisions are documented for the team, and a personal practice for building product sense. He compares the personal version to a pianist doing scales—beginners and 30-year veterans alike keep doing the foundational exercise. Product sense, in his definition, is simply the ability to make good decisions with insufficient data, and the core of that is decisions. PMs therefore need as many reps as possible making decisions, documenting the rationale and then seeing the outcome.

His personal method is deliberately lightweight: a daily log in one big text file or note, with meetings and takeaways bulleted under the date and decisions tagged with a hashtag. When Shopify launched its Shop app, he wrote down his theory that Shopify was using package tracking to hijack a consumer buying loop Amazon owned, drew the flywheel and posted it. Shopify employees noticed, and later conversations confirmed that he had the broad shape right even though the internal reasons differed. The point was not to be right in public but to force a rationale into writing and then close the loop with the real outcome.

He recommends starting small, like a runner laying out shoes the night before: commit to a tiny weekly bet, write down the decision and set a calendar reminder to check what happened. Over time the practice becomes second nature and feeds back into how the PM sees the market. He adds a strong caveat, though: a decision log is complementary to building products, not a replacement. Sitting back, reading Hacker News and making calls without being hands-on will not make someone a better product leader.

The unsell email came from a hiring failure at Square, where Yien had to hire quickly and brought people in despite a quiet suspicion that they were not the right fit. Within six months some of those hires said the role and environment were not what they had expected, and they either left, underperformed or tried to move internally, leaving the same hole. His fix was to front-load the gnarly parts of the job that candidates would otherwise discover only after joining. During interviews he listens for hinted fears and anxieties, then decides which ones are real.

At offer stage he sends a candid email of no more than eight bullet points that reinforces those fears rather than papering over them. For example, if a candidate seems worried about work-life balance and the company is a Series A startup pushing hard at product-market fit, he says plainly that people are expected online at 10:00 and may occasionally need a weekend meeting. If the candidate reads that and is still equally excited, Yien considers that an A+ hire; if not, both sides avoid a six-month mistake. The practice initially lost 30% of candidates at offer stage and upset recruiting partners, but he argues it has to happen after the process because he does not know what the candidate fears until then.

The email is not a yes-or-no test: most candidates come back saying they are fine with six of the eight points but want to talk about the one that scares them. Yien says hiring managers have a responsibility to bend over backwards at that stage, even taking a call at 11 p.m. after a candidate's children go to bed. He acknowledges that process and pipelines matter at large scale, but direct hiring managers should still be deeply invested in each individual they are trying to close. The broader lesson is to optimize for hires who stay and succeed, not for a recruiter's offer-to-close metric.

Yien argues that PMs should not settle for research reports, sales summaries or market research that has already been processed by someone else. They need direct exposure to raw customer material, because otherwise they are looking through bent glass. If a PM is literally not allowed to talk to customers, he treats that as a structural problem to fix before anything else. The excuse he targets next is time: PMs say they are too busy to run a research program or send emails every week.

For B2B research, he points to User Interviews as a way to specify criteria and get a steady stream of qualified ICP participants without doing the sourcing. He also reframes the sales team as a research team, saying that a PM who does not view sales calls as research is missing half the value. Tools like Gong can record calls, filter for terms, phrases or competitors, and alert a Slack channel when those terms appear. The speaker credits Beth Hills at Mutiny with building an excellent automated system around this.

In that system, a Gong alert posts the transcript excerpt and customer name into Slack, and a Zapier workflow uses that information to send an email through a tool like customer.io with the PM's research Calendly link. The result is that interviews show up on the calendar automatically after a customer mentions the relevant problem. Yien also suggests looking for communities on Reddit, Twitter, support forums or wherever customers gather, and building custom scripts or alerting with an engineer when off-the-shelf tools do not fit. The effort required is not an excuse to avoid customer contact.

He warns that every PM starts a new role energized to talk to users, then gradually tells themselves they already know the customer and can rely on intuition from a hundred past interviews. That is a tempting lie because customers' lives and the market keep changing, and PMs need exposure to the micro-changes. He cites Patrick Collison's framing: customer conversations do not directly dictate what to build; they inform the PM's mental model of what the customer needs, and that model informs what to build. The difference between reading a report about a line cook and standing with one is the ancillary detail a PM can only get by being there.

Yien's most memorable AI story is not a workflow but a moment with his seven-year-old daughter during the Midjourney V1 beta. He typed a prompt, got a rainbow-like image, and then she tried 'unicorn prancing in a field,' which produced a hideous, demented unicorn with two rear ends and a demon flying over it. He expected her to feel bad, but she was in awe. Then she asked, 'Did I draw that?'

The word 'draw' stuck with him: to his daughter, an image-generation model was conceptually no different from a crayon. He says he cannot comprehend what a child who grows up with an LLM as a crayon will consider a good product in 20 years. That is why he answers questions about AI's next interface with humility—he has no idea—and why he believes the world is not even beneath the dust on the surface of what will change. As a parent, he feels he has a cheat code because he gets to watch children adopt these tools in real time.

Yien's failure story is landing his first official PM job at a startup and then going through rolling layoffs; he was in round four or so while his wife was nine months pregnant with their first child. The personal fear was severe, but the identity blow was worse: he thought being laid off was evidence that he was not actually a product manager. He wrote an essay called 'Finding Swagger' partly for himself, as a reminder of how he got to the other side. The feeling of not being worth it has recurred over the past decade, and rereading his own account helps him get back on the horse.

The lesson he eventually internalized is that there is a difference between not being good at something and a company not needing that thing at a particular moment, or needing it in a way that does not match the person's strengths. His next role at Square became a place to prove himself, and early product launches, peer trust and restaurant owners' messages gave him the validation that he was competent at product management. He acknowledges the current market is weird and many strong people are being hit sideways, so the same identity crisis is widespread. He advises separating what was in your control from what was not and using that reflection to find a better fit.

He names two common reasons a layoff may not be about competence: the business simply got ahead of its need for the role, or the person's skills and the company's way of operating are incompatible. He has seen people struggle at company A and kill it at company B five years later, often because the environment changed rather than because they transformed. That is why performance conversations can feel like 'you are bad' when the more accurate message may be that the existing machine is not the kind of environment in which this person thrives. The empowering move is to change how you work to fit the environment or find an environment that fits how you work.

In the lightning round, Yien recommends autobiographies and memoirs as a cheat code for spending time with people you respect, along with The Courage to Be Disliked, which he rereads annually, and The Paper Menagerie. He praises The Bear and the Korean competition show Physical 100, and mentions two favorite products: magnetic trays for working on an old Jeep with his daughters and the Circuit HIIT timer app. He shares his mother's 'everything happens for a reason' and his father's 'where's my other 3%?'—a lesson that became a call to define and exceed the work rather than do only the minimum. He also describes earlier eating challenges, including a 97-ounce steak at Manny's, and closes by asking listeners to be kind.