About product tools, a very opinionated piece. In a current project, I was asked to tell a little bit more about the different tools and processes that you use when you develop a product and when you manage a product. And so, I sat down to think about, “Okay, what are the different kinds of artifacts that you usually use in product management and the ones that I learned to use when I started to do product management in 2006?” And especially, what I find interesting is how I use them today and what I think about them today, because this has slightly changed with some experiences over time and working on different kinds of products and in different kinds of team sizes.
So, let’s start. Product management and product ownership, those usually used in parallel, sometimes not, sometimes a position is just marked as a product owner, and sometimes it’s just marked as a product manager. And I would say, most of the times, it’s basically the same, so product managers are also product owners. So, what is the difference between those two terms? Product manager is more a business position, I would say. So, it’s someone who usually is in the product team or, if there are some product teams, one person who is managing some kind of product.
So, in the past, the product manager sometimes even was just a marketing manager. And that, I would say, is pretty clear today. So, in that case, this person would be called product marketing manager. And maybe in an old business, it’s still the fact that a product manager can be, basically, a product marketing manager, so someone who’s taking the attire and things about, “Okay, how do I position it? How do I do my marketing brand? How do I do distributions and so on?” So, it’s usually the same as the old product managers did. But I would say the digital product manager is usually someone who is also involved in product development and… Yeah, so the thing that we usually assume when we talk about digital product managers.
A product owner is, I would still say, the term derived from [inaudible 00:03:03] setups. So, at least, this is where the term was coined in the first place. And so, basically, a product owner in an agile team is the person who is, basically, responsible for the ways or it’s like the interface, how a product should be developed, what’s the other next steps, what other user’s requirements and so on?
And I think this part has changed over time. So, when I started with product management and did the certification as product owner in 2006, which was 15 years ago, the product owner was sometimes even coined as the CEO of ‘product’… Well, the mini-CEO. And so, it puts a lot of emphasis on people, those people who are in this position create the product experience or create the product itself, are like the… How do I say this? I don’t know. The architect, the designer of the product.
And I think the reason why it got this huge emphasis and this huge… How do I say this? This high level, this high positioning in the place, I think the reason for it was that product management at that time was pretty new. And so, product management, usually, in organizations, and especially in organizations who were already existing for some time and were not just new and just doing the stuff the new hot startups were doing… In this other business, products had to establish themselves, and sometimes, even to earn its place within a company.
And that time, when I started product management, product management was usually a part of another department. So, not to be too blunt, but to say, in most cases, it was a part of marketing. I think that was the most difficult phase, and other times, it was a part of project management. So, I was, for example, at some point in this position. And sometimes it was a part of the IT, of the development department. I think that would be the best place to start.
But still, at that time, at least in Germany, in Europe, you really have to promote ‘product’ a lot within a company. You really had to show the benefit of having dedicated product persons to work on the product. And so, why do we need them? Because people are saying, “Yeah, well, of course, we have the IT, we have project management.” And especially compared to project management, it took some effort to really convince people of what’s the difference between project management and product management, sometimes still today. And sometimes still, I see product management basically is related to project managers.
And so, this is, I think, the reason why, when you read some posts and articles about product owners in that time, from 2005 to 2010, you have the experience that they set a lot of responsibilities but also a lot of powers in this position. So, especially the CEO of ‘product’ or the mini-CEO, that was something that you started in product management as a product owner, for something that made you feel, “Wow. Yeah. Here we go,” and so on.
Yeah. So, let’s look at this from today. So, I think the major learning that we all had over the time, it’s like, yes, it’s good to have product people, so it’s an essential position. And you don’t really have to fight for it anymore, so it’s a natural thing. So, if there’s a company that has a lucrative product, it has a product team. So, sometimes in startups, it’s coming a bit later, so sometimes one of the CEOs is taking the product part. But at some point, they will introduce the whole department. And it’s a natural thing, so you don’t really have to discuss it anymore.
I think one of the learnings that we had over the last 15 years is that we learned, well, ‘product’ is pretty complicated. And it’s an amazing assumption to think that a product manager can act as a CEO of ‘product’ and can… Maybe we were a little bit blinded by people like Steve Jobs. And so, the product management, like a mini Steve Jobs, is basically forming the future of ‘product’ in a company. So, of course, it does not work in that way. Not a huge surprise, but yeah, so… I think this is the major learning.
So, in the end, one thing that I think that the product owner position has changed is that, I would say, it becomes more and more an interface position. And it was an interface position in the past as well, but I think the emphasis on this is a lot bigger because, in the end, as a product manager, you have to… How do I say this? You have to be an end point for a lot of inputs that can be transferred into product decisions. And then you are basically a facilitator to help to make the right decision on how these different kinds of input are then to be put together. So, this is how I see ‘product’ today.
It’s basically as if you have two different kinds of stakeholders and sources where you can collect input and where you work together, and you as a product manager also have to decide which kind of input here is maybe a little bit more important and necessary even, so you collected them more. And then you facilitate, basically, also the decision-making. I see it pretty critically when a product owner still has this position that they basically own. And this is maybe the problematic term here, own the product. And in that way, they can basically decide what we do next. And so, this was the setup that I saw pretty often that you have a product owner…
Okay, this is maybe a little bit very opinionated, but you have a product owner who started mainly in an agency. So, we did a concept strategy UX in an agency. And if you have ever done [inaudible 00:10:30] concept of UX in an agency, you know that you have to suffer a lot, because then [inaudible 00:10:34] you have a head full of ideas, so usually you are a very creative person and you’re usually an efficient person because that’s why you do strategy or concepts. And then you have to go to the clients, and this is usually the frustrating part because they are not in the same position like you are. They are careful, they have other goals, they want to optimize. And so, in the end, you work on a level where you have to make a lot of compromises.
And what I often saw was, when these people then move out of the agencies and so then the product position becomes more and more popular… This was a major source where people were hired into product positions. And so, when you come down from this agency and have the product position, your first idea… And maybe you’re one of the rare people who didn’t have this idea, but I know most of them. I had this idea, too. I don’t have this big agency background. It’s like, “Now I’m the master of… Because I know where we go,” and so on. So, it’s pretty tempting, this power that you can immediately get. Even when you just pull the part of the product. So you need to get some power to really create some stuff. And I think this is the misleading thing, that you put ‘ownership’ in the front, but ‘ownership’ does not really help when you create products.
So, this is what I see. The product position is moving more to this, I don’t know, facilitator, mentor, or ambassador in a way. So, you have to be really good at collecting all the different kinds of influences that are important, because in the end… And this is the other thing, ‘product’ itself has ended up in different kinds of roles and different kinds of special brands. So, for example, there’s some product research. And then a company usually has a whole team which is usually doing product research and it’s working closely with the product team in itself. And then you have some product design, product UX, product analytics, and so on. So, the second thing is happening in this role or [inaudible 00:12:49] in different kinds of roles, for example. But still you are a product manager or product owner.
And so, what you will do today is: so you come away with the problem, this might be because of the research team that is covered in some interviews or maybe you did some customer interviews or maybe the customer service approached you with, “Hey, we have a bunch of customers that are calling us, complaining about this,” and then you sit down with them and then you analyze, okay, what the real problem is, and then you try to find a solution. So, what you would do, at least from my experience today, is, you become the person who is leading this problem-solving-thing. But of course, you cannot do it alone. Of course, you can try to do it alone, but it’s usually not a good idea to do it alone because you have lots of cool people, usually, around you and people that’s a good basis of resources. And so, what you basically do is you try to get all these different kinds of people to contribute to problem-solving.
And what’s your role as a product manager, that part is that you stay on track, so when these… Creative people often go into it (a room) and look for solutions, they can easily walk astray and can maybe lose the goal on the other side. This is your thing, so you have to always make clear, “Okay, this is where we’re going, this is where we going.” And then, I think one of the integral parts is really to enable this, and also to enable groups of people who find it difficult to contribute on a level. So, for example, for me, this was usually development. So, especially with the older development teams I’ve worked with in the beginning, they were totally used to the fact that everyone is telling them to shut up. “Yeah, just code and just do the work. Why is the code not ready yet? Why haven’t we released it yet?” And so, this is like the position in which they work.
Of course, it’s the idea to do something like this, and what I saw is, once you have them activated in a way that they know, “Hey. We want to have your contribution when we solve the problem because, of course, once we have your point of view there. It’s super valuable what you provide. You add a very cool input source to product development.” And so, this is what I see. As a product manager, to go around, find these different kinds of people or the new team, maybe sometimes even externally, and to get their input and to get their contribution to bring on solutions for solving the problem. So, I think this, for me, is how product owners behave or should behave today.
So, of course, it’s still some part of ownership, so of course, it’s impossible. I think the responsibility has not changed, so in the end, the product manager is responsible for the part of the product that she or he is responsible for. The way you achieve that, I think, has changed for the good. So, we had this “everyone is a Steve Jobs” phase, I would say. And I still see these young product managers. I think every product manager, in some way, has to go through this “I’m a Steve Jobs” phase. The quicker you can get through, I would say, the better, because in the end, of course, no one of us is Steve Jobs. But you’re really cool, and maybe Steve Jobs did the same thing. I don’t know it in detail. But you are a really, really good product manager if you can facilitate the different kinds of input sources that you have at hand. And do not underestimate if you have lots of input sources at hand. Yeah.
So, this is what I see. I see how this position has changed. Let’s talk about a second one, about ‘product roadmap’. So, this is a tricky one for me. So, here’s how I learned about ‘product roadmap’. So, product roadmap is basically like a very high-level view on what kind of product activities, product items, I don’t know, what kind of areas you want to improve in the product on a very high level. So, usually, like three-months, six-months, even 12-months product roadmaps. And a tricky thing, especially in the jobs I did in startups, I was like, “I don’t really want to create a product roadmap because I know that we are changing, currently, our priorities every eight to 12 weeks,” which is a natural thing in a startup environment, just because, well, yeah, you do some experimentation things, you do some interviews, and you find out that the thing that you thought that was really relevant is not so relevant anymore.
And so, I usually try to avoid it, to create a product roadmap in a way. And I was also a little bit annoyed when I was always pushed to do it. Of course, then I just put something down and just knew, “Okay. Well, it’s ridiculous because, I would say, 30% of it comes true. When you have a more established product already, then I would say a roadmap is still a good idea, if you really do it on a very concentrated and high-level basis. What I found difficult still is the product roadmap that showed us, I don’t know, 20 areas where they want to do improvements over the next quarters. And so, yeah, we improved [inaudible 00:19:27]. So, maybe you have this fragmented patchwork of features that you do, because on the one hand, you really just do 50% and things will stay the same. But the problem is it doesn’t really give a lot of value.
So, for me, it’s like the question: what kind of value should a product roadmap give?And so, of course, if you’re really good at delivering stuff on the roadmap, a roadmap can be a cool thing that can show to stakeholders and, most likely, also to customers what will be coming in which time. So, if you have a very solid product development basis and you can predict pretty well, I think then it’s nice. And it’s also nice to put bigger features in it. When you don’t have it, I think you don’t really have this benefit that you basically give good forecasts to people about what they can expect of the product in the next 12 months, and so then I wouldn’t do it because it doesn’t really help. It doesn’t even help internally because it’s kind of random.
What I learned in that case, as a better tool, is to design the roadmap in that way that should define, basically, topics that you want to tackle here in a specific timeframe. And so, then this timeframe differs a little bit. So, I know, for example, base camp has this, I think, six-week timeframe they usually use in their planning, and they have a major topic they put in this six-week slot. I know other companies are doing this in two months. I know others are doing it in three months, which is basically a quarter. Six months is more work. Six months would be pretty long. So, I would say it’s more in this range, let’s say, from six weeks to three months in the end. And then you define a topic that you want to tackle mostly within the next few months and that you have a focus point.
And this I like more because, when you don’t really have this solid product development regime where we already know, Okay, this is what we want to deliver,” and especially like in startups where we cannot know what you will do, it helps a lot to define these focus areas because, in the end, it gives you the freedom to then decide, once you start to work on these focus areas, what you will come up with. And so, it also emphasizes a lot more these problems, so in the end, you define a problem as a focus area and you say, “Okay, we focus on this problem for the next eight weeks. And so, we come up with solutions.” And then, afterwards, maybe if we think it’s good, we will move on to the next problem area.
And so, this is what I like. And I think, especially, this is something that, sometimes, also can help with customers. So, when you communicate this out to customers, the customers know, “Okay. Oh, look.” So, in the next 12 months, they will focus on application speed. So, you can use this as a focus thing, which can be really good. Because you discovered it, it might be that people already know by your application’s speed and then see, “Okay. Oh, look. They have this application speed on the road map. This is pretty awesome. So, let’s do that.” And I like it a lot more than to say, “Oh, yeah, we released this feature in, I don’t know, blah, blah, blah.” Or you can split it up.
So, sometimes, you have some features which I usually call these new invented features, but they are really more like extensions. So, for example, you have notifications with emails, and so now you want to offer notifications also with Slack. And this is not a new product feature for me, this is basically an extension of the notification feature, just as another endpoint. And so, usually, the implementation of this is not so complicated if you do it in the proper way, so it’s mostly like an extension. So, a mix can be then quite good, but on the one hand, you have used the product roadmap for the focus areas and then, on the other hand, use it to already say, “Okay, these are the extensions we are planning to do. So, we will add Slack, WhatsApp, SMS for the notifications thing, and we will add, I don’t know, Google Sheets and something else [inaudible 00:24:25],” so that you take the existing features and say how are you updating to expand it to offer more possibilities.
And so, this could be a good mix for a product roadmap. But I would still say the important thing, when you maintain a product roadmap, is usually to think about, “Okay, what kind of goal should it fulfill? So, whom does it help and for whom is it important?” And basically, then design it for that purpose. Yeah. So, this is what I would say about product owners and product roadmap. And I will have some follow-ups as I look into other product tools that are useful sometimes. And I think my use of that has changed over time, so stay tuned.