Episode 130: Product Management in the AI Era with Hubert Palan, Founder and CEO of Productboard

In this episode of Product Thinking, Hubert Palan, Founder and CEO of Productboard, joins Melissa Perri to dive into the ever-changing role of product management and how it is influencing the technology industry. They also touch upon current events in the tech world, including AI, and how they may be shaping product management practices.

Hubert is a versatile entrepreneur, product maker, mentor, and angel investor. He founded Productboard, the top customer-centric management platform that accelerates product delivery. Trusted by 6,000+ customer-driven companies like Zoom, UiPath, JCDecaux, and Microsoft, Productboard helps teams understand user needs, prioritize development, and unite everyone behind the roadmap. Previously, Hubert served as VP of Product Management at GoodData.

If you enjoyed this episode, make sure to subscribe, rate, and review it on Apple Podcasts, Spotify, and Google Podcasts; instructions on how to do this are here.

You’ll hear them talk about:

[05:18] - The tech industry has recently moved from an era of abundance and experimentation to a more focused approach. Companies now prioritize efficiency and concentrate on profitable segments with proven market needs. This shift often leads to a narrowed portfolio and potentially fewer employees. Such trends are natural during economic downturns, but companies tend to rebound when conditions improve, as seen in the experiences of giants like Adobe, Microsoft, Salesforce, and Intuit during the 2008 recession.

[08:40] - Every business lies on three key factors that drive success: revenue, cost, and risk. Limited resources demand a sharper focus on the core business, enabling better product management. Identifying crucial pain points, target markets, and superior product offerings becomes paramount. To thrive, you must excel at understanding customer segments, their willingness to pay, and the value your product brings compared to alternatives. Therefore, adaptability and expertise in these areas are now more critical than ever.

[17:50] - As a product manager, it's vital to have a solid education and trust in your instincts, but it's equally important to back those instincts up with customer interactions and market research. Finding a balance between precision and efficiency is key, and you can leverage the experience of your team members to avoid redundant efforts. Open communication among leadership is crucial to sharing essential context. Conducting workshops can help facilitate understanding, and team members should actively seek guidance from seasoned mentors. By working collaboratively, you can ensure optimal outcomes for your company and its products.

[37:50] - The economy's ups and downs are influenced by various factors, industries, and perspectives. To thrive, mastering product management and strategy is crucial. Despite exciting technological advancements, the key is applying them effectively to different segments and prioritizing resources. Long-term success demands differentiation and foresight, focusing on elements that remain relevant over five to ten years. In the competitive AI landscape, a strong product strategy is essential for survival and standing out from the crowd.

[40:50] - AI's emergence is reshaping product management, and PMs must ask the right questions to use AI as a reliable tool to guide decisions. However, critical thinking remains essential to uncover unique insights and find valuable opportunities. While AI can improve existing products, it may not discover entirely new market needs. Project managers should view AI as an asset, not a replacement, and leverage it for incremental improvements while relying on human creativity for true innovation.

Episode Resources:

Melissa Perri - 00:00:02:

Hello and welcome to another episode of Dear Melissa. This week we've got three questions for you relating to product strategy. One of them is about should I build it or should I buy it? Another one is about product ROI techniques and how we relate our product metrics back to our financial metrics and how we use that for prioritization. And then the last one we're going to do is about market size estimates and how we can get realistic ones for your team. And I wanna remind you that I do this every other week and you can get your questions answered by me as well. So go to dearmelissa.com and let me know what you're thinking. No question is too big or small. It can be about generic product management stuff or situations that you're currently facing in your role. So head over to dearmelissa.com and let me know what I can answer for you. So for this week, let's dive in. The first one about build vs. buy decisions.

Dear Melissa, what are some of the decision points in a buy or integrate versus build situation? I'm working with a product that wants to incorporate asset management features. There seem to be many good solutions out there already, ready to go. So what are the steps to assess this?

Building versus buying is a really important decision for product managers, so I'm very happy that you asked this. Now, when you're thinking about building versus buying, the first and most important question that you wanna think about is will this new feature set or the thing that you're buying be delivering on the core value proposition for your product? So for example, if you are delivering a SaaS product that helps people do market research, is it a market research function? Is it the knowledge behind it? Is this the core value proposition that they're actually buying? That's what you want to assess. Now, if the answer is yes, that's worrisome. You don't want a third-party software being the main delivery of your value because they can be in control of all the software and all the changes and whether they fix bugs or not, and then you're beholden to that. So if all your value is kind of tied up into somebody's third-party software, that's a little worrisome. That's a lot of risk for your organization. But if you answered no and you decided, hey, this isn't our core value proposition, this is more adjacent, it's something that enhances, it's definitely something we want, but it's not our core value proposition, then you might wanna consider buying or integrating with somebody. So think about that first. And the way that you could think about it as well is saying that we wanna spend our hard development hours on things that are gonna help us innovate to deliver that core value proposition, right? That's where you wanna keep your budget. So in adjacent products or things that are maybe supplemental to that value proposition, that's where we're gonna look at buying or integrating. It makes it more powerful, but it doesn't tie up all of our value in somebody else's third party application.

