Feb 21, 2024 · 59m · news
Scott Williamson: Hiring the Best Product People in Five Steps, Why the Best PMs are Writers | E1118 · 20VC with Harry Stebbings
0:00 / 0:00
▶ Watch on YouTube →
gold bands on the timeline = statements, start to end. Hover to read, click to jump. CC turns on captions
In this episode of 20VC, veteran product leader Scott Williamson joins host Harry Stebbings to share his comprehensive playbook on hiring, managing, and scaling product management teams, emphasizing the power of written strategy docs, structured interview pipelines, and outcome-oriented frameworks.
How this conversation actually went
Every chapter scored 0–10 on four independent dynamics. Hover any point for the reasoning behind the score. Harry holds 18.4% of the talking time here. How this is scored →
Harry as informed peer 3.6 Guest teaching 4.7 Guest disagreement 1.3 Harry pushing back 2.6
speaking balance: gold is Harry, purple is the guest (3 minute bins)
Sharpest disagreement ▶ 10:25 Scott defends waiting until $2-3M ARR to hire a PM
When Harry argues that waiting for repeatable product-market fit at $2-3M ARR is quite late to hire a PM, Scott firmly rejects early delegation, citing founder context loss and execution failure.
Hardest push from Harry ▶ 42:26 Harry challenges the promotion path via ICP knowledgeHarry explicitly challenges Scott's guidance, questioning how having a strong opinion on an ideal customer profile directly catches executive attention to earn a promotion.
Biggest teaching moment ▶ 3:53 Scott reframes art vs science in product managementAfter Harry calls his fifty-fifty response a cop-out, Scott systematically educates Harry on how systematic data capture combines with creative insight derivation across different company stages.
Harry holds his own ▶ 21:55 Harry calls out sales comp misalignments in enterprise strategyHarry demonstrates strong market expertise by identifying how sales commission structures create internal pushback against sticking strictly to mid-market ICPs.
the scores for every segment, with the reasoning behind each
| Chapter | Topic | Harry as informed peer | Guest teaching | Guest disagreement | Harry pushing back | Why |
|---|---|---|---|---|---|---|
| Scott Williamson's Journey into Product Management | 3 | 3 | 1 | 1 | Harry asks Scott about his career path from sales to product leadership and follows up with a standard question on whether MBAs remain valuable today. Scott explains how MBAs can provide long-term career benefits for aspiring CPOs despite fast-track alternatives existing for individual contributors. | |
| Is Product Management Art or Science? | 4 | 5 | 2 | 5 | When Scott answers that product is fifty-fifty art and science, Harry playfully calls it out as a cop-out answer. Scott defends his framing by detailing how data collection requires scientific rigor while insight derivation demands artistic creativity depending on company maturity. | |
| When to Shift from Intuition to Rigor | 3 | 5 | 1 | 2 | Harry asks when startups should transition from intuition to scientific product processes. Scott explains the transition point occurs after finding repeatable product-market fit and details how product managers should act as hubs between internal and external stakeholders. | |
| When to Hire Your First Product Managers | 5 | 5 | 3 | 6 | Harry challenges Scott's timeline for hiring the first PM, arguing that waiting for repeatable product-market fit at $2-3M ARR is quite late. Scott firmly holds his ground, explaining that delegating core product decisions earlier creates founder misalignment and organizational failure. | |
| Peer Interviews & GitLab's 'Think Big, Think Small' Exercise | 4 | 4 | 1 | 2 | Harry asks about peer interview structures and references a previous guest to validate the importance of writing skills. Scott breaks down GitLab's 'Think Big, Think Small' interview exercise, which tests candidate vision, iteration ability, and concise writing. | |
| The One-Pager vs. Six-Pager Strategy Docs | 3 | 5 | 1 | 2 | Harry asks how strategy documents are used internally and why true alignment is difficult to achieve. Scott explains why verbal projections and slide decks create illusory consensus, whereas long-form written documents expose subtle strategy differences. | |
| Structuring Internal Debates and Strategy Reviews | 5 | 5 | 1 | 3 | Harry asks which stage of document review causes the most friction and demonstrates industry insight by pointing out how sales compensation structures push teams toward enterprise deals. Scott confirms executive team reviews create the most debate due to cross-company trade-offs. | |
| Opportunity Canvas: Validating Product Concepts | 2 | 5 | 1 | 1 | Harry asks when to use full strategy docs versus short templates. Scott outlines the Opportunity Canvas, a one-page validation doc completed before engineering work begins to assess problem severity and target customer interest. | |
| Dual-Track Agile: Validation vs. Build | 3 | 5 | 1 | 2 | Harry asks how product leaders balance speed with innovation without stifling teams, and how to spot chaotic product development. Scott details dual-track agile systems and identifies constant mid-sprint switching as a clear sign of process failure. | |
| Effective Interview Case Studies: The Milk Scenario | 3 | 5 | 1 | 2 | Harry asks Scott how to run effective case study interviews and whether domain background matters. Scott shares his famous non-technical milk line scenario designed to evaluate systems thinking over corporate jargon. | |
| Star Candidate Signals: Outcomes and Iterative Journey | 4 | 4 | 1 | 2 | Harry draws a parallel between metrics-driven social media hiring and PM hiring signals. Scott agrees, explaining that top PM candidates demonstrate a clear connection between customer discovery insights, product instrumentation, and business outcomes. | |
| Setting Clear Ownership and Effective Onboarding | 2 | 5 | 1 | 1 | Harry asks Scott how to fix notoriously poor PM onboarding practices. Scott emphasizes that founders must explicitly define ownership boundaries around vision, strategy, prioritization, and hiring from day one. | |
| Identifying Underperformance and Lack of Ownership | 3 | 5 | 1 | 2 | Harry asks how quickly underperformance becomes obvious and jokes that venture capital is far easier than managing PM reviews. Scott shares his 4-bucket career development framework and bi-monthly review cadence. | |
| How PMs Can Get Promoted: Driving Business Impact | 5 | 5 | 3 | 6 | Harry directly challenges Scott's advice, asking how simply having an opinion on the ICP actually gets a PM promoted by leadership. Scott reframes the argument, explaining that deep customer knowledge earns cross-functional trust, enabling the execution that yields business results. | |
| Participant Alignment and Managing Remote Product Reviews | 4 | 4 | 1 | 3 | Harry brings up remote meeting dynamics, suggesting remote product reviews allow wider passive participation. Scott explains how recording reviews at GitLab provided complete organizational transparency without overcrowding decision-making. | |
| Allocating Resources: Technical Debt vs. New Features | 5 | 5 | 1 | 3 | Harry asks Scott how to balance technical debt against revenue features and offers an insightful thesis on CFOs centralizing spend in the current market. Scott details SendGrid's 60/30/10 resource allocation framework to protect technical health. | |
| Quick-Fire Round: Product Best Practices, AI, and Future Outlook | 4 | 5 | 1 | 1 | Harry initiates a quick-fire round, citing a statistic that numbered points improve memory retention. Scott shares perspectives on ignoring user solution recommendations, AI blurring the lines between PM, design, and engineering, and praise for the Arc browser. |
Statements from this episode (35)
Williamson defines four core PM competencies: validation, build, business, and communication
“There's four buckets for an individual PM. One is around valid. I call it validation. Customer interviewing, product usage data, kind of like gathering insights. Two is build, which is how well do you work with engineering? How can you make trade-offs? Can you…”
Williamson: MBAs are unnecessary for PMs unless aiming for executive roles
“If you want to be a badass PM, I don't think you really need it. You can learn the skills that you need to learn through product-focused training, through being in the right situation, through learning from Jedi Masters at your company. If you want to be a CPO…”
Williamson: Scaled growth PM is 80% science; startup product is 80% art
“If you're a growth PM at Facebook, you got shit tons of data, the path Math for the product is pretty clear. You're mostly just running a B test. Maybe it's more like 80, 20, 90, 10 data to art. If you're a startup, you have very little data at your disposal. …”
Williamson: Introduce scientific product structure only after repeatable product-market fit
“Basically, it's when you've found repeatable product market fit. You know who your ideal customer profile is. You generally know the problems they need you to solve. You generally have confidence that your product experience can both attract and retain them at…”
Williamson: Scaling to 10+ PMs requires formal systems to maintain quality
“And when you get to maybe, maybe when it's still three PMs, there's still not a big need for big structure process, but when you get up to 10 plus, You're only as good as sort of the average PM's performance. And if you don't think about the broader system tha…”
Williamson: PMs should spend 50% of time with customers, not 5%
“Now, to do that well, you need about half your time to be out of the building. Most PMs spend about 95% of their time facing engineering. And zero to fives talking to customers and being out in the world.”
Williamson: Only 20% of product teams operate in an outcome-focused way
“Maybe 20% of teams work this way. Still a minority.”
Williamson: Founders should not hire product leaders before achieving product-market fit
“And I think if you hand it off before then, it can be very problematic because it's these decisions, which ICP, what are we going to prioritize to build for them? What's the core user experience? These things are so central to a company, especially if it's a P…”
Williamson outlines a five-step interview process for hiring product managers
“Five interviews total. First one's a 30 minute recruiter screen or hiring manager screen if you don't have a recruiter. Just checking for the basics. Then the hiring manager should spend an hour with them checking on sort of the clear the bar for the core comp…”
Williamson: Breaking work into small chunks is an underrated PM skill
“I think it's a very underrated aspect of great PM and great product development is this act of breaking things down into small chunks so that you don't overcomplicate what you ship.”
Williamson: Clear writing is mandatory for success at all-remote GitLab
“GitLab's all remote. You're dead in the water if you can't write clearly at GitLab, so it was testing all those things at once.”
Williamson: SendGrid and GitLab required opportunity canvases and Amazon-style strategy docs
“There are two that we used at SendGrid and GitLab that I think were essential. One was a one pager called an opportunity canvas, which asked PMs to outline sort of the concept they wanted to build. And the other one, it's like a two to six pager. I think Kevin…”
Williamson: Strategy docs should cover two to three planning cycle iterations
“Make sure it's two or three iterations larger than a planning cycle. So if you plan every quarter, make sure it's at least a year. If you plan every year, make sure it's two.”
Williamson: Long-form writing is the only effective way to align strategy
“And I think the only way you get to it effectively is through long form writing.”
Williamson: Startups with 10+ people should adopt written strategy documents
“Even if you're more than 10 people, this can be helpful. I would say maybe when you're not all on the same run. When you start adding new people at some clip, Because new people just don't have that context. They don't have the tribal knowledge. And when you a…”
Williamson: GitLab's overall product strategy document was only two to three pages
“The one I did at GitLab for the whole product was probably a couple pages. Two, two, maybe three. It wasn't that long.”
Williamson: Validate product concepts holistically to kill flawed ideas before coding
“The problem with ideas is they can sound very good from one perspective, like customer X asked for it, or wow, that sounds cool. Or, oh, if we did that, we could up tier them into the next tier. There's always some reason why an idea sounds good on the surface…”
Williamson: SendGrid and GitLab used dual-track agile for product management
“PMs always have two tracks going. At least that's how we ran it in Sengri and GitLab. There's a validation track where you're doing your homework on the things you want to pump into engineering, and then you have a build track.”
Williamson: Early product validation speeds up overall engineering development
“Doing a proper validation shouldn't slow down engineering. They have more than enough to do. This is about making sure that the next thing you tee up for them is well conceived. But to my far earlier point, PMs need half their time available to be doing this k…”
Williamson: Developer confusion and context switching signal poorly conceived product backlogs
“If there's a lot of context switching, there's a lot of confusion about why, and there's a lot of back and forth between the engineers and whoever asked them to do this thing. It probably isn't a well-conceived backlog in the first place.”
Williamson: Product interviews should use non-technical, unrelated case studies
“I'd like to pose a non-technical scenario that they haven't worked in before and actually isn't what we do either. Because I don't want them to, A, rely on the jargon that they learned in their last job, and I don't want to also sort of penalize them for askin…”
Williamson: Product management ability is domain agnostic; domain experience is secondary
“Mostly what I'm testing for is how you do product and how you think, and that's relatively domain agnostic. I tend not to hire for domain if I don't have to”
Williamson: Top PM candidates connect their daily work directly to outcomes
“Yeah, I think someone who can clearly connect the work they were doing to the outcome they were trying to drive And can describe, like, okay, what did I learn from customers that led me to believe that they would take this action if X were there? How did I ins…”
Williamson: Founders rely on pedigree bias when hiring product managers
“Most of them haven't been a product manager. They have no idea what this role is about. So they don't know what to look for. They don't know how to grade it. And so they go off of pedigree. Oh, they were at Google or B they know the lingo, you know, they talke…”
Williamson: Founders must explicitly define product ownership boundaries during PM onboarding
“First, especially in early stage scenarios, the founder has to be crystal clear with the incoming product person about what they want to own as the founder and what they want this product person to own.”
Williamson: Severe hiring misfires are clear within the first week
“Well, I think if they're really bad, you know, within the first week, if they're maybe good, but not good enough, you're going to know within the first quarter.”
Williamson: PM hires must demonstrate ownership and conviction by month three
“By month three, you should really see them start leaning in, have a strong point of view, take ownership, have some conviction and priority”
Williamson: Deep target user perspective builds cross-functional trust for PMs
“If you really understand them, then you're going to tee up the right work, which is going to drive results. Ultimately you want to drive results, but how do you get there? I think the building block is having a ton of. Perspective on the target user and what t…”
Williamson: PMs must track executive-relevant KPIs to prove business impact
“And then from there, you're trying to prove business impact. So make sure you have a KPI that leadership cares about, that maps to the work that you report on regularly and openly and honestly.”
Williamson: Separate work-in-progress reviews from overall product area reviews
“If you're early, you might be able to combine all of this, but I tend to separate reviews that are about work in progress from reviews about the product or product area as a whole.”
Williamson: GitLab recorded and internally published all product review meetings
“At GitLab, we recorded all of them, and we posted them, and anybody who wanted to watch them could. So we were very transparent about all these meetings. You could see them all as an internal employee.”
Williamson: SendGrid used a 60/30/10 split for features, iterations, and tech debt
“At SendGrid, we had a recommended split, and granted, this is when we were sort of a hundred million-ish, of 6030, 10, 60 on net new, 30 on iterative improvements, 10 on tech debt.”
Williamson: Budget constraints are forcing PMs into short-term tactical work
“There are fewer engineers, fewer PMs, fewer designers. People are being asked to do more with less. I would guess the average PM probably has less time to get out of the building. And there's more focus on revenue. And if you're a product manager and you're tr…”
Williamson: Listen to customer problems, but ignore their solution ideas
“Broadly speaking, listen to customers about their problems and generally ignore their recommendations around solution because they may not, building exactly what they want may not be the most elegant way to solve the problem.”