Product Excellence w/ Hubert Palan, CEO of productboard

Hey everybody, this is Mike Belsito, co-founder of Product Collective, and thank you very much for joining us for another edition of an industry interview. So I know many of you are filtering in right now. For those of you that have never attended an industry interview before, first of all, welcome. I appreciate you taking the time to join us today. If you have, this is going to be a little old news to you, so, so bear with me, but These industry interviews, you know, we, we have these live video Q&A chats with product leaders from all around the world, really. And we do this twice every month on the first and third Wednesday of every month at 1:00 PM Eastern. So I know there's a couple more coming up that are already scheduled, but we'll be adding more. So keep an eye out for that. And this is a production of Product Collective. For those of you that have never heard of Product Collective before this industry interview, We're a community for product people. So we've been around for a few years. We're product people ourselves. I mean, that's kind of why we started this is we were confused product people just trying to learn from others. And, and now it's our, you know, this is our product. The community is our product. We have a conference that's our product. So we love it because we're sort of getting to work with, you know, people that were just like us, you know, product people wanting to learn. And we do it all year round. But aside from these industry interviews, there's a lot of other things. That are going on with Product Collective. We have a weekly newsletter that goes out to about 30,000 people every week, and it's a new topic every single week. So we love being fun with it. You'll, you'll see what we mean when you sign up. We have a Slack group, and there's about 10,000 people that are in the Slack group. So that's a great place just to sort of pop in as needed. You don't need to be there every single day, but you know, if you need to get some feedback, you want to meet some other product people, run something by folks, that Slack group's a great place to be. And so all of that, that's free. You know, if you go to productcollective.com and sign up, you could have access to all of that, get an invite to the Slack group. There's no cost to take advantage of any of it. We do meet in person twice every year at our conference, Industry: The Product Conference. And our flagship conference is in Cleveland, Ohio every fall. This year we'll have about 1,200 people with us, but we're gearing up for our European edition of Industry, which is in like 3 weeks. It's in Dublin, Ireland. We're there every spring. We'll have hundreds of product people with us. I'm excited for it. I am also a little anxious. There's always a lot to do this time of year. So if you see beads of sweat dripping down my face, maybe that's what that's all about. But you could learn more at industryconference.com. And after this, I'll follow up with y'all and send you a little more information on it. But, but coming back to these industry interviews, These are fun because this is a chance to get to know product people, but then dive in with them on specific topics. And, and my guest, Hubert Pallant from Productboard, he's the CEO of Productboard. First of all, just thank you for joining us, Hubert.

Oh, totally. It's so great to be here. Thanks for having me.

No, it's awesome to have you. And I know, you know, by the way, you know, Productboard's been a sponsor of Industry in the past, and we're having your team with us again. So thank you for that. Um, but Today, I know we're going to talk about a topic that for some product people, they might have heard this phrase thrown around, but it means different things to different people and it's product excellence. And so I was excited to get to chat with you on, you know, kind of your take of what product excellence is all about.

Yeah, I mean, this is my favorite topic. So we can dive into it. I just want to say that I went to Cleveland, Ohio for the last conference. It was awesome. It was a great crowd. It was, it was wonderful. So I encourage everybody to attend.

Well, I appreciate that. Thank you very much. So I guess before I even ask this question, just a little note to everybody attending, you can ask questions to the guests too. At the very bottom, there's a Q&A section and a chat. The chat's more for, you know, you could introduce yourself, maybe share where you're from, what product you're working on. It's fun to see people from all over. So maybe you can mention it there. You could also just, again, give me— I always say this, but give me peace of mind that you can see and hear us okay. You can mention that in the chat. But in all seriousness, you know, I'm in Cleveland, Hubert's in San Francisco, but I'm sure you all are in a lot of different places. So feel free to use the chat for that. If you have questions though, use the Q&A feature. The Q&A, you can ask any question. I'll be able to take a look at that and review it the whole time. And if we're right in the moment and I see a question that's relevant to ask, I'll ask Hubert. If I might wait to the end for some questions too, but fill that up because I'd rather get to a lot of your questions other than mine. So you will have much better questions for Hubert, I'm sure. But you know, I will start off with a question of my own, which we're talking about product excellence. I said it means different things to different people. What does it mean to you, Hubert? Like, what— how would you define that, and why should product people care?

