Productside Stories

AI Evaluation for Product Managers: Why Benchmarks Lie

Featured Guest:

Yoav Goldhorn | Chief Product Officer at PALSAR and AI Evaluation Manager at Red Hat
10/20/2026

 

Summary

In this episode of Productside Stories, Rina Alexin talks with Yoav Goldhorn, who leads AI Evaluation Manager at Red Hat while also serving as Chief Product Officer at PALSAR. Yoav arrived in this field through a master’s degree in data science at North Carolina State University, nearly a decade in Israeli military intelligence, and a series of product leadership roles at startups. He is building a field that barely existed two years ago.

The conversation covers why AI benchmarks measure the wrong thing entirely: they test the model, while product teams ship systems. It explains why adding ten tools to a frontier AI agent can drop its performance from near 100% to 67%, why LLM-as-a-judge scoring is less reliable than most teams assume, and what the metrics pass@k and pass^k actually tell you about whether your AI system will hold up under real-world load.

Yoav shares his own aha moment: a workflow he spent weeks running manually, decomposed into seven agentic workflows, that compressed four hours of work into 25 seconds once properly specified. That experience, he says, is what convinced him we are not in the middle of an AI revolution: we are on the cusp of an agentic one. He closes with the most practical advice he gives product leaders: verbalize your failure modes before you ship, because if you have not said them out loud, your engineers almost certainly have not built around them either.

Key Takeaways

Benchmarks test models. Products ship systems. Those are not the same thing.

  • The famous benchmarks score frontier models at near 100%. Real agentic tasks given to those same models complete at around 20%. The gap comes from measuring the wrong object: a neural network with weights, instead of the full system with context, tools, agents, and harnesses that your product actually uses.

Adding more tools makes agents worse, not better.

  • Research found that when a frontier model reached a toolbox of just ten tools, performance on standard benchmarks dropped from near 100% to around 67%. Product managers building agentic systems need to understand that tool overload is a real and measurable failure mode, not a theoretical one.

LLM-as-a-judge is less reliable than most teams assume.

  • Asking one LLM to score another LLM’s output on a scale of zero to one produces answers that diverge significantly depending on which model is scoring and what context it has. If you cannot precisely define what “correct” means yourself, you cannot expect a model with even less context to define it consistently.

Pass@k and pass^k are the metrics product managers need to learn.

  • Pass@k asks: if I run this test five times, how often does it pass my threshold? Pass^k asks: what is the likelihood that all five runs pass? In high-stakes environments, pass^k is the number that matters. Product managers deploying AI to thousands of users need to know their system’s consistency, not just its average accuracy.

The agentic revolution is not the same as the LLM revolution.

  • ChatGPT was a tech demo that grew beyond its design. Agentic AI, systems that reason, make decisions, and carry out multi-step workflows with given constraints, is a different order of magnitude. The breakthrough, Yoav says, was not the language model. It was the logic and reasoning layer on top of it.

If you do not verbalize your failure modes, nobody can build around them.

  • The single most useful thing a product leader can do today: ask what AI failure would cost you your customers. If you cannot answer that question precisely, your thresholds are not set, your alerting is not configured, and your team cannot respond when something goes wrong.

Chapters

  • 00:00:00 – Introduction to Yoav Goldhorn and AI Evaluation
  • 00:04:27 – Limitations of Current Benchmarks and Real-World AI Performance
  • 00:08:43 – Moving Beyond Answer Correctness to Better Metrics
  • 00:11:57 – The Importance of Evaluating User Input Quality
  • 00:15:08 – Understanding Pass@k and Its Significance
  • 00:18:08 – Setting Thresholds and Managing AI Risks
  • 00:21:56 – Building Trust and Avoiding Trust Erosion
  • 00:23:22 – The Evolution of AI Quality Assurance Practices
  • 00:25:37 – The AI Revolution Versus the Agentic Revolution
  • 00:27:16 – The Breakthrough Moment with AI Reasoning and Logic
  • 00:29:55 – The Rise of Agentic Systems and Future Implications
  • 00:30:22 – How Product Managers Can Leverage AI Agents
  • 00:31:27 – The Peanut Butter and Jelly Sandwich Exercise and Communication
  • 00:32:21 – The Role of Product Managers in AI Evaluation and Communication
  • 00:34:50 – Leadership’s Role in AI Evaluation Maturity
  • 00:36:04 – Warning Signs of Immature AI Evaluation Practices
  • 00:37:39 – Avoiding Confirmation Bias in AI Testing
  • 00:38:15 – Practical Advice for Improving AI Evaluation Practices
  • 00:40:33 – Key Questions for AI Performance and Organizational Readiness
  • 00:41:03 – Connecting with Yoav Goldhorn on LinkedIn

