The World of Product Management

Introduction

Wiktor Żołnowski: Welcome to Pragmatic Talks, a podcast and video series where we discuss startups, contemporary digital product development, modern technologies, and product management. I am Wiktor Żołnowski, the CEO of Pragmatic Coders, the first-choice software development partner for startup founders. In today’s episode, I invited Michał Kania, one of our best product owners. Today, we are going to discuss the topic essential for any startup: the product and product management. We’ll start with the basics by explaining the difference between product and project management. Then, we will dive deeper to explore how hiring a good product manager could help your business thrive. The greatest waste of money and waste of time in software development, especially in startups, usually came from a lack of product management or weak product management. In the startup environment, of course, there are many reasons why startups are probably not doing it in the best way possible. We’ll try to discuss it today, and we’ll focus more on how to do this right instead of all of the mistakes that you can make when you’re doing product management.

The difference between product and project management

Michał Kania: I’m going to start, or we are going to start, from the basics. Let’s discuss, let’s try to define what a product is and especially how it differs from a project. Maybe before we start, we can make it clear for everyone that most startups fail because then it will be easier to understand what we want to say later, and it will be easier to understand why what we are saying is important. So, like more than 90 percent of startups fail. So, the biggest part of the code, of the software that we are delivering, is going to crash. A lot of effort is a waste. So, that’s why that topic is important and that’s why we need to understand deeply the difference between products and projects. So, let’s start from the project. A project has, as in the definition, we can find time, budget, and scope. All of those are fixed. So, you spend time to describe it deeply, what you want to deliver, how much money you need for that, and how much time you need for that. It’s super clear that there is an end of the project. In the product, there is no end. So, a product can fail, and that’s the end of the product.

Wiktor Żołnowski: A project is something different. I usually say that the difference between the product and project is that, as you mentioned, a project is fixed in time especially. Sometimes the scope changes, and according to the PMI and other management approaches, it can change, or some rules could change, but usually the time or budget or both time and budget are fixed. There is a fourth dimension that usually is not mentioned, which is quality, but this is like a side topic, not for today. But compared to that, the product is something that, as you said, doesn’t have an end. It may fail at some point, and that would be the end of the product, or it might be replaced by another product designed and created by the same company. I think that you already mentioned one very important thing: that we can create a lot of software that nobody will use because startups are failing. Even the startups that didn’t fail, they also create a lot of software, a lot of code, that is not used. It just came to my mind that when we are talking about physical products, like, you know, phones and glasses or caps or whatever, or this table…

The problem with waste in software development

Michał Kania: We can easily see if we do something that is unneeded. Nobody is using it or something, it’s very transparent. When we are talking about code and about software, it’s not so transparent. It’s very difficult to notice, especially for people who are not developers and especially if you don’t have any metrics that measure the code usage. You can actually define if the things that you are delivering are used or not. My problem with that is that it’s quite easy to measure, but most companies, most startups, don’t measure it. I know Google measures it. I know Microsoft measures it. How many functionalities, how many different apps that Google provides are used? The percentage of it is not too high. That’s interesting. And we know that they have a lot of money, they have a lot of budget for research, for that discovery process, but still, a big part of their ideas that are developed are not used. From the other perspective, like product thinking, instead of the project thinking or project mindset, product thinking is more focused on the long-term game. Like, it’s more strategic. Even if you have a high budget, you’re thinking not about spending all of your budget because you have a project and you want to have a budget so you can spend this budget. You’re thinking about going to the production, plus validating your hypothesis or collecting the feedback, improving your product, and constantly improving, because there are other companies, there are competitors on the market who are most probably working on pretty similar products and want to replace you. So, you’re challenged all the time, and you need to respond to the market changes. I need to interrupt, sorry.

The danger of a large budget

Wiktor Żołnowski: I see it as a risk if you have too big a budget.

Michał Kania: Because then you’re not hungry. You are not looking for the best options. You are not looking for how to be better, more efficient, and you will produce a lot of waste. A sad budget is a problem, not a limited budget is a problem. It’s easier to make that mistake that you will think, \”I’m safe, I’m secure, we can deliver a whole year or something.\” If you have a limited budget, you need to be smarter, and then you can be more creative, and then you can be more efficient if you are focused more. One of the sins that companies are making very often is that they are not measuring budget and they are not measuring the progress of spending money on delivering software. So, it’s very often that when you’re closer to the deadline or to the moment that your budget is not so big anymore, you’ve spent a lot of money, then you realize that, \”Oh my God, we haven’t delivered anything with value, and we are in trouble right now.\” Actually, this is something that some of our clients came to us with and started the cooperation with us. And we actually very often start in this kind of situation. So, yeah.

Wiktor Żołnowski: And what happened next? And next, what we are usually talking about with these clients is that we tell them that, \”Okay, we need to start with assigning a product manager to actually learn what’s wrong and what’s the problem and what are the possibilities.\” And the funny thing is that most of those people are saying that they don’t need it. It’s a happy path if you are able to find a good product manager there or establish product management there. But if not, what I observe usually is, as a result, they will see that it looks like we have a limited budget.

