 Hello, everyone. I'm Thomas Lomborg. Welcome to my session called Nine Distilled Experiences for Boosting Product Management Teams. In this session, I'm sharing nine hands-on tips and tricks that I've learned during my 20 years as a product manager. Many of them come from the seven domains and nine organizations I've been working for. My real passion is to find solutions matching problems, so working with teams and customers and really innovating until you have that solution that really solves the problem. That's kind of what I'm most passionate about. My favorite acronym is Nihito. Nothing important happens in the office. It comes from Pragmatic Institute, I would say. So that's something I believe a lot in you. You really need to go out there and meet your customers. I'm based in Sweden. This session will be very hands-on. It's a very concrete advice right to the point. So there's a lot of text on these slides. I will share them afterwards so you can go back and see what was really there. I won't have time to mention everything. But yeah, let's dig right into it. Okay, so the first one. Turn feedback into qualitative data. And the problem that I've seen is that if you're not capturing all you learn from conversations with customers and partners and colleagues and whatnot, it's really hard or impossible to get the value out of those conversations. You really need to find and define a way to store that and make use of it and really convert it into data. This is important because priorities and finding the right solution to a problem is hard enough without data. So yeah, make sure you have it. You as a product leader and the product team and everyone knows how to take customer notes, where to store them, how to share them, and how to eventually report on them. And this is my hands-on tips and tricks using JIRA, where you often have requirements in JIRA and you can link those into Confluence Notes and a very neat way of creating Confluence Notes is to create a template in Confluence so that you can quickly create a new customer meeting notes page and add everything that's said in the meeting into that. There are also other tools like JIRA Product Discovery, which has a neat feature of just quickly collecting data points from many different places with one click. So you can often get away from the copy-paste way of doing it. You of course work with the team. So caption data is one thing, but you also need to share it. So ask your team and your organization to subscribe to the Confluence page with all your notes connected to Slack if needed. Make sure to have a conversation about what you learn and the best thing is if the team reaches out to you and have follow-up questions and gain interest in what's happening in the user community. That's awesome. And last but not least, set up an ID portal. Make it easy for users to create your own qualitative data. Ask them to create IDs in the ID portal from AHA, for example, and really try to boost the input of data. But once again, keep it structured and make sure you have your data readily available when you're prioritizing and working with your discovery phase. Yeah, there were some resources. Really good talk from Rob Fitzpatrick, the mom test. And you can also hear more about quality versus quantitative data and learning from Marty Kagan. Two videos I recommend. I also have a blog where you can read more about this specific topic. All right. Number two, connect users and teams during the delivery. You really want users and the development teams working really closely together. When you're writing code, when you're creating, when you're delivering, make sure to have users and the team as closely as possible. And one way of doing that is essentially to remove yourself as a PM between them. Introduce a selected few users to a selected few developers and UX persons and ask them and tell them to talk to each other and ask questions directly. Follow up, be on CC. If you invite users to your Slack channels, make sure to follow those as a product manager. Be aware for scope creep, et cetera, et cetera. But please remove yourself. Don't relay every single question and answer because that will just slow you down and it will increase the risk of not finding the optimal solution or worst case that the team becomes driven by the users and are introducing features that are not really necessary for that perfect solution. All right. Yeah, of course, I do A-B testing as early as possible, share builds, and don't forget to give users that you have worked with during the development credit when you launch. As for permission, of course, but try to use them and really show that you appreciate their feedback and cooperation. All right. Number three, write requirements, not PRDs. So product requirement documents, I see them as more or less throw over the fence artifacts to spend days and months sometimes writing these PRDs and they're the perfect means for excuses. Yeah, I was not in the PRD. So we have not developed it, right? You don't want that. My experience is that stop writing these long documents that you share with the organization. They comment on them for a bit and then you forget about it and go back and do your job. Instead, have living requirements. I think Georepics are great. There are other tools, of course, but Georepics, they work because they are close to the code and they're close to the team. They are tracked. So when you update them, everyone can be notified, for example. So work with the customer, work with the user UX development and really see the requirements as a living thing as you discover the best solution. Make sure you have enough information in them so that you can allow the team to do their work and find the best solution. Write them as if they were already implemented because you will write some release notes or do new presentations. So write everything as if it already existed. That would save you a ton of time when you're briefing the marketing team, for example. So that's a good advice as well. Yeah, don't design. You're a product manager. There are people that are awesome with designing UX. I think to those by all means, but don't include them in the requirements themselves. I also prefer to keep requirements short. I sometimes see every single requirement starting with as a user or product feature, XI. I tend to skip that. I mean, people get it. Keep it short, keep it easy to read. Keep it easy to get an overview of what the requirement is really about. And going back to having a live requirement, there will be follow-up questions continuously. So you as a product manager need to be ready to go back to users, customers, book new meetings to find answers to those follow-up questions. It's a living thing and be prepared to do that and keep generating and validating solutions. I've seen a lot of people that are looking up requirements into other epics. There are sometimes great ideas that may not have the validation they require just yet. Spin them out to another epic and look at it that's a later time. All right, number four. Keep your product direction up to date. As a product manager, you should have your direction clear. So that everyone knows where we're headed, why we're doing it, what are short-term and long-term challenges. What do we really need to innovate about? What problems are out there? That's something you should always have up to date and keep fresh, including the actual presentation of your direction so that everyone can go in and find it, which means the engineering team. You should never share it with the sales team or with the customers in electronic form. So please make sure that you are the one presenting it because you want the feedback from it. Having a direction presentation is the best thing to generate interest in your company, in your product, and the most engaged users tend to show up to direction presentations and that's what you want. That's where you want your feedback to come in from, right? And you will also broaden your contact network. Make sure to write down, as we said previously, you should have a process for how you collect quantitative data or quality of data, and make sure to do that from these presentations and add everyone that was in the direction call to those nodes with email addresses preferably with roles as well so that you can reach out at the later point. You never know when you're building what and it's always great to have references to users and customers that are engaged and willing to provide more feedback. What should be in the direction? Well, a safe harbor, the future will change so always have a safe harbor slide in the beginning. Contact details, of course. You want feedback and questions. Pitch the company and products just to remind everyone about what you're here. And then a summary is great because the direction is full of stuff that has not yet been implemented. So remind everyone that yes, we are actually releasing quite a few valuable solutions and just highlight some of those too to show that this is an awesome point to direct to an ID's portal. For example, if you have an HAL ID's portal you can show what has been implemented of all the IDs. All right, and then of course focus on what you want feedback on. Focus on the near-term solutions you're about to deliver. That's what your focus should be about. I'm getting into the actual content a bit later on here in number five. Team up with your sales team. And the directions presentation is one of the most valuable tools when you're in meetings with customers and your sales team. However, in this scenario you should be ready to adjust your direction presentation. Tune it and tweak it on your way to the meeting as you learn what this customer is more interested about. Just hide slides or shuffle slides around. Tune the message. Make sure that the customer and the sales team gets as much value out of this meeting as possible. This is their meeting, not yours. So talk about the topics that they are interested in because they will provide the awesome and valuable feedback about the areas they are interested in. If you start presenting the whole product direction and they're not interested in half of it, it's just a waste of time. So be prepared to adjust your presentation. Don't commit to anything, of course, not to customers, not to sales. Don't talk for quarters months or any timelines. Treat also the sales team as a customer because if you share things on your way to a customer meeting, for example, there is a big risk that the sales rep will use that in some way and you don't really want that. So please don't commit or talk timelines at all. You will get rewarded with a lot of insights and my way of paying for those insights is to be transparent. Tell the customer and the sales team what has lower priority, higher priority. Share what you're uncertain about. If you are uncertain about something, you're in the discovery phase, let them know that and ask for feedback or dialogue, follow-up meetings to decrease the uncertainty. Also, let them know what will not get done because if they are requesting something over and over again and you know that you will not do it, say that. But also tell them why. Tell them if it's related to cost or tech or direction or priorities. Just let them know that and find alternative solutions and try to be innovative and go back to the core problem of why they are requesting something that you can't deliver. So, once again, be transparent. Yeah, of course, don't share the direction deck and be personal. Be nice. Ask questions. Be curious. Ask the why again and again. Yeah, make sure your live demos work. Sales reps and customers, they love live demos. So, make sure they work. Worst case, have a video ready. Don't use it if you have internet connectivity and you need that for the demo. You should demo. But worst case, have some kind of emergency backup. If possible, prepare the engineers back home so that you can answer questions on the fly that are super technical. Maybe your team can be a slack message away and you can have an answer quickly within the meeting and really surprise the customer with that and how you work together with the engineering team as a product manager. Claim your own demo booth at conferences. That's also an opportunity to get a lot of traffic, a lot of interaction with sales rep marketing customers whoever passes by potential partners. Don't let the demo booth go to someone in pre-sales or sales or anyone else. If you're there and your product manager have your own demo booth. All right, number six. Being a product owner is about 10% of a product manager's job. But it's also very much your job. And I know it's easy to get caught up in team activities. You're spending all your days as a product owner slash project manager. And that's really not where you want to be. However, you want to be close to the team. You want to monitor the team. You want to serve the team with insights. Ask any questions. Really leverage your network as a PM to support the team in the best possible way. And you also, and this is probably the most important thing, you want to close the gap between users, customers and the delivery team. So having a separate, worst case separate product owner between a PM and the team is just the worst thing. You're just increasing the distance between users and your team who should be innovative and deliver the best possible solutions. Why would you introduce additional roles between them? Because that's just not feasible. So be a product owner, but try to reduce the number of hours you spend on typical product owner tasks and work closely with the team. Join the team, it is when you can. Try to be the ones to start the meeting so that you can have your things said early. And then the conversation tends to be more and more technical and then you can drop off if you have other things to do or just listening. Try to encourage working with customers and give the team credit for that. Ask the questions, of course. Ask if there's anything you can do, any information you can give the team through your network. Remember, you're a product manager. You have the most awesome network. You know stakeholders, you know engineering managers, you know customers, partners. You have a great network with a lot of potential to provide feedback to the team, right? So try to do that. Be observant to a scope creep. That's something that happens sooner or later. So be on top of that. Once again, make sure your demos work. As the team develops more capabilities, it's easy to forget that there should always be a working demo. So try to be on top of that. And it should be your demo, not something that a developer can spin up in their development environments, right? Are you talking about stores and tasks too much? Try to avoid that. Keep your conversation on Epic level and leave it to the team to define stores and tasks. That's not really your job as a product manager. Have you inherited a messy and long backlog? That has happened quite a few times. There's no way around it. You need to block a week or more to just sort it out, get it in order. You will never get a messy, long backlog completely in order. But try to focus on creating a top one-third of it and really have that prioritized and fill any gaps with qualitative and quantitative data. All right, number seven, UX and design innovation. The problem here is that UX teams tend to enhance the existing product and they do that really, really well. But sometimes they forget to be innovative, to research new trends in user experience and design, and your product is kind of stagnating as it comes to look and feel and how it's perceived. It tends to feel more and more dated over the years. So as a product manager, and especially if you're a lead or a director of product management, make sure to request and sponsor UX and design innovation. Make sure that's something that you do continuously. Show everyone that you are doing it. Be honest with timelines and when it might make it into the product, but do it continuously. Always try to find new ways of navigating your product, color schemes, look at fonts, look at how your product is perceived, and do that. And if needed, print out those designs and hang them on the walls in the office. Make sure this is something you do continuously, to avoid your product feeling dated and embrace new ideas in UX. Yeah, if you want to hear more, I recommend Product Talk, where you can listen in on products, cover product delivery, and also Product Hunt. A lot of great products are presented there, and many of them have really innovative and nice UX and designs. We'll check out those two sites. Yeah, go full stack. When you're innovating, go full stack. Don't just innovate within your team. Bring in the whole product, look at it holistically, see if there's anything you can do together with other teams to really be innovative. Don't forget the business case. Don't bring in the business model as a product manager. You know the business. Bring that into the innovation. Be honest about the current problems you're trying to solve so that you're innovating in areas that are important to you and the company. Avoid innovating just within the UX team or in a feature team or product team. Innovate on a higher level. Make sure it's on the top product level. Yeah, I think that's it on UX and design. So let's move into tips and tricks. Number eight, keeping a sense of urgency in agile organizations. So the problem I've seen is that in agile organizations and feature teams, it's easy to end up in a sense that there is always another sprint, another release, nothing is urgent to deliver right now. There's always plenty of time for side projects and process enhancements. And this is, yeah, as a PM, especially as a product manager, this is a really tough situation to be in. You want to be agile, you want to discover the best solutions, you want to deliver in the end. And having this kind of mentality that, yeah, we didn't make it, but maybe there's a new release within two weeks, so why would it matter? This is being agile and working in product teams has nothing to do with losing a sense of urgency. It's not a reason for running like a headless, safe, waterfall approach or anything like that. But please try to be personal. You're a product manager. You know the problems out there. You know what needs to be solved and you have names and references for why. So mention those names. Mention those contacts. Introduce developers to those contacts having those problems so that you raise the urgency and you make it personal, not only within the team, but also personal with actual users waiting for your solutions and features. So make it personal, make it fun. Try to get team members to help each other. Don't forget to celebrate and really find that perfect balance between backing off and pushing the team. And you will do great. The other advice is to be demo driven. Always demo what you do. Create end-to-end demos. Request demos to be possible to run by you as a PM so they are not engineering versions. So demo yourself and demo early, demo to the company, demo to customers or share builds. That's my other advice. Yeah, validate it with customers, of course. And last but not least, don't accept the, yeah, but this other team is releasing later so we can wait until they are done because, yeah, why would we push something out now when they will not be ready anyway and we will just have our stuff laying on the shelf. Don't buy that. Make sure to deliver on time, deliver quality, solve the problem and move on. Don't take external dependencies as an excuse for having projects running unnecessarily long. Right, we are already at the last tips and tricks and that is competing product areas. What do you do when your problems are not always considered the most important to solve as a PM? This can be really frustrating. You have collected all the evidence. You have the notes. You have tons of IDs in the ID portal, but your organization has other priorities. This can be really frustrating as a product manager. If this happens, and I believe it will sooner or later, remember to represent the product team. If you're a product lead or a product manager, act as a team, stay behind the direction, the vision, the strategy you have laid out, communicate that as one team. Even if it currently says that your favorite features and solutions have lower priority, communicate what you have agreed upon as one team. This could be kind of a competitive situation. You really feel for your customers and your features. Keep collecting data and communicating customer paints. At this point, it's important that you're super clear about what's needed within your product area. Continue to collect data. Continue to be clear. Find new ways of communicating it. Maybe present part of it in company meetings. Just remind everyone that the problem is still there, even if it has lower priority, and make sure that when other things are decided, make sure that everyone knows what is not getting done. Because that's your responsibility as a PM to tell people making decisions above your head what the impact will be, what will not get done, what solutions will not reach end users, and what could the impact be? For example, they may churn on certain use cases. Maybe they won't use your product to solve certain problems, which means they will bring in competitive technology into the mix, and that's high risk, of course. So just be transparent and keep collecting it. Also, read up on what's actually the most important thing right now. Read up on that. Learn. Support them. Collect quality and quantitative data for that solution. Maybe it's actually something you would like to move into as a PM. That could be your next career step. Validate the most important solution right now with your customers. Maybe you can find a match between their needs and what you have been talking about in this new strategy. So use it as well. And inform your team. Inform your team that the decision is here. These are the new priorities and work and support your team in that. All right. That's nine tips and tricks and some experiences as a product manager. I would like to say thank you and I will be happy to continue talking to you on Discord. Or you can just reach out on my Gmail or LinkedIn. Thank you very much for your time. Have a great day.