Scott Williamson on Hiring Product Managers and Writing Better Strategy

Harry Stebbings speaks with Scott Williamson, formerly chief product officer at GitLab and a product leader at SendGrid. Williamson started in technology sales, became interested in product, and earned an MBA with a technology-management specialization. After graduating into the post-dot-com downturn, he worked in alliances close to product before moving into his first product-management role.

An MBA is not essential to becoming a strong product manager, Williamson says: training, a suitable role and experienced mentors can teach the necessary skills. He sees potential longer-term value for someone seeking to connect product with the wider business as a senior leader. The cost and opportunity cost make the answer dependent on the individual’s goals.

He describes product work as both science and art. Systematic customer interviews, usage instrumentation and business metrics provide inputs; interpreting them and designing an experience that solves a problem requires creativity. The balance varies: a data-rich growth role may lean toward experiments, while a startup with little data may rely more on qualitative insight and judgment.

Williamson recommends more structured product processes after a company finds repeatable product-market fit: it understands its target customer, can acquire them and retains them sustainably. As the product team expands, particularly beyond a handful of managers, a shared system can reduce wide variations in execution. His thresholds are rules of thumb rather than universal milestones.

He defines product management as a hub between customers, markets, competition and technology on one side, and engineering, marketing and sales on the other. The PM sets priorities and direction, connecting work to a customer and business outcome. Williamson thinks many PMs spend too much time facing engineering and too little understanding users directly.

When should a founder hire the first PM? Williamson prefers waiting until product-market fit is reasonably repeatable. Delegating core customer, strategy and prioritization choices too early can leave a PM without founder context, or lead the founder to take the work back. A junior PM may help with day-to-day backlog management earlier, in his view.

His hiring process has five conversations: an initial screen, an in-depth hiring-manager interview, an engineering-manager interview, a hands-on peer interview and a final case or bar-raiser interview. He groups core PM abilities into validation, building with engineering, business judgment and communication. Each audience requires clear communication at a different level.

At GitLab, a peer exercise called “think big, think small” asked candidates to write a vision and work with a PM on an iterative path to it. Williamson says it tested broad thinking, breaking work into manageable steps, collaboration and written and verbal communication. Writing mattered especially in GitLab’s remote environment.

Williamson values two written artifacts: a longer strategy document and a one-page opportunity canvas for a specific major idea. Writing makes disagreements and ambiguous assumptions visible in a way verbal presentations or bullet points may not. A strategy should state which customers and use cases the team will pursue, and which it will not.

The strategy should look beyond the immediate planning cycle—roughly a year for quarterly planning or two years for annual planning, as examples. At GitLab, strategies connected the overall product to areas and individual teams. A startup may need only one concise document; Williamson says two or three pages can be enough.

At GitLab, Williamson refined the strategy asynchronously through expanding groups: the CEO, product leaders, the executive team, the broader product organization and then the company. Comments and suggested edits exposed misunderstandings. Executive review could be hardest because decisions required trade-offs across functions.

At SendGrid, he says, the team largely stayed focused on midmarket customers even when sales leaders wanted more enterprise features. He believes that restraint helped keep the product simple and self-service oriented. The example is his retrospective assessment, and sales incentives can understandably favor different priorities.

The opportunity canvas applies to substantial work taking weeks or months, not every small improvement or technical-debt item. Williamson asks a PM to interview roughly five to ten target users, then summarize the user, problem, workarounds, potential upside, alternatives, risks, first step and KPI. A single page can expose whether an appealing request is narrow or poorly aligned before engineering begins.

To preserve velocity, he separates ongoing engineering build work from a parallel validation track for future ideas. A well-prepared opportunity should reduce back-and-forth rather than starve engineers of work, assuming the team has an existing backlog. Frequent mid-sprint redirection, confused engineers and repeated debates about the intended user are signs of a poorly conceived backlog.

For a final interview case, Williamson likes a fresh, nontechnical problem outside both the candidate’s and the employer’s specialty. One example asks a PM at a food company to investigate a milk production-line problem. He watches whether the candidate asks useful questions, reasons systematically and starts with the customer instead of relying on familiar jargon.

Domain expertise may be necessary for some roles, such as a billing PM, but Williamson generally tests how a candidate thinks and practices product management rather than requiring an identical prior product. He asks for examples where customer research or usage data challenged an assumption and led to a change in direction.

Strong answers connect customer insights to the work chosen, show how the product was instrumented and explain the resulting iteration. Williamson says early in his career he lacked a clear hiring rubric and did not test systems thinking well. Founders can make a similar mistake by relying on a recognizable company name or product vocabulary instead of evidence of competence.

Onboarding starts with explicit agreement between founder and PM about ownership of vision, strategy, prioritization and hiring. Williamson recommends documenting it before the person joins, then providing people to meet, documents to read and early deliverables. A first month might include customer interviews and a product demo, adapted to the company.

Williamson says a very poor fit may become evident quickly, while a person who is capable but not strong enough may take a quarter to assess. By around month three he expects growing ownership and a point of view. Difficulty forming a judgment, communicating it or collaborating may surface only once the person is doing the job.

His career-development framework specifies expectations for validation, build, business and communication at different PM levels. Every two or three months, managers record concrete strengths and constructive feedback, assess progress and agree on what to improve. He sets aside preparation time and a separate career conversation so the annual review is less surprising.

For a PM seeking promotion, Williamson advises developing a deep understanding of the target customer and connecting that knowledge to measurable business impact. He believes this helps earn trust from sales, marketing and engineering, but stresses that knowing the customer is a means to delivering useful results, not a substitute for them.

Williamson separates reviews of a product area’s overall performance from reviews of work in progress. Monthly KPI reviews ask what happened, what the team did last month and what it will do next. Opportunity-canvas and prototype reviews check whether a specific proposed investment and design solve a real problem before development.

The focused review normally includes the PM, designer, product and design leaders and anyone else needed, often an engineering manager. At GitLab the meetings were recorded for employees who wanted to observe later. He welcomed broad visibility but kept the number of active voices manageable in short meetings.

After a concept and prototype are approved, the work enters development and later KPI reviews track what changed and what comes next. Williamson keeps the forums distinct so early reviews test whether an idea deserves investment while ongoing reviews manage priorities and results.

The balance between new features, iterative improvements and technical debt depends on company stage. At SendGrid, at roughly $100 million in revenue, his team’s default recommendation was 60% new work, 30% improvements and 10% technical debt, adjustable by team. He warns that neglecting existing experiences or debt can create costly problems later; the split is a context-specific starting point.

Looking back at his first product role, Williamson wishes he had started more consistently with customer problems rather than requests from large enterprise accounts. Stebbings asks whether tighter budgets could push teams back toward short-term revenue requests. Williamson thinks that is plausible when smaller teams face quarterly pressure, but presents it as a hypothesis rather than measured evidence.

His rule of thumb is to listen closely to customers about problems without automatically adopting their proposed solutions. He cautions founders against hiring based on pedigree alone or recruiting a leader from a large company who does not actually want hands-on early-stage work. Product friction often arises with engineering or sales when either function expects the PM merely to take orders.

Williamson expects AI to affect both product capabilities and PM workflows, potentially helping summarize customer and usage data or assist prototyping. He imagines some boundaries between product, design and engineering blurring, while still seeing a need to choose customers and problems. These are scenarios, not a claim that AI has already eliminated those roles.

His enduring advice is to talk to customers more. He admires Amazon’s product practices and points to the Arc browser as a more recent example of thoughtful user experience in a crowded market. These examples are his assessments, and his estimate that most PMs do too little customer research is not a measured industry statistic.