Well, look, you know, I'm a product manager, right? I grew from junior product manager to VP, and ultimately I found a company and I still wear where the product had a lot of the time, a lot of the hours. And kind of what happened to me is that I looked around, and maybe I should explain. I came from like an engineering background and I got an MBA at Berkeley and Steve Blank was my professor, the founder of Lean Startup, and I kind of got sucked into this whole Lean Startup movement, but then I kind of started asking, well, what other methodologies and processes are there? And I was looking around because I wanted something that would be optimal for the needs of product managers. And not necessarily in the early, early days when you're just looking for the product market fit early on and, you know, you're ideating and it's a lot of testing because that, you know, Lean Startup and kind of that whole concept covered that well. There was Agile, which is a methodology for delivery, right? It helps you break down, hey, here's what you want to build, break it down and just make sure as you're delivering it that you're kind of not veered off the path too much and that you kind of course correct. But when I looked at my needs of a product manager, I was at a company that grew from 20 to 300 people and we had a BI SaaS product in the market and we had an early product market fit and we had a lot of feedback and people wanted like a zillion different things because that's the thing about digital products. There's no limits, right? You can always grab another feature. And so I figured that there's a need for kind of a rigorous approach and basically almost a methodology that would cover product management for maybe already more mature products or, you know, after product market fit. And that would kind of COVID all the key pieces of product management, which is, you know, go from the product vision, like long-term what you wanna build, but then realize that you can't build everything at the same time and that you need a strategy in terms of what you're gonna build first, second, and third, and then you can execute. And so you can use the lean methodology to kind of figure out what the product market fit is. You can use agile to execute effectively and efficiently cooperate with your engineering team. But the strategic piece and kind of tying it all together was missing. And so, you know, this concept of product excellence, it's not like, you know, we invented a new thing that was basically just like, hey, how do we name the set of best practices that product managers have been following and adopting for years? In the digital world to make sure that you end up building the right thing and that you get it to the market as fast as possible. And we just, you know, you said like, okay, let's call it product excellence because it is really about being excellent at the craft of product making, right? And have a set of best practices, processes, guidance, tools, and so on and so on. And then obviously, as time progresses, it's perfecting. It's just like, you know, Agile Manifesto when it was written in 2001, it wasn't all hashed out. It was just like, few points, right? But then look at where we are now and like the crazy industry that's around the consulting there. And the same thing with lean. So that's kind of, you know, overall I'm happy to dive deeper, but this is, this is, yeah, kind of a summary.

No, I appreciate that. No, and I, I can relate to that even just like product management in general. Like it's been around forever technically, you know, especially if you talk about like consumer packaged goods, but thinking about it for the software world, when I was a co-founder of an internet startup, even, I mean, not quite 10 years ago, but, you know, about 10 years ago, it wasn't like being a product person wasn't yet in my vernacular. Like it was very early where people really defining themselves as, you know, hey, I'm a product person. So I do feel like it might be those, it's still those early days, right?