Why Listen to This Episode?

In this episode, you will get:

  • A plain-language explanation of why AI benchmarks mislead, and what the model/agent/system distinction means for how you evaluate AI features before launch
  • The pass@k vs. pass^k distinction explained for product managers, not data scientists
  • A concrete model for what AI quality assurance looks like as a function, and who should own it in your organization
  • Yoav’s aha moment: how a four-hour manual workflow became a 25-second agentic workflow once properly specified
  • The one question every product leader should be able to answer before they ship any AI component to customers

 

Introduction to Yoav Goldhorn and AI Evaluation

Rina Alexin | 00:00:02 – 00:00:56

Hi everyone, and welcome to Productside Stories, the podcast where we dig into the very real and raw lessons learned from product leaders and thinkers all over the world. I’m your host, Rina Alexin, CEO of Productside, and today I’m talking with Yoav Goldhorn, Chief Product Officer at PALSAR and AI Evaluation Manager at Red Hat. At Red Hat, he leads the global research and development team building a rigorous methodology and tools for measuring how AI systems actually perform.

Before that, he spent nearly a decade in Israeli military intelligence before taking on multiple product leadership roles at startups. Today we’re going to be talking about why most AI benchmarks might be measuring the wrong thing entirely, why individuals inside organizations are racing so far ahead of their leadership on AI, and what product leaders can actually do to close that gap. Welcome, Yoav.

Yoav Goldhorn | 00:00:56

Hi Rina, great to be here.

Rina Alexin | 00:00:58

I have to say: Chief Product Officer I’ve heard before, but AI Evaluation Manager is a brand new field. Can you explain it? And how did you even end up here? Tell us about your story.

Yoav Goldhorn | 00:01:12 – 00:04:27

It is a brand new field, and as I hope we’re going to explore, it’s very much a wild west. We’re still at the nascent stages of the AI revolution and very much at the nascent stages of AI evaluations.

I got to this role via my master’s degree. I moved to North Carolina to take a master’s at the Institute for Advanced Analytics at North Carolina State University. It is the country’s oldest data science program and it appealed a great deal to me. When I was close to graduation, I really felt like I wanted to blend data science with agentic systems. I bring a lot of pilot experience, so I wanted to work at a strategic level on one hand, but also with a lot of technical rigor on the other. That is a very unique blend. I found very few openings that offered exactly that. Red Hat was one of them, and by far the most interesting.

When I first started, we didn’t really have a clear picture of what precisely I should be doing. It was a much more open question than a list of tasks. I had the pleasure of coming up with the grand strategy for how to approach this problem, defining the methodologies and frameworks we were missing, identifying the problem statements, and then coming up with solutions together with our architects, engineers, and leadership.

Limitations of Current Benchmarks and Real-World AI Performance

Rina Alexin | 00:02:58 – 00:04:27

How does your background in special ops and product management help you figure out your role? Because it sounds like you’re defining it as you go.

Yoav Goldhorn | 00:03:16 – 00:04:27

We love using this phrase: we’re building the plane as we’re flying it. That is literally what’s going on.

Let me define AI evaluations clearly, because there are a lot of connotations. My team and I are responsible for building the methodologies and tools to ensure that AI system outputs are at the quality, consistency, and reliability that we expect them to be. A lot of that has to do with performance, a lot has to do with security. My team is focused primarily on quality evaluations: having an AI system that consistently delivers reliable, actionable outputs that cover the entire user input and do what you actually want them to do, subjectively and abstractly, at a consistent level. That is a huge challenge even with today’s frontier models.

Here is a number I like to quote. Research came out recently that measured how different frontier models handle agentic workflows in real-life scenarios. We have our benchmarks: SWE-bench, ARC-AGI, and all the famous ones where models are basically outputting near-100% quality results. But when that research group took real freelance work and assigned it to AI agents built on these frontier models, the best model managed to complete only 20.2% of the tasks. And Claude Fable 5.5 was tied for second place at around 19%.

Rina Alexin | 00:05:26

What? 20%?

Yoav Goldhorn | 00:05:45

19. Yes.

Rina Alexin | 00:05:44

19. Wow. Okay. So where is the 80%? Why the gap?

