Product Discovery Masterclass

Extremely challenging to be a junior PM right now because with all those tools, large language models, AI agents, automation, the low hanging fruits can be done by artificial intelligence. Even the ideas that work usually require many iterations and even if they are good from the start, you do not want to deliver an entire idea on production, you want to deliver that idea in some smaller chunks to minimize the time to learn. The goal of discovery is to ensure that the features that you ship are the right ones. And as a result, you are supposed to deliver more value, not less value. So unless you are measuring the value you create by the number of features, the discovery will help you create more value for the customers. And as a result, it works much better when everyone is engaged in this discovery process, when people are asking questions about about our goals, about how they can see our ideas before those ideas are even tested. There are a lot of people in your company, like stakeholders, customer success, support, who spend hundreds of hours with your customers every month. That ignorant world they know is a waste. You cannot perform product discovery just starting with. Welcome to today's episode of the Product Growth Podcast. I'm super excited to have my good friend of many years, Powell Hearn, here with us today. Thank you for being here. Thank you for having me. It's great to be here, Akash. So if you don't know, basically my entire journey is thanks to Powell. Powell is the man behind the Product Compass newsletter. He writes to over 70,000 subscribers there. He has hundreds of thousands on LinkedIn. And I have to say, I have a bit of a man crush on his content. He writes really thoughtful content. All of his content tends to go super viral on LinkedIn, and he is a practicing PM as well. So he's a senior product manager at Ideals. So he has a ton of insights to share with us. So, Paul, where I want to start is your hot takes for product management. And one of the ones I love is that you've said junior PM roles are done. Can you explain? I believe that it's extremely challenging to be a junior PM right now because with all those tools, large language models, AI agents, automation, the low hanging fruits can be done by artificial intelligence. And at the same time, I see that the senior PMs who learn how to use those tools can achieve even more, which only adds the pressure that you don't need so many PMs to manage a product. Yeah. So do you think that... the ratio of product managers to engineers, which historically has been in that seven to ten engineers per product manager range, is going to expand so that a PM supports more engineers? It depends if we still need junior developers, because if the only job of the developer and it is not the case right now, but when I started working as a a .NET developer, some developers were responsible only for basic crude operations, like displaying a list of items, editing these items, saving this database. So these types of operations can be easily automated with the tools like Cursor, Replit, and even you can ask ChatGPT to generate the code for that. So I expect that if I had to guess, we will need less juniors, both in terms of developers and in terms of product people or designers even. Okay, so basically what I'm hearing is all the junior tasks that PMs, designers, engineers, the whole product trio is doing, AI will take away. Now, where I want to press you a little bit on this opinion is, doesn't that just mean that the people who are junior take on higher level tasks? Why does it necessarily mean that they're going to be less junior people? Today's episode is brought to you by June, the customer analytics for product-focused teams. Are you not sure what users do in your SaaS? What features they use the most? Do you wish that you could know what each company does and use this information to generate incremental lift in revenue? June is the product analytics platform you need. It generates profiles for each of your customers that get you closer to your most important ones. It also connects your product data to your CRM so you can get a full view of your customers in one place. So you can engage with the right message at the right time. What makes June different is that it's made for B2B SaaS. It comes with account level analyses, fast ways to look up your customers, and CRM integrations to share this information between your product, your success, and sales teams. And one line of code is all you need and you're good to go. Sign up for a free trial today. at june.so slash akash. That's j-u-n-e dot s-o slash a-a-k-a-s-h. You get a discount if you use my link. This episode is brought to you by Sprig. What if product teams knew exactly what to build to reach their goals? From increasing conversion to boosting engagement, these challenges require a deep understanding of your users. Something we can't get from product analytics alone. Meet Sprig. a product experience platform that generates AI-powered opportunities to continuously improve your product at scale. First, Sprigg captures your product experience in real-time through heat maps, replays, surveys, and feedback studies. Then, Sprigg's industry-leading AI instantly analyzes all of your product experience data to generate real-time insights. Sprigg AI goes even further with actionable product recommendations to drive revenue, retention, and user satisfaction. Join product teams at Figma and Notion by uncovering AI-powered product opportunities at scale. Visit sprigg.com slash product growth podcast to book a demo and get a $75 gift card. So in order to take higher level tasking to experience, it's not enough to learn a few frameworks and like the theory. So, for example, if you want to create a product strategy, it's not enough to download the product strategy canvas or business model canvas or link canvas and just go from there. You need years of experience to know and understand how to do it well, what are the risks, how the practice is different from theory sometimes. And yeah, so if you take a person just after graduation, without experience and the large language model large language model in many cases or even in most cases will perform better it's true and i think that in an era of gpt5 gpt6 gpt7 i think we'll only see that those models become more and more capable now i want to move to another hot take that you have which you've said talking to customers and creating value for customers is not enough so what is enough uh yeah key thing to understand is that every product has two purposes one is creating value for the customers and as a result you can capture some part of this value for the business and i saw you talk to itamar gilat and he also has some great thoughts on that so yeah and i see that there is this trend that product managers expected to focus more and more, not just on product outcomes, customer outcomes, but also on this business perspective. So how our products, how features we build, not just help our customers, but how they help us build competitive advantage, how this will result in a bigger revenue for our organization, or how it will result in reducing the churn. And if you work with traditional tools, for example, with Opportunity Solution Tree, which is a great approach, you always start with customer outcomes. So those are product outcomes, but they describe changes in human behavior. And then teams are supposed to discover problems that when solved will drive those expected outcomes. But those problems are limited to customer outcomes. to customer problems and customer outcomes, so outcomes that customers care about. So what I like to do is to extend the opportunity solution tree and on the top, we place a problem that the team is currently working on. So this can be product outcome or customer problem or business outcome. And I like identifying not just customer opportunities, but also business opportunities. For example, moving a feature from a lower tire to the higher one. And even though it doesn't create a value for the customers, actually it reduces value for the customers in the lower tire. It is essential to capture more value for the business. So this is the trend that I am observing, that we focus more on the value for the business. And while building and thinking, starting with the customers, we also need to consider the impact on the business outcomes yeah i think it's like a circle so there's like the circle of fashion that everybody knows you know 20 years ago we were in baggy clothes five years ago we were in skinny now we're back to baggy i've seen the exact same trend in pm so when i started in 2008 i don't know if uh many listeners know this but like pms we used to write these things like brds or mrds which were like business or market requirements documents it was business first then we had this huge shift of prds and putting the user first i think google played a big role in this because google preaches like pms must put the user first and so pms kind of had it fashionable to focus on the user but i really feel like the pendulum has swung back to the business yeah at the i believe that at the end of the day so we start with the customers because value for the car i believe that value for the customers and customer outcomes uh are correlated with leading indicators so if you focus on the revenue revenue you cannot track changes in revenue on a daily basis but you can track um changes in customer satisfaction in customer effort score in time to task completion so it is easier to focus on the value for the customers you can measure that you have a faster feedback loops and as a result in the long term Creating value for the customers, improving that value for the customers results in capturing more value for the business. But the goal for every organization is to create value for the business. And also another reason to focus on the customers and why many product managers like to focus on the customers is that it's hard to be excited by the monetary goals. If your goal is to increase revenue by 10%, it's hard to get excited about that. But if you want to help others and you can connect it to your mission, to your vision, it's something that it is much more easier to engage with. Does it make sense? Yeah, it's certainly more motivating to provide value to the users than to move everything from your free plan to your paid plan. So it's something in the middle. But I hear your point here, which is like, creating value for customers is not enough you also need to create value for the business and ideally you're also doing something that is technologically new because otherwise competitors will just come in and copy you pretty much straight away and you won't create any durable advantage so it really goes back to our friend marty who we interviewed earlier this year original thesis which is it needs to be at the intersection of user business and what's most technically recently possible and that's correct okay so another one of your hot takes is we need to balance empowerment with how mature the team is explain uh yeah i mean i've been working in different organizations and in some organizations team were more mature in some organizations that were let's say less mature And what I noticed is that it's very easy to empower, to fully empower trust and the team that is very mature. So people that are used to think about the business perspective are used to talking to customers. They don't need much, like it's enough to communicate the strategic context to explain what are our goals and they can figure out the rest. But when you have a team of juniors, like junior developers, junior designers, I think you need not only to, well, you still need to lead with the strategic context. This still matters. So what we are doing, why we are doing it, why does it matter, how it will create value for the business, how it will create value for our customers. But you But if you give them too much freedom, they can feel lost. And as a result, they are disengaged at work. Yeah, I've had this experience myself where I've worked with more junior either designers or engineers, and I've had expectations that they'll perform like a senior, like with a designer, I can just give them the high level spec. and they're going to totally nail the ux but it doesn't turn out that they're actually able to do that or with an engineer i can give them an 80 complete prd and they'll work out the corner cases i find that the more junior they are the less they're able to handle that ambiguity able to make those product decisions ultimately their product thinking isn't as advanced yeah absolutely and that's why it's important to balance empowerment with at the same time control but not in the sense of micromanaging but rather especially if you are a manager coaching others and helping them understand what are the best practices how to work how to for example if you're working on continuous product discovery how to approach discovery how you can identify assumptions how you can test your assumptions by experimenting uh and we cannot just expect that people will know that and that will figure out everything just after we give them a goal so if i had a junior pm i think it is also important to especially for product leaders to actively work work with those people um yeah and just to coach them so that you can upgrade their skills and eventually coach them until they become competent enough. Yeah, I personally feel like this is part of the reason founder mode is such a thing is because so many founders, especially your series A, series B startups, your PM teams that are less than 10 people, they're not paying for the creme de la creme of the talent. They're not playing for 90% market. They're paying for, you know, 30, 40% market rates. If they're doing that, then they inherently get people. who require more hand-holding, who can handle less empowerment. Yeah, I had the same in my startup. But also in the past, when I was working with junior people, an essential part of leading them was focusing on how to teach them what they need to know in order to be able to perform their work. So we've been talking about the product trio, but I think you have a hot take on the product trio, which is that we don't need a clear definition. Why? Yeah, so first of all, so the product trio, this is a concept by Teresa Torres introduced in, described in continuous discovery habits. And when we talk about the product trio, we typically think about product manager, designer, and lead engineer working together. But even Teresa Torres doesn't say that those must be those three roles so that we so for example if you have a platform team it makes perfect sense to skip the designer or maybe if you are working on some more complex product you can include user researcher or data analyst and for example right now at Ideas I work with product designer, content designer, data analyst, engineering manager, and me. So we have a product Quinted. But the more I work with this concept, and this is my take, I'm not even sure we need to draw a clear boundary between the product trio or product quartet or product Quinted and the rest of the team. And what inspired me about the Lean UX, so... a great book I highly recommend, is that they emphasize the importance of allowing everyone on the team to contribute according to their skills and interests. So what I do right now at my work is that we do not have a close group. Usually we work in the quintet, but every engineer who wants to participate, they can participate. Our channels, like a Slack channel, are open. Anyone can join our discussions. uh sometimes we may work with a product marketing manager depending on what we need and depending on how they are interested if interested in what we are doing right now uh yeah i think it is important uh especially when talking about engineers because this is when the problems here the problem might be uh the most visible is uh not to select just one person and this is our a person selected for the product tree or this is a person selected for for product discovery and all those other people those are people who will just be responsible for coding it works much better when everyone is engaged in this discovery process when people are asking questions about about our goals about they can see our ideas before those ideas are even tested before we present them in the product backlog and also when they are encouraged to challenge ideas during the refinements. So before we put final ideas in the product backlog and before we select them for implementation. And actually right now in my company, it works exactly like this. So not just an engineering manager, but also others on the product team challenge ideas, suggest solutions and participate in different meetings. They are not responsible just for coding. Okay, so specifically within the engineering side, we can't just have one engineering representative in the trio's activities of continuous discovery. We need to involve all of the engineers, or at least all of the ones who want to occasionally be involved. There'll still be those headphone engineers who just want to code. But for anyone who wants to be involved, let's involve them. A final element that I find interesting about the trio is the division of responsibilities. I feel like the division of responsibilities is kind of this underrated source of tension where Teresa wants, you know, the three, whoever it is, you know, we've just said for the engineer, it could rotate, but she wants like, you know, all of them to be at the activities. And I think that designers, they often want to do their own discovery process on their own in addition outside of what the whole team is doing. I think PMs often want to do some wireframing. So basically, in particular with the PM and designer, the lines are not so clear. What do you feel like the division should be there? So there are two things we need to do. The first thing is to embrace this messy nature of product discovery and add feedback loops and visualize that you can transition so that even though there is some logical sequence of steps, this is not a process. And the second thing I would like to fix about the Diamond is that it doesn't represent product discovery well, because the original Diamond by the Design Council ends with shipping features to production and delivering value for the customers. And as we know, in product management, we have those two streams that run in parallel. So for example, Jeff Patton has been talking about and has been a big proponent of Dual Track Agile, but also Marty Kagan currently talks about continuous discovery and continuous delivery. So for me, the double diamond of product discovery is about exploring the problem space, structuring your knowledge, ideating and testing your assumptions by experimenting. And what I call the third diamond at the bottom is about delivering value for the customers. you first plan your work if you work in iterations those are sprints that you have in scrum but even if you work in approaches like kanban there is still some planning phase where you split larger stories to tasks for developers and then you deliver that maybe not in iterations but as that the work flows through different stages so yeah The first thing is to get rid of delivery and separate delivery as a separate stream and embrace that all those phases, all those diamonds are interconnected. So, for example, the outcomes from delivery stream. Delivery stream can inform your product discovery or can inform your experiments. And actually, most of the ideas, even the good ideas that So even the ideas that work usually require many iterations. And even if they are good from the start, you don't want to deliver an entire idea on production. You want to deliver that idea in some smaller chunks to minimize the time to learn. So ship something simple to the customers, get feedback and iterate from there. So what are the biggest mistakes product managers make in discovery? Something that I hear. uh commonly here is claiming that we do not have time for discovery so first of all some people do not understand that discovery is not to take away your time um of course you will be less yeah if if you if especially if engineers contribute to discovery they might have less time to work on the features But the goal of discovery is to ensure that the features that you ship are the right ones. And as a result, you are supposed to deliver more value, not less value. So unless you are measuring the value you create by the number of features, the discovery will help you create more value for the customers and as a result, capture more value for the business. So this is what people really need to understand. Then another type of the problem is limiting product discovery to just customer interviews. Of course, customer interviews are important, but I have seen many product managers who, after starting their work, wanted to discover everything from scratch, like there was no existing knowledge in the organization. tell product managers is that there are a lot of people in your company, like stakeholders, customer success, support, who spend hundreds of hours with your customers every month. And ignoring what they know is a waste. Founders are often deeply knowledgeable about the customer, right? They know the most about the customer than anybody. Yeah, that's often the case. They have spent enormous amount of time talking to the customers doing research market research understanding how competitors work and if a new product managers starts work and just ignores that and i want to now i want to talk to the customers because i know need to understand validate every all the problems and discover it myself this is this is wasteful and the goal of product discovery is to eliminate waste or minimize waste so talking to those people is essential you also need to include insights from product analytics if you have an existing product so many different sources of insight not just customer interviews another problem is a mistake would be doing discovery alone so product discovery is not a task for a single person and we already discussed that that you need to bring different people to the table, people with different perspectives, different experiences, so that they can all contribute and look at the problem from different angles. So that's essential. And maybe the last, I can think of more mistakes, but the last one would be to interpreting discovery as some initial phase that once we do discovery, we can hand off the results of discovery to the team and now we are done, you just deliver it and everything will be great. The problem with that is that first product discovery doesn't eliminate the risks completely. It minimizes the risks, but we... cannot test every hypothesis, and some hypotheses honestly cannot be tested in advance. Sometimes you have such complex features that only testing them with the users or with A-B testing, but you still need to deliver something to perform an A-B test. Sometimes you have to deliver things to production and learn from customers using it. And even if you have performed experiments, This is not the same as people using your product for real, with the real data in real environments. Something on the market might have changed. So it is essential to remember that you need those continuous cycles of discovering, delivering, learning from it and going back to discovery cycles. So it's one thing to understand all this in theory. Can you walk us through an example of a big feature you recently had and the specific discovery activities you decided to schedule and how it looked iteratively? So recently we got an objective about extending the use cases that we want to cover to solve problems of specific customer segment. And from there, Instead of talking right away to the customers, I went through analyzing support requests, support tickets, and the feedback from customer effort score and customer satisfaction score. So the knowledge that was already in the organization, not customer interviews. So I didn't pretend that there is no existing knowledge in the organization. I also spoke, or actually we spoke, to customer support, to customer success. to better understand what customers from that specific market, what problems they have and how we can could best help them. The next step was we actually were able to secure interviews with a few customers, but they only confirmed our assumptions. So there was really not a lot of new learning from those customer interviews. And the next step was bringing all those insights, data, tickets, some trends from product analytics for the product Quintet meeting, where we started with some initial idea on how this problem can be solved. We created a prototype in Figma, a clickable prototype that we were later able to test with the users. And the first step was testing the prototype with internal users. So we just shared it on Slack. within the organization so that we can it is easier it is faster than scheduling customer interviews and then after including the initial feedback we actually tested that with the customers when the customers got us this is what this was a specific type of test when the customer gets a task to accomplish without an explanation how the system works and we track what steps they take in order to to perform this task. And we measure the number of misclicks. We also ask the customer to think out loud. So as they were going through the prototype, they were asked to describe what they see on the screen and how they interpret what they see so that we can understand if there are any gaps in the user experience, in the flows, or maybe something that customers doesn't expect. After confirming, after validating that the prototype works as expected, instead of implementing everything at once, we selected a very small subset of functionality, basically solving the most pressing problem in a very simple way. So not implementing all the additional use cases, some additional filtering. but just a basic happy path that perhaps it it can solve a problem for 70 percent of the customers and shipping it to production so that even though theoretically we could continue with prototypes adding features and making more complex experiments We preferred to ship something on production and just see how customers will use it, what they will suggest. Yeah. So I think that what I heard there is four major steps. So step one, mind your internal company, you know, talk to people at your company, look at customer support, look at data. Step two, go talk to customers. Step three. put an initial prototype out there for your internal users. Step four, do usability testing with your prototype in front of real users. And then kind of 4B, figure out based on that real testing with users what the MVP is that you send to production. Did I get that right? Yeah, in this specific case, yes. And this is the process I like to follow. So before you... talk especially before talking to the customers you need to understand what are your research questions so the questions you need to know to answer to and then based on that you can formulate questions think about questions that you will actually ask to the users so starting with interviews and wondering what we can ask what i can ask this person about it wouldn't make much sense you need to start with something awesome so i hope that helps people understand like From theory to practical, that's what often a discovery process will look like. And what Powell has highlighted doesn't need to take very long. I don't know how long it took you in that specific example, but I remember when I first started product management in like 2008, seeing that four step process, I would think, oh, this might need to take me a month. What really opened my eyes was when I most recently worked at Apollo.io. I would have senior ICPMs go through that process you just mentioned in like four days. You know, day one, internal. Day two, internal users. Day three, talk to customers. Day four, prototype testing. Like, you can just do it that fast. It doesn't need to be this long, drawn-out process. Yeah, I agree. And sometimes you can skip some of the steps. So, for example, some problems are obvious and you don't necessarily. need to test it with the customers. You can just share a prototype internally or sometimes the problem is so obvious and the solution is so obvious that you can skip discovery completely and just deliver things to production. And then you do discovery via having the data in production, though. You don't just stop there. You look at what people are actually using, maybe use some session replays, maybe use some heat maps to kind of recreate discovery, right? And then you iterate in production. Yeah, I'm a bit obsessed about tracking data almost every day. i use heap to understand how customers use our product and the features that we recently released like user funnels the number of events then i um when i see something unexpected i didn't drill down by customer segments or the cohorts to to better understand the trends and better understand how how people are really using it and of course i also have the session recordings I don't do it so often because it is more difficult to aggregate the data. That's true. It is harder to aggregate. But what I like about session recordings is let's say you have like an enterprise account. This enterprise account delivers 10, 20% of your revenue. I always like to go see what the buyer is doing in that account just to make sure that they stay. All right, let's move on. So that's our masterclass in discovery. Do check out his newsletter. He writes a lot about discovery in there. I want to talk about metrics and I really like your framework of three types of metrics. So what are they and how does this differ from how Teresa Torres defines product outcomes? I think we are talking about three types of product outcomes and I get the impression that what they talk about is aligned with. Teresa Torres, especially, she might have mentioned it in her blog. So overall, there are three types of product outcomes. The first one, there's three types of outcomes. The first type is our product business outcomes, so outcomes that stakeholders care about the most, like revenue, churn, market share. And the problem with business outcomes is that the team, specific team cannot necessarily influence them directly. So we need to translate those business outcomes into product outcomes. So something that the team can directly influence. And I wouldn't, I'm not sure I should analyze how Teresa interprets it in details, but okay. At the top of the Opportunity Solution 3, you'll typically have the product outcome, which is, as Joshua Seydan also noticed, this is related to the change in human behavior. So, for example, you can translate business outcome of reduced churn by 10% to customers, click a specific button, or spend 20 times more, 20... percent more time in our app every month so this is something related not to the revenue not the churn but to something that people do in your app and this is something that the team can directly influence and the third type of outcomes those are customer outcomes in jobs to be done they can be called desired outcomes so this is something that customers care about so obviously customers They do not care if they spend 10 times more in the app or if they churn or not. They only care about the value they get from the product. And the three types of outcomes are functional outcomes. So, for example, for a car, it's traveling from point A to B. Another type of outcomes are outcomes related to emotions, like what do you feel when driving BW, when driving Mercedes? what do you feel when driving a sports car and the third type of outcomes are outcomes related to social aspects like how people perceive you or how you perceive yourself when using a product and a great example can be tesla so for example what driving tesla communicates to the others and also what it tells you about your values about your approach to environment And what are the signals that you're sending in the society? So those are the three types of outcomes to simplify. So my follow up question is, I was just talking to a VP of product at a public tech company that's worth about $100 billion. And he was saying that they have this debate going on within their company. So these are a bunch of people who understand what we just explained, where There's this debate that so many product teams are gold on these product outcomes, but they're moving those product outcomes like successfully, but they're not ultimately moving their business outcomes. So he was saying like they're having this debate to give more teams business outcomes. But then, of course, you know, your internal tools, your platform PMs are the first to speak up and say, hey, we can't even directly move the business outcomes. So he's kind of landing within his org around like 70 to 80% of the teams who can move a business outcome even if it is a second or a third order effect that's the key sort of north star metric that they have which is like a business outcome so this is an e-commerce business so they're giving everybody outcomes around aov but At the same time, then we do lose that connection you were just mentioning around product outcomes. So I'm curious, like how do product leaders, how should they negotiate this debate between whether teams should be gold on product outcomes or business outcomes or both? What have you seen in your experience? In my experience, and I wrote about it in the newsletter, product outcomes are not always enough. at the end of the day but the only issue is when setting an outcome or an objective with key results for the team that i would care about is that the team can directly influence that goal and do not obsess whether those are changes in human behavior or not it's not relevant as long the team can directly influence it it's a good problem to solve for the team And for example, actually, I don't encourage people to use outcomes directly. I prefer using objectives and key results, or you can express the meaningful problem to solve and set of key results for the team differently. But anyway, this would be something like the objective that we have, the way it is important and the set of key results. And some of those key results can be related to solving a problem for the customer and others can be related to capturing value for the business. So instead of setting just one metric, one desired outcome, I prefer doing it like you have this objective and key result or any other team objective at top of your opportunity solution tree and you perform discovery from there. and then every customer opportunity that you so every opportunity that you discover you place on your opportunity solution tree must contribute to to the outcomes um yeah the key results related to to creating value for the customers but also they must work for the business now let's move into strategy i think strategy and customer discovery are the two topics i feel like are your like big wheelhouse you're always advancing the thinking of the product field on those so within strategy you say strategy differs from a business model so can you briefly just explain the difference between those two uh yeah sure business model is just about revenue streams and cost structure uh the issue with that is that or not maybe not an issue but the popular business model canvases like business model canvas and lean model canvas they are not just about business model those are strategic tools and they contain many elements of product strategy and so for example so and the strategy is about making choices so in order to win you need to decide why we are doing it so what is your vision what you are trying to achieve because without the vision uh making decisions doesn't make much sense then you need to define uh your customers your market so the problems that people have you need to define um how you are going to solve those problems high level so this is your value proposition and what will be the outcomes for the customers what do they will gain what pains we will solve and finally how does it how it differs from what others on the market offer This can be represented as a value curve, but also we need to think about something that will make our strategy difficult to copy. The Business Model Canvas and Lean Canvas address many elements of strategy. In particular, Lean Canvas addresses the unfair advantage. Business Model Canvas doesn't do that. And as we know, the moment you succeed is the moment that someone else will try to do the same. So I think, yeah, Lean Canvas addresses it better. At the same time, none of those tools addresses the vision. So defining, so to me, defining making decisions without the clear why that you want to communicate. And this is the The basic thing you need to communicate when working with people is why we are doing this. So that's the main thing that those canvases are missing, in my opinion. Well, I think that a lot of PMs get this advice to be more strategic. How can they do that? I would have to understand what being more strategic means because I'm not sure how you can be a product manager. Do not think about strategy. Everything we do needs to be embedded in the strategic context. So you cannot perform product discovery just starting with your objective and not understanding who are your competitors, what is unique about our product, what we are trying to achieve in the long term, how we grow, what are our marketing and sales channels. Those are basic questions. product manager needs to answer. You need to understand how your business works. Because one of the risks you are responsible for is making sure that what the team is building will work for the business. So being more strategic, for sure you need to understand every aspect of the product strategy, of the strategy of the product that you are working on. Also, so maybe what we mean there by being more strategy is actively contributing to strategy. In my experience, strategy is best defined when it is built top to bottom and bottom to top, because it's not something that CEO or chief of product can dwell on. You need people, so of course you need this high level strategic thinking, but also you need to be close to the customers and see, and people being closest to the problems are engineers, are designers, product managers, sales, customer success. So product managers can facilitate that discussion. And in my head, continuous product discovery that we are performing. on a weekly basis, it informs your product strategy. So this is not just one way relationship, like some product leader at the top creates a product strategy and then product managers execute it. It's rather that it is an ongoing discussion between product leaders and product managers and product teams so that the interviews you make, the patterns that you observe in the data. it informs how your strategy, how your product strategy evolves and you provide insights, you provide data, you can identify trends. I'm hearing is like a lot of the important elements of strategy should be embedded in the discovery work that we're talking about, in the business outcome work that we talked about at the very beginning, our very first question, like you can't just be focused on customer value. So if a PM is doing all of that, which let's admit most PMs are not, but if they are and they're still getting this feedback, then really they need to speak up. They need to socialize these insights. They need to be willing to challenge the strategy as it exists today in order to improve it. Yeah, if I got this feedback, I would like to understand what exactly it means because for me, product manager needs to work with strategy on a daily basis. But I can talk about my example. So at Idealus, every product manager is supposed to contribute to strategy. Do I actually not just execute the objectives, but identify some new opportunities, find new use cases, suggest the objectives for the future? So it's not like a... top to bottom management we we actually work on our strategy and contribute to to how it evolves over time yeah but i think that's not the majority of pms if we look at the majority of pms still you know they're in banks they're in hardware companies they're in different companies where they're handed a strategy so if you use the discovery techniques that we talked about even if you're handed a strategy make sure you're speaking up about what you're learning make sure you're shaping what you're building and that's where i want to go next because what is the most heart of product management is i think a topic of debate and i think we also within this conversation have taken multiple sides of this debate so one side of the debate would say hey it's strategy so in fact you'll see like some product managers they're not very involved in delivery Then one side of the debate would say it's all about discovery. Like once you're handed the strategy, you need to finesse it. And those PMs are all focused on discovery. Then another side of the debate would say, hey, it's more about moving metrics. You need to do whatever it takes. I think you have actually said it's about managing risks, which I think then comes more into like once a strategy is defined, once features are defined, making sure that those risks are addressed. How do you think about the various sides of this debate? What is kind of the resolution of this and why is managing risks so important? The most important aspect of product manager's work is thinking about the risks because most of the time we should spend on discovering what to build as a product manager you cannot code you cannot deploy anything to production your work is not to test at least if you work in a good product company you have qa engineers who can do that and if something happens in production unless this is this is if this is a technical problem you shouldn't be involved in that engineers can tackle it themselves so what's left is what happens before delivery And this is product discovery. So the goal of product discovery is to discover the product to build before you start building anything. And so we need to first discover the best ideas, but the key part is addressing the risks related to value, usability, availability, feasibility. Some people have ethics. There are different risk classifications. You can add go-to-market risk, especially for a new product. Because the problem that the product manager or, broadly speaking, product leader needs to solve is that most of the ideas do not work. So we need to identify those few ideas that have a potential to be the good ideas and test them before the implementation. The core what I'm hearing from you is we need to manage risks as part of the discovery process as an input to strategy and some of the more project manager delivery aspects of PM. We need to outsource and empower our developers so that we have time to do those. It's OK. OK, now let's move into prioritizing ideas. So we've been talking a lot about. ideas in isolation strategies in isolation how do you prioritize different ideas what's your favorite method i don't necessarily start with prioritizing ideas i try to prioritize opportunities that we have so those are their customer opportunities or business opportunities so the problems that are worth solving and once we understand what are those opportunities that we want to pursue the most we can prioritize different ideas within those opportunities. I really like Dan Solsen's approach, which is about estimating how important a specific problem is for the customers. So if we are talking about customer opportunity, how important solving a specific problem is for the customer and how satisfied they are with what they already have, and the more important the problem is. the more value we can create and the less satisfied they are with what they already have. Also, the more value we can create by solving the specific issue. Then we need to consider the financial perspective because you might have great problems, but solving this problem, so your idea is too expensive for the business. So I like to include a relative estimation of your ideas and then calculate. This is actually pretty simple. So how much value we can create, so opportunity score divided by the cost of implementing this idea so that we can maximize the return on the investment. At the same time, I avoid calculating this. So this is like a thinking framework for me, but I do not actually calculate that in Excel or in any other tool. There are also other dimensions that you need to include, like how time critical something is for the business, or sometimes you can have a small customer problem, but you can actually monetize it. you, by solving a problem, you make some impact for the business. I've been playing with different formulas and different frameworks, and at the end of the day, right now, I use the ice scoring. So impact, and I just estimate the impact from 0 to 1, 0 to 10. Effort, also relative effort from 0 to 10. Confidence. So what is our confidence that we can achieve that impact? And if we have a low confidence, perhaps we can run an experiment instead of implementing it and then re-estimate our confidence again. And I also don't do it in Excel. I just create this table, look at it, and use common sense to prioritize ideas. So no calculations. Let's move from product management to content creation because there are few people with as swift a rise in content as you. About a year ago, you grew from basically zero to 100K LinkedIn followers in 12 months. Really, really fast, like seven to eight K followers a month. That's way, way faster than I've ever experienced. On notes, subsect notes, your average post gets hundreds of likes. Mine gets like tens of likes. So I want to really break down your framework for content. And I want to start with your hooks because your hooks are really, really good. How do you think about the hook? So the hook is important. It has several functions. The first is to select the right audience. So you don't want to. communicate to everyone on LinkedIn, but to the people that will benefit from your post. So in many of my hooks, I use product manager or PM as a shortcut, just so that people who have a specific problem can understand that this post is specifically for them. The next function of the hook is to communicate the value of the post. You make a promise about something that people will get. And later, of course, in the post, you need to deliver on that promise because you can promise something and not deliver on that promise only several times. And then perhaps the most important function of the hook is to stop the scrolling. So, for example, you can use some numbers or interesting facts or statistics. just so that people cannot easily ignore what you have to say and you have like one, two seconds to grab their attention. But it shouldn't be any attention. You want an attention of people that you are talking to and they need to understand what they will get by reading your post. Awesome. So that's the hook. Now, I think your posts themselves, what is kind of the secret to your how you create a LinkedIn post? It seems like you probably spend a lot of time on the visual aspect of it and how scannable it is. Is that right? Yeah. So I think that when it comes to the even if you write the text only posts, I estimate that most people who click, read more. They actually don't read the post. They just scan the content. They look at the headers and decide whether they like it or not. Like really. Just the main points. And they may decide to bookmark it or share it with others or bookmark it for later and perhaps never it again. So being scannable, easily to scan, easily to understand in terms of the structure is probably one of the most important attributes of a good post and visuals helps a lot because visually you can you can process much more information when you're looking at the picture compared to reading text so visuals helps a lot in that understanding when it comes to that to the text content there is the rule of 4s so short sentences, short paragraphs, short words, and yeah, sentences, paragraphs, words. What is the fourth S? I'm not sure. So basically everything, everything you, all the elements in your post should be short. Like sometimes you can have a paragraph with one or two sentences. Sometimes you can have a paragraph with a single sentence. And also the words that you use, they should be clear, easy to understand. Even if the person has a rich vocabulary, it is much more easy to understand if you use common words. How do you choose your topics for posts? 90% of the time, those are things that are just interesting for me. So I just follow my curiosity. And after... writing the post after exploring the summary then I think how to communicate it to the readers in a way that they will be engaged but I rarely start with the topics like there is no research perhaps I should do that more often I recently do that when writing a post about introduction to AI product management this was initialized by by discovery and research but in most cases i just follow what seems interesting to me i create a substack post and then i convert this substack post to a series of linkedin or x articles Okay, so it's like the hub and spoke model. Your hub is your post and then you have these spokes, which are like your social media posts that support it. Now, what's really interesting about your social media posts is just how successful they are. Like your average post, it's getting thousands of likes on LinkedIn, hundreds of likes on Substack. Are there any elements that we haven't talked about that are driving the engagement of your posts? Yeah, I think it is important to Of course, the time when you publish, people say that it is important. I also noticed that perhaps some times of the day are better than others. But theoretically, Sunday is the worst day to publish. I recently posted on Sunday and got more than 1000 reactions. There is one important element, one more important element that would be just engaging in conversations, especially within an hour after publishing a post. So that when people reply, when people comment, you try to respond. So they are encouraged to interact with you in the future. And after publishing a post, actually for exactly for an hour, at least for an hour, I try to... check all the comments and reply to them if there is something to reply to. All right. So that's LinkedIn. The final element I want to ask about your posts on LinkedIn is your CTAs. How do you think about CTAs? Do you think about links in the post, links outside the post? Most people who post links in the post. they tend to get crushed. They have 500 average likes, they put a link in, they get 100 average likes. That doesn't seem to be the case with your content. Why is that? I think you get crushed when you do that on X, but I have not noticed being crushed on LinkedIn. I'm not sure. Are you sure that others get crushed for links? there might be some penalty but oh that's that's the truth for me so you can just look at my last seven posts my five without links have 500 plus likes my two with links have like 100 likes yeah yeah i'm not sure i don't do anything specific i just yeah i was never penalized on linkedin for publishing links And many of my posts, some of my posts contain 10 or more links and they work as expected. So you need to reach out to LinkedIn. I don't think so. I think like if I had to summarize what are the differences between your link strategy and mine. Number one is your CTA isn't always at the end. I've noticed that your CTAs, you might even have some in the middle. Number two is that you often will highlight free content, not content with a paywall. So when people click on it, they're actually going to go get value for free. And then number three is I think you're pretty generous with your links. You don't just link to your own content. You link to my content. You link to Marty's content. You link to Sean Ellis's content. So I think those are probably three of the things that help your links. Yeah, so first of all, I doubt I can persuade people to subscribe to the newsletter and stay subscribed if they don't know me before. And the way to let people discover what I offer is providing a real value, not just... not only paid links. Of course, some of the links I post are paid and lead to subscriber-only articles. But yeah, as you said, many of them are just to... So how I think about my funnel is that the person should... First, they should subscribe to the newsletter. They should get some value. They should understand what I'm posting about. And only later, they can upgrade to a paid version. I do not care about converting people immediately from the start. Yeah, you have this like, this again, I think it's kind of like Alex Hermosi, Justin Welsh sort of idea where you're giving a lot of free stuff away, you're developing trust, then people subscribe to your newsletter, then you convert them. You're not trying to just like convert them from LinkedIn. No. Yeah, if you summarize it, it was not specifically inspired by those people, but yeah, the first thing is to be trusted so that people can know me, they can understand what they can expect, and only later I can ask for them to upgrade. All right, so LinkedIn is not your only growth channel. We talked a little bit about Substack Notes, and I think there's also SEO. I think those are, are those your... top three channels, is there anything I'm missing? Yeah, there are more, but Substack Notes, Substack Recommendations, SEO, and LinkedIn, those are the most important ones. All right. And I think you've gone deeper on SEO than your average content creator. What have been your learnings over time? What are the people who are just focused on LinkedIn, for instance, missing out about SEO? What are those one-on-one learnings they should get? The great thing about SEO is that it works when you don't on LinkedIn in order to keep people. coming to you, you need to keep posting. And in case you write SEO friendly articles, there are a few pages that get me hundreds of visits and dozens of subscribers every month without me doing anything. They are just indexed high in Google. And for example, my product strategy canvas, it took some time, but right now when you type Product Strategy Canvas in Google. My Product Strategy Canvas is number one. And also when you type something like product management resources or free product management resources, there is a high chance that I will be on the first page. Probably I will be in like 80% of the cases. So, yeah. And if you rely on social media, you need to keep posting it. It requires constant effort and you need to keep investing your time so for seo obviously you need to create content for terms that matter what are what is the other processes do you focus on alt text do you focus on url do you focus on meta descriptions do you focus on generating backlinks how do you what are the other elements that you do focus on when it comes to seo i perform keyword research so this is part of my publishing workflow. So before publishing anything, I open Ahrefs. I have some initial idea of the keywords and phrases that I should use, but I do that research. And I select, this is not rocket science, those are basic techniques, so keywords that have a low keyword difficulty and have a high traffic potential. And I place those keywords, those phrases in the tags, like h1, h2, h3, in the titles. And I also select one of the tags that is aligned with the article title in the URL. So it turns out that it is actually important for the URL to contain the keywords that you most care about. Also, a lot of traffic I got is not from the search text, but from images search. And for that, you need images with the alternative text. And this alternative text needs to include the keywords so that people, when people are looking for, for example, the double diamond that we discussed or product strategy, they will get my pictures with the links to my pages. Yeah. And it sounds like this might be an area you could use AI. I'm actually curious throughout your workflow, from generating topics to choosing a topic, to writing an article, to writing the social media posts afterwards, if that's your workflow, where do you use AI along the journey? Until recently, I used AI primarily at the end to check the grammar, to improve the flow. Grammar, flow, logical errors, statistical errors, it's much better than Grammarly. But I also use AI for ideating. It's not that I have a specific workflow when exactly I use it. But for example, I can upload a series, a list of my articles or another example. Recently, I uploaded a series of questions or topics related to artificial intelligence. I found on Reddit and I asked AI to identify the pain points that people have and the questions that they commonly ask and suggest different post ideas. But this was... more in this ideation phase. I use AI less in the middle, so ideation, the initial research, sometimes I use perplexity, it's not like a strictly defined workflow. Then I usually write an article without the help of AI, and I use AI to check the flow, to improve the grammar. to suggest any changes that will make it more easy to read. And sometimes I accept these changes, sometimes I do not. It depends on the case. And what's your favorite AI? You mentioned Perplexity. Is that the main one you use? Do you use ChatGPT, Claude, Gemini? I use ChatGPT right now. For most of the queries, I use the ChatGPT 4.0. And for those complex searches, when I want to scan an entire article and find any logical or flow issues, I use O1 Preview. And yeah, it's enough. The limits are not that high, but if you only want to validate the end result, it's enough for me. Okay, so you're a big ChatGPT perplexity user. You don't use Notebook, LIM or anything like that? No, I've been using it in the past. I've been playing with Notebook LM podcast, of course, but I don't use it to create content. Okay. So last question related to content is how do you manage your time with a full-time job plus a full-time content business, which is really big, by the way? What are the tools and techniques you use? Yeah, so first of all, I think that what is important here is what I do not do. So I do not focus on delivery. And I am fortunate enough to have a team that can handle delivery themselves. So recently, for example, recently during a big release, I took a few days off and it was not a problem. And I knew that if something happened in production, i'm not a developer i'm not a tester so why they should what they should need me for they can make that they understand the objectives they understand why we were building it and they can make decisions themselves so this really helps me a lot so that i can focus on the discovery part more i automate a lot So, I have a library of custom queries, many of which, some of which I shared, but I also, I often write queries or scripts, like temporary scripts, just to perform specific tasks. Like, for example, to import the data from Gyra to Excel or from Notion to some other system. I'll start GPD for that, to write a simple script, run the script and perform the task. or, for example, to create a report based on the raw data. I write PRDs with the help of scripts and the templates that I defined. I summarize interviews with LLMs. I did with LLMs. Of course, I need to verify the outputs, but I think it allows me to save a lot of time. This episode is brought to you by Dovetail, the AI-first customer insights hub for all teams. Dovetail has always been the go-to tool for teams that want to find insights in customer calls, user interviews, or documents. Now they've stepped it up with the release of Dovetail 3.0. It's three new products and a ton of AI features that make it faster and easier than ever before to truly get to the heart of what your customers want. You can get a real-time pulse on what your customers are thinking with Dovetail's automated feedback analysis platform channels. or pull summaries and insights from every customer interaction your team has ever had using their conversational AI, Ask Dovetail. You've built... ai into all of your workflows to be more efficient and i think that's the key here is your average pm you know if you go look at reddit they're all burned out but i think it's probably because they're not using these ai tools enough they're not creating these custom scripts that they have they're not leveraging the tools or they're getting sucked into delivery it sounds like those are the two sort of big things you do in order to manage your time yeah if you are not sucked in delivery i'm yeah i know that you have said many times that pm has to work in many companies they have to work like 60 hours a week but if you are not responsible for delivery you are not testing your product for me 40 hours is more than enough. It's really more than I need to so that I have time to write a newsletter and at the same time manage the core product team. And yeah, people are happy with my performance. So a lot of PMs, as a part of job searching, they're thinking about the idea of writing content like you and I do. Is that a good idea or not? I doubt it matters. The last time I applied for a job, I was actually minimizing my... In some resumes, I have totally hidden that I create some content because recruiters are not interested in... They don't want a content creator. If they are looking for a PM, they are focused on getting a product manager resume. And you need to... match the criteria and job description and adding some content creator newsletter writer podcaster this can only increase the cognitive load and they are more likely to go to the next resume so i wouldn't do that yeah i think so too i think like the trend to like write content to get a job the only place that might make sense is as a leader And still as a leader, I think you're better off, you know, speaking at conferences or being a podcast guest than you are kind of creating your own content powerhouse. Yeah, it makes sense. And you can also network on LinkedIn. Perhaps you can use your content not to demonstrate the content in the resume, but to build connections or spark discussions. But you can also do it without writing content just by... writing insightful comments under other posts. So that's probably easier. All right. So that's a brief overview of all of these topics that Paolo is an expert in, whether it was discovery, strategy, managing your time, content. Now we're going to move to the lightning round. What's your favorite interview question of product management candidates? I really like asking about how do you know what to build? Because it reveals a lot of, like the entire workflow. So it reveals how they understand the product manager's job. If they understand what discovery is, whether this is only a task for them or maybe others also should be involved. So there are many different things that... Yeah, I think it's very revealing. so you're a voracious reader you've published some lists of your top product management books before we see some books behind you if we're watching on video what's a under the radar book that people might not know but has a lot of lessons for product people i think that the book that everyone should read is directed by alberto savoya and at least for me it was under the radar i read it just last last year and It introduces a lot of new concepts, new ideas, like the necessity to use your own data rather than data collected by others. A specific way to express and test the marketing engagement, this is the XYZ hypothesis. And also it is a great source of insights about collecting skin in the game and how to measure that skin in the game. when testing new product ideas. So for me, it's the number one book for if you want to build a startup and test how people engage with your idea. All right. High praise from you. What's a newsletter you anticipate hitting your inbox? The newsletter or maybe blog I'm waiting the most for is Marty Kagan blog. And even though those articles do not necessarily contain any frameworks or to-do lists or some templates that you can download in your work. They discuss very deep topics, sometimes philosophical. And yeah, like maybe not every, but every second post is something that I can print and hang on the wall. So that's my favorite one. Yeah, they have like a Paul Graham-esque quality for product management. And I heard Marty used your slides in his conference talk in Nigeria this weekend. So congrats on that. What product feature or product are you most proud of shipping? Yeah, I think I'm really proud when I started the startup and we didn't have a product at that time. My first customer. became the biggest Polish airline slot. And we created the SharePoint intranet for them, which allows, and we did it like for crazy money, it was like 1,000 bucks for an intranet worth maybe 50,000. But we got references and it allowed us to position ourselves as leaders in Polish, leader in SharePoint intranets. And dozens of other sales and enterprise customers followed that implementation. So maybe it was not technically. Yeah, it was a simple product, but from the business perspective, I'm really proud that we were able to do that and later build upon that success. Yeah, I think that's the playbook for enterprise is sign like a name brand enterprise client for pennies and then watch all the others sign for your full price. What's one particularly memorable product failure that you learned from? Yeah, the biggest, maybe it was not a single failure, but rather a period where I failed. it was after transitioning from a product leader to a team leader to a project manager because i at first so i yeah first i was a project manager for maybe for two years in my career and then yeah the issue is that as a team leader, I was able to track the people because I was not responsible directly for finances. And as a project manager, actually, I became a department manager, so it was more a program manager position. And I started micromanaging people and as a result, they were disengaged at work and I thought I need to control them even more and specify the tasks. yeah added all those details i was testing software myself as a former developer i was even fixing some bugs in production but the more i tried the the more people were disengaged at work so over time i learned to trust more and i reverted to that previous approach of the team leader so i i learned how to trust how to communicate the strategic context and trust more that I'm comfortable with. But it was a process. So for maybe for two, maybe for three years, I was failing as a leader. So that was probably my biggest failure. I think that's one of those lessons you can hear a million leaders tell you, but until you go experience it, it's hard to internalize. So thanks for being vulnerable and sharing that. Where can people find you online and how can they help you? They can find me on LinkedIn. They can also visit, that's the best place, my newsletter, the Product Compass. So this is productcompass.pm. How they can help me? They can join my community so they can subscribe. They will get access to all my content. My two courses, one course on product strategy, which is called From Strategy to Objectives. And the other one is about... continuous product discovery they can get certified and also my subscribers can join our private slack community where they can interact with me and write me a direct message or network and meet other product people mostly product managers amazing all right guys well if there's one voice i personally turn to When I have a problem, it is Paul. As I hope you learn from this podcast, he has a wealth of insights. Let's go give him a couple hundred, couple thousand more followers on LinkedIn and subscribers to his newsletter. And thank you for being here. Thank you. Thank you so much for listening. If you found this valuable, you can subscribe to the show on Apple Podcasts, Spotify, or your favorite podcast app. Also, Please consider giving us a rating or leaving a review, as that really helps other listeners find out about the podcast. You can find all the past episodes or learn more about the show at product-growth.com. See you in the next episode.