Now. One thing to look at is does this product do everything that you need? And think about it as well from a short-term perspective versus a long-term perspective. So if you're going to buy a product, does it have all the features you need ready to go? Will you have to do any kind of custom software for it? Like, will you have to build onto it with your developers? How easy is it to integrate? Will it actually involve any developer capacity? And then you wanna think about that over time. So is it good for right now? What about in three years? What about in four years? Now there's a lot of good benefits to buying something to get it out to market faster in the short term knowing that you're going to innovate or build your own later. So that might be a strategy or a plan. So buying things can help you realize that value, sign people up fast, especially if they've been asking for it. So consider, is this a long-term plan or a short-term plan? If it's a short-term plan, it doesn't have all the bells and whistles you want, but it's going to get you to market and you do have a plan to actually build your own on the back end, you know, eventually do that, right? Like that's a very good technique. If it doesn't have everything that you need and it will be selling your value short, maybe you shouldn't buy or integrate. Maybe you should actually look at building your own. Another thing to look at is cost. So cost is a really big factor as well. How much does it cost to keep this integrated and are customers willing to pay you enough to make that value worth it? So if you are integrating or if you're buying a software, and especially if it's on like a subscription basis, you can think of AWS, a great example of Build versus Buy. People don't like to build their own databases, they pay for AWS. Now you have to think about In the Cloud, the Host of Costs. That's also a buy decision.

That's not a roll your own decisions, does that outweigh the costs of us actually building it and the price that we would be getting for our customers? So take into account how much it will cost and what it will look like over the long term and how that cuts into your profit margins. So I would really look at those things. Does it focus on your core value proposition or is it adjacent? In adjacencies, that's really good. I worked with a healthcare company once that had a main value proposition of being an EHR service, so an electronic health record system. And they also had things for like payroll and for HR on the backend that they had built themselves. And they found that a lot of people were not actually using them, and there wasn't enough development resources to go around to actually concentrate on that and focus on shoring up the value proposition of the core. So they decided to buy the HR and the Payroll Systems to help make a complete package so people wouldn't be turning to other packages, but they knew that wasn't what people were coming to them for. That's not what the customers were coming to them for. So in this case, it's a solved problem already. HR and payroll has been done a million times before. It's not where they want to spend their money innovating. It's an adjacency. It's not the core value proposition. The timing piece as well that we talked about gets them to market faster, make sure that people are happy, and then also the cost was enough to justify the price that they were charging for the whole product. So that's really the things that I would look at, and I hope that helps you on your build versus buy journey. All right, let's go to our second question of the day.

Dear Melissa, I want to help my organization make product trade-off decisions on financial analysis rather than what the founder feels is the right thing to invest on. What are typical ROI analysis frameworks that are appropriate for a SAS product?

So as we're deciding how we should make product trade-offs, you may have seen some of the different frameworks for prioritization that come back to effort, time, cost, all these different things. I don't love those. I think you should really look at cost because you wanna know how much it's gonna cost to build things. You should look at timing as well, but you need to do it in a lens that combines it back to the financial metrics, just like this person is talking about. So thank you for asking this. One thing that you do is tie it back to the strategic intents. So in a lot of these episodes, I talk about the product strategy framework that I teach where we have strategic intents at the company level, and those are about company metrics like increasing ARR, increasing retention, reducing costs overall. You want to figure out how your product ladders back into each one of those by using things like lagging indicators and the problems you're solving for customers to show a correlation between what you're building and what you expect to achieve up there. Now to do that, I really love frameworks and things like cost of delay. So cost of delay is something that I love teaching. It's really looking at the measurement of benefit over time. So what cost of delay calculations will tell you is if we release Product A versus product you know, do one in sequence versus the other. What's the benefit we expect to realize in that sequence? Now, what if we switched it, the Product A, then A? Cost of delay is telling you how much money you could potentially be losing by delaying the work on a specific product. So you want to look at that. It takes into account how long it's gonna take to deliver and to start generating money. It's also going to look at how much money total is expected over time. So when we put those two things together, now we can start to look at, should we reorder our roadmaps? Should we start to look at different options for bringing in maybe even people to help us release things sooner because we can be getting that benefit. So I'd look into cost of delay for sure to help you with your ROI framework prioritization.