Yoav Goldhorn | 00:05:57 – 00:08:43

Exactly: where did that go? We have four major problems, but I want to touch on the two most concerning.

  • First: misspecification of what we’re actually measuring. Benchmarks measure the model: the neural network with its weights. But when product managers build an AI system or an AI-centric component, we are not using just a neural network with weights. We’re using agents, we’re using harnesses. Model plus harness is an agent. We’re using entire systems with context and tools that span way beyond the model itself that the benchmark actually measured. If you’re not measuring the same thing, you should not expect the same results.
  • Second: lack of definition for what we’re checking. We are still not very good, and I mean the tech world broadly, at defining the thing we’re measuring. Two very popular AI evaluation frameworks have a test called answer relevancy or answer correctness. It takes an LLM as a judge, gives it the output that another LLM generated and the user input, and then asks: on a scale of zero to one, rate how correct the answer is. Sometimes you measure it against a ground truth, which is its own problem: if you already know what the answer should be, can you not perform a more deterministic check? But often you don’t know what the answer should be, because the answer depends on nuances and on the user input.

Think about it this way: take a group of very smart, very capable people from a university classroom. Give them a question-answer pair and ask each of them: how correct is this answer on a scale of zero to one hundred? They are going to diverge significantly. So does the LLM. If we cannot precisely define what it means to be correct ourselves, how can we expect an LLM with even less context than we have to do that consistently and explainably?

Moving Beyond Answer Correctness to Better Metrics

Rina Alexin | 00:09:21 – 00:09:30

So the problem is that we don’t know how to properly measure the quality of the output. How do we move from 20% to 40% task completion?

Yoav Goldhorn | 00:09:52 – 00:11:57

Conceptually, there are a couple of things we need to do very differently.

First, we need to measure what we’re evaluating much more precisely. We need a taxonomy and even an ontology that is much broader than what we currently have. The most popular evaluation frameworks today have maybe five or six pre-built evaluation tests. That is nowhere near enough.

The structure my team has landed on asks: what is the object at test? What are we actually measuring? There is a meaningful difference between measuring an entire system, measuring just an agent, and measuring just a model without any harness. You also have to measure the RAG engine, the MCP servers, the tools as individual tools, and the tools as a collection.

And this brings up something important: when you reach a toolbox with just ten tools, even frontier models drop in performance on standard benchmarks from nearly 100% to around 67%. It’s a huge drop just from adding more tools.

Rina Alexin | 00:11:48

So adding more context actually reduces their ability to perform. That’s interesting.

Yoav Goldhorn | 00:11:51

A lot of the time, yes. You have to figure out the evaluation hierarchy: what object are you precisely measuring? Keep everything constant, change just one thing, then measure the differences. Then ask: what aspect am I evaluating? Because if I want to evaluate the output, what specifically about the output do I want to evaluate? And output is not the only thing worth evaluating: I might want to evaluate internal reasoning, or the tool calls the agent is making.

The Importance of Evaluating User Input Quality

Yoav Goldhorn | 00:11:57 – 00:15:08

One of the things I don’t see people doing nearly enough, and we are strong advocates for, is evaluating the quality of the user input as well.

It’s only natural: if the user input lacks clarity, lacks specificity, or doesn’t precisely cover a topic, how well would we expect a skilled human worker to answer that? So why would we expect an LLM to do any better?

Rina Alexin | 00:12:57

It’s garbage in, garbage out. It’s almost like when I ask my husband to do something mid-sentence.

Yoav Goldhorn | 00:13:06

Yes. And we have guardrails against that, both in relationships and in model evaluation.

Rina Alexin | 00:13:15

So if you’re prompting incorrectly, you should also be evaluating the quality of the input.

Yoav Goldhorn | 00:13:25 – 00:15:08

Exactly. We want to measure a lot more. We also have to abstract all of this, because leadership doesn’t want to see a bunch of tables. We are data scientists and we love data sets, but leadership typically cares about one number.

And I think it is our job, whether you’re coming from a data science perspective or a product management perspective, to first question the results we see, and then ask: am I truly representing reality here? I have to make sure that the numbers I’m reporting are stable. If I can run the same test four different times and get four completely different answers, then either my test or my test subject is not what I need it to be.

Understanding Pass@k and Its Significance

Rina Alexin | 00:15:08 – 00:15:28

Is running evaluations multiple times a minimum of what someone can do to check stability?

Yoav Goldhorn | 00:15:17 – 00:18:08

