The Ledger
Every statement that passed quotation and attribution checks. Mix any filter with any other: certainty 1/5, debate potential 5/5, or both at once.
why aren't all 35 resolved? a statement only gets an assessment when the public record can support or contradict it. opinions and what-ifs never can, and 0 checkable ones are still open, waiting for their date. predictions held up or didn't; assertions are supported or contradicted. on every card: ▮▮▮▮▮ certainty · ▮▮▮▮▮ debate potential. speakers are clickable
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: AI will merge PM, design, and engineering into a single role
“I can imagine this triple roll down the line where they're doing PM, design, and engineering with the help of AI.”
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: 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: 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: 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: 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: 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.”
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: 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: Only 20% of product teams operate in an outcome-focused way
“Maybe 20% of teams work this way. Still a minority.”
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: 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: 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: 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: 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 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: 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: 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: 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: 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.”