77:24
product leadership
Tamar Yehoshua (President of Product & Technology at Glean; former CPO at Slack; product/eng leader at Google and Amazon) argues that product leadership is fundamentally about reading people — users, engineers, and teams — rather than optimizing metrics or following a career plan, that product-market fit plus a trusted engineering partnership matters more than whether a company is 'well run,' and that AI will not replace product judgment but will separate PMs who add real creative/strategic value from those doing rote execution.
Evaluate and value your engineering partner before joining a company; without one, great ideas go nowhere.
Alignment with engineering means explicit division of ownership plus staying aligned, avoiding the 'ask mom, ask dad' dynamic where people play leaders against each other.
The most overlooked career skill is excelling at your current role — you won't get the next job without doing this one well.
Table stakes for any tech role, especially PM: be technical, know current technology, deeply understand your product, understand metrics.
Building products requires understanding user motivations the same way building teams requires understanding people's career motivations — both come from 'reading people.'
Don't be overly reliant on metrics; build product intuition and use a 'beginner's mind' (Marc Benioff's phrase) by asking questions instead of assuming.
PMs are biased to think their own feature deserves top billing in the UI — 'you got to earn that right.'
Doing a great job means driving organization-wide impact, not just completing what you were asked to do.
Being well-run and being successful are not correlated; some highly successful companies are internally chaotic, and some well-run companies fail.
Product-market fit is closer to a necessity than a 'nice to have,' but it's insufficient alone — you also need distribution, a working sales team, and enough runway.
Hypergrowth naturally produces chaos (infrastructure and comms break under headcount/customer growth, with ~50% of staff often under 6 months' tenure), and this is normal until roughly the 5,000–10,000-employee 'growth engine' phase.
Not all chaos is acceptable — constantly changing strategy or reassigning people's projects so nothing gets finished is 'bad' chaos and a legitimate reason to leave.
Myspace is cited as a company that had product-market fit but lost it when the product became too slow.
No five-year plan is required; the guiding heuristic is to follow people you learn the most from, and to target companies that are a 'nexus of great people' with 'gravitational pull.'
Financial outcomes are the hardest thing to predict; who's good and where you'll learn is far more predictable, and skills — unlike a failed company — can't be taken away.
Take a job where, if you hire people into it, it will make their careers.
Lessons from Jeff Bezos: six-page memos instead of PowerPoint; he speaks last in meetings after polling every lead; unwavering operating principles (customer-driven, no unlabeled icons) make an org easier to navigate; a competitor's 10x headcount advantage was reframed as 'your advantage' because great products take patience (the 'seven-year hill').
Lessons from Stewart Butterfield: a fixed 2014 four-box 'master plan' for Slack (product people love → network/Slack Connect → platform → AI) that never changed even as yearly priorities shifted; deep commitment to prototyping over mockups because 'I have to feel it.'
Lessons from Marc Benioff: he approaches marketing keynotes and stunts (e.g., 'no software' campaigns) the way a product person approaches building a product.
Cross-functional alignment with a CTO/engineering counterpart works through explicit ownership splits, mutual trust, direct disagreement rather than back-channel complaints, and joint OKR/exec reviews.
Slack's OKR review process evolved from live per-team reviews to async video reviews (Slack Clips) plus red/yellow/green triage and Slack Huddles for quick sync, after total review hours ballooned to '300 and something.'
Internally, Slack employees used almost no email — everything ran through Slack itself.
Don't over-index on the 'vocal minority' unhappy about a change; design for the larger future user base, but be authentic, transparent, and give people time/choice to migrate.
AI will blur the lines between PM, engineer, and designer over the next 5–10 years, but this will mostly eliminate execution-heavy PM jobs while great PMs keep great jobs, since AI can't be creative or decide what to build.
PMs should treat trying new AI products as a standing practice, the same way they once had to constantly use mobile apps.
Glean evolved from enterprise search (BERT + vector embeddings since 2019) to a chat interface after GPT-3, becoming a 'knowledge graph of your organization.'
Enterprise AI products need guardrails and suggested prompts because users intuitively understand search but not chat, and enterprise users expect deterministic behavior even though they tolerate non-determinism in consumer AI tools.
True product differentiation must be durable beyond patching current LLM weaknesses, since as underlying models improve, every competitor benefits too.
Her father's advice: 'There are no right decisions, you make a decision right' — commit fully rather than agonizing over which fork to take.
Beginner's mind (Marc Benioff) — An approach to customers and product decisions that assumes you know nothing and must relearn from scratch. Apply: Ask a lot of questions and listen to customers rather than assuming your existing mental model is correct.
Car-ride debrief / motivation-reading habit — A habit, learned from her psychiatrist father, of analyzing why people said or did things after a social event. Apply: After meetings or team interactions, deliberately review why people reacted as they did — watch faces and reactions in the room, not just words.
Impact-over-output framework — A standard for judging job performance based on whether the business and the wider org moved forward, not whether a task was completed. Apply: When evaluating your own or a team's work, ask whether it was actually used and whether it made the whole organization more productive, not just whether it shipped.
Feature-request prioritization filter — A filter for deciding which of many requested features 'really matter,' since even building 80–90% of requests may not move company success. Apply: Push back on sales/stakeholder feature lists by asking which few items would actually change outcomes, and deprioritize the rest.
Company-phase awareness — The idea that acceptable chaos and management style depend on company scale — startups tolerate more chaos, but past roughly 5,000–10,000 employees a company needs professional, cost/execution-focused management. Apply: Calibrate how much organizational chaos to tolerate or fix based on the company's current headcount/growth phase rather than a fixed ideal.
"Follow people, not domains" career strategy — A career-navigation heuristic of choosing jobs based on who you'll learn the most from rather than a fixed domain interest or five-year plan. Apply: When picking a next role, prioritize proximity to the best product thinker, engineer, or salesperson over the specific industry or title.
"Nexus of great people" company selection — Targeting companies where many top-tier people currently work or have worked, since relationships persist even if the company fails. Apply: Research where respected people cluster and treat that clustering as a signal for where to work, independent of the company's outcome.
Company "gravitational pull" for talent — A concept (credited loosely to Marc Andreessen) that a company either draws in the best talent or is losing people to a rival that does. Apply: When evaluating an employer, check whether you can actually recruit strong people there; inability to recruit is a warning sign.
"Take a job that makes careers" heuristic — A job-evaluation rule that the right role is one where hiring people into it will visibly advance their careers. Apply: Before accepting or offering a role, ask whether it will demonstrably build the resume/skills of the people who take it, and reject pure 'turnaround' or mercenary offers on that basis.
"List respected people, target their employers" tactic — A concrete tactical method for turning the 'follow people' philosophy into a target company list. Apply: Write down the people you most respect for being best-in-class at their function, then look at where they currently work as your shortlist.
Bezos's six-page memo — Bezos's practice of replacing PowerPoint decks with narrative six-page memos read silently at the start of meetings. Apply: Require written narrative documents instead of slide decks for major decisions to force clearer, more complete thinking.
Bezos's meeting protocol — Bezos's habit of polling every lead in the room for their view before offering his own, and always speaking last. Apply: As a senior leader, withhold your opinion until everyone else has spoken, to get honest input rather than premature consensus.
Bezos's fixed operating principles — A small set of unwavering principles Bezos held (customer-driven, relevant to the customer, no unlabeled icons) that made the org predictable to operate in. Apply: Define a short list of non-negotiable principles and apply them consistently so teams always know what leadership will and won't accept.
The "hill" metaphor for long-term product building — A framing that building a genuinely great product can take around seven years, so near-term resource gaps matter less than sustained direction. Apply: When facing a resource disadvantage versus a competitor, resist the urge to demand more headcount and instead commit to the multi-year climb.
Butterfield's 2014 four-box Slack master plan — A fixed long-term roadmap (product people love → network/Slack Connect → platform → AI) sketched in 2014 that stayed constant even as yearly execution priorities shifted. Apply: Set a small number of durable long-term destinations for a product early on, and let year-to-year plans serve that fixed structure rather than replacing it.
Prototyping-over-mockups philosophy — Butterfield's belief that you can't judge whether a design will work from a mockup alone — you have to build and feel a working prototype. Apply: For major design decisions, insist on building an interactive prototype before committing, rather than deciding from static mockups or opinions.
"Everything behind one button" prototyping exercise — A specific exploratory redesign exercise where Butterfield had the team build a prototype hiding the entire interface behind a single button, purely to learn — not to ship. Apply: Use deliberately extreme, throwaway prototypes to explore a design space, even when the team believes the idea is impractical or unshippable.
Prototyping-enabling engineering infrastructure — The observation that prototyping speed depends on having lightweight engineering infrastructure; heavy infra (e.g., the old mobile app architecture) blocked fast prototyping until redesigned. Apply: Invest in engineering infrastructure specifically built to make rapid, disposable prototyping fast, rather than reusing production-grade infra for exploration.
"Prototyping mindset" — A shared mindset across product, design, and engineering of writing fast throwaway code purely to learn, before writing production code. Apply: Hire and cultivate engineers/designers willing to build disposable Figma or real-data prototypes quickly, treating that speed as ultimately faster than skipping straight to production work.
Cross-functional ownership-alignment framework — An explicit division of responsibility between a product leader and engineering counterpart (e.g., 'you drive this, I drive this'), paired with mutual trust and redirecting questions to the right owner. Apply: With a peer leader, explicitly define who owns which decisions, honor that boundary in practice, and raise disagreements directly to each other rather than to teams.
Joint review cadence with engineering counterpart — A practice of doing OKR reviews and weekly exec updates together with the engineering counterpart rather than separately. Apply: Schedule shared review meetings with your closest cross-functional peer so both of you dig into teams jointly instead of getting siloed updates.
OKRs (Objectives and Key Results) — The goal-setting framework used to drive planning and review processes at Slack. Apply: Have teams set and present OKRs each cycle as the basis for prioritization and progress tracking.
Async OKR review format — A review method where each team posts a written doc plus a time-limited Slack Clips video walking through their OKRs, instead of a live meeting. Apply: Replace live per-team review meetings with a required short video-plus-doc submission per team to cut review time at scale.
Selective live follow-up meetings — A triage rule where only the 5–10 teams with the highest priority or most questions get an actual live follow-up meeting after async review. Apply: After reviewing async submissions, reserve live meeting time only for the highest-priority or most-flagged teams rather than meeting with everyone.
Red/Yellow/Green status triage — A status-reporting convention where only 'red' (problem) OKRs are discussed live, to save meeting time. Apply: In a status meeting, skip discussing green/on-track items and focus discussion time only on red/at-risk ones.
Weekly four-person leadership sync — A standing weekly meeting between two co-leaders (product and engineering) and their two respective Chiefs of Staff to cover broader org issues. Apply: Pair each senior leader with a Chief of Staff and hold a small joint weekly sync among the four to surface organizational issues before they escalate.
Quarterly retrospective on the review process itself — A recurring practice of evaluating whether the OKR planning/review process worked each quarter and adjusting it, treating the process itself like a product. Apply: At the end of each planning cycle, explicitly ask whether the review process worked and iterate on its format rather than leaving it static.
Slack Huddles for synchronous quick-questions — Using Slack's Huddles feature to quickly jump into a live voice conversation to resolve a question during an otherwise async review process. Apply: When an async update raises a quick question, use a lightweight synchronous huddle instead of scheduling a full meeting or a long thread.
Design-for-future-user-base principle — A principle that the number of current users is usually much smaller than future users, so products should be designed for who will use them, not just current vocal users. Apply: When redesigning a UI or removing a feature, weigh the needs of the larger future user base more heavily than the smaller set of current users who will be unhappy.
Authentic/transparent change-communication approach — A communication method for controversial product changes: be respectful, transparent, explain the real reason, avoid marketing speak or dismissiveness, and give people time and choice to migrate. Apply: When deprecating or changing a feature (e.g., Slack Calls → Huddles), explain the genuine rationale directly to affected users and phase the transition rather than forcing it abruptly.
AI-driven blurring of PM/engineer/designer roles — The claim that within 5–10 years, AI tools (Figma AI, Copilot, Cursor) will erode the sharp boundaries between product, engineering, and design roles. Apply: Encourage PMs and designers to use AI tools to build their own prototypes/code, rather than treating implementation as strictly an engineer's job.
"Always be using new products" practice — A standing practice for PMs of constantly trying new products in whatever category is currently shifting (mobile before, AI now). Apply: Regularly use tools like ChatGPT, Claude, and Glean firsthand to understand their current capabilities rather than relying on secondhand descriptions.
Long-context-LLM ingestion for sentiment/feature mining — A technique of feeding an entire long-form data source (e.g., a full Discord channel transcript) into a large-context LLM like Gemini and asking analytical questions about sentiment and requested features. Apply: When a large volume of unstructured community/customer text exists, dump it into a large-context model and query it directly instead of manually reading it or skipping the analysis.
Internal AI app for sales-call summarization — A Glean-built internal app that ingests Gong sales-call transcripts, structures them into a spreadsheet, and summarizes top requested features, refined to distinguish salesperson opinions from actual customer requests. Apply: Build a lightweight internal AI pipeline over call-recording transcripts to surface aggregated customer feedback, and iterate on the prompt to separate rep commentary from verbatim customer asks.
Launch-readiness cross-referencing prompt — A custom Glean prompt that cross-references the Launch Calendar with open Jira tickets, Slack conversations, and beta-customer feedback to output a launch date plus a confidence level. Apply: Build a prompt/app that pulls from multiple internal systems (roadmap, ticketing, chat, feedback) to generate a single feature-readiness status with a confidence score.
AI-assisted incident pattern matching — Using AI to surface previous similar incidents when a new incident occurs, as part of incident management. Apply: Feed current incident details into an internal AI search/assistant tool to retrieve related past incidents and their resolutions.
Persona/role-assignment prompting technique — A prompting technique of explicitly assigning the AI a role or persona (e.g., 'you are a product manager at Glean') before asking it to summarize or analyze something, rather than issuing a generic instruction. Apply: When prompting an LLM for analysis (e.g., competitive news, PR comparisons), frame the request as coming from a specific persona/perspective to get more targeted output.
Chat PRD — A templatized AI tool (built by Claire Vo) for writing product requirement documents with built-in frameworks, distinct from using generic ChatGPT. Apply: Use Chat PRD (or a similarly templatized AI tool) when writing PRDs to get structured framework guidance rather than starting from a blank ChatGPT prompt.
BERT + vector embeddings for enterprise search — The AI search technology stack (Google's BERT models plus vector embeddings) that Glean adopted starting in 2019 for enterprise search. Apply: Apply embedding-based semantic search models to index and retrieve content across an organization's SaaS tools, rather than relying on pure keyword search.
"Knowledge graph of your organization" architecture — Glean's underlying product architecture, built on indexed and connected organizational content, described as functioning like ChatGPT for an enterprise. Apply: Structure an enterprise AI assistant around a connected knowledge graph of all internal SaaS content rather than a single isolated data source.
Search-UX-pattern analogy for training chat-AI users — The idea that just as search needed autocomplete and on-page refinement suggestions to teach users to query well, chat AI needs guardrails and suggested prompts to teach users what's possible. Apply: When launching a chat-based AI feature, add suggested/example prompts and guardrails to compensate for users not yet knowing how to phrase effective queries.
"Switch" change-management framework — A book-derived framework (Chip and Dan Heath's 'elephant and rider' idea) for motivating people through organizational change, not just directing them. Apply: When leading a company through change (e.g., an all-hands announcement), explicitly work to motivate people emotionally, not just set the logical path/plan.
Personal AI workflow: preload-summarize-follow-up — A personal productivity technique of preloading material into ChatGPT's voice mode before an activity (e.g., a workout), asking for a summary, and then asking follow-up questions conversationally. Apply: Load reading material or notes into a voice-mode AI assistant ahead of a hands-busy activity, then use spoken follow-up questions to explore it further.
Successful companies are frequently internally chaotic and unhappy places to work, while some well-run, well-liked companies simply flatline — she explicitly says the two are not correlated.
Even at Slack, features considered internally to be 'the most important features ever' turned out to be flops nobody used — impact is only visible in retrospect.
Bezos reframed a competitor's 10x headcount advantage as 'your advantage,' arguing that resource scarcity forces the long-term thinking needed to build something great over ~7 years.
AI is expected to automate rote PM busywork (Jira updates, launch docs) and surface information ('here's what customers are asking for') but not the harder judgment of deciding what to build — a dynamic she expects to 'weed out the good from the bad PMs.'
A genuine AI product-strategy caution: don't build features whose sole purpose is compensating for a current LLM's weakness, because that value evaporates the moment the underlying model improves — durable differentiation must live outside the LLM itself.
Slack's own OKR review process became so expensive (roughly '300 and something' cumulative hours) that leadership had to redesign it into async video reviews — a concrete, quantified example of process debt during hypergrowth.
Enterprise users hold AI products to a double standard: they accept non-deterministic behavior from ChatGPT casually on weekends but expect deterministic reliability from work tools, which enterprise AI products must manage via guardrails and suggested prompts.
A PM using Gemini's expanded context window to dump an entire Discord community's transcript and ask for sentiment/feature-request analysis is framed as unlocking work ('a gold mine') that simply would never have gotten done manually, reframing 'I'm too busy' as a leverage problem rather than a time problem.
«if you have great ideas of what to build but you can't get them built then you go nowhere»
— 00:04
«you're not going to get the next job unless you do really well at the job that you're in»
— 03:03
«well no, you got to earn that right»
— 09:13
«if I were to put this into one word, it's impact — drive impact»
— 11:15
«the numbers are amazing, like they're growing like crazy»
— 12:34
«I Never Had A Five-Year Plan»
— 19:23
«you follow people you learn the most from»
— 20:25
«take a job where if you hire people it's going to make their careers»
— 23:04
«financial returns are the hardest to predict»
— 24:00
«skills can't be taken away a company can fail but if you learn a skill you will always have that skill»
— 26:11
«he is by far the smartest person I've ever met in my life»
— 28:18
«that is your advantage»
— 29:53
«I can't tell you if this is going to work, I have to feel it, I have to try it»
— 31:29
«did you talk to Cal?»
— 39:33
«I think the bottom line was respect.»
— 40:26
«I'm a very direct person so if I don't think that something is the right priority or is working I will be very clear.»
— 41:44
«it was like some insane number like 300 and something and we're like this has gotten out of hand.»
— 44:38
«we are underestimating how much it's going to change how we work»
— 51:06
«it was like a gold mine, do you know how long it would have taken him to read and we just wouldn't have done it.»
— 54:02
«it's not going to give you that leap it'll say here's what customers are asking for here are the problems today but you have to figure out how to solve it»
— 60:19
«the not so good PMS jobs will go away the great PMS will still have great jobs»
— 61:33
«your whole product gets better as the LMS get better»
— 66:24
«there are no right decisions you make a decision right»
— 73:53
«if you share your life with them they will share their life with you»
— 75:57
Reception
Viewers found the interview insightful and praised the guest's intelligence and groundedness, with only minor grumbling about ad load.
The interview is a dense, well-organized reference on product leadership, cross-functional alignment, and enterprise-AI strategy, built on named case studies (Bezos, Butterfield, Benioff) and concrete internal-process detail (Slack's OKR review overhaul, Glean's search-to-chat evolution) rather than generic advice. Some names, titles, and figures were garbled in transcription (e.g., 'LMS' for LLMs, uncertain book/person names), so those specific details should be treated as approximate.
77:24