Yeah, it is. Look, it, you know, I mean, obviously in the digital world, product manager is a role that we understand and probably most people are listening, I know what we're talking about. But if you look at where it's coming from, it's coming from before digital world, right? And if you look at retail and if you look at companies like Procter Gamble or even Hewlett-Packard in the early days in the hardware world, there maybe the title wasn't product manager, maybe there was a title of a brand manager, which is somebody who owned the product. If you're at PG, Procter Gamble, you own Pampers as a brand, like you're pretty— you're a product manager. You don't have the title. And so the thinking was very similar. And, and you could almost argue that, that kind of like marketing strategy, education and background is what was, was very important in the, in the physical world. And that's what the brand managers typically, you know, where they came from. And we just, you know, in the digital world, we basically need to apply the same thinking, the understanding of the needs of the market, how the market is segmented, you how similar the segments are in terms of the needs. And then figure out what's the right sequence of satisfying the needs, which customer segment you're gonna target first and second and so on. And so that's kind of the core piece of the product strategy. And that's the same in the physical world and in the digital world. In the digital world, just the product is a digital product or service. But that understanding, of the market and the strategy stays the same. Now, the interesting thing is that it almost feels like we kind of forgot that in the digital world because we kind of like realized, hey, there's these digital products and we can build software for everything. And it was very much driven by people who understood the technology in the first place and not necessarily had, you know, they didn't necessarily have the marketing experience and the marketing strategy experience that the traditional brand managers have. And that resulted in a lot of products that were clunky and maybe over-engineered and just for the love of the technology and not necessarily something that would solve really well the needs of customers because that wasn't the background. And then I feel like then we went to this second phase where we realized, okay, we now know how to build products in terms of the delivery. If you write a spec, if you define it, if you design it right, which is a big if obviously, then we know how to break it apart and deliver it. But the business world came and the sales thinking kind of showed up and suddenly from the engineering-led decisions, we fall into this sales-driven. It's like, hey, there's this request, this customer needs this, let's just build it. And there's nothing wrong with asking this and driving decisions or like, you know, having input into decisions. But the key thing is that you need to have a solid strategy because you need to know what you say no to and what you say yes to because again, there's no boundaries in the digital world and if you just blindly execute on everything that the sales team wants you to deliver, you're likely to build a product that's not great for anybody, just kind of mediocre for everybody and you're not focused. And so then now we're in this product, it was like, oh my God, you know, we need to think about customers first. We need to think about needs, which is what the real, you know, fast-moving consumer goods world have been doing for 100 years. But in the digital, it's coming to the prime. It's like, okay, we need to start there and we need to have the alternative, the analogy of a brand manager and go from there.

I'm glad you brought up the organizations that might be sales-led or engineering-led because there are probably people that are watching this and maybe they're in an organization that is, you know, traditionally sales-led or engineering-led, but they want to achieve that product excellence, right? So what advice would you give to those people, the people that want to achieve this, they want to be on this path, but maybe they are in organizations that aren't necessarily, you know, product-led?

Well, I think that the key is the realization that you need to start with understanding the needs of customers. And there is a set of best practices This is how to do that. You know, your product vision must be informed by insights that are coming from your conversations with the market, user research, feedback coming from sales team, support conversations that are happening. You need to be able to mine those insights and bring it into the— or closer to the product decision makers, whether it's product managers, designers, engineers in many cases. And this means that you need to have the discipline of kind of identifying the needs and then the dimensions of the different customer segments. So to give you an example, right, and something that is easy, if you're buying a car, there's different segments that have different needs to satisfy, and some segment wants a convertible, some segment wants a minivan, and other people want kind of like a just standard car. And so to be able to capture the information about the market in the digital world and say, hey, this is a segment or this is a persona, this is the set of needs that they have, and there's another segment and they have different needs, and achieve alignment across the organization in this, that's the first and most critical piece. Because if you don't have that, then you can't have a conversation about what is the most important thing and what is it that we should build next, because if you know, like, for whom? That for whom and what need are you trying to get done? So I would say that this is kind of the most important thing to realize and just do it. You know, start with an exercise where you just lock yourself, you know, in the room with the team and you bring in the salespeople and support people and marketers, everybody in the room, and you talk about, hey, Who's the customer segment? What are the dimensions? Is it customer size? Is it title? Is it obviously some other demographics? But then what is it in terms of— like, look, in our case, right, if I tell you about like product managers and how we think about segmentation, the needs are different if it's B2B versus B2C. The needs are different if it's a small product team versus if you have 100 product teams at a large company. Another dimension. The needs are different if you're a junior product manager or if you're a senior VP, chief product officer. Another dimension, right? The needs are different in terms of your sophistication. If you're just starting and you're kind of novice in the product management discipline, like, you will be okay with just a very simple set of criteria or prioritization. And, you know, you're not that sophisticated. But then if you've been doing product management for 20 years, you need sophistication and complexity and so on. And so, so these are some criteria, and there's more that we use internally to segment the market. But you need to understand how the market looks like and how big is the group of the senior 100+ product teams with expertise versus the smaller startup and so on and so on. And then that drives all the decision-making because then you have a common understanding and you can decide, okay, for this customer segment, for this need, what is the most important thing?