Michał Kania: So we have scope to deliver, we have time to fix it, so we need to decrease quality. And they try to deliver the same scope with a limited budget, and the quality decreases. And again, maybe someone will not use it because the quality is so poor. That’s the pattern that I see. Yeah, and then later on, it occurs that adding new features, changing something, etc., is even more difficult and more costly. So actually, the budget that was already limited is not enough to actually deliver the end goal.

Modern product development and Scrum

Wiktor Żołnowski: I think that we have already been talking about the old way of doing stuff because in modern product development, it’s pretty different. You are not doing a one-year-long project, but usually, you are iterating and delivering the product to the production many, many times in a way. So you have a working product almost all the time, not at the end of the budget or timeline.

Michał Kania: That’s correct. It should be correct, but let’s start from the frameworks. Like, we have Scrum for, I don’t know, 20 years or more, I think. And there is written that every sprint, we should deliver something that is shippable. How many companies are doing that, actually? Not so many. But any company that is using Scrum and doing it right, they are doing this. In our company, almost all of our teams are doing that. Of course, some products are not released to production and to the end users, but they are potentially shippable, as you call it.

Wiktor Żołnowski: Yeah, and I agree that in that company, it’s true. I observe many times in many companies that they are thinking that they’re using Scrum, they think they are delivering something; it’s not true. So it’s not Scrum. And I think that on the market, kind of average, it is not Scrum. It’s not delivering anything important to the market. So then there is no Scrum, no agile, no product management in a proper way. By the way, in one of our previous episodes, we discussed what Scrum is and how Scrum can help startups and how startups can, or even should, use Scrum for their product management. Don’t forget to check this episode out. So, getting back to the product and product management. So we already have an idea of how the product is different from a project. What is product management about? What’s the main difference between a project manager and a product manager, their responsibilities, and their goals?

Michał Kania: Okay, a project has an end, it’s clear timing. A product, not. So, my focus as a product manager is to focus on how we can deliver more value with less budget as fast as possible. So, kind of efficiency. We have a kind of vision, a kind of a description of our job. My job is to maximize product-market fit and ultimately create as big a revenue as is possible. So, that’s my job. That’s my job as a product manager. And it’s completely different than a project manager because as a project manager, you need to deliver that project with that budget, with that scope. A project sometimes has a goal, so a project manager could be responsible for also delivering the project goal, but at the end of the day, even if the project is delivered and the goal is not achieved, then no one should blame the project manager because the project was wrong from the very first day. In product management, it sounds different.

Wiktor Żołnowski: Yeah, I was a project manager before, and it’s super frustrating when you create the best description for the project, you get approval for that from the management board, let’s guess, and then you start delivering it, and then you learn something, and you know that what you described before is not correct. And there are two options. You will deliver that thing that you promised to deliver, and everything will be good, everyone will be happy, but you are not happy because you know that it’s not the best thing that you want to deliver or the clients need. Or the other option is you need to spend time and effort and create a lot of waste to change your previous decision, to convince the management board that you made a wrong decision and we need to adapt. So, I also noticed from what we are saying that there is a difference between the level of responsibility and also the level of autonomy between the project manager and product manager.

Michał Kania: Yeah, because as a project manager, your responsibility is on delivery. As a product manager, your responsibility is on market fit and revenue. So the strategy is different. So, I think that we are coming to this point where we need to discuss the difference between the output and outcome.

Output vs. outcome

Wiktor Żołnowski: Yeah, like Jeff Patton’s idea. A brilliant video you can find on YouTube or somewhere, Jeff Patton, \”Output versus Outcome,\” to learn about it more. But let’s, let’s discuss it.

Michał Kania: Yeah, so output is what we are delivering. You can see, so output is an application, output is a feature, but the outcome is a change of a user’s behavior. So with that feature, with that functionality, with that application, I can do something faster, easier, more effective, and we can measure the effectiveness of that user. So product management is focused more on the outcome, when project management should be focused on the outcome, but it’s much easier to fall into the trap of output and delivering mostly output.

Wiktor Żołnowski: I would rephrase it a bit. Project management is about delivering stuff, and product management is about delivering change over the world. So what I want to say, your users, they will be more happy because they can do it faster, easier, and that user’s behavior change, whatever the \”it\” is, the \”it\” that your product is solving. Okay, so of course, people are saying that, of course, you can build a product by performing projects on the way. Are there any traps? Are there any issues with this kind of approach?

Michał Kania: As I said before, to create a project, you need to describe it. That description should be clear enough for everyone to make the decision if we want to go in that direction. The description should be clear enough so we can estimate it clearly because someone needs to decide if you want to pay for that or not. And the trap is, it’s not easy to learn in that structure of development because whenever you learn something, you need to explain to those people that you’ve convinced before that you have the best idea of how to deliver it, that you are wrong. It’s difficult for every human to convince another person that, \”I was wrong yesterday or, you know, a month ago, but now I have a better idea, so trust me.\”

