Should your roadmap be your product compass? | Pawel Huryn
In Episode 63 of Talking Roadmaps, Phil Hornby interviews Pawel Huryn about using roadmaps as a strategic tool rather than a feature list. They discuss aligning roadmaps with broader company vision and objectives, focusing on customer outcomes over deliverables, and the importance of managing product risks. Huryn emphasizes iterative discovery and validation before committing to features, suggesting that roadmaps are better suited for setting direction than detailing every step.
Author, Product Coach, and Product Manager at iDeals. He has 9+ years of PM experience, including 5 years of running a successful startup. Paweł is passionate about building customer-facing tech products, sharing knowledge, and helping others grow.
He regularly shares actionable tips and resources for PMs on his LinkedIn, Twitter @PawelHuryn, and his product newsletter: The Product Compass.
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
In the next episode we are talking to Greg Prickril, Product Management Consultant, Trainer and Coach. So watch out for Season 1 - Episode 64!
-
Pawel Huryn:
It's extremely difficult to create a roadmap that will contain detailed features before finishing product discovery for a specific set of customer problems. But even after it, you have still have some risks related to how well the team will work together or whether the estimations are correct. So in most cases, when possible, I avoid placing features on the roadmap at all.Phil Hornby:
Welcome to Talking Roadmaps, the channel where we talk about everything road mapping, the good, the bad, and the ugly. Today I'm joined by Pawel. Pawel, introduce yourself.Pawel Huryn:
I'm Pawel Huryn. I'm working as a senior product manager, so this is my full-time job. And apart from the full-time job, I have a product compass newsletter with 57,000 of subscribers right now, I am also posting blogging and talking at the conferences. So you may know me from other, from social media and other places.Phil Hornby:
Yeah, and there's that 57,000 on the newsletter and the 157,000 followers on LinkedIn. There's probably a lot of people who've heard your voice or read your writing before, I'm sure. If you're enjoying the channel, subscribe, hit the bell and give us a like. Pawel, I'm gonna start you off with hopefully a nice and easy one. What's the purpose of a roadmap?Pawel Huryn:
When people start to talk about roadmaps, from my perspective they often mean that this is not the first step, that it's not something that you should start with. For me, the goal of the roadmap is to communicate the strategic context so that everyone is aligned on what they can expect and what outcomes are going to be achieved in the future. There are certain elements like dates that are often quite controversial for product managers, but I think it's worth emphasising that the goal of the roadmap is not to plan the features on the timeline. It has a totally different purpose. To explain what a roadmap is, you really need to start with strategy, with the vision, team objectives, and only then you can dive into how to create a roadmap and how to communicate, what are we going to do?Phil Hornby:
And that's a perfect segue to a question for you. How does the roadmap then relate to the strategy objectives? The bigger picture?Pawel Huryn:
I think we should start from the top. So at the top you have a vision, which is like aspiration for your team and what are you trying to achieve, why it is important, and how you imagine yourself in a few years, and also how it'll influence customers, what value you'll create for the customers. After setting a strategy, product leadership works on product strategy, which is I like the saying of Roger Martin, who defines it as an integrated set of choices that reinforce each other. So those are the choices about the market, about the value proposition, about how you are going to grow, about market segments that you will target at first. Also choices about the things that you want to do, so those are trade-offs because strategy is also about enabling focus on what matters and what doesn't matter. And how you will compete on the market, how you will be better or how you will be unique so that others can easily... Can't easily copy your strategy.Phil Hornby:
If I remember rightly, Roger Martin, that's Playing To Win. So it's how to win and what you need.Pawel Huryn:
Those are the five elements. I also created a product strategy canvas, which a lot of people use, but it is highly inspired by the work of Roger Martin.Phil Hornby:
And so we're taking this strategy and we're boiling it down to a way that we can set direction. So how do we kind of go from those choices and turn it into a roadmap then?Pawel Huryn:
The choices that you make on a strategic level, high level choices, and you can't place those on the roadmap but the output of strategy are objectives for the teams. So this is what Marty Cagan defines even in his last book, Transformed, as team objectives. And team objective is a specific problem. So let's say on a strategic level, you know that you want to address, for example, people who care about watching videos online, and they really care about watching series and not sport events or other kinds of activities. And on a team objective level, you need to define a specific problem that you want to solve and a set of how you'll measure the outcomes. My favourite approach is using objective key results. So objective key results is about setting meaningful objectives, meaningful inspiring emotional objectives, and a set of metrics that explain how you will know that you achieved this, solved this problem or achieved this objective. And with those objectives, we can start working on the roadmap. So those objectives, those same objectives are related either to customer problems or problems for the business. Teresa Torres calls them product outcomes. And she argues that product outcomes are always related to changes in human behaviour. This is by the way, highly influences... Highly influenced by Joshua Seiden, but I think that we shouldn't be... I struggled with Teresa's definition several times. So I would argue that you should just define it as a problem to solve, a set of metrics, a set of results that will tell you how you will... Whether you have solved this problem. And then you start... If this is an existing product, you start continuous product discovery, you may identify more detailed opportunities. So those are needs, those are jobs, those are some gains that you will create for the customer that will... When solved, will drive this expected product outcome or this team objective. And those objectives can be placed on the roadmap. So on the roadmap, from my perspective, it plays either your team objectives or you can place specific customer outcomes. So the things that you will do for your customers related to the objective that you got from leadership.Phil Hornby:
Yeah, funny. In fact, so I often talk about you have those product level outcomes, that might be a change of customer behaviour, it's moving the needle somehow. And then you've got the, I think as Teresa would call them, the opportunities that kind of might be the things that move it. I often get into and talk about user outcomes there, maybe going into... Which more comes from the jobs to be done to kind of thought process of pains and gains, needs we're gonna address. Those are the things that I can start to think about prioritising sequencing 'cause that's how I'm gonna change the customer's world that then hopefully drive those bigger level business metrics.Pawel Huryn:
The important thing about those customer outcomes and of course those outcomes, in most cases cannot be achieved with creating something like a feature, but the point is that when starting product discovery, you do not know, you do not have ideas, you do not have... So first you need to discover those customer problems that when solved will drive the expected outcome, you need to think about ideas and how to solve those problems. And you need to validate those ideas, test those ideas by experimenting, and this happens before implementation. So it's extremely difficult to create a roadmap that will contain detailed features before finishing product discovery for a specific set of customer problems. But even after it, you have still have some risks related to how well the team will work together or whether the estimations are correct. So in most cases, when possible, I avoid placing features on the roadmap at all. There are some cases that... And Marty calls it "high integrity commitments" that the business needs a specific data, some maybe high level description of the feature. I did it in the past, but I did it rarely as an exception, not as a rule. And always stating that this is just an estimate. And really before customers start using what you build, you can't be sure even after performing experiments, even I think working with prototypes, even if you address the feasibility risk by creating some spikes, you can't be sure how people will use it for real. So even those validated delivered ideas tend to not work as expected in some cases. So it's a risk to communicate what exactly you are going deliver.Phil Hornby:
Yeah. I mean I think I typically find it's two or three iterations before it starts to dial in on what you really want to drive, what you want to deliver. I have to say I do... I do quite often put a feature in the Now column on my roadmap, but that's essentially saying I already did the discovery on it, I've gained a high degree of certainty, not a hundred percent certainty but a high degree and we're probably building it. So we're gonna deliver this feature. Whether it'll deliver the outcomes is the question that's left there, but this is the thing we're going to... That we are working on delivering right now, but it's a relatively short time window when we've done that understanding.Pawel Huryn:
Yeah, I agree. And as I understand you mentioned Phil the Now, Next, Later roadmap because this Now column suggests this format. So this is my favourite format, I also use it. For me Now is like the current month. I know that some use the current quarter, next quarter and everything else, but yeah, for me it's up to two, four weeks, this is Now. And this means that we are currently building it, we gained enough confidence and we know that it'll be released. We estimate what the outcome might be, but we'll measure it after releasing it.Phil Hornby:
Yeah. And I think I'd even take away the, is it one month? Is it two month? It gets into the Now column when we're building it. So when we're actually building the feature, not when we're done with discovery. That's the way I work it. So we're even breaking that nominal two to four week window or even quarter window. It's like it might take a quarter to build it, it might take a day to build it, we are building it. In fact, I sometimes even retitle it, that's the delivery column versus the discovery column versus the exploration column.Pawel Huryn:
That's an interesting argument because sometimes you indeed need to deliver something bigger and it cannot be splitted. And even if you can split it technically, you cannot split it from the release perspective. But I feel that's a separate discussion. And yeah, when possible I try to divide those deliveries so that you can release often and learn from customers using what you built. Even if this is not fully released for our customers, maybe release it as a preview or maybe release it only for new customers that just signed up to try your product so that you can get more validated learning.Phil Hornby:
Now, earlier on you said we need to align everyone. So that suggests that there's a multiple people, multiple audiences may be looking at this thing that is our roadmap, and looking at that different content we've just talked about. Who's the audience then? Who are we showing this thing to?Pawel Huryn:
Our stakeholders in the organisation. Everyone who might be interested in your product, who will be affected by what you build. Even there are so those are people like marketing, like customer success, like other departments. And some of them need to... Some them just need to be informed like the chief of product or maybe chief of technology. But other stakeholders also need to plan their work. Like marketing need to prepare some marketing materials. We need to prepare knowledge based articles. Maybe we need to create a series of blog posts related to release. You need to train support. So for all those other people, it's not just about informing them what a specific team or product team as a whole is working on, but also it allows them to plan their work.Phil Hornby:
And so they're all looking at the same artefact, is it? Does it look the same to them all? Have you got the same information onto them?Pawel Huryn:
So it depends. Many teams do it differently. I personally prefer having a very simple high level roadmap and the same roadmap for everyone without hiding anything. Some people used to have a more detailed roadmap, like an internal roadmap with all the tasks and dependencies. I don't find a lot of value in having it, for me, it's just working casually, having a backlog of prioritised ideas. Like prioritised but also ordered ideas and knowing in which order they will be tackled is enough. So I never needed to create like more detailed roadmap with features and a lot of extra details. And the more... I think that the more artefacts that represent the same information you create, the more problems you have later with synchronising information between different sources.Phil Hornby:
And there's the crux of it. Yeah. I have this philosophy that it's one roadmap, but I might have multiple views of the same roadmap. So the same data. But yes, the more artefacts you create from it, then there's a risk that they get out of sync with each other.Pawel Huryn:
Yeah, that's also possible. And many tools allow you to create those views. I just don't feel the need to add those details anywhere because the only roadmap I need, and this is my experience maybe other PMs have different experience, I just don't need those. We can deliver, we can create value, we can sync with others without them.Phil Hornby:
And now interesting, something I picked up that you said is all the internal stakeholders. What about customers? What about external stakeholders? Do they need to see this thing? Do you ever share your roadmap externally?Pawel Huryn:
This largely depends on your approach and on your communication to customers. Some companies do not communicate their roadmap until everything is ready and don't promise anything, but others are transparent about what they're working on. And also some allow customers to... This is a bit tricky because what they really allow customers to prioritise is a list of ideas. So like having a customer community where they can vote and they can then see how those ideas are tackled. Then you need to reverse engineer product discovery to understand the problems that people have and yeah, perhaps suggest an alternative solution. Yeah, I feel there is no one good answer to that question or a solution. I have never used an internal roadmap as tool to communicate with the customers because internally you can say that what we present on the roadmap are estimates, but once you put it on your website, it might be interpreted as, I know that sales often want this information and they like using this information about the features that are not yet in our product, and other competitors have those features but we will have them in a moment. And this is a shiny design, let's look at it together. I don't really like it, but I'm also not responsible for go-to market. I have never been responsible for my go-to market strategy. Any of the organisations I worked in, most of my companies communicated what's coming when we got enough confidence. But those were very high level information, like maybe some screenshots, maybe some rough details for example, that in the next quarter we will introduce new AI search in our product, but without a detailed description because we don't know the details. We just verified that this is technically feasible. We are, for example finalising the implementation. We see the potential, we know that it'll be released so then we can communicate the rough details and let customers know that they can expect it.Phil Hornby:
Yeah. And I think you hit the key answer there on the head at the start. It depends. Like, so I spent much of my career in B2B, and that kind of sharing of the direction with large enterprise customers was often a key part of the sales process. But it's a different thing that I'm showing to them versus what I'm showing internally 'cause of the level of commitment, the level of granularity, et cetera. Ultimately it's a communication tool, right? And you said communication and alignment, and depending on which audience we're talking to, what we might share with them.Pawel Huryn:
It's communication and alignment. At the same time, if you use roadmaps with methods like objective key results, also you have objective key results that should be aligned with each other. And during the, for example, quarterly planning, you align those objectives with the objectives that are the most important for the company for the upcoming quarter. So teams should be already aligned and they should understand what are the strategic objectives for the organisation. Yeah, but you can align them on specific outcomes that first are set as goals, so they might be achieved. And second, how this will influence customers. So the specific opportunities that we will tackle. And this is something that is rarely defined on an objectives level.Phil Hornby:
Yeah, and that's... I always find that OKRs and roadmaps can work super powerfully together. We're essentially saying this is the needle we want to move with the OKR and how we'll measure success. And these are the ways we think in a prioritised way we're going to move those needles over a given timeframe by addressing certain customer needs.Pawel Huryn:
Yeah, so both. So everything that we mentioned is related to communication and related to building alignment. So vision is about communication and about building alignment. Strategy is a tool to align on what is the most important in the strategic choices you make. Objectives and team objectives, this is also a tool to maybe not only to align but also to create focus on what's the most important right now and ensuring that everyone will work towards the same goals even though they interpret it in the context of their specific teams. And then you have a roadmap that creates this alignment. And I agree, this is a communication tool to align on specific customer outcomes that can be achieved.Phil Hornby:
And earlier you mentioned having a prioritised backlog. I'm just wondering how you could... Can you think about how you align those two things, this artefact that is the roadmap and your backlog, how do they relate to each other? And is there anything else at that more I guess executional level that we need to think about aligning?Pawel Huryn:
As we discussed, you have specific outcomes, specific opportunities on your product roadmap. So this might be either a team objective, which is for example, objective key result and the set of key objectives and the set of key results. But those also also might be opportunities that you discover, or jobs, if you use jobs to be done and desired outcomes that you discover during talking to the customers and basically working with opportunity solution tree. So here you have outcomes that can go to the products roadmap. And after talking to the customer, after exploring this problem space and structure, structuring your knowledge about the problems people have, then you can start thinking about ideas that, how to solve those problems. And those ideas are candidates for your product backlog. I usually keep separate product discovery backlog and product backlog because those ideas that result from product... Because those ideas that result from product discovery, those are early stage ideas with a lot of risks, a lot of assumptions to be discovered. And then we need to test those assumptions by experimenting. And once we address the risks, we can move an idea from the discovery backlog to a specific product backlog. When it comes to specific tools, I like using Jira even though it's far from ideal, and many product managers don't like this solution. I think it can be adjusted to your needs and it can serve your purpose. So I usually have one project for product discovery ideas. So those might be draught user stories, some documentation, some assumptions. And then after validating them they can be transferred without rewriting it, without copy anything. Just moving elements from one backlog to another and prioritise accordingly.Phil Hornby:
Yeah, I mean I've heard some interesting good sort of signals about the new sort of Jira product discovery capabilities as well. Haven't used them personally.Pawel Huryn:
Yeah, Jira product discovery, in my opinion, this is not a product discovery tool, it's great for prioritising ideas. It doesn't even have an opportunity layer.... Opportunities layer. So this is just a list of ideas that can be prioritised according to the ICE scoring, but probably you can also implement your own scoring system. And then you can connect it to specific Jira tickets. But yeah, what I'm missing in Jira product discovery is this starting with opportunity, starting with customer problems not starting with ideas. Even though sometimes you can start... I would argue that sometimes you can start with an idea, but this shouldn't be a rule, this is more an exception. If you review the double diamond by design council, they also suggest that this first diamond which is related to exploring the problem space, it's optional, but they highly recommend it. But if you have an idea and you can validate the risks related to value, usability, feasibility, viability, and that you can make sure that it creates value for the business, it creates value for the customers, we can implement it. This means that it solves an important problem, right? But just starting from ideas by default, it doesn't seem like a good approach to me. I get the impression that Atlassian just addressed the needs of many organisations in which stakeholders have some ideas and then want to throw them to the teams and then we can prioritise those ideas and go to implementation. But the risk is that talking to customers and exploring, trying to understand the problems will be skipped.Phil Hornby:
So I totally agree. I think... I mean sometimes the idea or the solution is something you just have to work with. Like there are industry standards, there are the regulations, et cetera. Sometimes it's the right thing, but sometimes it's just the starting point of understanding the problem. So you have to go backwards before you can go forwards quite often I find.Pawel Huryn:
I agree. We do not have always to under... Yeah, sometimes the problems are obvious, like customer wants have a document and wanna to download this document as PDF. So then you can start thinking, you do not need to... And you know that 50 customers requested it. So you do not necessarily need to perform 20 interviews to understand what is the problem. You can take that request and just start thinking about different variants to convert the document to PDF, this is quite obvious, but not all problems that you solve are obvious. And even those obvious problems sometimes seem obvious but after digging deeper, they're not.Phil Hornby:
Even one that simple, right? It could be, okay, we need a PDF, now we've gotta go and do some discovery. We're ready to do the feasibility work and the usability work, we know that the value's there. We still don't know... Because we know that's the needed outcome, but maybe we've also gotta consider the viability. Can we do it economically? So there's still some discovery, some de-risking to work through.Pawel Huryn:
Yeah, 'cause the second part of discovering the solution space and validating your assumptions, one of those assumptions is the feasibility assumption.Phil Hornby:
Although I have to say, sometimes I've found that doing some of the feasibility work earlier can also be super important. I personally wasted a lot of money on products where we knew the value quite clearly from day one and we skipped the feasibility element. We just thought we can solve this, and then found later on, we couldn't. So I sometimes advocate pulling feasibility further forwards in the discovery process.Pawel Huryn:
Just to understand, do you suggest really not starting with feasibility, right? Or starting with feasibility?Phil Hornby:
I'm suggesting figuring out what's the highest risk in fulfilling the need for that customer. Which sometimes is feasibility, sometimes is viability, sometimes is value, and sometimes is usability.Pawel Huryn:
Yeah, I agree. So it all depends on the technology that you use and how would you work with this technology. So if you are building something with artificial intelligence, maybe starting with feasibility and making sure that this can be done at all is the right idea. But if you work on a product and the technology hasn't changed for many years and you are just going to build another form similar to other forms, then maybe feasibility doesn't need to become considered at all.Phil Hornby:
And there what we've got is a proxy for risk or again, for that feasibility... How high that risk is of how long have we been working this space? But sometimes you can get tricked. I'll give you an example. I was working on a product several years ago and we thought that the data set we had in our product and how we could utilise it from historical use that we've been using for 10, 15 years was our unfair advantage, our kind of USP. It turned out we could deliver at the scale we'd been delivering it previously, but delivering it at the scale that was 10 to a 100X larger, we couldn't. And that if we'd have done that feasibility work, we'd have known 'cause the value was quite clear with this scenario but the feasibility was what killed us. And so I know that I should have pulled that forwards. This is one of my learnings of thinking about largest risk first over which is the classic order 'cause I went for the classic order of de-risking.Pawel Huryn:
Yeah, I like how many times I feel we used the "risk" word, 'cause in the past in my posts also, I have repeatedly argued that product management is hard about managing risk and making sure those risks are addressed before the implementation. So like in any risk management technique, you tackle the risks that are the highest first.Phil Hornby:
Yeah, I've even contemplated taking tools from my old engineering world like FMEAs and thinking, can I apply this as a methodology on product risk? Haven't gone there yet, but it's one of those experiments I want to play with at some point.Pawel Huryn:
Yeah, that might be interesting. I like to think about... I'm not sure I should tell you that, say this, but I really like to think what can go wrong when working on a product. And rather than on how to succeed, I focus much more on everything that can go not as planned. Because if you tackle the risks, the success often kind of takes care of itself in many situations. So yeah, I'd first focus on the risks and things that can go wrong, and only later I think about how to succeed.Phil Hornby:
I mean I've more commonly hitting the concept of the pre-mortem for that exact reasons. Like pretend you've just launched your product and it's all gone wrong before we even start, map out why you thought it could go wrong, essentially. Because then you've got a better way of addressing them going forwards and being successful.Pawel Huryn:
A required ingredient of continuous improvement is to retrospect and analyse what went wrong and how we can avoid this. So how we can improve in the future. So those cycles are essential. Hopefully, so if possible it's of course better to fail on a small scale like a failed experiment, it's arguably not a failure because you learn something new, but if you fail with a big initiative, then the cost of the lesson might be higher than what you have learned. But still it's good to leverage this knowledge and yeah, use it in the future.Phil Hornby:
Absolutely. And obviously you could have the post-mortem or the retro. And the pre-mortem coming before kind of taking that same thought process, that same mindset, but applying it in advance so we avoid the risks in the first place can be super... Is something I'm seeing much and much more of. So let's switch gears a little bit, pal. If you have to think about road mapping and best practise, what are the things that come to mind for you?Pawel Huryn:
I think there are three groups of best practises. One is to focus on goals not on the features. So focus on what you will achieve for the company, what you will achieve for the customers, how customers' life will change. So those are the outcomes not the outputs. The things that really matter and the things for which you already start doing something. The second group will be maybe the second good practise is not committing too soon. So you shouldn't commit before starting the discovery. You shouldn't commit before finishing the discovery. So you need to understand the problem, you need to structure your knowledge about the problem. It's not just customer interviews but also leveraging analytics, talking to internal stakeholders. Then you need to ideate about possible solutions and identify your assumptions and test those assumptions. And then rarely you can commit to the output, but if your business really needs a date and some rough overview of what will be delivered, but this is just an estimate and things still can go wrong. So commit as late as possible if you are going to commit at all. And the last thing will be shortening the planning horizon. So even with discovery, I wouldn't commit to something that is like six months in the future because I seem to often too many times that those long term plans virtually almost every time they fail. So rather than planning what you will do in Q2 of 2025, I would focus on, right now it's March. So I would focus on what can be done like in the next one, two months, maybe three months, but three months is already quite a lot. And then you can blurry your planning a little bit. Like those are the things we know that we are going to do next or in the future, but we cannot precise when exactly. And the order in which we think we may tackle them can change. And some of them might not be tackled at all because priorities might change, the business environment might change, something in the market might be different, it's hard to say. So shortening the planning horizon is essential,Phil Hornby:
Not sure I absolutely agree with the last one in certain contexts, but I can see in many contexts it's the right thing to do.Pawel Huryn:
Yeah, like for every rule, every good practise there are... You can find an example when this rule doesn't apply. So yeah, I try to avoid saying always and never in product management. So there's always an exception.Phil Hornby:
So we always like to ask people about advice and resources and so on. Now I can see an interesting looking bookshelf behind you there, Pawel, maybe not a directly road mapping related book, but is there something that you would recommend all product managers go and read and are inspired by?Pawel Huryn:
Most of the books you see behind me are good books and in my newsletter productcompass.pm, in the resources section you can find links to all books categorised by seniority level, categorised by product area, like product discovery, leadership, strategy and so on. When it comes to maybe some best books that I can recommend for a product manager that starts the career, it would be Inspired which tackles product discovery. Yeah, 'cause product discovery is the most critical area for a product manager of an existing product. So how to work together with designers and engineers, how to tackle the risks, how teams start with team objectives. Also Continuous Discovery Habits by Teresa Torres in which Teresa introduced the concept of the product trio and presents specific techniques on exploring the problem space and exploring the solution space, which is an opportunity solution tree. And she also mentions how to identify assumptions that can be tested. Empowered. Empowered by Marty Cagan. This is more for... I would say this is more for senior product managers. Of course, in your PM you can still be interested in how things should be empowered, but if you cannot influence it, it can be just frustrating because you can just feel that you are not allowed to work, that your leaders don't do the job that they are required to do. And as a continuation of Continuous Discovery Habits, this would be Testing Business Ideas best strategies because this is the next part of validating your assumptions by running validation experiments. So this is a good set of three books. And of course, yeah, I can discuss a lot more, but this would be a good starting point. If you are working on a new product, I really like The Lean Product Playbook by Dan Olsen in which then it's more actionable than The Lean Startup. And Dan proposes an organised way to think about creating a value proposition and testing your product idea with the help of MVP prototypes. And also jobs to be done, which it's intended to be addressed to new products, so this is a product outcome driven innovation for new products. But thinking in terms of jobs, it's extremely useful also on working on existing products. Just asking the question, what is the job that customer is trying to do? This helps in discovery a lot. So yeah, Inspired, Continuous Discovery Habits, Testing Business Ideas, best strategies are in The Lean Product Playbook by Dan Olsen, and Jobs To Be Done. This is a good starting point for a product manager.Phil Hornby:
Well, Marty's a previous guest, Torres is a previous guest, David Bland's a previous guest, Dan's a previous guest, and Bob Moesta is a previous guest. So I think we've got a great... I love that kind of space in terms of-Pawel Huryn:
Yeah, if I can use opportunity, because Marty was my guest like a month ago and we discussed his book, Transformed. So I do not have my own book, but if I can recommend a great book which summarises the principles of product model, the model in which the best product organisations work. And I think this is not helpful not only for organisations that will want to make a transformation and want to change the way they work, but also for everyone interested in principles of how product organisations should operate on different levels like strategy, team level, product discovery, product culture, product delivery, so it's summarises it all. But for a new PM, I would still suggest starting with Inspired. And for all others, Transformed is good position.Phil Hornby:
So I saved the hard last two questions till the end, Pawel. If you had to distil your philosophy on road mapping down to one or two sentences, what would it be?Pawel Huryn:
Yeah. In one or two sentences, this would be that you should keep your roadmaps simple. Do not try to complicate things because they do not need to be complex. And focus on the outcomes not on the outputs.Phil Hornby:
What's your greatest road mapping failure?Pawel Huryn:
In the past I've been working as a product manager, and so at the beginning of my career after being a team leader, I became a project manager. So I did all the mistakes that can be attributed to bad product management, like creating detailed roadmaps and yeah, leading with control and all those other things. So yeah, when it comes to roadmaps, I did create a few very detailed roadmaps with features and I was trying to manage risks and manage dependencies and be informed about everything. But I realised that this approach doesn't work and I completely changed my approach. And one of the reasons I got interested in product management was reading Inspired.Phil Hornby:
So I love it. And can I tell you, I've got the same sort of dirty little secret, I was also a project manager many years ago.Pawel Huryn:
A lot of people have this experience in the past, but it's helpful because you can relate to those experiences and you can avoid specific mistakes.Phil Hornby:
And I think there are still some tools and techniques and concepts we can carry over. We still need to get stuff done.Pawel Huryn:
Some concepts, some techniques from product management can be used in product management, definitely, like risk management. And it's not only about improvising, it's not only about being agile and doing everything from week to week, but they would have to start a separate discussion to discuss how you can leverage some project management techniques in product management.Phil Hornby:
So Pawel, we're kind of at the end of the session there, always like to finish off with how people can get hold of you, how you'd like to engage with them, how you can help. Fire away.Pawel Huryn:
Yeah, so people can find me on LinkedIn. I post two, three times a week. Less rarely than before, but I started caring more about posting unique content. I also have a newsletter, the Product Compass on Substack. It's in the top 20 technological newsletters globally. Currently 57,000 of subscribers who read my posts every week. I think the newsletter is the best point to start. A lot of articles are free, a lot of resources like product management templates, recommended books, recommended videos, free courses or special discounts I got just for my community. A lot of things are available without the paywall. Of course there is also a paywalled layer with some deeper insights. And yeah, my premium subscribers can also access Continuous Product Discovery Course. This is my product discovery course in which I explain how to combine the best product discovery techniques. So this is Continuous Discovery Habits by Teresa Torres. An approach of Dan Olsen to prioritising opportunities by importance and satisfaction. And I also combined it with strategized learning and testing cards so that you can plan experiments and you can document your learning. And apart from describing the process and how to perform continuous product discovery and leveraging different sources, not just customer interviews, which is typically the way people work with opportunity solution tree. I also included a Notion template so you can easily start your discovery journey.Phil Hornby:
We'll make sure everything's linked down below in the show notes as well. Pawel, it's been absolutely awesome having you on the show today. Thanks very much for your time.Pawel Huryn:
Thanks for having me. It was a pleasure.