You definitely want to run evaluations again, and there are metrics we need to start adopting: pass@k and pass^k. Let me define those.

  • Pass@k asks: if I run this test k times, say five times, what is the percentage of those runs that pass my threshold? And critically, I have to set a threshold. I have to decide what counts as a passing grade.
  • Pass^k asks: if I run this test five times, what is the likelihood that all five of them pass the threshold?

That second number, pass^k, is hugely important in high-stakes environments. As product managers deploying AI components, we want to start talking about those numbers and their distributions. If I have ten thousand users interacting with the system in a certain way, how confident am I as a product manager that my system will perform well all ten thousand times? Pass^k is the metric that answers that question.

Setting Thresholds and Managing AI Risks

Rina Alexin | 00:16:43 – 00:18:08

A lot of the product leaders I’ve talked to this season mention LLM-as-a-judge as a practice. But I don’t think practices are fully mature at most organizations. Individuals are often more mature than their organizations. Why is evaluation so important for product managers specifically?

Yoav Goldhorn | 00:18:05 – 00:21:56

Let me start with the product manager’s perspective. If you were the product manager for a company that builds vehicles of all sorts, you would not use one test for a sedan, an SUV, a truck, and a train engine. You would not compare different object types on the same test. Same principle applies to AI components.

You also cannot describe an AI component’s quality with one number. You need many numbers to understand its different qualities. With those numbers, you can change your behavior and your procedures at the product level.

We advocate a two-fold approach:

Before launch: set thresholds as objectively as possible with as little confirmation bias as possible. Don’t think about how your AI performs so far. Think about what AI system you would trust to put in the hands of your customers. Figure out the thresholds from there. Ask: what indicators will tell me when something goes wrong in the output, in the reasoning, in any underlying component? Before you ship, make sure you pass those thresholds with statistical significance. Product managers in the age of AI need to learn at least a little bit of statistics.

After launch: you have live data coming in. Some interactions will fall below your thresholds. Accept that as a fact, because you are not dealing with deterministic systems anymore. Set up gates and an alerting system that tells you when something systematically fails. When that happens, you as a product manager need to have worked ahead of time with your engineering teams, architects, and business leadership to respond quickly: categorize what went wrong, identify the root cause, understand your timeline to fix. If you do not speak in those terms and transmit those insights back to leadership, they will treat every AI failure as just another hotfix. Engineering teams get left helpless because no one understands deeply enough why AI systems fail. We need systemic, company-wide approaches to that root cause analysis.

Building Trust and Avoiding Trust Erosion

Rina Alexin | 00:22:03

What’s the danger for organizations that don’t get better at this?

Yoav Goldhorn | 00:22:09 – 00:23:22

First, they might lose business to a competitor who does better. That is what every product manager is concerned with.

But to answer more directly: from my experience in special operations, building systems that people trust means you cannot fail. In special operations, failure means loss of lives. Sometimes the rerepercussions are diplomatic in scale. Building systems that high-stakes users trust means you need extensive contingency plans, and you need your stakeholders to understand very deeply what your system is doing, which also aligns expectations.

For commercial products, the answer is simpler: if you do not implement better AI evaluation methods, you will lose your users’ trust. And if that trust is vital to users choosing your platform, you will lose your users. As simple as that.

 “If you don’t want to get replaced by AI, own your work.”

The Evolution of AI Quality Assurance Practices

Rina Alexin | 00:23:53 – 00:24:57

Organizations are struggling to even articulate simple governance for how individuals use AI. How do they make the leap to what you’re describing?

Yoav Goldhorn | 00:24:57 – 00:25:37

If they have data scientists and AI engineers, they need to understand that they have a new discipline: AI quality assurance. This is what it boils down to.

We’ve had quality assurance in software development for many years. That was mostly deterministic work, and an entire profession grew around it: first one person, then departments, and today many teams have moved to a model where each engineer is also their own QA. If you’re building AI products, your AI engineers need to be as proficient in AI quality assurance and evaluation as classical programmers were in traditional QA. And if your resources and scale justify it, you may need an entire dedicated function for AI evaluation.

Rina Alexin | 00:26:14

There’s no shortcut.

Yoav Goldhorn | 00:26:16

There are no shortcuts. Hopefully my team will provide tools and methodologies to deliver a capability out of the box. Nvidia has contributed to one such framework. But take all of those with a grain of salt, mine included. Your engineers must understand deeply how evaluations are performed, because evaluations are your only quality gate. With deterministic products you can click a button, test a field, and ship. With AI, there is an uncountable number of ways users can interact with your system. You do not get the luxury of small test cases.