Wiktor Żołnowski: Yeah, trust me again. Try to trust me. I’m the project manager, trust me. I’m the project manager.

Michał Kania: That’s good. And from the beginning, when you are a product manager, you need to build trust with the management of the company, someone that you are working for, that you can learn faster. It’s about learning, it’s not about delivering stuff. It’s about learning. When I was a young project manager, I asked my investor how to become better. And he told me a story that he hires not the best-qualified managers, not the most experienced, but those that are learning faster. And that mindset stayed with me because it’s always about learning how we can learn faster so we can then be more efficient.

The role and skills of a product manager

Wiktor Żołnowski: If you could name maybe a few, or maybe one, the most important thing in product management. So what is the most important for product management or in the product manager role?

Michał Kania: Okay, that’s a difficult question because if I need to pick one, it’s communication. But let me explain. I’ll make a research that I grab a lot of job offers for head of products, product managers, from the internet. I try to categorize all responsibilities, all tasks and skills into different categories. And the outcome from that research is 37 percent of responsibilities is about strategy, 21 is about leadership, and 17 is about the delivery. When you think about strategy, you need to be able to grab all information together and be creative, but then you need to act as a leader to keep focus for the whole organization on what you decide and on learning. And then you need to spend your time on delivery to be able to convince those people to deliver the right things in the right way. So everything here is about communication, and only some part is about analytic skills, kind of smart ideas.

Wiktor Żołnowski: So what tools do product managers use for communication or for improving the communication? What tools do you use for that?

Tools for product management

Michał Kania: When you read the books that are shared in our community, they’re about communication. It’s about the visualization of what we’ve learned or what we think. Because, let’s guess, you mentioned about Jeff Patton, user story mapping is really good, and it’s a visual tool to describe ideas on what we want to deliver. It’s a visual tool to discuss what kind of strategy, what outcomes we want to produce, and then what output we need to deliver to get to that outcome. And you can imagine, I don’t know, impact mapping, even event storming is the same sort of communication tool. User stories are communication tools and many, many more. Every tool like that is about communication. And you can work on your own so you can be more creative, I believe, in a visual way, and at the same time, you can communicate better.

Wiktor Żołnowski: Are there any differences between the tools or methods that product managers should use at the beginning of the product development and later on? Like, how do you start product development?

Michał Kania: For example, from the goal. So you need to define and understand what you want to achieve, what kind of human behavior change, and then you need to create a kind of strategy for how you want to do it. And Jeff Patton’s user story mapping is a really good tool to do that. Usually when I start working on some product, I’m starting with something like that. So, a kind of user story map to understand what, how, and what for we want to achieve it. And then it’s super easy to see the kind of steps on the roadmaps because of a limited budget, because of other external topics, we need to convince the investors to get more money to deliver it. So we need to deliver something that we will be able to convince them about.

Wiktor Żołnowski: So, for example, sometimes we need to deliver mockups before we start delivering the software because on the mockups, we can find real users that will want to use it. And then with that information, with that potential clients, we can go to the first investors and look for some money to start delivering any software. So, very early-stage ideation, we can again start with first defining the product goal and defining the features that should be in the first version. Then we can design a mockup, a clickable mockup for that, and then we can test this mockup with potential real users. And based on the test, we can already go to investors and convince them to invest into the product.

Michał Kania: Yes, but what is missing from what you said is when using user story mapping, it’s super easy to find out things that we don’t want to deliver. It’s one of the visual tools that I use on the workshop. Is I like workshops in a physical way with sticky notes. I use a separate color for a card that we try to cover a user story that is not needed now because we can do it manually, because in that stage of the application, users don’t need it, or other topics. So you can imagine if you want to start any application and you can think about a kind of back office for that, usually you can cover with that color, so you don’t want to deliver them in the first few stages. It’s not important because you don’t have enough users to do it, so it will be a waste instead of delivering something that is important for the users.

The importance of scoping and time to market

Wiktor Żołnowski: To make it simple, like one of the jobs of the product owner is to cut the scope or postpone some things that don’t need to be done at first. So at the end of the day, we can deliver the product to the market faster. So time to market is one of the measures that we should observe when we are talking about product management, is it correct?

Michał Kania: Yes. When I think about my productivity, my value that I’m delivering to the product is focus on the things that are important. So I can measure how many user stories I move to the trash or for later, that long later, let’s call it like that, never ever in the future. I literally measure it on the workshop. It’s super clear when you have a lot of cards on the wall, and I organized many workshops that after the workshop, we see that we need to deliver only a few user stories to check if the idea is correct. So before the meeting, we thought that we need to deliver, I guess, 20, 30 big user stories to create the product, and then we discovered that only three of them are important. Everything else can be done later.

