Strategy Definition And Implementation For Successful Product Launch

Yaroslav Karulin at UXDX Community: Helsinki. Video: https://youtu.be/eN2UfduZP5M

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

What product management actually is

[00:00:10] I'll put this quote in the beginning. I really like it. I started reading this book and this quote struck me. I always thought it's my personal kind of feature to think more about failures than successes, but after reading this quote I realized that product managers probably have something in common. By the way, do we have anyone on the product management side, product owner, product management? Okay, great, not that big, but some presence. Yes. For the rest, I think it will be useful to just understand why this kind of strange guy comes to you and asks, or strange girl comes to you and asks you some stupid questions always. So I hope this presentation will help you understand a bit of the thinking of product managers.

[00:00:59] So, product management. Here is a simple explanation, and actually it started with the following thing. Did you recently go to job interviews, any of you? Did you get the question, why do you want this role? Did you actually reply, I need a paycheck? No. It's actually strange, it's not a valid answer. I think it's an absolutely valid answer, but I was replying in the beginning that for me it's a really interesting position. This is what I want, this position, this position is being a translator or being the bridge between the technical people and the business people. I have a technical background, I used to be a software engineer for quite a while, then I went to business school, got business education, and I can understand what business people are talking about, so I can try to bridge those two worlds together.

[00:01:57] It's actually still a valid explanation, I still think it's true, but now I realize, as any model, it's really a simplification of real life. And I will tell you, I suppose you have development in your organization, then you've got a design team, and it's the product manager's responsibility to make them talk together. Then you've got architects. It can be enterprise architects, I have no idea what that means but it sounds funny, it can be software architects, solution architects, they're sometimes together with developers, sometimes a separate team, and they should be talking to development as well, and to design, and vice versa. Then project management, sales, marketing, account managers, they all have to talk to each other, and it's up to the product management to ensure that this information actually flows.

[00:02:58] In some cases it flows by itself. It's quite natural for developers to talk to architecture guys, I don't see any problems there. There is another problem, that when they talk they make a decision and you should be aware of this decision. It doesn't mean that you should block them from talking, it just means that you have to somehow be there. Other people, like marketing talking to development, it rarely happens, and it's up to the product management to make this dialogue, or at least the information flow. Sometimes it's not a direct information flow, sometimes let's say development needs to talk to project management and then this information should go to the account managers. And everything about product managers is making this happen.

[00:03:47] It's like, I don't know if you think about an epic, or some epic story, not epic in a SAFe way, SAFe methodology way, but some big literature book. It's probably like gathering the teams of, I don't know, elves, humans, boars[?], well, probably not orcs, and making them do something together. So it's like being, again, Gandalf.

Jenny and her stakeholders

[00:04:12] Let's talk about some real stuff. So let's talk about Jenny. Jenny is a young, passionate, enthusiastic product manager. As I told you, she needs to communicate with people, she needs to identify the key stakeholders. Some of those stakeholders were in the previous picture. Can you suggest any other stakeholders? Yeah, that's a great one, the top management, the guys on top of the company. That's great. Any other? The team? Yeah, I agree, the dev team, it's usually the product team, whatever they call it, it can be developers, but yeah, she definitely needs to talk to them.

[00:05:08] Who else? Lawyers? That's actually an interesting one, I didn't think about it, but this is absolutely true. I think Natalia was talking about the regulations and legislation in the industry, and they definitely would need to talk to lawyers. Customer service, that's true, that's kind of close to the operational team, and you need to understand what's going on with the product. But anything else? What about customers?

[00:05:45] And actually in the B2B world it becomes a bit more painful, because it's quite hard to define the customer in the B2B world. It's not like in B2C, at least, sorry, at least that's what I'm thinking, I actually never worked in B2C. I realized in B2B the big challenge is that when you sell your product to a person, it's another person who uses it. So one person you need to persuade, one person to pay for it, another person to use it.

Keep your management updated

[00:06:30] So, talk to the stakeholders. I'll just briefly give you several examples of what is critical. Keep your management updated. And what happens? Let's say it's probably too low, but let's say there is a Michael. Michael is, I don't know, head of executive or corporate sales, whatever, he's somewhere in the top, VP whatever. And at some point he bumps into Jenny in the corridor and asks Jenny, we need some bestseller, we need a kind of big nice product I can talk about, do you have anything? Yes, I do. We came up with this beautiful concept, we are developing it, it's this car, do you like it? Michael says, yes, it's a wonderful concept, please give me a presentation, give me whatever you have, I will go and I will upload it on my phone, I will show it to my friends and when I will be golfing, I'm ready to go to some conferences and show that. So Michael's happy, Michael's going away.

[00:07:40] Jenny starts to develop the product further. She starts talking with the engineering team and the engineering team says, you know what, this kind of fancy looking doors, they are really nice, but the problem is the mechanics is really, really complex, and if we start doing that, the price tag will reach the Bentley price tag. Can you make them just go up? Well, Jenny thinks that, okay, up is okay, it looks nice, almost as good as this one, let's do that.

[00:08:15] And then she faces another comment. Hakeem[?] says, you know what, this kind of front looks very nice, very beautiful, but there are some regulations in Europe that protect pedestrians, you need to make it smaller. Well, Jenny thinks, it's regulation, I cannot do anything about that, so she makes it smaller. Then they run user tests and users tell them that, okay, those upwards going doors are really beautiful, but you know, when it's raining then they start dropping water and it becomes messy. And Jenny thinks that, okay, that's true, I mean those doors are nice, but that's not what they want, they just want regular doors.