I love that. I mean, because oftentimes as product people, we're thinking about our customers, we're trying to articulate who we're serving, but reminding ourselves that it's not just us being, you know, us understanding that it's being on the same page with the rest of our colleagues who might be in different departments even beyond product. So I, I think that's super important, so I'm glad you brought that up. I have a couple audience questions coming in. It's a good reminder for everybody, if you have questions for Hubert, feel free to roll those in because there are— we definitely have time for some, and I'm going to take one right now. So for perspective, this is coming from somebody that is, they work at an organization about 450 people. It's a B2B e-commerce company. Their question is, how much does or can organizational team and team structure fuel or undermine a company's quest for product excellence? So does the structure matter? I'll ask you about that.

Totally. It matters because the structure, drives behavior and you're gonna achieve different results if you're productive. I mean, look, in the old school world, you would have complete separate organizations. You would have engineering completely separate and you would have product management separate and design separate and we would live in a waterfall world. I know there's another question, you'll get to it about PRDs, where you just like write the spec and then you go and execute and it's completely siloed. Well, we kind of know that that's not the ideal setup, right? So now we're talking about setting up cross-functional teams and having the cross-functional teams, product management, design, engineering, QA, product marketing, even all on the same team. Now the question though is what is the purpose or what's the objective for these teams? Because these teams can be focused on a persona. They can be focused on a user journey or user flow. They can be focused on, again, some companies kind of do the cross-functionality, but then they break it down by the architecture of the product still from kind of the from a technical perspective. Hey, you own the login page, you own the signup page, you own, you know, whatever page that you have in the application. And I would argue that the most— that the companies that organize their teams and where the teams own the needs or the jobs to be done or the key pain points that are aligned with the business customer segment. Segments are most— like the productivity and the alignment is the best. To give you an example, right, at Spotify they have one product team owns the browsing experience, another owns the playlist experience, another owns the discovery experience. And so this is kind of— this assures that the team as a whole, not just the individual product manager or the designer, but the team as a whole understands really well and really deep the need And they understand how even the needs differ for the different customer segments. If you're, again, I don't know Spotify segmentation, right? But I assume that there's gonna be different needs for somebody who's kind of like a hardcore music geek versus somebody who's just listening in on the background through Alexa, right? Or like whatever. So, so to your question, I would encourage people to structure the teams around the needs or jobs to be done again, or like however you want to Pick your favorite methodology terminology, but that seems to be the most productive way.

Yeah, I'm gonna mix in a question that I had for you, Hubert, which was, I remember in reading some of what you and the team had written about product excellence, there was this term you mentioned about black box organizations. And I'm curious if you could talk more about that and just sort of how it plays into product excellence.