Wiktor Żołnowski: I just recall that many of our potential clients or clients came to us and asked for the estimates for their project. And what we often do, we offer them to do the scoping workshop or product kickoff workshop with us just to do what you described. And very often, I overheard stories that they came with a set of requirements, and you or others of our product managers were able to decrease the scope by even 90 percent. So the question about all the price, cost, estimate, or whatever was totally irrelevant if we found a way to go to production for the 10 percent of whatever the price would be, because we decreased the scope by 90 percent. And by that, we could deliver 10 percent of functionality that delivers way more value than 10 percent. Usually, it’s sometimes comparable to 80 percent of value. What’s the most important, delivering that scope to production usually brings new ideas, brings feedback from the market, so founders and other shareholders could make a better-informed decision instead of guessing what users will like and what users will use. They can make a better-informed decision on what is actually needed and what should be done next instead of just guessing.

Michał Kania: I have a problem with what you said because it’s true. That’s my problem, literally. It’s about 90 percent of waste in the previous scope. That’s usual. But my problem is that the world is working that way.

Wiktor Żołnowski: Yeah. So usually when I’m discussing with the client and he tells me that, \”Okay, we can do it that way, but I can go to another software company, software house, and they will deliver it for sure.\” And that’s the problem. We are generating more unused code in our world, and I don’t like it. It makes no sense. Like there’s a problem with the market. Like most of the software delivery companies, even our business model, is based on the hourly basis. So the more hours we will work, the more hours we will charge the customer, the more money we will earn. But it’s not the point, because our mission is to play the long-term game and build the partnership operations with clients, not the short-term delivering projects.

Michał Kania: Yeah. It’s a lot of waste, and if you are looking for how to deliver more, you need to cut the scope because you don’t want to, let’s go back to outcome and output. You don’t want to deliver as much code as you think you need. You want to deliver outcome, and that outcome will produce impact for you, so kind of revenue.

Wiktor Żołnowski: There are like a few different types of clients who we’ve spoken to. Those are the best clients, especially those who have a limited budget but have this capability to actually increase this budget. I mean, raising new funding, growth, or finding investors, and etc. Those are the clients that I would say that we love because with them, we usually work on the products for a very, very long time, despite the very limited budget. And by limited, I mean like a hundred thousand dollars or something like this, or even a little bit less.

Michał Kania: Yeah, because that forces you to be smart. And then if you have a limited budget, the creative work starts. You need to think, you need to be smarter than others, because if you can think about your startup as you have the best idea, every startupper has the best idea, why Google didn’t deliver it? What they don’t have that you have? It’s a limited budget, it’s creativity, it’s the ability to learn and the focus. Because of that lack of focus, because we have too much budget, we are delivering too many things. So usually then you realize that there are too many things. You need to have more developers to maintain it. You need to have more product managers to focus on delivering, and still, it doesn’t bring any or too low revenue because there is no focus.

Wiktor Żołnowski: For example, when I hear from our clients that they have like a huge budget and the deadline is a year from now, I know that it will be a failure. Like 90% of the time, that will be a failure. So it’s a way you shouldn’t build a software product because it’s so easy to add waste to software that without any limitation, any borders, you will most probably add this waste to the product and waste a lot of money, burn a lot of money on things that won’t be used at all. Okay, so let’s imagine the situation that we have a software development team, a product development team that has a product owner that is not a very good product owner, or a product manager that is not very good or who is missing some product management competencies. And we have a team without any product manager at all. Which one do you think could be a better team and which approach will be better: a team with a product manager who is not a good product manager or the team without any product manager?

Michał Kania: Both situations are quite difficult or not correct. But in the first situation, you have a weak product manager and maybe you don’t know it. So maybe you think you are doing it in the right way because it’s possible and it’s okay if you don’t know how to measure if he’s productive, his productivity. From another hand, if you don’t have any product manager, it will be clear for you that something is missing. So it will be easier to fix that issue that you have in your organization. Your developers, if they are good, they will ask the right questions. You will be able to clearly see that you don’t have answers. So if you don’t have answers, you see the issue, and then you can fix it. So I think if I were to choose, I would choose a lack of a product manager at all, so it will be more transparent. So you cannot pretend that you are doing product management. You can simply say, \”Okay, we have a problem because we don’t have product management, and we need to set it up.\” So, for example, developers came to you and you realized that you cannot ask the question of why we are delivering that feature, what for? And if you don’t have an exact answer to what’s the goal, you can observe that there is a lack of product management in your company.

Wiktor Żołnowski: How would you respond? I’ve met a lot of founders who are saying that they are the ones who are doing the product management job and they are CEOs, like solo predators. So there are no other people in the company. So they have a lot of responsibilities, and then they focus on product management. They are saying that they will do this job. What would you recommend to them?

Michał Kania: I do have an answer, but I want… It looks like it is a smart decision because you as a startup, you don’t have too much money. So you need to be smart, you need to deliver a lot of different things. So instead of one product manager, you can hire one developer, and I guess it’s true. So then you can cut more trees. Let’s use that analogy. But you are not sure that you are cutting the right trees. Another problem with that is that because you are focusing on product management–so strategy, leadership, and delivery–you are not focusing on your organization.

