
Uppersky Podcast · 2026-03-04 · 1h 1m
Key moments - from our scoring
Substance score
45 / 100
Five dimensions, 20 points each
Martin Felcman walks through his evolution from founding Applaud Digital as a web design and development shop to joining Productboard in 2018 when it had just 25-27 people. He articulates Productboard's "product excellence" methodology, which operates at a higher strategic level than Agile or Shapeup, focusing on three key components: understanding customer insights, defining clear product strategy, and establishing shared roadmaps. The framework addresses a critical industry problem - that roughly 80% of enterprise software features go rarely or unused - by emphasizing early ideation and rigorous validation before committing to delivery. Felcman explains how this differs from and complements frameworks like Jobs to Be Done (a strategic thinking tool) and Shapeup (a delivery methodology). For startups, he advises focusing on domain expertise, validating whether a problem is a genuine pain point versus a "vitamin," and ensuring customers will actually pay for the solution. He uses Productboard's own examples - pausing capacity planning work due to lack of standardization, versus shipping strategic planning and collaboration features with strong customer conviction - to illustrate decision-making grounded in customer research rather than intuition alone.
Product excellence is a methodology focused on customer insights, strategy, and roadmapping that helps teams decide *what* to build, operating at a higher strategic level than Agile practices. Unlike Shapeup, which guides discovery and delivery after the decision is made, product excellence addresses the critical earlier phase of validating the right problem exists and customers will pay to solve it.
Focus on whether you're solving a genuine pain point (not just a vitamin feature), validate customer willingness to pay, and leverage your domain expertise if you have it. If you lack deep expertise in your chosen domain, spend more time understanding customers before building; if you have strong intuition in the field, you may need less external validation.
Jobs to Be Done is a strategic thinking tool for structuring customer needs and evaluating strategy fit. Product excellence is an operational-level framework that helps organizations move forward and build excellent products efficiently, encompassing the full lifecycle from discovery through post-launch feedback collection.
The team discovered that companies lack standardization in how they approach capacity planning, many use spreadsheets with no unified approach, and complexity varies highly across organizations - creating too much risk of building the wrong solution, so they paused to revisit after more discovery work.
Productboard uses Productboard to build Productboard, meaning the team directly experiences the products they're building and can perfect capabilities based on daily internal usage, giving them a unique advantage in understanding user needs and validating solutions.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode contains a handful of concrete operational details (Productboard's 2019 ML model, 3 - 5k monthly feedback pieces, 40% of work tied to AI) but is padded with well-worn PM platitudes - vitamins vs. painkillers, founder-as-first-PM, and the 80% unused features stat. The filler-to-insight ratio drags the score down significantly.
we have roughly, uh, roughly 1112, uh, product managers, product team, we would get three to 5,000 pieces of feedback monthly
roughly 40% of what we are doing is associated to AI today
The distribution→engineering→discovery bottleneck framing is the most interesting structural argument in the episode, but the vast majority of content recycles familiar PM orthodoxy: validate before building, pain vs. vitamin, context matters. There is little that would challenge or reframe a practitioner's existing mental models.
before Internet the distribution of the product in a software...was the biggest problem...And then...engineering in like building stuff used to be bottleneck...Then it boils down to the initial component and it's the uh product discovery
a lot of the early failures would definitely come from...you built something. Maybe it isn't the right thing because you haven't done the...discovery
Martin Felcman is a genuine practitioner who joined Productboard at ~25 people and grew with it through scale-up, giving him credible insider perspective on a real B2B SaaS product org. However, he is not in a C-suite or definitively senior strategic role, and his domain is narrow; the transcript never fully exploits the depth his tenure should provide.
I joined Product board back in 2018. Uh originally my story is a little bit complicated, might get there later. But uh it was when the company had some run 25, 27 people
we are drinking our own champagne. So we are using a product board to build product boards
There are a handful of real specifics - the 2019 ML model build, 3 - 5k monthly feedback items, the paused capacity planning feature, ~40% AI investment share - but most examples remain illustrative rather than measurable, and financial outcomes, customer counts, and timeline data are conspicuously absent.
one particular uh thing that we have done a discovery on and we have decided to pause it...is the functional door capabilities around capacity planning
we actually started relatively early on...back in 2019, uh, probably like when we actually built our own machine learning model
The host makes occasional genuine attempts to press for specifics ('I will push you again,' 'Do you have any example from product board') and covers a reasonable range of angles, but the follow-ups frequently dissolve into 'Got it, got it' and broad topic pivots rather than drilling into vague or incomplete answers. No meaningful pushback occurs.
I will push you again like how and how this compare for example with I know about J Pop
Do you have any example from product board like maybe recently that you decided to discard not to build something
Computed from the transcript - who did the talking, and the words that came up most.
Martin Felcman leads the Core Product at Productboard. In this episode, he shares his story of becoming a product person, from building websites as a teenager, to growing a digital agency, to moving into product management because he wanted to build products that last. We then break down how strong product teams work: how to collect customer feedback without drowning in it, how to spot the real problems, how to write clear product specs, and how to keep a roadmap that people can trust. Martin also explains how Productboard thinks about “product excellence”, and how they stay flexible while planning in a steady rhythm. We briefly touch on AI too, mainly as support for the heavy lifting, like sorting and summarizing lots of feedback, so product teams can spend more time on better decisions and alignment. Stay connected with Martin on LinkedIn: - Are you curious about what we do at Uppersky? We design digital products for impact-driven businesses, helping startups and innovation teams solve real challenges and create meaningful results.
Transcribed and scored by The B2B Podcast Index.
Speaker A: Hey everyone. Welcome to the Upper Sky Podcast. My name is Ricardo Monegas and I will be your host on this podcast. We would like to share valuable knowledge, lessons learned, and stories from entrepreneurs, investors and managers while running their businesses. We strive to ask, uh, the right questions and discover insight from our guests so you can apply them in your business and life right after each episode. Thanks for joining us. And let's get started.
Speaker B: Hi everyone. Today we are having Martin Feldman. He's leading the core product at Productboard. We are going to be talking about his personal story, how he arrived to product management, talking about his advice about how to do product management in the way they are operating in Productboard and previous experiences and of course, any. Anything related to a topic that we are all talking these days, like AI, for example. Um, and yeah, his advice in general on, um, product management and the resources that he's following and trends that he's watching for the future. So welcome Martin. How are you doing?
Speaker C: Thank you very much. Thank you for having me. I'm doing very well.
Speaker B: Yeah, Martin, so I think I want to start for your story first, if that's okay with you, before going deep into product management, going into ideas, processes and stuff like that. Um, so I was wondering. Yeah, how, how did you start being involved into product management if you can travel on time and tell me a bit about that. How was your experience?
Speaker C: Yeah, yeah, it all started back when I was 16, roughly. Actually, as many people in my generation started building the websites and like that's how we learned some basic coding, uh, web designing and kind of like all the things, uh, around then evolved in kind of like me working within a bigger group. And then we actually established the digital agency called Applaud Digital, which is still up and, uh, up and running. However, after a few years I had an internal call like, I want to build something what is kind of like lasting longer and is a little bit more meaningful. So the focus of the agency and I feel like it was a really good decision that we have made back then because we're all young, we tried to learn a ton of new stuff and try different things. We were intentionally focusing on a relatively short project. So, uh, typically it would be like one to three months projects and we would quickly run through many projects, but track management. Isn't this kind of like a sprint of 1, 2, 3 months? Uh, it is a marathon. And so I was looking into a longer distance with more meaningful purpose and just something where it's kind of like up and running, uh, for a couple of months because Also many of the projects that we're working on, they were uh, supporting certain marketing campaigns, for example, for a larger brand. So very often it had some expiration date, um, as well. And so, uh, I decided to step down and pursue the career in uh, product product management and joined the company that was kind of naturally adjacent to what we were doing. We were doing a lot of stuff with the uh, social networks and building on top of Facebook, Instagram, Twitter, YouTube API at that point. So I joined the advertising technology company called ROI Hunter and uh, based in, uh, based in BRNO here. But uh, uh, yeah, it was the start of the product management journey and I continue from there on the product management track.
Speaker B: Got it. And what were the lessons that you learned out of those beginnings in product management that maybe you were doing, uh, that you now reflect and maybe you were doing it somehow wrong, that or, or you believe it was still perfect for your perspective?
Speaker C: I mean like, I mean like, of course there are like so many like rookie mistakes. So, so like retrospectively I really like, like if somebody says that they were doing something very well 10 years ago because like, that's actually, uh, 10 years ago when, when the moment that I described happened, uh, I would, I would be very skeptical, um, uh, about it. So a lot of things definitely were done in a very naive way. It was very much kind of like a building instead of setting up the right strategy and building the right products. A lot, a lot of, I would say failures or like, like smaller failures, like came from, Came uh, from it. Like you built something. Maybe it isn't the right thing because you haven't done the, and write the discovery or haven't validated this. Have you validated that? So a lot of the early failures would definitely come from uh, these moments.
Speaker B: Okay, and do you have anything like mentors and people that were helping you in that moment to learn more about product management and tools and strategies to follow or how was it for you?
Speaker C: I'm like, definitely. I mean like every person that I work closely with or work closely with throughout my career somehow influenced me how I think, what I think is, is important. What are the things that maybe they do better than, uh, uh, I do. So like, I am a very analytical person. So like, I do analyze this. I do, uh, and make a lot of observations in a way, how different people operate and what I can learn are definitely two people or two, three people from product board that were in a product management role that influenced me probably the most, uh, on my journey. But um, yeah, it's like many People from the industry, whether it's uh, some thought leaders but I don't necessarily have a personal relationship with them. But then the people that I think lead by example and I could take uh an example uh from them. So like this would be probably three people. My ex managers here at Productboard.
Speaker B: Got it. Now if we go towards your entry or working with Product Board so what calls your attention to start working with Productboard if you remember that or. Yeah. What was the idea of joining with them?
Speaker C: Uh actually had one of the class with founder co founder of Prague Board uh Daniel Hale. So actually I was at the Czech Technical University, he was at the University of Economics here in Prague. But we had a joint class on uh one of the courses and we were actually a uh teammate there on the project. Like that's how how we met. And since at that point most of my career actually I spent working with teams that were here in Central Europe but then the headquarter or the car business was uh somewhere else typically in California actually. And so there's a lot of parallels between the early days of the Product board because from the get go Product board was distributed. Uh there were a team here in Prague and Hubert founder CEO was in San Francisco and San Diego. Early members were in San Francisco as well. So we'd meet meet uh occasionally to uh grab a breakfast or drink and chat about kind of like these dynamics and kind of like building a uh early stage uh products and uh and themes and uh ah before actually I I started working at the pry board I was a customer of Product Board and so uh a lot of connections came from it as well and uh some additional folks joined the Product Board and then Bregboard was raising a series A uh at that point and so and so we met with Daniel and said like hey like maybe it's a good opportunity for us to actually work work together. And so I joined Product board back in 2018. Uh originally my story is a little bit complicated, might get there later. But uh it was when the company had some run 25, 27 people.
Speaker B: Good good. And how was in that moment Product management in Product Board it was not formal lies, it was more yeah punk or yeah. How was the in that moment and how has changed to now if you can coming into the evolution like we
Speaker C: have definitely went through the, through through the phases. I feel like Product Board is very meta. Uh when you talk about building the products your customers are our product managers. There are very high expectations on you as a product manager from customer but also also uh internally like it's the same like with a football or Isaac, you know, ah, get a championship, right. Everybody has opinion on it like who should be in the lineup and whether you should pause it left or right, um, and so on. So it'll be like very, very similar here, which is actually quite motivating but on the other side quite terrifying at the same time. But at that point uh, like product management was primarily about really building the right product and it was less about any structured or more uh rigid process. We went through different phases uh, of product board and now because we are at the phase where we are doing a lot of ideation and discovery. So like we need some, some structure to, to support that. And so for example right now we are defining and implementing something what we call product excellence which is a methodology that uh we came up with and structured around customer insight, strategy and also uh product uh product planning and, and roadmapping. So we are now refreshing it and adding more structure and building some of the new rituals that uh, we see as super uh valuable for us but also for many other uh teams out there. So we are decoding it ourselves and in the next couple of weeks or months we'll definitely share some learnings with the rest of the uh, rest of the community.
Speaker B: Good. If you need to define product excellence in some way. So how does it look or is this something you would recommend even to an early stage startup or this is something you would recommend only for scale ups?
Speaker C: Yeah, yeah. So I would say like this is generally applicable and like a most important component is how do you actually work with the customer insights and uh market insights and how does that shapes product uh, uh product uh strategy and how uh, how do you do ideation as like a very first step before you go into a deeper discovery and kind of like also like how many let's say false ideas you discard early on to actually get and only build stuff that are actually meaningful. And so if you look at it today's world where actually building stuff is getting extremely cheaper, especially if you are in early stage and building on the green field really the focus is on uh, what should we actually build so we don't need to, we don't have a bloated product with a ton of features. Uh, uh, some of the people from the audience might remember a total commander to say uh, program on a Windows vacuum, I don't know 90 uh something I'm dead old has like bloated ton of buttons, uh et cetera. Like nobody would use it uh today. Right. So uh, that's the emphasis. And then also kind of like how do you go and make sure that you actually deliver on the results that you, that you said. And like ourselves many times a mistake of us kind of like chasing another tail, another hot product uh feature or product for us to introduce without actually getting, getting a basic, basic stuff. We talk a lot about different maturities of uh product excellence and how teams and companies uh operate. So eventually recommend if I may advertiser recommends to just go and Google product excellence uh stages and there's a good metrics of uh um maturity across. How do you approach customer insights and how do you understand customers? How is product strategy clear defined and shared with everybody else and how are you relying the teams around the uh common roadmap? So those are the three key components there. And uh, very often if you actually talk about it you see that if you have two colleagues in the audience uh eventually so like they're trying to assess where they, where they are and you would be very often surprised that it's uh. We're often not very high uh on the uh, on the scale when it comes to the stages. So a lot of possibility to improve and I think it will be a necessity because engineering used to be the bottleneck so everything was optimized towards uh, that it's getting to the point where it's not going to be the case and uh, the right decision making supported the evidence and customer and business in mind is going to be.
Speaker B: Got it. And is this not in some way influenced by for example jobs to be done or these kind of frameworks or how do you define these? Yeah, how you compare, I don't know product excellence process of customer insights and discovery with something like jobs to be done. If you know what it is of course.
Speaker C: Yeah, yeah, yeah, yeah. I mean like we, we are using jobs to be done here at parent boards to certain extent I would say jobs to be done is like more of a, it's a useful framework for you structuring your thoughts and kind of like putting customer needs in the buckets and then you can eventually structure product strategy around it and evaluate how good job you're actually doing. So like a very good I think strategic tool and very often we would go and come back to it and assess where we actually have uh, where we actually have gaps. The product excellence is something what is more let's say on the operation level. So like actually helping organizations to move forward and uh operate excellently so not only build excellent products that people love but also uh doing it In a way that it's uh, efficient and actually leading to the right outcomes.
Speaker B: Okay. So it's more related to product development and how the companies operate themselves. Like how do you decide? I don't know, let's say the sprints or I don't know cycles of development.
Speaker C: Yeah, I would nearly say that like the whole thing of uh, of Agile is like very like a lower level like practice sensing like more high level. And it's like what are the things that you need to consider and how you should operate to for example minimize the state where. And like there was a, there's a survey to be very often quote that 80% of features that are typically built in, in enterprise uh software are uh rarely or not used at all. And so like how do you actually limit it? Because it's a ton of uh, it's a ton of waste. You're eventually building something which people actually don't need, will not be using and will not be, will not be be paying for. Right. So how do you actually, how uh, do you actually overcome it once you decided you actually build something? So yeah like Agile and whatever agile methodology you will, you will use.
Speaker B: So okay, I will push you again like how and how this compare for example with I know about J Pop and um like they have this framework also a methodology how to bet, let's call it bet towards what features to build. Um and of course they have some other ideas towards fixing time viable scope. So yeah how does it if you can relate product excellence to J Pop how does it relate to it?
Speaker C: Yeah like there, there is a, there might be some overlap with the way how uh the team around Shape Hop uh thinks about building uh building products or like more like driving a certain initiative. But, but it doesn't help you I'm m. Like Shape up itself doesn't help you to decide on uh, what to build, what to build next. It doesn't give you that kind of like a guidebook of kind of like how you should actually think about it, how you should structure your thoughts and what you should do to for example validate your idea. So like see it as something like you decide on building a excellent or like hopefully you decide on building a certain product. That's the first step and that's what Prac Excellence uh is aiming for uh to help with. And then you got the shapeup where you go and you continue with eventually the discovery and then also delivery or you might be using instead of Shapeup you might be using uh dual track agile uh just a different way of actually doing the later discovery and, and delete it.
Speaker B: Got it.
Speaker C: Yeah. Yeah. Maybe also say like very often like it doesn't end with shipping the feature. And so like there is a continuation of that life cycle, right. Like you're evaluating whether you actually reached the goal that you, that you had there, whether people actually love the product that you uh, that you built and collected feedback back the customer insights, customer feedback and that influencing the product strategy.
Speaker B: Uh, if you need to advise a startup like thinking about product development and uh, how to approach it in a better way than just based on their gut feeling. So what would be the initial version of the product excellence that they can do? Because of course you can of course apply all of these if you have all these, the different type of product people and everything. Right. And the team members for this. But if you are in a small team, how would you advise to approach product development in certain way that you don't build these old features that no one use, for example. So what would be your advice into those terms?
Speaker C: Uh, context always mentors, right? Like what type of product is that? Does the founding team have any experience in the field and the domain expertise, uh there is this something what is more like a vertical product for very specific domain is more like uh horizontal. So like all of those are factors that will definitely shape up the way how you build the product. And like an important piece is kind of like what's your confidence and what the level of intuition that you uh, that you have, right? Like if you are professional in the field and you know for example how if I take an example your accountant, uh by profession and you know exactly like what's the process etc. And like you are trying to innovate that you might not need that much of a validation from other accountants that hey, like this is how this should be done, right. But like if your expertise is like you are uh engineer somewhere and like you see like you pick the domain like hey there's a lot of inefficiencies and like that's what I heard uh, from my uh, father for example who has accountant and I saw the tools that they are using and it's so painful and like he's always complaining your level of intuition will not be as high. And so you need to make sure that you very well understand uh the customers and you need to spend much more time, much more time there. So that's what I like matters, uh, matters the most. Like very often I've seen like people make a mistake that sort of, it would be Cool if we had this feature and feel like it would be cool. But also like think about is it such a big pain that people will actually pay for it or is it just a vitamin that like it will make something 10% better? And so the really the best products out there, like consider like whether they can actually build something what is ten times better than what is the status quo uh in that industry. And then ideally it's a major pain point, therefore people are willing to pay for it. A lot of products die because it's a uh, vitamin and not necessarily a pain point. Like figure out, think about how many fitness apps in app stores you actually uh, you actually have. And like you have to pour a lot of stuff in the marketing because it is a uh, it is a vitamin. It's not necessarily the, the uh, the pain point that many people would have. And the other thing is are people actually willing to pay for it? And the people might be end users, people might be the company's uh.
Speaker B: Do you have any example from product board like maybe recently that you decided to discard not to build something or and maybe other example where you said well yeah this have the signals that this is a really big pinpoint and people is willing to pay that you can remember.
Speaker C: Yeah, it's a daily breadth. Right. So, so one particular uh thing that we have done a discovery on and we have decided to pause it so not to proceed to the delivery just yet is the functional door capabilities around capacity planning. And like it was because let's say companies are not standardized there. And so there's a high risk of us actually not uh building the right uh solution. Many people do it or many companies do it in some spreadsheet. There isn't necessarily kind of like a unified way how they would operate. And so the needs and the complexity needs is also highly diverse. And also with us now going after enterprises and large enterprises, the complexity there is even bigger with different layers of the organization, different organization silo. So we decided that we will pause here and revisit it later on most likely later, later this year to probably do another set of discovery uh, on so like this one of the examples but you would, you would find many of them in uh, the daily life of product war. We would explore something and decided it's not the right time or it's not the right path to actually go in, in that direction when it comes to other stuff. So very often what we are building or most cases it's supported with a hard uh evidence of uh, what we actually need. To build. And so relatively recently we have introduced a lot of the capabilities around uh strategic planning and collaboration which has been a big pain point for customers and also areas where we try to really solve the pain for a couple of years. Like from the point where we actually when I joined product board and it was for example around the voice of the customer and like it it was the very tedious process where you have to go and review every piece of feedback. And so now with e.g. aI and introduce a product called uh Prior Pulse, this got so much easier and helps you to shape the right strategy, understand what are the detail pain points so easily that like this is a great example of something like where we had a very strong conviction that this is needed but it's all grounded in us as a organization operating in a very customer uh centric way and working very closely with them. Our advantage also advantage is that we are ah drinking our own champagne. So we are using a product board to build product boards. In our case it's very meta because to certain extent some tools that we are building we are building for ourselves as well or perfect it based on daily usage of product.
Speaker B: Can you let's say describe like what would be the ideal team member for you guys in product management or what skills are you looking for? Because of course it's maybe different in an early stage startup. Uh what are the skills if you can mention that you would advise if you're looking for your first product manager, what would be the skills that you consider are necessary in that stage? But maybe is there different skills that you consider to have in the level that you guys are as a scale up already or
Speaker C: definitely a lot has changed with the stage where, where we are and definitely one factor, other factor is also how much of uh, kind of like whether we are doing more of a delivery and focuses on it or we are spending much more time in ideation and uh discovery. Whether that is um iteration something what uh we have already built some of the use cases and capability there versus something what is a zero to one like that's highly influencing the profile that we uh, that we hire that we hire as well. And it has been changing throughout the uh, throughout the prep board journey. And also last factor recently is that with the changes on the I would say like job market we have a luxury that we can tap into higher caliber of uh people who are willing to switch their, switch their, their jobs. So like in an earlier stages like during like a major scaling of the organization we would have many people that would have uh Product manager title and let's say some portion that uh, wouldn't be the senior product managers. Now we very often hire for much more experienced people when it comes to senior or principal product managers. There are not many of them that would actually fit that uh, category and meet the bar. So like uh, that's one aspect you ask about who should be the first PM, PM hire. And I feel like it's typically the founder is kind of like a first product manager. Right. So the way I would, how I would think about it is kind of like what are the things where the founder needs help the most? And uh, like that should be pretty much the first uh product hire because it's also how I'm thinking about the way, how to build the team. So there might be a specific problem for uh us to tackle. But on the other side I want people to bring something unique and help us to have a unique set of uh, set of skills as a, as a team. So like if you are, if I'm missing somebody who is very great with ambiguity and zero to one and like we'll, we'll go and chase the problem until it's, it's actually solved and leads to the product market fit. It's a very different profile of a product manager than somebody kind of like doing the iterative work that is extremely valuable, don't get me wrong. But kind of like is more like iterative. You're eventually adding a new segment to existing capabilities and so the needs are expanding. But it's different. It's a different uh skill set and something.
Speaker B: I will come back to your previous answers because I forget to follow it up when you are deciding what to build next. Right. So how does it look this discovery process for you and the uh product roadmap? So is this something that you are keeping updating or. Yeah. What is the cadence let's say of updating your roadmap based on the discoveries. Can you mention to us how, how do you currently work with that?
Speaker C: I would say ideally there actually isn't a specific moment which now we are updating a roadmap and continuous and since we are using, using product board, I mean like it really is kind of like a uh roadmap should be always, always up to date uh based on the, based on the information there. But to make it maybe a little bit more, more practical. So we operate with roughly a quarterly cadence in a way where we kind of like revisit the reset the objectives or course correct adjust and uh. So we use this moment to eventually make Some changes to the roadmap when it comes to what are the problems and solutions that we will go and discover and additionally uh, what are the things that we actually push to deliver. But a lot of things is happening continuously throughout the third quarter as well. And like if there's any major shift, I mean like we will just do it anytime. So we are not waiting for the end of the quarter to make the strategic decision. I mean like if we eventually see, hey, there is a really strong pull from uh, and that's the area where a lot of things is changing very quickly. We are not going to wait two, three months to make any decision. Like we will make that decision immediately in a matter of days.
Speaker B: And what happens with the stuff that you remove from there? So how do you take decision that okay, I am removing this feature that it was important because if you put it there was important but so it was. Yeah. How do you evaluate the priority or the, if you can talk a bit about that.
Speaker C: Like it is like it's very often like a messy, messy process. Like that's the hard part about product management because like you are juggling quite a lot of, lot of inputs and a lot of factors in uh, your decision. But like it comes with clarity around the strategy. So who are we after? What's the segment that we are building for? What are the objectives? Very often also the objectives would blend any mention just to be done before. So what are we trying to advance and why? And then we come back to so what is the thing that is still true in the new reality here and we should still uh, continue work then versus what are maybe the things that are suddenly kind of like below the line and it's like they are still important. We'll just get to them eventually. Eventually later. Right. And it's, yeah, I'm like it's still very hard, I'm like for many people and it's hard job uh, of a product manager to explain how this process works. And so if some organization has a two year long roadmap, it doesn't mean that the solution that you see somewhere on the roadmap year from now actually will be delivered. I mean like there might be a lot of things that you will change in the meantime. Like it is a, um, it is a direction. But yeah, like you can always predict and like you would use the analogy of you uh, going on a, on a trip somewhere and like if you got a flat tire. Yes. Like it will be later on. You have to solve that uh, problem. You might go, yeah, there Might be traffic jam. So you change the course uh, a little bit. So like those are the things that normally happen. And it doesn't mean that you will, you are still going in that direction, but it doesn't mean that you arrive at exactly on the minute when you, when you, when you set. And then maybe I mean like you or somebody from your family got sick and you have to turn around or go somewhere and go visit them. And often like that that's a journey and like you see that in life and you will see it in the life of a product.
Speaker B: Uh, yeah, that's a uh, good analogy to explain people that the robot is not written, let's say in a song and it cannot change. Now if you talk about AI as something that is changing, of course not only Productboard but in a lot of industries and everything. I know that you have these products called Product Board Pulse. Yeah. Can you tell us a bit? Yeah. What is the idea behind implementing AI in Product Board and how this has changed the way that you are discovering customer insights and maybe helping people to decide for a better product strategy? Yeah.
Speaker C: So um, here we actually like before this uh, new tectonic shift with AI and primarily powered by the large language models, uh, we actually started relatively early on. I feel it's like back in 2019, uh, probably like when we actually built our own machine learning model to help with uh, the probably the most mounting task in product war. And it was you get a feedback, you're reading it as a product manager and you're linking it to your feature idea and then you can stick, rank the all the insights and like, then you understand kind of like what matters the most to your customers. Then you can use it anytime to actually shape the product and run discovery on, to go deeper. So that, that was a super mundane task for everything. Product managers would spend, spend hours. Imagine that at a scale of product board and we have roughly, uh, roughly 1112, uh, product managers, product team, we would get three to 5,000 pieces of feedback monthly. So like imagine that you are actually like not only flipping through the email, like you have to understand that and you have to link it to the right piece. So we have built our first model that would actually recommend where you should link it based on the existing insights that you had and also based on description of the feature idea. And a lot has changed with large language models because they are great in understanding, especially written uh, text and then can help you to um, make some recommendation on top of it. And so we are using the large language models with Some let's say internal uh, internal bells uh and whistles around it to actually not only help you to link the individual pieces and like we have some like fully automated and kind of like more like assisted way like how we help you with this fairly traditional process of mapping a feedback to feature ideas. However the uh and it works well for things like feature requests and more of a commitment where you actually need to make sure that the link is there. However really the bigger question was kind of like how can you get a more higher level understanding of what are the topics for different audiences uh that you might have in your customer feedback. So would there really be top 10, 20 things people uh, people care about. And very often in the larger organizations you would see somebody who would own a uh program called Voice of the Customer and on a regular basis they would come and say like hey uh these are the top 10 pain points for our, for our customers. So here product team do something uh around it and that would eventually influence the product strategy. Or they would say hey we are actually working on the number two and we're already working on the number three and hopefully we should solve some portion of it. So it's a fairly high level more strategy but it helps you to understand uh, understand the trends of uh, of a customer feedback. You can slice it and dice it by different segments. For example what is the feedback from, from churn customers. What is the feedback for example from the prospect that you have in your sales sales process and kind of you can compare all of it. So see it as a way of visualizing and summarizing on that one pager what are really uh the customer needs and then your strategy is going to be much uh stronger. Actually not many organizations, especially early stage organizations, uh, they are not doing, they are not operating this way and and they are really kind of like setting a uh, incremental strategy to okay, how can we get closer to the vision or it all set based on the let's say a recent bias of a customer that actually talk to you or the loudest voice among the customers. So like here it really helps you to have much uh stronger evidence. Also understand the financial implications of behind it because we are able to bring a customer data for example from, from Salesforce. So for B2B organizations like that's actually like really strong evidence like hey I got this neat and it's associated with X million recurring revenue here for me. And so if you're not building it we are potentially risking this revenue. So so then I'd say like strategy is significantly easier. I wouldn't say like it's a, it's a piece of cake, but it's significantly easier because you are not, you are not kind of like starting with a blank blank in this case.
Speaker B: This works of course, when you have this amount of feedback.
Speaker C: Uh, right.
Speaker B: But I was wondering. Well, there are two points to go thanks to your answers. It's like how do you. Because it's a bit tricky that maybe the customer doesn't even know how to write the feedback.
Speaker C: Right?
Speaker B: Because maybe the feedback is already a solution or even they are saying it's a problem, but maybe that's just the surface problem. Or if it's not even the problem itself, but they describe it in that way. But then you need to go deeper and figure it out what is the real problem. So is the AI helping you in some way to discover that? Or you need to still go manually and do an interview and try to discover more. Thanks to you guys. As a product manager.
Speaker C: So like you are working with the feedback that either customers share with you directly or for example somebody from the organization submits it on behalf of a customer, for example they had a conversation or you actually go and talk to the customer directly and you have some, you have some notes, uh, uh, note from it. So like it can be like all different levels, granularity and level of uh, level of quality. And uh, yeah like very often I'm like excuse, like you're pointing it out as well. Like hey, like we don't have a product yet so like wouldn't be the product feedback about. And it's like yes, but like those customers that you are focusing on and ideally you have at least a segment or somebody like who you actually are solving for. Because if not you are solving for everybody and nobody at the same time. So they eventually start there. But going back so you actually have these understanding of the problems. Right? Like you can ask someone like hey, like what's been the most painful thing for you this week? That's been the most painful thing for you, uh, today. And then like what would pause, eventually pick up. It's like, hey, accountant has a problem. Going back to the accountant has a problem with this. And like it takes them uh, a lot of time to do XYZ and like you will pick it up as a topic in the feedback. It doesn't tell you anything about what the solution is. Then you see like, okay, this seems to be the most important uh, thing uh, to solve. And then you can go deeper or you can continue assessing it's like yes, but like is it for example frequent enough uh for me to solve it? Would I actually pay for it? And then you can go into deeper discovery. But like it sets the initial direction for you that you are for example going to focus on that type of problem and not something what you actually thought that it might be important based on whatever um, whatever input. And so like really focusing on the, on the right problems to tackle is the first step. Then like if you have existing product, yes some portion of the feedback will be around this. Uh, get me a faster horse right? If I go to the analogy of uh, a Ford with a car and like it's still extremely, extremely valuable. Right. Like if you build something what actually people use and so like you can go and make it, make it better and the more you understand the people. So then you can eventually take even a novel approach like that's what we see very often with AI like it is a novel approach to some stuff that has been done in certain way because there was no other way like very traditional way how software was uh built and looked like Now a lot of things is, is changing. We got for example a lot of the chat interfaces um again after the era of chatbots and so it's definitely like changing the way how um people think about it. But last thing they won't say like what you can do with pull is like you can have a conversation about the feedback and so if you are not let's say happy with the way how it's eventually frame like you can, you can ask about it and like you can mention certain segments and eventually so if I get a feedback and for example somebody is not happy with some integration at ah product boards and like yeah but like what does this segment actually say? Is it important for this uh, do they mention anything specific? It's like you can literally have a conversation with the uh, with the the product board uh AI or product board polls to go deeper. But we need to make sure that we are not hallucinating kind of like the answer. So eventually tell you hey uh, we can see it in the feedback. We have a citation there so you can go and select okay this statement generated via uh is actually based on this evidence and you can go and kind of read it yourself. The raw input, it actually uh lets you it. So it helps a lot with the credibility and with the trust which is extremely, extremely important because the decision that you are making uh on top of it and you're using that um as an input are uh, or do have a really Big implications very often if you are a bigger organization.
Speaker B: Exactly. Now if we kind of try to think about the future with AI. So how do you think this will change the product manager role or how we will enhance the. I know that we already describe stuff like mashing feedback with features and helping them to summarize and take decisions better. Right. But do you see what is the next level? How this will help the product management or how it will change or role?
Speaker C: This is what we are thinking about daily, right. Like it's like roughly 40% of what we are doing is associated to AI today. And the portion of that investment will only be increasing. Like every product manager at ah, product board will be building a capabilities that are leveraging some AI component. Uh, AI component uh there I like and I'll probably start with the thesis that actually Martha Kagan shared on one of that. One of our events two, three weeks ago. And, and it was kind of like a very good observation that before Internet the distribution of the product in a software, if we talk about software was the biggest problem. I'm like you would have to burn CDs, distribute them somehow for disk, right? You name it. It was a big problem. And the product managers were spending a lot of time with how the hell are we going to distribute the software, how we will uh need to get to the usage. And then also we have a newer version again like how do you do all of it now? Uh, it has changed with the uh Internet so we get marketplaces, you download it online, you have it in your pocket, in your phone, in the app store, uh et cetera. We see disruption in the delivery phase. And so like engineering in like building stuff used to be bottleneck. I uh would use the past and not like now. It like we see that it's no longer going to be a uh bottleneck and we see probably the early stage prototyping, uh something where the existing tools are already better but also the productivity gain. Engineers using AI to uh, to help them code faster. It's really fascinating. And so you will see, you see the disruption there. Then it boils down to the initial component and it's the uh product discovery and making sure that you are very well understanding the problem and that you are tackling it well. And so the understanding of the customers and market is going to be even more important than uh before because on many other stuff like you will see that AI will take the Monday tasks and I use an example of you linking manually something in the product and you filling out this field, etc. A lot of it will get significantly uh, easier or will be, will be replaced completely by some of the AI components. Literally like you would go and conduct a report to your manager or to somebody. Like people would spend two, three hours writing it. Now we see that it's much faster. You just put a bullet point there. It will format you everything. There's a reality of today and this is going to continue and tackle these Monday tabs. But on the other side it will actually help you to process many more inputs into your uh, your strategy. It will help you to make it a much more bulletproof because it will challenge you in many ways in your uh, in the reasoning. And so the clarity of thinking will, will improve. With AI. I still believe that let's say fragmented AI will not replace it product management because it's still so many factors that you consider. Many of them are super soft. AI will not, will not have for very long time access to a lot of the insights, dynamics, uh, etc. But it will be a great tool that uh, will elevate the product management practice and will make uh, product managers, uh, product managers better. And so if I also look at the reality of for example a Czech market here, right we get so many product owners um, on the Czech market and like generally in central, central Europe that role will slowly be replaced by AI because that's primarily the product delivery role. That's not the product management, uh, product management role as the uh, uh as we see it and so deciding on what to build next and like really curating the product because on the other side as I mentioned it's easy to build now but you don't want to build everything. Like you really want to make sure that you are building the right thing and you are delighting your customers on the right thing. And that's something where you need a strong product based or product sense I would say. And that's something where I think, I think the unique and like more like a creative approach of a product, uh, manager or like product maker in general. Right. Like many people can eventually do product management even though they are not, they are not having a uh, product management title.
Speaker B: Got it, Got it. So since we have short time I will make the last two questions for now but then and we can close it and maybe later we can have other conversations. So since. So yeah, I was, I was thinking also that you were, I know that there are some companies also working with, let's call it AI avatars or AI interviews. What is your, your thoughts into that? Because it's it's like we are replacing the human feedback for some large language model and to give us some feedback like it's created in general or artificial. Let's say. Yeah, do you think this is a good approach to take this data and take it as a valid. Or do you think we are still gonna rely more into going and talking to human beings about their problems and stuff like that?
Speaker C: Right. I would say there will be a lot of dead ends here and maybe the products that will not actually reach the product market fit. I do have an opinion on the specific example that, that you use and I would actually hate it myself. But as somebody who I would consider like in the category of intelligent worker. And so I value my time and if I'm talking to somebody, I want to make sure that they value my time on the other side for let's say workers that are, let's say doing um, I don't know, construction work, etc. And like you're trying to get some initial input. Yes, like it might, it might eventually, eventually work in certain, in certain industries. So I'm like, we will have to see. A lot is now unlocked with the technology. Like very often like a lot has been unlocked with the rise, uh, of Internet. Uh, a lot has been unlocked with the mobile devices. A lot has been like if I go kind of like outside of the uh, outside of the uh, software, uh, industry, like for example nanotechnologies, like a lot has been unlocked with that. Like it didn't start with a specific purpose and application and like you were looking for the right application there afterwards, which is completely legit approach in depth is a little bit harder because like you're looking like, okay, so where can I apply it? And very often I'm like startup and like, like okay, now we get this large language model component, like where can I apply it? Where can I make it useful? But it will lead to yeah, some, some features, some products will not be the, the right, the uh, right ones and will not, will not take off and, and now we will see, we will see a lot of them, but I don't think that it's necessarily something what is um, uh, issue of AI. It is just like now we have more opportunities and actually great. And many people try those opportunities and uh, go and explore them.
Speaker B: Got it. Um, now as last point, so is there any resources and events, podcasts or books that you or thoughts leaders that you followed to help you to keep growing and learning in your role?
Speaker C: Uh, I mean like, yeah, definitely. And like there are somebody that are let's say more uh uh traditional and people that I follow and admire from uh product management. So it would be for like already mentioned Mark Hagan it would be Trey Joshi uh who I think now joined Dropbox I'm not mistaken. So uh they actually post a lot of really interesting and like a spot on spot on uh uh context there is reforge and many people around it kind ah of like uh really advancing the default leadership around product management and making a lot of observations around product management but also products that are now being being built on the other side. So like this like more the observation and the idea that they share that I deeply think about on the other side I am learning the best if I can touch the thing. So like I am occasionally playing with what's the newest greatest go to look at product Hunt for example uh kind of like what people build. What is useful for my uh current preg role is there's a lot of analogies with adjacent verticals. So like what we are building for product uh somebody might be building something what is similar but applied for e.g. cRM tools or for uh. I don't know support tools or something like that. So like looking into those kind of like analogies like those sort of things that uh hopefully uh hopefully shape my my thinking in a right uh in the right way. But yeah I'm relatively active on LinkedIn and and a lot of a lot of stuff that I will then go and check out I see there and yeah it's a long list of posts that I have that I have saved on LinkedIn and want to get get back to them.
Speaker B: Good good. Um, is there something that you want to remark about the conversation today that you consider is important to leave or something that we haven't talked but you consider it can be interesting for people to research more and check it out
Speaker C: out there I would say it was like maybe actually two things. Like I feel like we are on the verge of of the AI shift uh here and there's a lot of people that already use AI to like depth. Plant has like go and use it and test the hell out of it and like push the limit on the other side. Don't forget about customer needs and who are you building it for and is somebody going to pay for it. Don't get too high on the enthusiasm and like really think about is this something what can reach a product market fit and uh how to get there. Because the way how you build a product is very different than how you built the traditional. Let's Say software where you have the database and then you have some UI layer on top of it. If I oversimplify. So the evaluation there is, for example, critical. But very often the, like, people forget about the customer understanding and like, what's needed on the other side. There's still a lot of, uh, skepticism around AI and like, what it can, uh, what it can do. And like, I really recommend just like go and play with the, play with the tools and like, go and ask around, like, what are other people using? I'd say like, I hate, for example, NPS surveys. Like, would you recommend this to your, to your friend? But actually in the era of AI products, like, this is, I think, extremely, extremely important. And what I hate about nps, like, you don't go in the pop and ask like, hey, would you recommend me this? Or what tool would you recommend it? Like, it's not an intentional, not a question you'd ask typically. But I'm like, now with AI and I would really advise many people to go around, like, ask them, like, how are you using it? Like, what worked for you? You don't have to go through all the challenges that they went through. And so you can get a lot of insights and the booth and understanding of the world of, uh, AI tooling from, uh, people that are around you. And I feel like people, people don't do it enough.
Speaker B: Good. So thanks for the recommendation as well at the end. Um, yeah, so it was a pleasure to talk if, if people wants to connect with you. Yeah. How should they do it?
Speaker C: LinkedIn is the easiest. So just add me on LinkedIn. Say hi.
Speaker B: Good, good. So I will have it on the notes of the podcast so that people can go directly to your LinkedIn. So thank you, Martin, for your time today. It was a pleasure and um.
Speaker C: Yes, pleasure was mine. Pleasure was mine. Thank you for having me, Ricardo.
Speaker B: Thank you and have a good rest of the day.
Speaker C: Bye Bye everybody.
Speaker A: Thank you very much for joining us. We hope you have enjoyed this episode and gained valuable insights. Feel free to share with your friends and looking forward to seeing you next time.
Speaker C: Mhm.
Speaker A: Sa.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.