
For the Love of Product ๐๐ ยท 2026-03-20 ยท 43 min
Key moments - from our scoring
Substance score
38 / 100
Five dimensions, 20 points each
The conversation explores the collision between feature inflation and AI tooling in product development. With AI enabling teams to build integrations and features in hours rather than weeks, product managers face intense pressure to ship faster while risking the creation of feature factories that dilute core business value. Ohad Biron, CEO of product intelligence platform Bagel AI, emphasizes that the real competitive advantage now lies not in building more features, but in understanding what drives business impact. He introduces the concept of "time to impact" - maximizing impact while minimizing time to market - as the metric that matters most. Bagel AI analyzes qualitative feedback sources (Gong calls, support tickets, CRM notes, NPS) alongside quantitative data to help product managers quantify their roadmaps and identify which initiatives actually move the needle. Biron also addresses the classic build-versus-buy decision in the AI era, arguing that while AI makes internal development easier, teams should evaluate three factors: whether it's core business, data reliability, and total cost of ownership. He cautions against the "open check" mentality of experimentation, warning that unchecked AI infrastructure costs and maintenance burden often outweigh the benefits of building in-house unless it's genuinely differentiated capability.
Focus on understanding your core business and optimizing for time-to-impact rather than feature velocity. Use metrics like rework ratio to validate whether shipped features actually solved the intended customer pain, and ensure synchronization between product, go-to-market, and other stakeholders before building.
Time-to-impact means maximizing business impact while minimizing time to market. It matters because shipping features fast without ensuring they drive real business outcomes leads to rework, damaged reputation, and wasted resources - the metric forces teams to focus on what actually moves the business needle.
Evaluate three factors: Is it your core business (opportunity cost of focus), is the data reliable enough to make decisions on, and what's the total cost including maintenance and scaling. Unless it's genuinely differentiated capability, the open-ended costs and maintenance burden of building often make buying more economical.
Bagel AI is a product intelligence platform that automates the product management lifecycle by analyzing qualitative feedback sources (Gong calls, support tickets, CRM notes, NPS) to extract product pains and gaps, then connects them to quantitative data and analytics to quantify and evaluate the roadmap.
Horizontal tools like ChatGPT provided broad access to data, but vertical solutions succeed because the real difficulty is getting the right data in the right business context at the right time - solving that vertical problem becomes the moat for specialized AI players.
Our reviewerโs read on each dimension, with quotes from the episode.
A handful of genuinely useful concepts surface - rework ratio as a proxy for alignment quality, 'time to impact' as a successor to 'time to value', and the PM/engineer role convergence - but they are buried in significant padding, host restatements, and platitudes about 'focus' and 'core business.' The density per minute is low.
rework ratio, meaning when I can ship features very fast, how many of them come back to development because of enhancements, request or bugs or something that was wrongly, uh, described or done in the next quarter?
what you actually need to optimize is time to impact. We used to think about time to value, right? But time to impact is actually what matters nowadays
The 'time to impact' reframe and rework ratio are mildly fresh angles, but the build-vs-buy triangle is explicitly acknowledged as decades-old, the feature factory warning is ubiquitous, and the 'Good Strategy Bad Strategy' Rumelt reference is a well-worn recommendation. Almost nothing is contrarian or first-principles.
bio versus build is not a new problem or a new phenomena. Uh, it's maybe amplified nowadays because it's very much easier to build. But that has been here for ages.
I strongly recommend a book called Good Strategy, Bad Strategy, uh, by Richard Romlet
Ohad Biron is a legitimate practitioner-founder with 20+ years spanning R&D and GTM, and a concrete revenue milestone ($10M) at a prior startup. However, the episode is transparently sponsored/promotional content for his own product, and his operational scale is mid-tier startup rather than a large-scale operator, which limits the depth of battle-tested insight.
joining a French uh, startup in the space of autonomous vehicles, building the whole go to market uh, from scratch to more than 10 million in revenue
with more than 20 years background in the industry, both on the R D side. I spent a decade there
The Amdocs anecdote (named company, 13-year timeframe, specific vendors SAP and Planview) and the '$10M revenue' GTM claim give the episode some grounding. But most assertions - '10x faster,' 'build any integration in an hour' - are unverified, and there are no customer case studies, retention numbers, or rigorous data to back up the product intelligence claims.
I worked at a telco communication company called amdocs
The market came up, SAP came up with a similar and even better solution. Uh, planview had the same.
The host consistently rephrases the guest's answers back to him as questions, volunteers his own lengthy anecdotes, and asks no challenging follow-ups. The promotional framing (the episode opens as an ad for the guest's own company) precludes any meaningful pushback, making this a PR conversation rather than an interview.
So what you're saying is that because it's easier than ever with AI, it's tempting to just sort of become, just overload yourself with just more and more features and lose sight of kind of what your core business focus is basically.
Yeah, definitely. Yeah, I think that is definitely, um, something that people have to keep in mind. Always.
Computed from the transcript - who did the talking, and the words that came up most.
In this episode, brought to you by Bagel AI, we sat down with Ohad Biron, CEO & Co-Founder of Bagel AI, to explore a growing challenge in modern product teams: feature overload in the age of AI. As building gets faster, itโs easier than ever to lose focus. So how do product leaders avoid becoming feature factories - and instead drive real impact?
Transcribed and scored by The B2B Podcast Index.
Speaker A: Foreign. How much of your day as a product manager is actually manual? Sure you have some automation set up, maybe even an AI tool or two, but you're still digging, still pulling together sales calls, CRM notes, support tickets, slack messages, emails. And that one forgotten meeting that somehow contained the most important customer insight of the entire quarter.
Speaker B: Classic.
Speaker A: The feedback exists, it always did. It's just scattered across 12 tools and three people who've since left the company. Bagel AI pulled all of that together automatically. It prioritizes based on your specific KPIs, surfaces, trends and signals you didn't know you were missing and closes the loop with every stakeholder inside the tools they already use the full picture. Finally, in one place, visit Bagel AI and make every feature count.
Speaker B: Today I'm privileged to be joined by Ohad Biron. He is the CEO and um, co founder uh, at uh, Bagel AI. Uh Ohad, thanks so much for joining us today.
Speaker C: Hi Anthony, thank you for having me.
Speaker B: Before we get started, do you want to just tell our audience a little bit more about yourself, um, and about your kind of journey to your current position maybe?
Speaker C: Perfect, I'd love to. Uh, first again thanks for the opportunity for being here. Um, I'm the co founder and CEO of Bagel AI, um, with more than 20 years background in the industry, both on the R D side. I spent a decade there, uh, in roles like product management, uh, information system engineer, uh, doing incubation of uh, the next generation of products in a big corporate, uh, then I switched sides uh to the go to market and also to startups and I joined a French uh, startup in the space of autonomous vehicles, building the whole go to market uh, from scratch to more than 10 million in revenue. Um, and when wherever I was that friction and tension and misalignment between product and the stakeholders existed. Uh, and that's why I started Bagel to be that glue between product and its stakeholder to help product managers to take uh, decisions that drives the business.
Speaker B: Yeah, absolutely. And that's a really really like key um, pain point I think definitely, um, the product teams have to deal with. Okay, so we are today to talk about like two particularly big growing issues. Um, and I suppose this is probably an issue that's been around for a long time which is like feature inflation, uh, within product teams, um, and also um, how that connects with kind of the rise of AI, uh, AI tools. Do you want to just dig into that a little bit for me, um, sort of outline the problem, uh, and how these two issues have sort of Collided a little bit.
Speaker C: Yeah. So I'm sure first, I'm sure you all feel it, right. And if not, you're probably in the wrong profession. But the tool set we have today and the speed in which we can develop and iterate has just become insane. Um, and we see indeed a proliferation of internal AI initiatives which is amazing. We're also doing it ourselves where we are AI native ourselves. And uh, that's a big uh, advantage for early stage companies nowadays that can build it from the ground up. Right. Uh, just a few examples. Right. Uh, just something that I see all over. Our customers are doing it, we're doing it. Just think about how many uh, automations you can do today with Slack. Right. How many you built with like a prompt. You build an agent that can ask whatever you have in Slack and about all the interaction with customers internally and develop notifications around that. To some extent I saw even companies building with prompt, um, turning Slack into their main ticketing system. It's uh, insane. And that's very, very easy to do. Um, and this is of course only one example, um, I can give you an example of how this affects uh, Bagel AI internally. We are building ourselves uh, today we're enhancing our proposition with very much ease. I'll explain about Bagel in a second. But our core proposition lies on um, feedback sources we digest. Today we can build any feedback source and any new prospect comes with another feedback source we don't have. Right. But this is today solved easily and we can build any new integration in an hour. This is something that didn't exist uh, a year ago. Um, but today if you have the right infrastructure, you can definitely move faster and build features that are significant to your business with very much ease. Now the trap is that is not to fall into like a feature factory, really understand what needs to be done and focus on your core business. That's become a harder task uh, nowadays.
Speaker B: Yes. Yeah, I can imagine. So, so what you're saying is that because it's easier than ever with AI, it's tempting to just sort of become, just overload yourself with just more and more features and lose sight of kind of what your core business focus is basically.
Speaker C: Exactly, exactly. Uh, there's actually uh, it's not only. Okay, there's the fact that shipping features is very, very easy. Right. And the development team is already moving 10 times faster than before. Right. Add to that the fact that there's a ton of pressure from, from management to, to move faster. Right. Everybody talks about product velocity and so on and we Will we will deep dive into that further down the, the podcast. But so there's a lot of pressure top down, right? There's the ease of building, you know, bottom up. And now if you don't navigate that, that, that ship towards the right direction, then you will fall into like building things that nobody cares about and then you risk of hurting your core business and your product and the quality of it, et cetera, et cetera. That's a very, very big risk. Um, I was listening two days ago. I give you an example. And not only me saying it, of course. Right. Um, so I'll give you an example from a podcast that was published two days ago. Um, uh, we, they interviewed the head of Claude Cowork Design. Her name is Jenny Wen. Right. So Claude Cowork, right, is the uh, maybe number one go to today to you know, build these auto, these AI, uh, automations. Right. And she basically said we can do wonderful things. Right? But someone, at least for the next or the near future, someone will still need to decide what to build and why it matters. And that's the core skill that is here to stay and become even a harder task nowadays.
Speaker B: Yeah, harder, I suppose because like you said, it's just, I guess because there's so many things we can build out, it's tempting, it's easier to lose focus, right. So it's harder to sort of keep, keep the eye, keep your eye on the kind of especially like, kind of for customers. Like what is actually going to make a big difference for customers, right? What is one of the actual key pain points? What do they actually need? That's always kind of the um, the thing, isn't it, with any AI tool I think is the, the question you still have to ask is the same as any other product, isn't it? Is that how is this actually going to make a difference in people's lives? What problem is it going to solve for them? You know, it's very simple.
Speaker C: But the classical product management, uh, role, right, to understand the pain points of our customers, understanding what drives uh, uh, the value for their customers, what drives growth for the company. What's the real impact? Right, for, for our customers.
Speaker B: Yeah, definitely. Yeah, I think that is definitely, um, something that people have to keep in mind. Always. Um, okay, so, so should we talk a little bit about metrics and team misalignment? Okay, so teams measure success by how quickly they ship features a lot of the time. But why can feature velocity be a misleading metric? And what kinds of metrics matter more for real business impact? In your opinion?
Speaker C: Yeah. So again it comes back to focus, right? And how not to fall into the trap of being a feature factory and really drive impact. If you could like, you know, formalize it, uh, what you actually need to optimize is time to impact. We used to think about time to value, right? But time to impact is actually what matters nowadays in the product velocity world. Meaning you have to maximize the impact and minimize the time to market. That's basically the new uh, ah, formula to optimize. Um, there are many uh, that translates into other interesting uh, metrics that you can categorize them by of course efficiency and alignment and impact. And your core business is like standard, trivial, but they goes under some transformation these days. We see that also we have the luxury, so maybe just a bit of context. So what is Bagel AI and who are customers? So you can understand from where I'm coming and saying that, right? So yeah, Bagel AI is a tool for product managers, right? It's a product intelligence platform, AI native that automates the entire product management life cycle and helps product managers to steer their company and the roadmap towards the right direction. And we do that by uh, analyzing all the different feedback sources like gong calls, support tickets, uh, notes in your CRM, nps, all these qualitative data sources, we analyze them, we automatically extract the evidence the product pains, the product gaps, the product issues, categorize them, triage them, basically reevaluating your roadmap, quantifying your roadmap. We connect you to any quantitative data uh, point and telling you what to do, what is missing, what's more trendy and not only the planning but also during the execution, even post launch. So that's basically Bagel, we can come back to that later. But my point is that we, our main Persona, our product managers, we are the number one uh, tool for today for product managers in terms of accuracy and context. So we see a lot of product teams uh, in enterprises in the most, in the most known companies nowadays and how they work and how they measure. So let's try to unwrap it. For example, some things you may not have heard of. Um, one. So I talk about categories of metrics, right? One category of metric, we talk about alignment because of all this speed that happens in silo in the company. How do you actually measure M? If we have proper synchronization between all these M meaningful and wonderful initiatives. One of the uh, metrics I was very surprised and love it and since then I adopted it as well. To Bagel is Called rework ratio, meaning when I can ship features very fast, how many of them come back to development because of enhancements, request or bugs or something that was wrongly, uh, described or done in the next quarter? This means a lot about the quality in which I'm shipping and more importantly whether I actually solved the pain that I intended to do. So this is something really, really nice. Um, um, because if, if I didn't synchronized well with, let's say my go to marketing or didn't analyze properly, what is the exact pain I'm solving, then I'm developing something just because of a gut feeling or because someone, uh, in a specific, let's say region shouted very loudly. So I'm doing something without proper validation, without proper understanding of why this is needed, then it's inevitable that this will come back to us as a boomerang.
Speaker B: Yeah, absolutely. And we can tarnish your kind of brand reputation ultimately. Right. And I suppose, um, I, I mean I can, I can, you know, attest the experience myself, like kind of dealing with products that you know are great, but you just get kind of feature overload. Right? You just kind of like, there's just. I don't. Sometimes I think you can, you can fall into the trap of thinking more is more. Right. You think that like, just because you can do so many different things that people are going to get adjusted to it. But that doesn't actually always remove friction, right? Sometimes that creates more friction. If people like who your target audience are very busy people, they want to get started with what you're doing as quickly with, with the product as quickly as possible. They want to onboard with it, don't they? Very quickly. If there's all this friction of so many different things going on, there's all this noise that can create a real problem. In the end, people can bounce pretty quickly, can't they? I think that's probably a major problem.
Speaker C: And then. Yeah, indeed. And then you come back to the basic. The basic is your core business.
Speaker B: Right.
Speaker C: Uh, you need to. And when you can do so much with no less, when you can get access to data nowadays quite easily and let's assume that you can filter the noise and so on, you have the right tool set, no matter if it's bagel or not. Right. Um, to help you do that. What matters is now as a product manager or product engineer, depending on. We can talk about that as well, how the definition is being changing. Um, the expectation is that I will be even more domain expert. I will have more time to do the role I was Hired to do. And this means understanding not only the value for my customers and the pains I'm solving, but how it actually reflects uh, empirically like how do I measure this impact? And because I have access today to all the data points I can imagine, uh, that you know, it wasn't available in the past to connect all these like qualitative feedback with quantitative data, with analytics, with everything. Now I have power to do real a B testing, understand what is this needle that moves the business or not. How should I measure success of features? These are core metrics. Nothing new here just now. It's possible to do it and it's very hard. This is like the hardest question. Successful companies know what drives their business. If uh, I, it's not necessarily ARR, it's not necessarily um, uh, usage ah, metrics like logins. It can be transactions, volume in a specific time of the customer journey. It could be a lot of things depending on your business. And today you can measure it. And this will be, if you understand that this is the impact you should optimize and this is what will make the difference. This is the focus we were talking about before. What I should know make ten times better. And this is my moat uh, versus what's not my business and I should leave it to the expert, the other experts to solve.
Speaker B: So do you think in the past then, because you said a lot, a lot of these metrics you know, are ah, quite old really what is, what is kind of new is the ability to be able to, to put them all together, analyze it and get the answers quickly, right in an efficient way. Do you think in the past that product managers spent too much time trying to figure this stuff kind of out, like data was too scattered. Was that one of the issues?
Speaker C: A year and a half ago you had uh, data science in uh, many companies you had data science, you know, in working in groups with, with PMs because PMs needed someone to hold their hands and bring them the data, uh, and create these dashboards and connect the dots between different systems. Now this is a d deal, this is solved. Now you have all the, the, the power in the world to just test it. Just like test if, like if you actually, which, which metrics you moved and whether that, you know, it's a, it's a real indicator of the business or not. And, and you, that's your job. You have to do it, you have to understand it. And, and the faster you'll do that, the faster your business will be more, you know, successful and focused. The fastest you'll take right decisions that, that actually matters and, and the fastest you'll have a stronger mode versus your competitors.
Speaker B: Definitely.
Speaker C: Yeah.
Speaker B: Ah, that makes total sense. Okay, so, so we've been talking about AI and I think you know, um, everybody knows, especially product managers, um, product leaders, that, that um, AI is now just going to be a common part of our job. You know, it's, it's Pandora's box is open. You can't ignore it or you can fall behind the curve. Basically, you know, that's just the reality of it. So we have to take advantage of it. But I think one of the questions people, you know, need to decide and I um, think that people contend with is building AI capability in house versus buying or adopting an external solution. Can you talk about that a little bit? Um, talk about like what might be the best solution depending on like kind of what team, kind of team you're in, what kind of company. Maybe weigh up some of the pros and cons for either side.
Speaker C: Yeah. So first the beauty is that bio versus build is not a new problem or a new phenomena. Uh, it's maybe amplified nowadays because it's very much easier to build. But that has been here for ages. That's how software has been sold for ages. Why you should buy an HR system and not build it yourself. That's how uh, uh, uh, salespeople sell the software for 50 years. Uh, so the dilemmas are not new. It just amplifies what's important, uh, to make sure. And this usually comes to, uh, there's a triangle that you need to think of when you do that build versus buy analysis. The first one is, is this my core business? Uh, if this is what I want to spend time because there is an opportunity cost. If I'm spending time and resources on something, it means I'm not spending it in other places. So should I really spend this even mental focus on something that is not my core business? That's one angle to look at it, to evaluate it. The second is what is the reliability of that, uh, system? Meaning do I trust the data? Uh, uh, what are the pitfall inside? Can I actually take decisions based on that? The third one is the cost associated with it. Can be labor, can be, uh, hosting, can be uh, tokens, whatever. Right? If you have this triangle and you score according to that, you'll get a good um, guiding uh, metric versus if you should go and follow that path or not previously. So one of my first positions, um, uh, I worked at a telco communication company called amdocs. And I was in charge of building internal tools for um, um project uh managers and version managers and so on. And one of them was an HR management system. And not surprisingly, uh, two years later it was like the advantage was clear. Like we wanted something secured, we wanted something very like common accommodating our own practices. Um, we, the way we measure FTE and, and do resource allocation was quite, not, not very you know, uh, uh not, not very much standard with the industry. There were a lot of like things we kind of know methods we invented internally or our financial teams like invented some formulas to um, uh size projects. So we wanted to accommodate that. And the only thing, the only way we thought this is like the best is to build it ourselves. So it was perfect and a lot of excitement and all our uh, ITMs in the company were supporting that and put resources to develop it and so on. Two years later we started looking outside because we saw first how we are lagging behind the market. The market came up, SAP came up with a similar and even better solution. Uh, planview had the same. Uh, the vendors in the market offered better solutions. We kept getting requirements for enhancement from our internal stakeholders and, and now we had to come back to the CFO and ask him for more budget to upgrade the tool. Right. So it was not maybe we underestimated that in the beginning but two years down the road that we actually went and did a vendor selection and started the project with an external vendor. And this is like again this is not new. I'm talking about 13 years ago. So it's not uh, a new problem that was always there. Now, now with AI which again does amazing job, amazing job and it's very, very easy to build. But again you need to now come back to this triangle. Uh, is it my core business? Because this will require maintenance afterwards. This will take someone to build and maintain and enhance it. Is it reliable? Do I trust the data does if I need to pre process it or do I need to do I have, do I understand all the data points as uh, a master of this domain and I know how to make it accessible to the right people at the right time with the right insights. And third cost. I think this is the biggest trap nowadays. Um, there's an open check today. Just run fast, just experiment, just do uh, do what it takes to make it happen. But in a few months from now you will see how companies like and it's already starting like they see their, their uh, their billing in their hosting billing or their AI vendor billing and they see how Many tokens they utilize. And because they're also not. That's again not their business. So they're not optimizing for that. And then this will come back to the decision, uh, makers and at the end companies need to take the decision whether this is my business or not, whether I'm bearing that cost or not. And probably I'm better off with someone else that knows how to do it more efficiently.
Speaker B: Yeah. So even I guess depending on whether you go in house or with an external vendor, uh, I guess there's just always the commonality between the two is that it's never a one and done. Right. You always kind of have to reassess where you are with things. Sometimes you have to be accountable no
Speaker C: matter what you do. Right. To be accountable for that, you need to uh, be accountable on the data itself. You need to be accountable on the cost. Right. You need to be accountable of the UM M serviceability so that it will be always live and working and, and relevant for whoever you're developing it to. Uh, by the way, everything I said doesn't mean that you need to buy everything. I'm not saying that at all. There are a lot, a lot of things that can easily replace nowadays with AI. Many, many things. But when you decide that. And uh, again we're doing the same when we are buying less software nowadays because a lot of things can be developed internally and that's a very healthy and good evolution of the market. What I'm saying is that when you do that decision, do that constantly and assess the right thing before entering these episodes.
Speaker B: Yeah, absolutely, yeah. Accountability and being mindful all the time, I suppose UM is always good, I think, especially in a time now where um, technology is moving so fast. I mean it always has moved fast, but especially now I think we're in period with AI and I think it's important to kind of um, for leaders, no matter what department you're in, to kind of always be educating themselves and always being. Staying up to date with what's going on as well. And that can be difficult in, in a busy job. But I think it's just essential, isn't it? You have to be aware of what your competitors are doing, what the market is doing. You know, it's, it's true.
Speaker C: And that's the hardest is data. Right. Uh, like it's easy today to build very neat ui. It's easy to connect data points, it's easy to break the silos. It's very hard to make the data useful and to bring the right Context. Right. If you remember, just look at the evolution of, you know, that we're living for three years. Right. ChatGPT came out, all these uh, horizontal AI players like surfaced and did amazing. They led an amazing breakthrough. But we suddenly had access to a lot of data points which was amazing for many, many use cases. Right. But when you want to go deep, right. That's still a struggle. And that's where the vertical players started to emerge and succeed. Right. In the last year. Uh, ah, because that's the difficulty nowadays to get the right data in the right context at the right time. And, and that's usually the mode for many of the AI players nowadays.
Speaker B: Yeah, definitely. Thanks so much. Okay, so we want to talk a little bit about um, roadmaps, roadmap strategy. So it's, it's becoming more common now to think about roadmaps more like kind of investment portfolios where sort of each initiative is a kind of, you know, bets where you have to, with expected returns or risks. So what do you think of the, of that way of kind of framing roadmap decisions? Where does it work? Well and maybe what are the shortcomings? What do you think?
Speaker C: Yeah. So um, the good news here is that, you know, the way we're doing roadmap, um, has definitely enhanced like we have more tools to do better roadmapping, uh, because of the ability today to analyze uh, all these unstructured uh, data points and feed that into, into our decision making process. Uh, we need to of course be attentive that we're not creating like a context, a context debt. Right. So that we are not um, no blurred by all the noise and we can filter what matters because we do always have commitments to customers and some history, some context that is relevant for our specific domain and product. We need to make sure how we make that surfaced above the rest and how we weigh that uh, properly. But definitely, as long as we value that and we treat that well again with the focus of our business today, we can do much, much better roadmaps. More accurate, more to the point, understanding all the pain points and so on. This is very, very, very good news. And as I mentioned before, even Claude Code said like there's a need that for someone to decide what to build and why it matters, that's here to stay. What is changing? What's the difficulty that is coming? Right. So first, I'm not necessarily that the granularity of how we do roadmap will stay the same. I'm actually thinking that this will definitely change and is Changing already. The faster we can ship, the faster we can build. The easiest we can build. It means that we have to think in smaller scope units, think of CI CD kind of approach. When I can ship autonomously, right then I need to ah, tune the scope to feed that speed and these fast iterations. And this is not only for defining the requirements, it's more importantly down the road when I need to test and validate it. When I need to test and validate it, I have to be very concise, very accurate about what's the acceptance criteria, what's the target I need to, uh, meet, uh, and accordingly guide the machine with some set of rules or instructions that is manageable and executable. So definitely this definition of scope is changing. Um, if you listen to again, the same podcast I was referring from the head of Claude Cowork, she also says you don't need to plan more than one year down the road. Like your roadmap should be six 12 months out. And I actually agree with that, uh, because again, you move so fast it's almost impossible to plan that far. Right. But it brings even more importance about the here and now and the midterm. Like, this is what I know I'm gonna do. Uh, this is the focus of my business. And now everything should propagate and should feed that strategic, uh, north star of the company or the roadmap. So this is, um, what we're seeing already changing and moving. And again, like in the beginning I said that sometimes we need to think about the basic of our world as product managers. Um, it was true in terms of focus, uh, what we are and what we aren't as a business. And it's definitely true in roadmapping and product strategy. I strongly recommend a book called Good Strategy, Bad Strategy, uh, by Richard Romlet, um, which actually describes what are the kernels of product strategy. And this has never been so important and true as of today. Like there are basically three steps for a good product strategy and that should drive our roadmap thinking. The first is the agnosis, understanding what is the right problem or opportunity to solve. The second stage is developing a guiding policy which is, um, once I know which opportunity I'm solving, what is the right solution for the right audience. That's again, that's the focus, right? And third is like developing coherent actions. How do I prioritize, continuously validate, continuously optimize it, repeat that, that cycle, that, that, uh, that wheel, right? If, and this again, this is not, not new. This has been here for ages. I just what has changed? I need to have that mindset and thinking faster this day. I need tools and systems that help me to, you know, mechanize this way of thinking faster because it is never being so important to follow these steps in order to take the right decisions that matters for my business and not falling into the, the trap we talked about before of you know, just like developing feature because someone wanted it or someone think it's, it's, it's valuable.
Speaker B: I suppose the danger as well as for some product managers is that if you're not using these kind of tools um, is that other people are.
Speaker C: Right.
Speaker B: So you're at risk of falling behind the curve if your competitors are able to make these decisions a lot quicker than you are. I suppose that's one of the issues I was talking about before with AI capabilities is uh, a case of being able to stay competitive. It's a tricky balance, keep up with the curve, stay ahead of the curve even without totally losing focus of the fundamentals. I think that's the kind of balance that we're kind of trying to strike in this conversation. Right. Like is, is.
Speaker C: Yeah but I'm, I'm considering that everybody has some AI tools and access to, and much better access to data. This is like no matter which tool you choose or even if you build it yourself, you'll, you'll have uh, better access to data. So it comes back now to whether this support the right decision making process and the right uh, outcomes that I expect as ah, the, in the new era of you know, product management.
Speaker B: Obviously a lot of challenges these days, product leaders, product managers, um, especially in the, in the age of technology but well of AI growing AI, um, always changing. Um, but if there are just some really solid kind of concrete takeaways that you'd like someone to take from this conversation, what would they be?
Speaker C: Yeah, so I think that there are two, two takeaways I would, I would strongly recommend, you know, ah, the listeners to, to have. Um, the first one is when, when shipping is cheap. Right. Focus, uh, and judgment is everything. Right. So you need to make sure that you can trust your data, that you can have the data, trust the data and um, ways to measure it that is relevant for your specific business. That's everything nowadays and that's what will defer Excel, PMs and companies compared to good ones. Context is everything and focus is everything. The second thing is when the silos are being broken and nowadays everybody has access to and uh, more visibility to others in the company, a common language and building trust is even more important. Right. And that's again leading back to how do I provide the right context, the right data, how do I make sure that I neglect the noise that may surface and if this is not my core business, then leave it to someone else that does it better. Right. Because it's easy to build stuff. But if you build something and provide and mislead, right, your users or your stakeholders, um, or generate a lot of false positives or inaccurate or semi accurate insights, M that will come back as a boomerang to you afterwards.
Speaker B: Yeah, absolutely. I love how um, really the moral of this or the key lessons of this is that kind of, of we use technology to remember what's always been important is um, is really good, you know, and, and I think, you know, a lot of people talk about leveraging technology to kind of do what we as human beings can do better than the technology can't replace. But I think that's definitely more true than ever. You know, is sort of give us efficiency so that we can get more strategic so that we can really get, get down and focus in on what's important. Which I really love that kind of message.
Speaker C: Um, it's what I said in the middle of the podcast. We need to optimize today time to impact. We need to maximize impact in minimum time to market. And that's the goal. It's not about developing more features, it's about driving the company towards more impact, faster. And that's what technology enables today. And that's what we should implement to move faster as the market expect us to do.
Speaker B: Yeah, definitely. That's great. Okay, um, what do you think is there just to end on Ohad? Um, what is the single biggest problem, hurdle or challenge you think that product leaders face today?
Speaker C: I think that um, the biggest challenge is that there's some blur in the world definition. Products are becoming more engineering, engineering are becoming more product. Ah, we even see um, more and more companies introducing this role called cpto. So the organization is combining and merging. The challenge here would be how, what's the new skill set? Right. Or what's the ratio that we will need in terms of PM and engineers? Who does what? Right. That will be solved not by bagel, by the industry. Right. But then we need the practices that will support that. Uh, because Definitely as a PM, our PMs in Bengal, for example, today develop code for production. They literally become engineers. Right. So they need to make sure they are their seat on uh, the business data so they can take this better decision, but they cannot develop super sophisticated stuff. For engineers, it's the opposite. Engineers can build sophisticated stuff even with AI, but they lack of, of business context of why this is needed for the first place. Uh, so these two type of roles are combining and the challenge will be, uh, how to build it in a proper way that actually support and accelerates the company growth versus hindering and creating more noise, less quality and less stability.
Speaker B: That's a great note to end on. Ohad, thank you so much for your time today. Um, if people want to reach out to you, um, get your thoughts anywhere. Where should they go?
Speaker C: They can definitely, uh, uh, come to visit our website, Bagel AI and they can book a demo and we'll be happy to show them what's Product Velocity all about.
Speaker A: What.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.