The AI Revolution Versus the Agentic Revolution

Rina Alexin | 00:27:48

You’ve said you had aha moments along the way. Can you share some?

Yoav Goldhorn | 00:28:42 – 00:27:16

We have aha moments every other week now. Things are moving that fast. Let me share two.

The first was when we laid out the foundations for our AI evaluation methodology, the one that decomposes entire workflows into what AI aspects we’re actually measuring and how to make them as deterministic as possible. That led to a realization:

 “We’re not in the middle of an AI revolution. We are on the cusp of an agentic revolution.”

I want to be clear. Yes, it started in the eighties in a different sense, but we’re not talking about that. ChatGPT was a tech demo that grew beyond its design. It was not a working tool. It was not meant to be a working tool. That is also part of my second aha moment.

The Breakthrough Moment with AI Reasoning and Logic

Yoav Goldhorn | 00:29:44 – 00:29:55

As Chief Product Officer at PALSAR, I had a workflow I ran manually over many weeks. I took some inputs, one-shot an LLM, saw the output, worked with it. Very quickly that evolved into multi-shot: taking the output, pasting it somewhere else, doing manipulations, returning it to another locally-run agent. All manual. All time-consuming.

I eventually built a graphical interface that wired everything together with the same logical process I was going through in my head, decomposed into a series of agentic workflows using seven different models: Claude for a specific part, and the rest were locally-run models, each with their own precise assignment.

When I saw that perform as well as I did manually, because I had given it very precise instructions with very precise conditions, and I saw that what took me three and a half to four hours was done in 25 seconds, that was when I realized we are at an entirely different type of revolution.

“AI reasoning and logic are the real revolution.”

It was not the language model part that impressed me. It was the reasoning, the logic, and the ability to make decisions given the right constraints. And that is exactly what makes me pursue better AI evaluations at Red Hat. We cannot yet verbalize our working patterns well enough. But when we can, we can build agentic systems that take care of entire workflows. That has huge implications for the future of work.

The Rise of Agentic Systems and Future Implications

Yoav Goldhorn | 00:29:55 – 00:30:22

To summarize it in a sentence: if you don’t want to get replaced by AI, own your work. Make sure you are the person still delivering the deliverable. Build your own army of AI agents that performs the thinking process you do, as precisely as you would have done it. Do not count on them to know what to do. You know what to do. That is why they hired you. You are the expert. But you now have an army of assistants to carry you through the work day. Use it.

How Product Managers Can Leverage AI Agents

Rina Alexin | 00:30:22 – 00:31:27

We’ve moved from thinking about prompt engineers to something more like agentic engineers. The entire time you were talking, I kept thinking about the peanut butter and jelly sandwich exercise. Do you know it?

Yoav Goldhorn | 00:34:02

I am happy to learn.

The Peanut Butter and Jelly Sandwich Exercise and Communication

Rina Alexin | 00:31:27 – 00:32:21

You ask people to write down the steps to make a peanut butter and jelly sandwich. Then someone else does exactly what’s written. It is hilarious, because there is so much you know about making a sandwich that you never think to write down. You don’t say “put the knife in the peanut butter and pick it up.” You just say “put peanut butter on the bread,” and someone takes the jar of peanut butter and places it on the bread.

That exercise illuminated for me how difficult it is to communicate requirements, how much implicit knowledge goes unstated. And in talking with you, this is a core skill for product managers now.

The Role of Product Managers in AI Evaluation and Communication

Yoav Goldhorn | 00:32:21 – 00:34:50

Exactly. And the person who needs to own that transformation at an organization is usually someone in C-suite leadership, because it has to be something the entire company is aligned to.

For product managers specifically:

As we integrate more and more agentic capabilities into products, which is often a leadership and market requirement, product managers have to perform these highly detailed decomposition steps and guide the innovative thinking required. A lot of the time, software engineers have turned into AI engineers without specialized training, and that is fine. But you as the product manager have the leverage of a wider point of view.

  • We have to use that wider view for the company good, the product good, and the user good
  • We have to teach our colleagues how to think and how to decompose agentic tasks
  • When building a system, product managers must own the entire decomposition as a product process
  • That decomposition becomes the requirements for AI engineers to build, not something we want to abstract away and trust them to infer from our heads

