 Hello everybody, welcome to this workshop. My name is Dr. Hendrik Thomas. I'm a senior product manager for Atlassian. Today I'd like to talk to you about the product head, how we can promote product thinking and the engineering domain. First again, I'll talk a bit about what product thinking actually means and why it's important. Then we talk about a couple of principles for developing these skills. And then we talk about the entire journey for product management and where these different areas, skills are needed, and I'm going to hone down on a few of them. So let's start the journey. We all know one of our big mission is actually to build amazing products. The best way to do that is to have the different teams work closely together. We know the key three teams we have for building good products is the engineering team. They actually build the physical product. It's all about feasibility. How can we build it with the technology we have in time? The design team is all about making the system attractive that people want to use it, make it desirable. And then we have the product management domain. This is all about viability. Can we build something the market wants as willing to pay for in its use? So they are all about shaping the product in a way that is a good product market fit. And the best products are built when all these three teams work effectively together at the center point where I place the star. In order to do these collaboration alignment, one of the key roles falls to the product management who is really at the core to create this shared understanding. So everyone knows what the pain points are and how you work together. But in many organizations we have to challenge, product management is the coverage, it's very thin. You either have only few or no product management at all. And if that's the case or simply the skills for doing product management missing, what do you do? And that's the key thing here in this session. I wanna show you how it can actually take the core essence of a product manager, the way product manager would think and share it among other people. For example, your engineering team. Not in a sense to making many product managers, let them do more work. Oh, quite the contrary. Actually I wanna showcase, give them an understanding what product management or processes are and what good practice looks like so they can answer the right question. It's all about questioning. So when it gives you an interview, understand what it means and you can ask, hey, does it mean that? Have you done X? Asking a question really is the key thing. Not only to identify a gap, but as a means to promote communication, conversation and open dialogue. So you can understand what the limitations are, what the best next way forward is. In order to promote product management skills, it's important to understand that we should not fall back into the trap to understand, we don't need that. We have a project manager. You shouldn't really confuse that because project manager is often the answer, but they are not. Project manager are a totally different brand of people. Project manager are people who are actually organizing tasks, they're planning and making sure they're delivered on time. So all about time delivery. They don't really care that much about what project as long as they're done. The project manager do a lot of different things about understanding the customer pain points. As I said, they talk about viability, deliver the right thing. So skills are unique to that domain and to focus on. And I believe very much from the heart that skills are a product manager and can develop by everyone. It's an inclusive thing that where we need to provide these development opportunities for every single team, be it the engineer or lead, the engineers or even a tester, they can pick up these skills and bring it together to improve our overall ability to deliver great products. The other thing is it's like any development. It's not really looking for big sprints, big certifications. It's more iterative, small steps along the way that are consistent. So when you want to think about product thinking, it's all about iterative skill growth, step by step, then you get better. And the other one is idiosyncratic excellence is idiosyncratic, meaning as a result, everyone is really successful if you understand why you're unique and build on top of your strengths. This is really important so we don't wanna shift people completely away. To be really successful, you need to understand how you can build these product thinking on top of your existing stack of skills. So you are unique, but you're extending your skill level that fits in well. Maybe some are programative, maybe more data driven, maybe more conversation and really has to be fit. And that's why inclusiveness, iterative and personal are the key principles for developing any skills in particular around product management skills. And there again, practical skills are way more important, official certifications of training. It's all about the skills. That leads to the question, what skills do we actually need? To understand that we need to think about a bit more of the customer journey. It all starts on the left hand side where we have customers and business strategies. What the customer want them, what the business trying to do, how they wanna grow, where they wanna grow. All that feeds into the product management cycle. Whereas all the beginning, identifying the pain point. What's the problem? Based on that, you prioritize going around and deciding what do you start and you're creating a roadmap. Based on the roadmap, you know what problems you wanna solve first and you give it a design. They decide how the solution should look like. Build, how does the development team, how it's built. Then we have quality control and a release and you start again. Once the product is built, it's up to marketing and sales to understand and communicate the value added to your customer. So this is the cycle you go through over and over again. And the key thing is from a skill perspective, marketing orange. The first thing is you need to identify pain points to do that a product manager need to do customer research. Get into the head of the customer, understand what they want, what they desire, what their pain points are. Once you have an understanding, you need to use that knowledge to create a prioritization, which is more important, more urgent. And based on that, you define a role, where's the next step. When you talk about storytelling building, it's all about taking the existing knowledge you have compacted and shared as a communication mechanism to your design team, to the engineer team. Because they haven't talked to the customer you have. So you need to own the customer pain point and tell them your story. So you need to really good storytelling. And lastly, that's really a bit of an outside. Overall, to make that a work, you need to understand what's viable, what success look like. And we're gonna talk about that or what that means and how you contract that. But these skills are universal and they can be applied and learned by anyone, particularly the engineering. And they can have it with more critical eye on what they're doing and ask the right questions. Let's start with the skill of customer research. What does it mean? First thing is to understand actually, we're focusing on trying to understand the core. We're not looking for a solution. For example, in this case, I need a bandage. Actually, we're trying to understand what's causing it. In this case, stop my knee from bleeding. That's a very good example that I always remember. In the olden days and states when they built a skyscraper, they built higher and higher. At some point, they needed elevators. The first complaint they got, the elevator is too slow. So the designer made them very beautiful. The engineer tried to speed them up faster and faster and faster. So the design engineer did exactly what they did, but it didn't help. The customer still complained that the elevator is too slow. The product thinking should come in. The product had, at some point, someone asked the right question. Okay, why do the people think it's too slow? What's causing, what's the emotions involved? And it turned out in the end, it didn't really matter how fast it went. They were simply bored, stuck together in a small cubicle, don't want to talk. So instead of making it faster, they put mirrors at the back. People could look at them. So they had something to do. As a result, they stopped complaining about the elevator being slow. Solution found, but a different one you thought because you understood what the core problem was, you're bored. As a product manager, that's what you need. So an engineer should always ask, do we understand the pain point? What's the pain point? Ask this question over and over again, and at some point you understand and have confidence that you understood it. To get to that point, to do product management skills and understand customer research, the key thing here is to promote customer empathy. It's above intuition. Or someone told me, someone was very loud, a generic customer empathy that covers your customer base. To do that, think to understand as customer research is always done in three stages. You're not just running interviews, running the three different types of interviews that are distinctively different. The first type of interviews are called VOC, voice of customer. The voice of customer interviews are problem spaces where you talk to people and they're opening up all their motion. You can only dip it in one by one. And the idea to bring out their core concerns, their challenges and data to their life. So you need to be broad, the entire end to end chain. The more you understand, the better. Don't limit yourself on the thing you're interested in. Take the whole thing. Based on that, you get a general understanding of what the problems are. And you can start working on a solution. CPT, customer preference testing, is a different one. They also gave them a specific solution, maybe a design product or whatever. And your role is to say nothing. Just observe how they interact with it, where they fail to understand which option works better for the customer. VOC, let them talk, keep them talking as much as possible. CPT, your role is not a moderator, just to give the instruction and then shut up and listen. CCT is customer confirmation test. This is the end. After you've built, you show them the final product and say, did we hit the mark? Did we miss something? And you can polish and optimize. But the core and the starting point is the VOC that needs to be run widely and need to understand it. Very important to done is, that sounds fantastic, but how do you run that? Particularly if you're 100,000 views, how do you run it at scale? That's one of the key challenges. And to do that, I have a whole session on that. First thing you understand, you simply don't really know what's going on and you have very little knowledge. Therefore, as a result, you can't really judge what's important or not. That's why you need to focus on the raw data. Make the raw data accessible through automation and archiving. So you can always look back and to the raw data once you have a better understanding. Do slack, bebex, whatever. Do recording. And then please use some to extract the text automatically. Automated text extraction makes the full text readable, accessible, and searchable. You can store it on wiki and you can analyze it. This is not now possible with modern tools. Even Zoom allows text extract or otter. There are a couple of technologies out there where relatively cheap and you get fairly good run. As a result, you're getting a good understanding of a very one hour interview. Get a full text. This is a good thing, but how do you process that? Once you have these interviews and many other things. In this example, for example, you had an interview, but also Tom writes an email, he gets tons of support emails, you get all these ones. And within the email, you have also some elements, Mary said, feature A and feature B are critical for her, but Tom said, I need feature B, but it's just nice to have. So you get this duality of things. You need to capture that. One feedback point captures multiple problem space features, one to many. You can't do that effectively in a flat file, for example, conferences, not positive. You can't do that in Word documents. Spreadsheets are terrible for that. Use proper tooling. Tools to collect and combine. This is a good example, for example, product orders, dedicated tool, that you can have all the interviews in each segment can then multiple linked different features. You can always say who said what for a particular feature, for example, career tips, or supported by 20 users. Other tools like Dovetail or GraphIU are really interesting elements that help you bring these different features together. And you need tools to make your work easier and your life easier. That's why you can analyze, slice, and dice, and change. Word documents, Google Sheets don't need dedicated tools. Once you have the data, you can now use it for your prioritization. Prioritization is deciding what you wanna do first. And we have different dimension that help you decide. But in many cases, resources cost, the budget, how many developers are fixed. You can't change it, well, at least not quickly. Try to start hiring in these days. Some people, it's gonna take it forever. Schedule and timeline often are dictated by marketing announcement, you can't change that. Quality, like data privacy, non-negotiable. People walk away if the quality is bad, so that's fixed. So the only thing you actually have control of is scope. Features and functionality. This way it really matters, they need to adjust. And this is a very simple overview. We have often impact, high, low impact, and low and high effort. But in many cases, people tend to do the low effort, it's only 30 minutes just to get something done, quick task. Use staff to death, don't do that. You need to focus on the high impact and high effort, one that have the biggest impact, you need to have a bet. The question, how you identify which are high impact, high effort? Where are the ones that you're high effort? And with the interactive standard and raw data, you can bring up the number of interviews, get a lot more insight, and you can use that for evidence-based prioritization. One easy way to do that is to use something we call rice. It's basically just a math formula that allows you to take raw data, combine it with a single score which you can sort. Needs a bit and have a separate session on that, but it's relatively input. You have a reach element. How many people will be touched by my experience? 100,000, just the admins or every user. What's the impact? How will their life change? Smiley better? Or a huge change that will save them days of work. And then you have confidence. How much do you think you have enough knowledge about how it will build? How the solution will look like or the problem space? The higher the confidence, great. The lower, the higher the risk. And then you're divided by the efforts, typically in death days. And by doing that, you can really balance off the more information you have, the more impact you have with the effort. And based on that, the higher the rice score, the more likely you should do it now. And it's a very data-driven, very objective and with my approach for raw data. You can explain and show them and let the real people talk. Prioritization. Challenging tasks, but again, with an engineering mind. Ask for them. Let them see the prioritization. How did we get there? What rice score did you use? What interviews? Have a conversation. It's not to challenge them. Just to bring up the information you have a good conversation. Next thing is about, once you collected all that in your head and you're done a product management work, you need to share that with your team. How do you do that? And the answer to that one is storytelling. You need to tell them a story. Because storytelling is about 20 times more effective in order to bring people's motivation and engagement. And it also helps you promote the behavior pattern you're trying to do. And there's a book out there about the seven standard plot types. It's surprising when you read through these books, you actually find out there only seven default patterns. All the stories, all the children books never will fall through. One of the examples is overcoming a monster. You overcome monsters that you wake up, you have a epiphany and you see what the enemy are and you're trying to fight the enemy and you get there and you fight them. And at this point in time, this story about defeating the enemy and getting there is a really nice way to understand and share it with everyone. Even any product you're building will have to overcome some challenge. And using this plot type makes it very easy to bring people engagement and you can learn that how to structure the challenge. Next thing, I wanna show you a bit of a video we have recorded from using it. Just listen. You've confirmed that's what the science went. Oh, so look, yeah, you've obviously covered and we've talked publicly with or we've talked in consultation with people around the system. And so yes, that's the way people have described it. I think you'll hear me using a COVID protection framework because it is still about protecting people from COVID and that's what it's designed to do. It's a video from our Prime Minister here in New Zealand. It's funny because someone asked, okay, do we build a traffic light system that shows the risk based on green, yellow, red? And she refuses to call it that because that's a feature you built. What she called is a COVID protection framework. She focused on the outcome of the value you were providing and only focused on that. And that's the better way to tell a story. Don't call it a feature, the button. Tell it what it's for, what the value it is and people get by. And to do that, you can actually use like opportunity crafts and Theresa Doris provides that. And it's about shifting from features to outcomes, start with the desired outcome. Use a different opportunities and solutions to experiments. So you see all the things you could do and link it back to the outcome and see which have the biggest chance to deliver the outcome. That's how you tell a story, package it, and you bring people along. Not about what you're building, but why. And the next one is the why measure success. How do we know actually done the right thing? How do we know that we have been successful? And the key thing is obviously in many cases it's all about retention or bringing new customer along. And with many new sales products it's about building this adoption. But you can't just have a single number. You often need to understand what the pipeline is. And that's a model which we call the RR framework, the pirate metrics. And simply shows that different stages once you build any type of product, internal or external. First one is acquisition. You need to show people and get them aware that solution even exists. Get them to the web page. Then it's the activation. The first interaction for the customer, maybe 30 seconds to make them aware of the value is and they understood, get the light blower on. That's what it's for. And get it now, why that's important. And then just then you shift over to retention of people coming back and start using it. And then at the point you get referrals. People find it so good that they recommend to their friends. You may have internal fans. And the last one is your make revenue. But the key thing here is the activation stage. At any product you build, internal external. At some point you need to communicate to someone else what the value is. What's the core thing, you cool thing you can do. And if you don't know how to get there maybe you want to activities to make them aware. For example, Facebook was something about that you have to share some information with at least two people, that's what we gathered. This is the key thing. So as a product manager and as an engineer, you're asked, okay, how can we communicate the value? What's the core thing that you have to do to get it? If you don't know, you don't have the discussion then you will never win. That's why having the private metrics and understanding have a discussion within the team. It's very essential for the engineer to understand what good products look like and how we make sure that this map that we're moving ahead make successful. So we're coming to the end and we bring everything to it. How to promote product management skills. First of all, don't call it product management via engineering. That's maybe frightening, even particularly if they're not familiar with that. Don't talk about certification or courses, don't. Talk about specific problems and outcomes. For example, I don't know what our customer want. You need to do customer research. What do we do first? Talk about prioritization and show them the evidence now. That's why you have chosen to do that first. Great, now we know and we understand. Focus on practical skills and tools and templates. For example, tools like product board where you can access the evidence or the metrics where you can have rice. It's really important to understand they have to see it in practice. They have to get access to the evidence to challenge and view. Again, this is all about not doing more work but asking the right question and start an open dialogue. In the end, this is a journey that is ongoing. It never really stops. The whole point of product thinking is to promote people's thinking about what good looks like and how can we get there. Starts lost by teams. Do one thing for some customer research, share some insights, and then just have the conversation. As a result, if more and more engineers can pick up the product head and think about that, overall the product quality going up and you may make sure about every solution with design and engineers are building, it's really fit for purpose, it's really a viable and the thing the market really wants. And you can only do that together. So it's all about design, product engineering and work together as a team are fully aligned on the values to deliver what you want. So keep going, promote product thinking and really include the engineer because then have a big thing to add. Thank you very much for your attention. If you have any further questions, please feel free to get me in touch with me. Thank you.