This is really, really, really valuable. Um. When you do this as well, you will also be doing a lot of modeling. Now you're not gonna go in there and just be like, hey, future A is gonna get us $6,000. That's not how this works, right? We open up the spreadsheets, we start to make assumptions. So you're gonna be doing a lot of financial modeling. We believe feature A is going to solve this problem for these segment of users. We have these customers in danger of churning. I'm going to put a number around them that we might be able to save. We have these potential customers we can go after. I'm going to put a number around them. I'm going to talk to sales. I'm going to model out how much we could potentially sell. I'm going to make it realistic. I'm going to do a low versus high calculation. I'm going to plug all those models in using cost of delay, calculating out that benefit, going back to the engineering team, figuring out how long realistically are we thinking about this, and you don't have to get into like... nitty-gritty weeks and days. You could say, if it takes a quarter, what is that going to look like? If it takes a month, what is that going to look like, right? Like swag guesstimates over here. We plug all that in and it will help us actually look at how much money potentially could we get from this if we do it in this type of sequence. I think those things are extremely powerful. Once you start introducing cost of delay to your company, it really takes away a lot of the noise and a lot of the fighting about which ideas are better. So. I've used this for quite a while. I've done cost of delay analysis with teams and with executives who've been very, very strongly opinionated, especially founders, where they think they need to do Product A versus A and you show them what you expect to get when you release it and they're blown away when the answer is different than what they expect. So I highly encourage you to look into that. blackswanfarming.com is a website by Joshua Arnold that has fantastic cost of delay resources on there to get you started. Definitely check that out and I hope it helps. All right, last question of the day.

Dear Melissa. In the modern product management world, how do we get market size estimates to convince executive leadership about the worth? Market research reports from various sources seem very unauthentic and unrealistic, with all inflated growth projections.

Well, that's true. I think some Market Research Reports are definitely like pie in the sky. We think this is going to happen. Not all of them, but some of them. And you should use it to help inform, but not to make a full decision on. When we do market research estimates, especially market sizing estimates, I start to calculate things out a little bit more in detail. When I had analysts on my team, this is what they would do as well, you would get some kind of subscription to something like Capital IQ or another platform where you've researched different companies, especially if you're in B2B. When you do that, you could start to pull the profile of different companies together. You could start to do research through magazines about how much they spend on certain types of product. You can get headcount calculations. You can get how much money they make, all those different things to help you make your segment sizing. And then that helps you calculate out your TAMs, your SAMs, your SOMs, all of that stuff. But you're going to be doing a lot of work behind the scenes to figure out what your assumptions are and Identify Companies within that assumption. And this does take a lot of work. So if you have somebody who's been on the team before that did consulting, a lot of people do this at your Bains, your McKinsey, any type of consulting or data analysis like that, probably going to help the team a lot. So look into that.

Denise and I also recommend somebody being on the product operations team who can do this as well because it helps the product manager get that data in and be able to do those market sizing assessments. So it's a lot of work, but if you don't have a product operations person who can do it, you can definitely try yourself. So I'd model it out like that, make a bunch of assumptions, do the research there and pull it together. You can also subscribe to Market Research Reports through Gartner or all of these different platforms that you have out there. They're going to get you some more information as well on the types of companies out there, what they believe the TAMs are, those types of things. But then it's up to you to calculate your serviceable addressable market and your serviceable attainable market. And those calculations involve you. Looking at the TAM, understanding it, trying to figure out where they got that from, and then breaking it down into what you can accomplish. That's the modeling we're talking about. Spreadsheets, all of those different things. So many people make the mistake of building their entire product roadmap off of a TAM or starting a company off of a TAM. And TAMs look great to investors because it's potential, but it's not going to tell you what you're making in the next two to three years. That's what you need to be able to actually prioritize and get to ROI calculations like we just talked about in the last question.

So a lot of modeling goes into this and I'd recommend really trying to find somebody with that consulting background that can help you. I think that person's going to be really valuable in that size. Then once you make your models, you'll have the data that you need as an input. Go out now and research the numbers for that. For example, if you need a population size of a town in Germany as one of your inputs, you can go Google that now. But you're not relying on the market research platform to just give you the final answer. Instead, you're breaking down all of your assumptions and calculating this out so it's realistic for you. That's what I really would be looking at. Market research platforms and market research reports are fantastic as well to keep you abreast of competition and how people fit into things. So definitely look at that. But for market sizing, you're going to have to do quite a bit of that on your own with your own assumptions and what you can target and how it's relevant to your business. So I would really focus on your financial modeling there.

Alright, that's it for Dear Melissa this week. Hopefully that was helpful. If you have any more questions for me, please go to dearmelissa.com and let me know what they are and they will be on a next episode. We also have an option for you to leave me a voicemail so I can hear all of your pretty voices. Those get prioritized ahead of written in questions, so if you don't have a huge fear of speaking in public, definitely drop me a voicemail and I will prioritize that. We will see you next time on The Product Thinking Podcast. Please subscribe so that you never miss another episode.

Stephanie RogersAugust 2, 2023