If we abstract away and trust AI engineers to understand what’s going on in our heads, they’re going to perform about as well as the average LLM probably. We have context that they don’t. We have to give it to them.

Leadership’s Role in AI Evaluation Maturity

Rina Alexin | 00:34:50

Who is going to lead the change at organizations? I tend to think product managers have the capabilities, but they struggle with becoming very precise.

Yoav Goldhorn | 00:35:40 – 00:36:04

The person who needs to own the transformation is usually in C-suite leadership, because it has to be something the entire company is aligned to. Whether this applies to specific roles or to everyone is a business decision more than a product decision. But the product manager’s job is to advocate for it, promote it, and consider its implications for the product, because our area of responsibility is the product itself.

Warning Signs of Immature AI Evaluation Practices

Rina Alexin | 00:37:51

Are there warning signs at organizations that are really immature? How can a product leader tell?

Yoav Goldhorn | 00:38:00 – 00:37:39

Yes, there are warning signs. But first: most of us are immature, and that is fine. It is a brand new field. Accept that we are in a nascent state. Accept that this is a wild west with no concretely good answers. Walk with what you have. It is better to break and fix than to not do it at all or to spend eternity in planning hell.

But look for the warning signs:

  • You as a product manager must set the thresholds for what you consider a quality output, very precisely
  • You must think through: what indicators would tell me my AI outputs are not at the quality I expected?
  • You must decide at what point you stop production efforts, trigger an alert, and start root cause analysis
  • You must know who is on your mitigation team when something goes wrong

If you are serving high-stakes industries: nationally critical infrastructure, government, defense, aviation, telecom, you may have cases where you need to stop all work and everyone performs root cause analysis immediately. For more lenient use cases, set up alerts and work it into your next version, but still perform root cause analysis offline. Set your gates and alerts according to preset thresholds.

Avoiding Confirmation Bias in AI Testing

Yoav Goldhorn | 00:37:39 – 00:38:15

And do not let confirmation bias get you. This is very important. We tend to look for the signals we already know. Do not look only under the lamplight. Think as broadly as possible and let the data tell you when things are going wrong.

“Don’t assume that you will know the failure modes ahead of time.”

Rina Alexin | 00:41:00

That’s such a good reminder. Before AI, we used to talk a lot about the importance of avoiding confirmation bias. I like to structure experiments to prove me wrong so that I can’t have confirmation bias. It’s such an important discipline to bring to AI evaluation too.

Practical Advice for Improving AI Evaluation Practices

Rina Alexin | 00:41:24

Given that AI evaluations are critical but we’re early in the skill-building, what advice do you have for product leaders who realize they need to improve? What is one thing they could do?

Yoav Goldhorn | 00:40:45 – 00:41:03

One thing product leaders and business leaders can do to improve: first, understand how sensitive your target audience and your real customer profile are to different aspects of AI failing.

Some examples:

  • If your AI component is supposed to provide instructions and it provides wrong instructions, that is probably core to your entire business
  • If your chatbot breaks out of persona and replies as Mike instead of Steve, that might not matter too much

To start improving, you have to first understand: what would be your major problems? What fail patterns would trigger a huge warning sign that something is going wrong? What would make you lose customers? Prioritize those, then fix that first. It sounds trivial, but when you actually ask business leaders how they expect their AI components to perform, what I find most of the time is that they do not verbalize this. And if they do not verbalize it to you, they probably have not verbalized it to themselves, which means they do not have the procedures in place to track it.

Key Questions for AI Performance and Organizational Readiness

Rina Alexin | 00:41:03 – 00:41:15

What I heard from you is: ask the right questions, find the mission-critical failure modes, and start there. Leadership cares about one number, but they would definitely care about losing customers. That makes sense.

Yoav, I truly appreciate you coming on and sharing your wealth of experience. How can our listeners follow you or reach out after they’ve listened to this episode?

Connecting with Yoav Goldhorn on LinkedIn

Yoav Goldhorn | 00:41:15 – 00:41:30

I’m not a super public person, but you can find me on LinkedIn. Feel free to send me a connection request. Just mention that you heard about me on Productside so I know you’re not a complete stranger, and I would love to connect.

Rina Alexin | 00:41:30 – 00:41:41

I appreciate that, Yoav. And thank you all so much for listening to this episode of Productside Stories. If you liked today’s conversation, please don’t keep it to yourself. Make sure to share with a friend and subscribe so you don’t miss a future episode. I’m Rina Alexin, and from all of us at Productside: let’s do product better, together.