[00:09:04] So what happens next? Nine months later, one year later, Michael bumps into Jenny again and asks Jenny, what's this prototype you were showing me a year ago, what's the status there? Oh, we're releasing it in a couple of weeks. Yeah, I'm really excited, can you show me? Yes, here it is. Do you know what happens with Michael? I can show you.

[00:09:39] So this is what you will see on Michael's face, and it's really bad if you have Michael in your direct chain of command. It can be really bad even if he is not. And it's not only bad for you, for your career, it's also bad for the people you were working with, the designers, the engineers. So it's really important for you to keep Michael updated about the progress, especially if you saw that he's taking the prototype really seriously. Actually, I think Matthias in the previous presentation mentioned about prototypes, showing the nice prototypes to the product owners, but with the product owner it's okay, because the product owner is quite close to the team.

Ask why, and talk to the end user

[00:10:27] Then, asking why from your customer. It also was mentioned somewhere in previous presentations and I'm just kind of trying to elaborate. So let's introduce another person, Saul. It's actually, I don't know, the purchasing director at one of the customers of Jenny's company, and she comes to Jenny and tells her, okay, Jenny, we signed a deal, you deliver us the product, and actually what we need, we need this trailer, which is basically half of the car, but it's a trailer. Well, if you don't start asking questions, you may end up building this trailer, but what's the point?

[00:11:17] So it makes sense to start asking questions. There is a rule of five whys. It kind of sounds stupid, but you should keep asking the question why at least five times, to get from the requirement to the need. Why do you need this trailer? Well, because we would like to have two additional seats, but we don't want to always be there. Why? Well, we are targeting the family segment, with parents with two kids and three kids, and sometimes the grandparents come, they just would like to ride in the same car. Okay. And you keep asking and you realize that actually they don't need this trailer. What they need, they need a struggle[?] or a 7-seater, and probably Saul was just not aware that this option exists. So keep asking, keep trying to understand not the customer requirements but the customer needs.

[00:12:14] Unfortunately in the B2B context it's sometimes quite hard, because of the way the purchase works. In the B2B world it's usually that they roll out an RFP, where you have just a kind of compliancy checklist. So how do you deal with that? It's a really, really tricky question, and this is something to discuss between the product team, the management and the sales team.

[00:12:43] Talk to your end user. This is what I mentioned before, when one person pays and another uses. If let's say Jenny was building a truck for the post delivery, and let's say David is a postman who will be using this truck. There is one trick with the post trucks. Have you ever noticed anything special? (inaudible.) Well, let's say in Finland they use the trucks which have the steering wheels on the wrong side, on the right side. It's just because it's easier for the postman to go out, or he doesn't even have to leave the car, he just lowers the window and pushes the envelope into the post box if it's available. So Jenny needs to talk to the end user and to understand how he works, what he does. She may need actually to go with David together and see what David does. Otherwise you may end up in this situation, meaning your users will be using some other tools to perform their tasks.

Matrix organizations, RACI and the balance of information

[00:14:11] Some additional tips or thoughts or whatever you would call them. I really hate to say it, but a matrix organization can actually help in the spreading of the information. It can screw your organization in many other different ways, but regarding the spreading of the information, I wouldn't say it will help, it may help. It depends again on the people you will have in place as line managers and product teams.

[00:14:48] Do you know what the matrix organization is about? It's basically when you have one organization, like you have a team of developers, team of designers, team of testers, team of product managers, and then you start picking people and assigning them to so-called virtual teams or horizontals, and telling them that, okay, from now, like the next six months, you're working on this product with this team. So you're just basically picking up the team. The idea is that the information spreads not only within the line organization but also along the horizontal, so there are a bit more ways to spread the information. But to make it actually work, you basically need line managers to take the responsibility of making people talk or sharing the information, and whoever leads the products to do the same. As I told you, it can screw you in other ways.

[00:15:53] There is also a good way of thinking, well, I wouldn't call it a framework, actually, I shouldn't use the word framework here: RACI. When you think about any task, you should think about people who are responsible for this task, who will be doing this task; who is accountable for this task, who basically will suffer when it fails; who should be consulted, that means that you should go and ask advice from those people and tell them what you are doing; and who should be informed, which people you are just pushing the information to. It sounds stupid, but this actually helps you to structure your understanding of the communication both within your company and outside.

[00:16:47] And then in the end I would say that this everything about information exchange is actually a fine balancing act. People say that there is never too much information, but quite often people tell you, please don't tell this information, it makes your team worry too much beforehand. So there is a kind of question of balance: sharing the information, or protecting your team from the organizational chaos. For example, how not to block your team by constantly pushing some information to them. How not to spend all of your time in different informational sessions, meetings, whatever. How to limit the amount of people invited to some specific discussions. Sometimes I invite one person, she or he invites another, and it grows like a snowball, and I get scared, but in the end it's quite beautiful.

Is there an alternative to face to face?

[00:17:59] And actually the five million dollar question: are there good alternatives to face-to-face communication? Actually, Rory, I think you were talking about getting people in the same room, so I think that means that there is no good replacement for face-to-face communication. Actually, if you know about SAFe methodology, the Scaled Agile Framework, it's basically being agile in the enterprise setting, they also tell you that at least once every two months you should get everyone into the same room.

[00:18:41] So I still believe that whatever tools you have, you can have Slack, you can have HipChat, you can have Microsoft Teams, whatever, this will not replace face-to-face discussions. Even if you have some video tools, they are not replacing face-to-face discussions. So you need to have a room for your team, for the key people you need to talk to, you need to have the whiteboard ready, you need to have those sticky notes ready, and this way you can start sharing ideas and spreading the information. Well, that's pretty much all I wanted to talk about. Thank you.