Wiktor Żołnowski: Your organization needs to grow. Your job as a CEO is looking for investors, for more resources so we can grow faster. It’s impossible from my experience to do it in one head. It’s too much work. Yes, I definitely agree with that. At the end of the day, the CEO who is trying to do product management has no time to be a CEO. And that’s one of the reasons why often such companies fail. I can imagine a situation that we have a CEO, a product manager, and no developers, and we are still able to deliver something that is important to the market, which is not so obvious.

Michał Kania: Yeah, but the opposite way, that we have a CEO and developers without product management, it’s close to impossible because someone needs to think about what we are working on. And if you are a developer, it’s hard to think in that way. As a developer, you think about solutions. As a product manager, you are thinking about problems. As a CEO, you have thousands of brilliant ideas that you want to bring to life, and no one is stopping you if you don’t have a product manager…

Wiktor Żołnowski: …who is focused on actually delivering to the production as fast as possible and cutting the scope. So I think that this is the greatest value of a good product manager in a startup team. But you know, from what I heard many times, and I remember that you told the story as well some time ago, that from the CEO’s perspective or from the founder’s perspective who has this limited budget, looking at the situation and, for example, hiring a team of three developers and one product manager instead of four developers, from, you know, a delivery perspective, doesn’t make any sense because four developers would definitely deliver more code.

Michał Kania: I agree. Like, you know, 25% more code than three developers and a product manager who is not coding. So what’s your response to that?

Wiktor Żołnowski: The question is if your client pays you for code. So, I mean the users. If your users are paying you because you have a lot of lines of code, usually not. Usually they don’t care. And that’s the truth. Usually they don’t care. They don’t care about many different things, about processes, about many different things. They only care about what they get from that product. So from the outcome, as Jeff Patton said in his book, in his stories, you need to maximize the outcome and minimize the output because then you can be more focused, then you can deliver the right things. Like many startups, founders, managers, whatever, they are talking about product management, and I believe that they are mostly talking about it. Not everyone or not many of them are doing it right. Product management for startups is like teenage sex – everyone is talking about it, some of them are using that, and only a few have real experience in that. So this comparison is maybe not very good, but sometimes for me at least, from my perspective, it looks like that. Startups are talking about product management, but then when we dive deeper, when we actually go on board, we see how they do that, it occurs that what they are doing is some kind of management which is definitely not the product management.

Hiring a good product manager for a startup

Wiktor Żołnowski: How to hire a good product manager for a startup? That’s the real question, because especially founders who are not experienced in product management may find it difficult to find the right person to do the product management for them.

Michał Kania: Before I answer that question, let’s go to the digression that you made. I make research about the job offers to understand if the market understands who is a product manager, who is a head of product. And from the job offers, understanding is correct. But then if you join basically any company or most of the companies, kind of an average company, the focus is on delivery, usually only on the delivery. And that’s wrong. That’s against the job offers that those companies create. There is understanding, but they are not using the knowledge that they have. That’s the problem.

Wiktor Żołnowski: Already different people are writing the job offers and those who are later on managing those people who are hired, especially in corporates.

Michał Kania: Yes, it could be the case. But if you are the CEO and want to hire someone, I guess in bigger companies, someone would prepare a job offer for you, but then you will approve it. But after that, you expect something different. And on the job offers, strategy and leadership, and then delivery. In reality, it’s the delivery.

Wiktor Żołnowski: Delivery and maybe you will be allowed to talk about strategy or consult the strategy.

Michał Kania: Yeah, that’s the problem. Okay, so that’s the problem with the market, with the way how organizations, how startups and bigger companies are perceiving the job of product owner or product manager. Let’s focus on hiring product managers. So how to hire a great product manager for a startup? It’s super difficult because it’s not about knowledge, it’s less about tools, it’s about mindset. So let’s go back to that story that I told you when I asked the investor – he’s hiring managers that are learning faster because you want to deliver something that doesn’t exist on the market. So you need to learn faster because if you want to create a grocery shop, you can learn how to do it from books.

Wiktor Żołnowski: Or just ask someone who already opened one.

Michał Kania: Yeah. If I want to hire a good product manager, I will ask him, that’s important, how to measure good product management. And depending on the response, I can make the decision.

Measuring a product manager’s success

Wiktor Żołnowski: Okay, so how to measure a good product manager?

Michał Kania: That’s difficult. That’s why I’m asking that question. And as I told you, my vision is to create product-market fit as fast as possible and then ultimately focus on the revenue. So how to measure a good product manager? Revenue with product-market fit. But the problem with those metrics is you need to wait too long to measure it. So to measure increasing revenue, you need to wait months, and you want to have that decision quite fast because if you make a mistake, you will probably lose a lot of money. So we can measure learning. We can measure time to market and time to learn. These are two important metrics. And we can measure how efficient that product manager is. So as I’m measuring the quality of the workshop, how much scope I can cut to deliver the same outcome.