Yeah, you know, Product management or product making is a team sport. And when we look around at companies that are succeeding the most, it turns out that that's the companies where information is shared freely and where the reasons why a decision was made is justified. And more importantly, not only you know what's kind of planned and what's coming on the roadmap and, you know, Yeah, what was planned, but you also know what was considered and what never made it to the roadmap. And this is a maybe subtle, subtle difference, but it completely changes the conversation. Because if you kind of paint for the whole organization, the bigger picture, and you say, look, this is how we see the market, these are the segments, these are the needs, we are not going to focus on all of them at the same time because we don't have the resources, obviously, because you can't build everything. Easily, even if you're a large, large company, you want to stay focused or you have limited resources. And so you paint that picture and you're gonna say, well, this is the segment and this is the need that we're gonna focus on now. What now is differs whether it's this quarter, whether it's this year or however, whatever granularity for your planning you have. But you talk about it and you say, all this other stuff we know about, we know about the other segments, we know about the other needs. But we are choosing not to focus on that. And that changes the conversation because suddenly if somebody shows up and says, oh, I think that— or I just talked to a customer and this is the most important thing that they need. And how come we don't have it? Well, now you can kind of sit together with that person and say, look, it's great. But this customer that you're talking about fits into this segment and the need is here, far right. And we decided that we're focused on another segment and the left need here. And that's our focus right now. And so thank you so much for the input. Thank you for bringing it to our attention. We're tracking it. It's somewhere outside of our focus area and we'll get to it maybe later, depending on what the strategy is like. You might, you might have even more clarity. You might know that it's going to end up on the roadmap. But my point is that if you do this, if you talk about this and you create this, it creates transparency and suddenly decisions are not perceived as a black box decision where like, Well, how did we decide what's gonna be on the roadmap? Like, you know, why are we not building this thing and that thing? Well, you need to have this conversation and paint the broader picture, because if you just say, hey, this is the persona that we're going after and this is the needs— even if you do that, which by the way, most, most companies unfortunately don't do even that— but if you do just that, you're kind of leaving out everything else and you're leaving the door open for all the doubts. It's like, well, did we consider the other things? And do we know about these use cases and so on. So, I don't think I've actually written about this much. I need to write a book about this.

Well, that's good. I'm glad that we're inspiring some more essays to come up for you. That would be good. You know, actually, like what you just touched up on, that there was an audience question somewhat related, which was, they're asking what a product person should do when the market is actually moving fast and it seems like competition might be out-innovating them. So they're in this situation where they feel like, you know, competition's there, we're here, we might maybe be scared that we're getting left behind. What do you do?

Yeah, I mean, look, it's tough. We live in a world where it took UiPath, robotic process automation company, 21 months to get from $0 to $100 million in annual recurring revenue. This is nuts. They grew from like 16 people $3,500 in 2 years, right? That's crazy. And so there is a reason for concern because it can happen in different industry again, because somebody finds a product market fit that's better and can execute faster and so on. I don't think there's a silver bullet. I think that you need to look at the opportunities. Again, look at the segments, look at the pain points, jobs to be done, needs, whatever. And, and figure out where you want to focus, where you want to differentiate, differentiate yourself. Do you have the skills? Do you have the capabilities? Do you have something that the market doesn't? But the key is focus, because the more focused you are, the faster you are, the better understanding of that need you have, and then you can out-innovate and be faster than the others. And so I would, I would encourage you to Go deeper rather than broader. And I mean, this is kind of like a bigger discussion because you could argue like, well, Trello is a company that satisfies many, many use cases because it's a simple workflow system that works for planning of your wedding through birthday party to product management, very simplistic version of it. Is that the right strategy for the product versus going deep into specific use cases? And then it's become more complex because you need to decide, well, for what use, for what market segments, what needs, which segments it satisfied, and maybe it's good for the bottom end of the market and so on. So my point is that it's not that simple and we can have a whole separate conversation about the strategic decision-making there. But in terms of the speed, if speed is critical, narrow focus, because then you're faster in a smaller area, but you're faster. The alternative is that you're doing more things, but you're slow and you're gonna die. So yeah, I'd go deep.

I think that's, I think that's great advice. I, you know, I also have been in situations too where, you know, CEO management team approaches us as product people and they're like, we see the competition, they just came out with this feature. And then we meet and we're like, we don't think it's a good feature. Like, we don't think that it's actually adding value, and we decide not to do it. And then 6 months later, that company shelves it completely. So I'm like, sure, thank goodness we didn't spend the last 6 months trying to catch up to something that wasn't all that good. So sometimes, does it— just because competition is, is fast with something also doesn't mean that they're right. But of course, maybe they are in some case. But sort of like trusting the research that you're actually doing with customers can be important too.

Yeah, it's an insight. It's an insight like anything else. Somebody did something. That doesn't mean, to your point, that it's working and that it's a good idea for a solution, but it's an input for you. Detect it, make a note, and see, well, based on your understanding of the needs, is it really the right solution? It might be, it might not.

