Tamar Yehoshua
President of product and technology at Glean, former Chief Product Officer at Slack
Where to hear and read about Tamar Yehoshua1 episode or test
Tamar Yehoshua is president of product and technology at Glean and was Chief Product Officer at Slack, after earlier product and engineering roles at Amazon and Google. The lesson most worth taking from her is to follow the best people, pair tightly with your engineering partner, and use AI tools hands-on every day.
If you have great ideas of what to build, but you can't get them built, then you go nowhere.
Lessons in product leadership and AI strategy from Glean, Google, Amazon, and Slack | Tamar Yehoshua
Tamar Yehoshua: the story and the lessons
1Tamar Yehoshua's career and how she picks jobs
Yehoshua has led product at Amazon, Google, Slack and now Glean. She spent five years at Amazon (A9.com), years on Google Search, four years as Slack's product chief, and now runs product and technology at Glean.
She never had a five-year plan and says she still has no idea what she'll want in five years. Slack grew revenue 10x on her watch.
She follows the best people at their craft, not a plan. She picks jobs where she will learn most from the best product thinker, engineer or salesperson, not just someone she likes.
She joined several companies that failed or stalled and still kept her skills and relationships. Her view: "Skills can't be taken away."
She takes jobs where the people she hires will make their careers. A friend gave her this advice while she was weighing turnaround offers. It raises the bar: she must honestly believe people will learn and grow there.
Without a gravitational pull, recruiting is very hard. She knew one person who took a job as a mercenary, and it did not work out.
She turned down a management job because the team should not exist. Early in her career she told her manager the new team she was offered should not exist. He agreed and found her something else.
She defines impact as building something people use and doing the right thing for the company, not just hitting assigned goals. Her one-word summary is "impact".
She treats technical depth, product knowledge and metrics as table stakes. Before aiming at a bigger role, she says, master what every tech job demands: know the latest technology, understand the product deeply and read the metrics.
She says ambitious product managers slip by eyeing the next job. Her instruction is to do a great job however simple the work is.
2How Yehoshua partners with her engineering counterpart
Yehoshua meets and assesses the engineering partner before joining a company. A product leader ships only as far as the engineering partner allows. If the partner is wrong, she checks that the organization is willing to change.
She names Slack co-founder and CTO Cal Henderson as the partner she could not have bettered.
She sets clear roles so nobody plays one leader against the other. If someone asked her about Cal's domain, she asked "Did you talk to Cal?" and never went around him. Where ownership was unclear, they talked and decided who would take it.
The goal was to avoid the "ask Mom, ask Dad" setup where people collect two different opinions.
She builds respect on trust that the other person follows up. When she asked Fuzzy Khos for more mobile engineers, he said "I'm on it", and that was all she needed.
If he could not deliver, he came back and said there would be a problem.
She and the Slack CTO ran every review together. They attended all OKR reviews, held a weekly Monday review of only the red items, and met weekly with their two chiefs of staff.
Each knew which questions the other would dig into. When she disagreed with a priority she said so directly, rather than complaining to her team afterward.
She replaced live OKR reviews with recorded updates after they passed 300 hours. Teams posted a doc and a time-limited Slack Clip in their planning channel. The two leaders watched them together and asked follow-ups in channel.
Only five to 10 teams got a live follow-up meeting. They revisited the process every quarter, like a product.
3What Yehoshua learned from Bezos, Butterfield and Benioff
Bezos made Amazon easy to work in by never changing his principles. Everything had to be customer driven, and he hated icons without labels, so after a few meetings you knew what he would ask.
He spoke last, after every lead around the table, and remembered details from one quarterly meeting to the next. Meetings ran on six-page memos, which she compares to studying for a final exam.
Bezos told her that competitors having 10 times the people was her advantage. A product, he said, is a seven-year hill, so headcount alone does not decide the outcome.
Butterfield paired a fixed long-term plan with a belief in prototyping. His 2014 master plan was a four-box grid: a loved product, a network (Slack Connect), a platform, and "magic AI stuff". It never changed.
He said a mock-up cannot show how something will feel. For the redesign he had the team put the whole interface behind one button. It was never shipped, but it started the redesign.
She says prototyping only works if engineering is set up for it. Engineers must be willing to throw code away and write production code later. Slack redesigned its mobile apps because they were too hard to prototype, while the desktop app was easy.
At Google, the head of front-end engineering called a team of prototypers his secret weapon. Early prototypes can be Figma, then move to real data.
Benioff taught her to keep a beginner's mind and treat a keynote as a product. His advice was to assume you know nothing and listen to customers. She appeared in his Dreamforce keynote two years running after the Slack acquisition.
She saw him push the envelope, for example by standing outside a competitor's conference.
4How Yehoshua decides what matters in product
She says product-market fit matters more than being well run. She knows chaotic companies with unhappy staff and amazing growth, and a well-run one that flatlined. No product-market fit is a death sentence.
Only a strong distribution machine can offset it. She puts 80 to 90% of sales feature requests in the category that won't matter to company success.
She separates normal hypergrowth chaos from the harmful kind. Fast growth breaks infrastructure and communication, and half the company may have been there under six months. Constant strategy changes that stop people finishing anything are harmful.
Chaos is no excuse to stop running a functioning, motivated team. She says to skip great companies if the chaos would make you unhappy. Chaos stops being acceptable once a company passes roughly 5,000 to 10,000 people.
She pairs metrics with intuition about customers. Over-reliance on metrics is the risk she warns product managers about. Decisions that feel right usually are, if you know the product well.
Her own failure mode is assuming everyone will want what she worked on. A feature has to earn its place front and center in the interface.
She designs for tomorrow's users, not the vocal few. When removing features that a small set of users relied on, she held that today's user count is usually far smaller than tomorrow's.
After a UI redo, existing users complain but new users find it much easier. She says to explain the change without marketing speak and give people choice and time, as with the move from Slack calls to Huddles.
She learned from a Google PR chief that a phone call beats an FAQ. At Google, with about 50,000 people, an engineer on her team was very unhappy about a product change. She asked Rachel Whetstone for an FAQ.
Whetstone phoned him instead, listened, then explained her reasoning. He changed his mind completely and told the rest of the org. Yehoshua's lesson: "You just act. You're authentic. You listen to people and you're transparent."
She commits to a decision rather than hunting for the right one. Her father told her, "There are no right decisions. You make a decision right."
She skips the "what if I had taken that job" regret. Her psychiatrist father also quizzed her after family events on why people acted as they did, which trained her to read a room.
5How Yehoshua uses AI in her own work
She says to use AI products constantly, as good PMs did with mobile. Her list is ChatGPT, Glean and Claude. Many engineers and PMs try a tool once, find it doesn't work, and go back to old habits, which she calls a dangerous spot.
"Use the products. This is what good PMs should do period." She uses Glean 10 to 15 times a day for things like deal status or the latest design doc.
She points to long-context models for mining community feedback. A PM exported a whole Discord channel into Gemini and asked about sentiment, top requested features and complaints.
He called it a goldmine and said he would never have read it all by hand.
Glean's Gong summaries only worked after Yehoshua's team tuned the prompt. They summarized Gong sales calls into a spreadsheet by account executive with the top requested features.
The first prompt failed to separate what customers asked for from what salespeople recommended. "It's not going to work out of the box."
She built a prompt that reports a feature's real launch status. It checks the launch calendar date against open Jira tickets, Slack threads and beta customer feedback, then gives a confidence level for the date.
She built it at Glean in a couple of weeks, so she no longer reads every related channel.
She expects strategic, creative PMs to thrive and execution-only PMs to struggle. AI can list customer problems, but a PM must work out how to solve them and differentiate. She hopes it automates grunt work like updating Jira and building launch calendars.
She expects fewer weak PMs but not fewer people overall, since companies always want more engineers. In five to 10 years she sees the lines between PMs, engineers and designers blurring.
6Yehoshua's rules for building AI products at Glean
Glean started as enterprise search and added chat on top. It began in 2019 using BERT and vector embeddings, and GPT-3 added a chat interface.
Her investors describe Glean as an AI company that is actually making money.
She tells builders not to differentiate on work that compensates for weak models. That work disappears as models improve. The whole product should get better as the LLMs get better, with something outside the LLM that keeps differentiating it.
It is fine to build compensating work, as long as you know it will go away.
Glean adds guardrails because users don't know what chat can answer. Users ask things the system cannot know, such as their own top priority next week. Glean uses autocomplete, refinements at the bottom of the page and suggested prompts.
Glean's assistant quality team found this was one of the biggest issues.
She says enterprise buyers still expect deterministic software. Chat is harder to learn than search, and ChatGPT retention is reportedly fairly low because it is not in people's workflow.
A CIO who plays with ChatGPT on weekends still expects deterministic software at work, so users need help accepting non-deterministic output.
Lessons in product leadership and AI strategy from Glean, Google, Amazon, and Slack | Tamar Yehoshua
Tamar Yehoshua shares career and product leadership lessons from Amazon, Google and Slack, plus practical ways to use AI at work and build AI products. Her advice is to follow great people, pair tightly with engineering, and use AI tools hands-on, backed by Slack's 10x revenue growth and Glean's success as an AI company that makes money.
Yehoshua has led product at Amazon, Google, Slack and now Glean. She spent five years at Amazon (A9.com), years on Google Search, four years as Slack's product chief, and now runs product and technology at Glean.
She never had a five-year plan and says she still has no idea what she'll want in five years. Slack grew revenue 10x on her watch.
She follows the best people at their craft, not a plan. She picks jobs where she will learn most from the best product thinker, engineer or salesperson, not just someone she likes.
She joined several companies that failed or stalled and still kept her skills and relationships. Her view: "Skills can't be taken away."
She takes jobs where the people she hires will make their careers. A friend gave her this advice while she was weighing turnaround offers. It raises the bar: she must honestly believe people will learn and grow there.
Without a gravitational pull, recruiting is very hard. She knew one person who took a job as a mercenary, and it did not work out.
She turned down a management job because the team should not exist. Early in her career she told her manager the new team she was offered should not exist. He agreed and found her something else.
She defines impact as building something people use and doing the right thing for the company, not just hitting assigned goals. Her one-word summary is "impact".
She treats technical depth, product knowledge and metrics as table stakes. Before aiming at a bigger role, she says, master what every tech job demands: know the latest technology, understand the product deeply and read the metrics.
She says ambitious product managers slip by eyeing the next job. Her instruction is to do a great job however simple the work is.
Yehoshua meets and assesses the engineering partner before joining a company. A product leader ships only as far as the engineering partner allows. If the partner is wrong, she checks that the organization is willing to change.
She names Slack co-founder and CTO Cal Henderson as the partner she could not have bettered.
She sets clear roles so nobody plays one leader against the other. If someone asked her about Cal's domain, she asked "Did you talk to Cal?" and never went around him. Where ownership was unclear, they talked and decided who would take it.
The goal was to avoid the "ask Mom, ask Dad" setup where people collect two different opinions.
She builds respect on trust that the other person follows up. When she asked Fuzzy Khos for more mobile engineers, he said "I'm on it", and that was all she needed.
If he could not deliver, he came back and said there would be a problem.
She and the Slack CTO ran every review together. They attended all OKR reviews, held a weekly Monday review of only the red items, and met weekly with their two chiefs of staff.
Each knew which questions the other would dig into. When she disagreed with a priority she said so directly, rather than complaining to her team afterward.
She replaced live OKR reviews with recorded updates after they passed 300 hours. Teams posted a doc and a time-limited Slack Clip in their planning channel. The two leaders watched them together and asked follow-ups in channel.
Only five to 10 teams got a live follow-up meeting. They revisited the process every quarter, like a product.
Bezos made Amazon easy to work in by never changing his principles. Everything had to be customer driven, and he hated icons without labels, so after a few meetings you knew what he would ask.
He spoke last, after every lead around the table, and remembered details from one quarterly meeting to the next. Meetings ran on six-page memos, which she compares to studying for a final exam.
Bezos told her that competitors having 10 times the people was her advantage. A product, he said, is a seven-year hill, so headcount alone does not decide the outcome.
Butterfield paired a fixed long-term plan with a belief in prototyping. His 2014 master plan was a four-box grid: a loved product, a network (Slack Connect), a platform, and "magic AI stuff". It never changed.
He said a mock-up cannot show how something will feel. For the redesign he had the team put the whole interface behind one button. It was never shipped, but it started the redesign.
She says prototyping only works if engineering is set up for it. Engineers must be willing to throw code away and write production code later. Slack redesigned its mobile apps because they were too hard to prototype, while the desktop app was easy.
At Google, the head of front-end engineering called a team of prototypers his secret weapon. Early prototypes can be Figma, then move to real data.
Benioff taught her to keep a beginner's mind and treat a keynote as a product. His advice was to assume you know nothing and listen to customers. She appeared in his Dreamforce keynote two years running after the Slack acquisition.
She saw him push the envelope, for example by standing outside a competitor's conference.
She says product-market fit matters more than being well run. She knows chaotic companies with unhappy staff and amazing growth, and a well-run one that flatlined. No product-market fit is a death sentence.
Only a strong distribution machine can offset it. She puts 80 to 90% of sales feature requests in the category that won't matter to company success.
She separates normal hypergrowth chaos from the harmful kind. Fast growth breaks infrastructure and communication, and half the company may have been there under six months. Constant strategy changes that stop people finishing anything are harmful.
Chaos is no excuse to stop running a functioning, motivated team. She says to skip great companies if the chaos would make you unhappy. Chaos stops being acceptable once a company passes roughly 5,000 to 10,000 people.
She pairs metrics with intuition about customers. Over-reliance on metrics is the risk she warns product managers about. Decisions that feel right usually are, if you know the product well.
Her own failure mode is assuming everyone will want what she worked on. A feature has to earn its place front and center in the interface.
She designs for tomorrow's users, not the vocal few. When removing features that a small set of users relied on, she held that today's user count is usually far smaller than tomorrow's.
After a UI redo, existing users complain but new users find it much easier. She says to explain the change without marketing speak and give people choice and time, as with the move from Slack calls to Huddles.
She learned from a Google PR chief that a phone call beats an FAQ. At Google, with about 50,000 people, an engineer on her team was very unhappy about a product change. She asked Rachel Whetstone for an FAQ.
Whetstone phoned him instead, listened, then explained her reasoning. He changed his mind completely and told the rest of the org. Yehoshua's lesson: "You just act. You're authentic. You listen to people and you're transparent."
She commits to a decision rather than hunting for the right one. Her father told her, "There are no right decisions. You make a decision right."
She skips the "what if I had taken that job" regret. Her psychiatrist father also quizzed her after family events on why people acted as they did, which trained her to read a room.
She says to use AI products constantly, as good PMs did with mobile. Her list is ChatGPT, Glean and Claude. Many engineers and PMs try a tool once, find it doesn't work, and go back to old habits, which she calls a dangerous spot.
"Use the products. This is what good PMs should do period." She uses Glean 10 to 15 times a day for things like deal status or the latest design doc.
She points to long-context models for mining community feedback. A PM exported a whole Discord channel into Gemini and asked about sentiment, top requested features and complaints.
He called it a goldmine and said he would never have read it all by hand.
Glean's Gong summaries only worked after Yehoshua's team tuned the prompt. They summarized Gong sales calls into a spreadsheet by account executive with the top requested features.
The first prompt failed to separate what customers asked for from what salespeople recommended. "It's not going to work out of the box."
She built a prompt that reports a feature's real launch status. It checks the launch calendar date against open Jira tickets, Slack threads and beta customer feedback, then gives a confidence level for the date.
She built it at Glean in a couple of weeks, so she no longer reads every related channel.
She expects strategic, creative PMs to thrive and execution-only PMs to struggle. AI can list customer problems, but a PM must work out how to solve them and differentiate. She hopes it automates grunt work like updating Jira and building launch calendars.
She expects fewer weak PMs but not fewer people overall, since companies always want more engineers. In five to 10 years she sees the lines between PMs, engineers and designers blurring.
Glean started as enterprise search and added chat on top. It began in 2019 using BERT and vector embeddings, and GPT-3 added a chat interface.
Her investors describe Glean as an AI company that is actually making money.
She tells builders not to differentiate on work that compensates for weak models. That work disappears as models improve. The whole product should get better as the LLMs get better, with something outside the LLM that keeps differentiating it.
It is fine to build compensating work, as long as you know it will go away.
Glean adds guardrails because users don't know what chat can answer. Users ask things the system cannot know, such as their own top priority next week. Glean uses autocomplete, refinements at the bottom of the page and suggested prompts.
Glean's assistant quality team found this was one of the biggest issues.
She says enterprise buyers still expect deterministic software. Chat is harder to learn than search, and ChatGPT retention is reportedly fairly low because it is not in people's workflow.
A CIO who plays with ChatGPT on weekends still expects deterministic software at work, so users need help accepting non-deterministic output.