Wiktor Żołnowski: So cutting the scope is one of the metrics. You mentioned measurable learning. What do you mean by that?

Michał Kania: Let’s use an example. As a product manager, you make a lot of decisions, like, \”Let’s do that feature instead of that.\” So if you decide to make that feature and if your time to learn or time to market is short, let’s guess one month. So after one month, you have it on the production. After another month, you can measure if your expectation before you made the decision, like your expectation was after one month of being on the production, let’s guess a thousand users will use it. You can measure it after two months. If your time to market and time to learn is short, then you can learn. And then as a CEO, you can observe your product manager to see if he’s making the right decisions. So if his assumption was a thousand users and the outcome of that or the impact of that is a thousand users and that was the right estimation, you can expect that another decision will be also good. But if they are wrong one time, that’s okay. But many mistakes like that mean that something is wrong. So of course, it’s good to allow people to make mistakes, but not all the time. If you are doing the same thing the same way all the time and you are expecting different results, it’s not about learning.

Wiktor Żołnowski: So measuring product managers, product owners, by time to market, time to learn, reducing the scope–those are the three basic metrics that you should add when, for example, you hire a product owner. Already by asking him how to measure the product owner’s job, and by that, you can define if you hired the right person after, let’s say, three months.

Michał Kania: Yeah, on the strategy level, yes. Because that’s the strategy. We want to make the right decision to deliver the right thing and to create the impact that we expect. Another metric or measurement that you can try to adopt in your organization is about focus, how to measure leadership about the product. So you can ask your developers if they clearly understand the strategy, if they clearly understand what and what for we are doing, how we want to beat the market. Because as a product manager, you make big decisions, but as a developer, you make thousands of small decisions every day, and these also have an impact on that strategy. So they need to know what decision they need to choose. So let’s guess, if they don’t know how many users you expect in the end, they will produce something that may work for 10 users per hour because there were no requirements. It is not correct because you expect more. Or from another hand, they can create something that expects millions of users, and it’s too big. So they create a lot of waste, so on the infrastructure, on the code, and the quality, etc. So you need to be clear on that communication with developers, on communication with sales, with marketing, everyone here on the delivery side has to be aligned. But your stakeholders, so it’s again about leadership, need to be aligned. It’s transparency, the way the product owner takes care about the product backlog, the requirements, how they are defined, described, and then explained to everyone.

Wiktor Żołnowski: Yeah, transparency is a tool. So what I want to say, my definition of transparency is I can see what I need in that instant to make the right decision. So transparency on the backlog level, I know what to choose for the next iteration because I know what we want to achieve. On the strategy level, I clearly see where we are, what the decisions are right now, and what to change if needed. On the business level, you need to see where we are with the budget, so how much money we need to raise or how much money we need to spend here because maybe we have enough money to increase the spending money on sales, let’s guess, so we can gain more users. So everyone should be aligned. That’s why transparency as a tool for communication is super important. Okay, so I believe that those are also topics that are very useful to be covered during the interview when you’re hiring a product owner, product manager. Also, one thing that you already mentioned that reducing the scope, like the way we are testing it during the interviews, is that we actually work with product owners, product management candidates, on the real, let’s say, backlog or a set of the requirements for some imaginary app. And we ask them to plan the release of this app, and they could use whatever tools and methods for product management, backlog management, they know what they can use. But at the end of the day, what we are looking for is someone who is really able to cut the scope to the minimum and then deliver something that makes sense to the production.

Michał Kania: By cutting the scope, it could be, I hope not, but let’s make it a bit more clear what does \”cutting the scope\” mean. Because someone can understand that we are not delivering the stuff, and that’s partially true. But cutting the scope means that we will still deliver that feature but a bit smaller, a bit less functional, or later. That’s also cutting a scope because still, as a software company, as a software startup, you want to deliver some code, but only the code that matters, that users will use, and it will change some behaviors.

Wiktor Żołnowski: I believe that answers the question, what’s the greatest value of a product manager? Because I hope that everyone knows that in software development, the most costly part is software development. Like software developers are costs. Of course, they bring some value, but they cost a lot. And if we can reduce the time of software developers needed to develop a product, then we can reduce the cost in probably the most efficient way. So this is why product management brings value to the table for startups especially, but to any company that is building software products. Good product management can reduce the cost and increase the value that is delivered at this cost.

Michał Kania: The problem with what you said is that for most of the companies, this doesn’t matter. So it’s possible to measure how much money you spend on delivering something and how big an impact on your market share or on your clients it makes. And lots of companies don’t compare those two values with the impact, how many users we gain, and how much money we spend on developing that. It is a problem because then you are not learning, because you spend probably too much money on something that brings no impact or too little impact. And then because you are not measuring that, as a part, you are not measuring how much time you spend on maintenance or making it work, keeping the lights on. And maybe here you have a lot of waste. I mean that the features, the functionalities that are not used, they still require some maintenance. Even the ridiculous things, like, for example, our code library needs to be updated because there were some security issues, and someone needs to do this, and someone needs to spend hours on that, and that costs.