Yeah. By the way, you mentioned, um, kind of in passing, and we had a question about PRDs, you know, resource, um, uh, like, and another— I'll bring up PRDs but also just sort of other artifacts. I'm curious your take on, like, What are appropriate artifacts these days for product teams? Like what actually helps?

Yeah. PRDs, Product Requirements Documents. I think that this is terminology from the past, from the waterfall world where you would write a doc and that would be the full spec and you would have maybe marketing requirements documents which would actually, the goal would be to capture the understanding of the market and the needs and the segments and so on. So you need to capture the understanding of the market. You need to capture the understanding. It's like a problem space. Space and solution space, right? So the solution space is captured by product requirements document. It's not that we would have the same long, stodgy, non-negotiable PRDs. We need to be much more flexible and we need to react much faster. And, and, um, so that kind of changes the format, maybe the length of it certainly. Um, but you need to capture the, the specification. I would argue though that there is never the world— and you remember probably in the past the debates about user stories and how exactly the user story should be worded and what exactly makes sure that there's no confusion about it. I don't think it's ever possible. It doesn't matter how you word it. If you try to capture the whole essence of the need and the solution into one sentence user story, you will never be able to convey the context that you need to share between the product managers, designers, and engineers. And so I wouldn't get hung up on that. I would say create a specification where you have the framework that touches on all the key things. And so the artifacts that you're asking, it's like, who is the customer? What are the characteristics in terms of their demographics? But then more importantly, in terms of their needs or behaviors or jobs to be done. And then again, Define clear what the focus is and then say, this is how we're gonna go to solve it. You, you think about the business outcomes, you think about not just functional needs, satisfaction, and functional aspects of the solution. You also think about emotional, the delighters, the aesthetics, because it's always— it's two things. It's the utility as the function and is the aesthetics as the delight, and you need to think about both of them. Obviously you can make a very conscious decision saying like, I'm after super utilitarian segment who don't care about delight or anything is better than nothing and so I'm just gonna, the first version is not gonna be high. But my point is that these are the pieces that you should have in the documentation. And whether it's like a simple description, one-pager that kind of provides it high level and then you go provide more specification in the detailed feature, epics, whatever, once you have it in Jira somewhere for delivery, just to make sure that it's captured, that's fine.

Yeah. Well, we're— we are already at the end of our session. It's almost 1:30. So I— before we do leave, um, I, I did want to ask you just if there's sort of any, you know, if there's one thing you wanted people to, to sort of take away from this, what might that be? Um, and if you could also share— I know Productboard's written a lot on product excellence. So maybe I'll share it and email everybody, but if you could just kind of give folks a heads up on, on the resources that you offer beyond your product itself, you have a whole lot of resources.

Yeah, sure. I mean, you can come to our blog productboard.com/blog and we are focusing a lot on sharing the stories. We have, we have an interesting content around, we want to put up more stories of how some of the great features and product were invented and created and how, you know, what was the history. And so I think that's gonna be very engaging. We have some, some cool ones coming up about the medium highlighting and how that, how that kind of, you know, idea happened and so on. And there's more coming, so I encourage you to do that. But look, you know, we're in this business not because— I mean, we're a company and we're, we're making software for product makers, but, but really why we exist is that We want to live in a world where every product is great and every service is great and every experience is awesome. And we believe that the reason why we live in a product where unfortunately not every product is great is not because people want to create something that sucks. It's because we don't understand intimately the needs of the customers. And I know that it might sound obvious, but go out and talk to people. But then more importantly, which is not something that we talk about enough in The Lean Startup, world is make sure that you capture it in a way that's understandable and that you clearly define where you start and what you're gonna do next. There's almost nothing on strategy in the Lean Startup kind of framework that's left out because it ends with product-market fit and so on. Yeah, I know you're being kicked out, so we're done.

It's okay. Well, thank you very much. I appreciate it. And, and everybody, thank you for joining me for this. And we will be in touch with the video of this, but also more details on future video chats. So thanks again, Hubert, and thanks everyone.

Nice to meet you everyone. Bye-bye.