Junior PM roles are disappearing, outdated frameworks like the Double Diamond are holding you back, and everything you know about product discovery might be wrong.

You’ve probably heard of @pawelhuryn —one of the leading voices in product management, with over 70K+ readers on Substack and 177K+ followers on LinkedIn.

This episode is a masterclass in modern product management—featuring cutting-edge frameworks, actionable strategies, AI integration, competitive edge tactics, and aligning product goals with overarching business objectives.

If you’re looking for actionable solutions to modern product challenges and level up your product management game, this is for you.

The agenda:

Intro - 00:00:00
Junior PM Roles Are Done – 00:02:17
Why Talking to Customers Alone Isn’t Enough – 00:07:44
Balancing Team Empowerment with Team Maturity – 00:10:26
Do We Need a Clear Definition of the Product Trio? – 00:17:49
What’s Wrong with the Famous Double Diamond Framework? – 00:22:18
Fixing the Double Diamond Framework – 00:24:04
The Triple Diamond Framework Explained – 00:27:20
The Three Types of Product Metrics – 00:37:44
How Do Metrics Differ From Teresa Torres’ Product Outcomes? – 00:38:13
How Strategy Differs From a Business Model – 00:44:43
What’s Wrong with Popular Strategy Canvases? – 00:46:57
Why Managing Risks Is the Heart of PM – 00:53:06
The Main Types of Risks in Product Management – 00:54:11
Extending the Opportunity Solution Tree (OST) – 01:00:32
How to Prioritize Ideas Effectively – 01:07:16
Why the ICE Framework Is Practical for Prioritization – 01:10:25
Growing 100K+ Followers on LinkedIn in 12 Months – 01:12:38
How to Start a Post With a Great Hook – 01:14:10
Examples of Bad Hooks and How to Upgrade Them – 01:16:45
The Rules for Crafting a Message That Resonates – 01:19:12
Driving Action With an Effective CTA – 01:21:38
Checklist for Creating a Stellar LinkedIn Post – 01:23:42
Best Systems for Growing a Newsletter – 01:27:08
Managing Content Creation Alongside a Full-Time Job – 01:30:46
Tips for Writing Substack Notes That Perform Well – 01:33:22
Adjusting Copywriting for SEO Success – 01:35:18
Top Use Cases for AI in Product Management – 01:38:07
Should PMs Create Content? – 01:40:32
How to Avoid Burnout as a PM – 01:42:44
Final Thoughts on Modern PM Practices – 01:45:12

💼 Brought to you by:

@junedotso: Customer analytics for product focused teams - http://june.so/aakash

@Sprig: Build products for people not data points - https://www.sprig.com/productgrowthpodcast

@hidovetail: The Fastest Way to Understand Your Customer - https://www.dovetail.com/aakash/

📍 Where to find Pawel:

LinkedIn: https://www.linkedin.com/in/pawel-huryn
Newsletter: https://www.productcompass.pm
YouTube: https://www.youtube.com/@pawelhuryn

👨‍💻 Where to find Aakash:

Twitter: https://www.twitter.com/aakashg0  
LinkedIn: https://www.linkedin.com/in/aagupta/
Instagram: https://www.instagram.com/aakashg0/

🔔 Subscribe and like the video to support our content!