Wiktor Żołnowski: That’s one cost. It’s not a big deal or it’s not as big a deal as what I want to say. The biggest deal is that you have part of the functionality that only, let’s guess, a few percent of your users are using. And whenever you want to deliver something more, you need to think about how to connect those two functionalities. So let’s guess you are creating calendars and you have a communication tool, and that communication tool is used by five percent of your users. I think that is also a really good metric for the product owners who you already hired and you have in your organization, if they are removing any function from the application.

Michał Kania: Yes, that’s a really good question to ask your product manager: \”How many functionalities you removed from your previous product?\”

Wiktor Żołnowski: Oh, yes, from the previous products. It’s a great interview question you should ask.

Michał Kania: So in that example, whenever you want to improve your calendar, so add new features, you need to think that maybe some users will try to discuss that, and you need to connect those two features. And it’s hard to make the right decision to avoid that discussion. That discussion is a waste because if nobody is using that, maybe nobody will use that new feature that you want to improve your core functionality, let’s guess it’s a calendar. And you’re wasting time to discuss how it should connect, and then your developers will waste time figuring out how those things should connect.

Wiktor Żołnowski: And it escalates pretty fast. Like you have a simple thing that needs to be discussed with many people and each of them spend an hour. You have 10 people in a room, you have 10 hours.

Michał Kania: Yes, that’s one visualization of that escalation. But from the other hand, as a CEO, probably you observe that before, you needed, for example, two weeks to deliver something, and now you need four weeks. What happened with your organization?

Wiktor Żołnowski: Or two months.

Michał Kania: Yeah, more often, yeah. So you see, as a CEO, you are going slower and slower and slower, and you don’t know why. And that’s because you didn’t remove unused functionalities. So you have a lot of things that the product managers, developers need to think about, and it’s not worth to think about them. That’s brilliant, to actually focus on also removing stuff from your existing products.

Scaling product management

Wiktor Żołnowski: Okay, so last but not least, let’s talk about scaling, about product management at scale. Since some of the startups who are not failing at the early stage, they are growing. And how to deal with product management when your organization grows, when your startup is growing, when you hire more and more people? Should you be hiring more than one product manager or maybe not? Maybe one is enough? How to help such a person to perform the product management? How does it work for bigger organizations?

Michał Kania: Before we think about scaling, we need to ask ourselves if we need to scale. Because as we said before, most of the parts of the system usually are not used. So maybe if you remove that, maybe if you have less code, less maintenance, maybe better quality code, then you can deliver faster and your current team is good enough. Or maybe I work with some kind of clients that have too many people because the problem with many people is that, or many developers, you need to deliver them a lot of scope to deliver. Maybe it’s not worth it.

Wiktor Żołnowski: Everyone will be busy.

Michał Kania: Yeah, and because you are paying a lot of money for that, you want to keep them busy. So if you hire, let’s guess, too many mobile developers, you want to keep them busy. And it’s probably a waste because if they develop something that is not used, someone needs to review it, so it’s a waste. Someone needs to deliver the scope, it’s a waste. Someone needs to test it, it’s a waste. Someone needs to integrate it, measure it later on. It’s a lot of work because you have, for example, too many mobile developers.

Wiktor Żołnowski: What you want to say is that product management is about not scaling the organization if it’s not needed.

Michał Kania: If it’s not needed, yes. You need to keep it as simple as is possible. But there are some cases that you need to scale because the complexity of the problem is so wide, or maybe the problem itself requires too many integrations or something like that. And you need to be smart here because if your current organization before scaling doesn’t work correctly, you cannot expect that if you bring more complexity, more problems, basically, it will fix automatically. It will be worse, always. So before you scale, you need to clean everything to be able to scale. And then you ask another question: how many managers you need and how to scale? And I experienced that at least three times with success, that Large-Scale Scrum is the best way to deliver software easy and fast without adding those many steps, without increasing your time to market, without increasing your time to learn. So if you want to learn, if you want to be fast, it’s in my opinion the most efficient way.

Wiktor Żołnowski: I think it’s a good idea to do another episode about LeSS itself. It’s a great tool, and I think it will be very valuable for any startup founders who are later in their product development. They’re already growing the organization, already grew their organization, and are trying to find out why they are much slower than they used to be, despite they are spending way more money on the current software development than they used to.

Michał Kania: It could be, but we need to start with something that is built in LeSS, in the framework, is a kind of technical excellence. Because if you scale something that is not correct, it will be worse, it will be more problems that you can imagine.

Wiktor Żołnowski: That’s the same with Scrum, that LeSS is also based on Scrum. If you have teams that are not working in Scrum, you need to start with Scrum, and then you can find a way to implement LeSS. Otherwise, you will only ask for trouble.

Michał Kania: Yeah, that’s why I agree. It’s good to record a video about LeSS, but we need to start from how to avoid scaling if it’s possible. And then if technical excellence is correct, if product management is correct, then it’s a place to scale.

Wiktor Żołnowski: That connects perfectly with one of our previous episodes about Scrum. Now we are talking about product management and talking about LeSS, which actually requires both great product management and Scrum implementation and technical excellence. So the next episode will be about the technical excellence, and then we can combine all three and talk about bringing it to scale, if needed, of course. So getting back to that. So let’s say that we are already in this place where we have great product management, we are using Scrum, we have this technical excellence, and we found out that we need to grow because we need to respond to the market faster, we see new opportunities, our domain is complex, it’s getting more and more complex with time. We need more people. So should we hire more than one product manager or not? Most companies that I observe are thinking that way, that we need to deliver more in the product, we grow, we have a lot of users, so we need to deliver more in the back office, so let’s speed up here.

Michał Kania: And that’s the worst case. So, from the product and the back office of the product, almost every product. And it’s the worst case scenario because, let’s imagine, like the previous story about mobile developers, you have too many mobile developers, and because they are not able to deliver anything except for mobile, so you start delivering things that are not used. And you spend a lot of time to integrate, test it, etc. In that case, if you split that way, in some cases you will see that you want to deliver something on the product and it’s not used on the back office. So you have teams that are working on something that is not important right now, so you are generating waste. And sometimes from the other side, you deliver something on the product side and you need to go here to be more focused, so you deliver something on the back office, and they generate waste. And it’s not a waste of one person, it’s a waste of the whole team or many teams. It’s a lot of waste.

Wiktor Żołnowski: A lot of money.

Michał Kania: A lot of money. So LeSS recommends splitting it in a way that you still have one product manager, a really strong, decisional person that can make decisions fast and be responsible for everything here. Then you have teams that are able to deliver something on a product, in the back office, on mobile, wherever it’s needed. And then because you have one product manager, one backlog, you can split that backlog through those three teams. Each team, let’s guess, two, three, five, have the ability to take each row from your backlog. So the most important topic, they are always delivering in parallel. It’s not the case that you are delivering something that is not important to avoid the bigger waste.

Wiktor Żołnowski: So the key is like a true cross-functionality of those teams and also like every team is able to deliver in any part of the system, which means you have collective code ownership in place.

Michał Kania: Yes, it’s like Scrum but more difficult. And let’s make clear what collective or cross-competence doesn’t mean. I don’t want to say that every team, let’s guess your organization grew, you have eight teams, I don’t want to say that every team can take everything because then you need to teach them every domain, they need to learn every part of the system. Maybe it’s too big, but some cross-functionality is needed. So like in typical Scrum, you have mobile developers, you have developers focusing more on the back end, on front end, but still, they are able to work in parallel. And they are able, let’s guess, if we have not too much on our mobile side this sprint, someone can take more code review, more testing, or whatever. They are able to work together fast enough. And with the teams, if you have eight teams, some of them are able to do something on that part, on that part, and then as a combined, you still are delivering the most important topics. So we can observe it, if you have proper teams or enough knowledge sharing in your organization, if you still can with those teams that you have deliver everything row by row in the set order. If you need to jump, something is wrong.

Wiktor Żołnowski: So actually the scaling is also all about good product management. If you are good in product management and you have this technical excellence and the right process in place, actually you don’t need more than one product manager. Maybe that’s the conclusion of that. Of course, it’s not easy to get there, but it’s definitely possible if many components are doing this.

Michał Kania: It’s not easy. It requires a lot of automatization. So yeah, a lot of automation in the tools that you are using. It requires a lot of analytic skills in a team. So basically, if you have one product manager in a bigger company, you push a lot of responsibilities to the team. So we are thinking about strategy, we are thinking about leadership, and they are delivering the right thing. You just put the directions. So I like to talk to our developers that there is only one requirement in a user story, it’s the user story itself. Everything that I prepared more, except that sentence, the user story, is a kind of suggestion. If you can imagine a better solution that I prepared, please do it. The question is if we fit the user story.

Conclusion

Wiktor Żołnowski: Okay, so I believe we covered all of the topics I wanted to cover today. Is there anything else we should talk about in product management? Anything on your mind?

Michał Kania: It’s a wide topic, so it’s hard to answer. Let’s stop here, maybe in the next episode.

Wiktor Żołnowski: Yeah, I believe that there will be more episodes on the product management itself, on the particular parts of product management as well. And I believe that there are a lot of things that we can, we can share as well. So thank you very much for today. And we invite you to subscribe to our channels on YouTube, Spotify, Apple podcast. And of course, stay tuned because soon we’ll release even more episodes about product management, about how we work, and and we’ll share our experience with contemporary startups development. Thank you very much.

Michał Kania: Thank you.