We're going to talk about a few more techniques to create better sessions, I'll avoid the term meeting, with your collaborators as you scale up your existing product. One of the really tough areas is estimation and planning. And a lot of the time the real problem here is the product manager or the product owner is trying to cram too much stuff into a cycle. And, I mean, that's really the root of a lot of push and pull and this and that. And so your main job as a product manager is to help your team build less software better with better focus. But to the extent that you need estimates to make decisions and prioritize things, I'll give you a few ideas. If you use some kind of story point system to look at your stories and say, "How big are these?", probably so you can prioritize them hopefully because precise planning is difficult and can be very wasteful. My main advice is don't get too specific. Use either, "Hey, this story is going to take either minutes, or hours, or days or months." T-shirt sizes, small, medium, large et cetera, is another popular system. Some people use the Fibonacci scale, and some people pair that with this activity of playing poker, where you talk about a story, all the developers put out a card, where they say how big they think it is. And if they're pretty much similar, then you move on, if they're not, then what you're looking to discuss there is there variance in everybody's understanding or is there a difference in how they think they would approach this feature? And that's a good thing to talk about. The main thing here is we're all optimists at heart. We don't want to just push people to create estimates that are beyond their envelope of visibility. You want to be able to think about, "What am I, the product manager, really trying to get out of this? Am I trying to just roughly prioritize things and make sure that I don't think this little thing that I thought I wanted to do now because I thought it was small is actually big, and I find that out and I changed my priorities." That's a relatively good reason to want to do these. But there are also a lot of really wasteful reasons, which is like having a super precise schedule, which you're just not going to necessarily probably know. So the best way to do that is to keep things general, stay focused on relative priorities and use tools like playing poker to add a little levity to the whole thing and keep it from getting too specific or too serious. Another question is, do you use the burn down chart? This is something where you add up the size of those stories and then over the period of your iteration from start to finish, you track on day X, day Y, day Z how you're burning down these stories. This is a relatively linear one. Oftentimes, they don't look like that. Some teams find that helpful, others don't. Many focus instead on what's actually happening, and they look kind of after the fact. What is our velocity? How many stories do we usually finish in a week or a cycle? That certainly introduces less overhead into trying to create a prediction about what's going to happen over an upcoming cycle. So there's a real job, I mean, you need to know what's going to be in a release or how soon something is going to come. But there are certain ways to do that that are more productive than others. Let's talk about another job. Introducing personas. It is really, really important to acquaint your development team with who the user is and what kind of makes them tick. It's a big part of that desirability dimension and creating intersection with that and feasibility in your engineering activity. One fun way to do that is you've gone out, done this research with these users and you brought back a bunch of photos, and you can play this game, day in the life. And the way the game works is you show a series of photos from the research you've done on personas, and then at the end, you ask the team a bunch of questions about the persona. And there's no right answer to the questions, but the right process is to infer your answer based on what you saw. These are examples of the kind of photos you might have from your work on researching the personas. These are examples of some questions you might ask. These are all kind of fun questions, but you can also interleave some more substantial questions that have to do with the way your customer might use the product. And the purpose of this really again is just to get them interested in that user and get them a little bit familiar with who this persona is and maybe if you're lucky, persuade them to go sit down and read about the personas as they're thinking through their users stories. The demo is something where I know in my experience, I was a sales engineer for many years. We always just tried to cram as much functionality in the demo as we could. It was usually stuff that wasn't quite ready. It was kind of breaky, and we were always push it right to the edge. A lot of the time, we did break stuff. And at the end, we were always like, "It was so dumb because the audience really just wanted to know why did we build this, and what are we hoping is going to happen." All the little details of the software that we thought were so important to invest all this time in preparing, that really didn't matter, and we stretched ourselves out. We broke stuff. And I don't know why we did that. Some kind of weird negative target fixation, but I think it's relatively common to just you know you're focused on the software, and you're focused on implicitly all the things that you wish were different about it. Instead, start with the audience to focus on what outcome you want with them from this meeting and then design the agenda that way. And you'll probably find it has a lot more to do with explaining what you've learned, the validated learning that led you to build what you built, and what outcome you are looking for in some kind of conclusion, output to the meeting. The retrospective is one of the most important parts of a strong high functioning interdisciplinary team and the practice of agile. These are examples of the kind of questions you would ask, and what you're really driving to is this question of how do we want to work together differently? This is not a meeting about who's doing the most work or blaming people. You may want to accept those things or change them, but that's a different issue. This is about the process that you use with your interdisciplinary team to work together and how to change that so that it becomes better. Another popular technique as you're going through the answers to these questions is the five whys. So let's say we're asking, why did this bug make it out to production? And the answer is, well, we didn't run such and such a test on it. And then we ask, well why didn't we run that test? The idea is not to be like because Bill forgot or Jane forgot but to ask do we need to fundamentally change the way we're thinking about our test infrastructure or are our integration process because those are better answers. They're more actionable answers because, again, you're not trying to fix or blame one little thing that happened. You're trying to think about your overall process and how over the longer view of you working together with this team, how you make it better. Finally, I would always take the time to create an agenda. If you're going to call a meeting. We started in the last video with this idea of how much a meeting actually costs a lot. And I guarantee it's worth 5, 10, 15, even 20 minutes for you to put together the set of questions you're trying to answer. Probably, even time-box them to keep the meeting on track, specify the output you want from this meeting and really think about who needs to be there and why. And so perhaps even pose the question of if they need to come or not. These are few ideas that'll make you a stronger interdisciplinary collaborator. Try them out. See how they go. Some will probably work better for you than others. Those are a few focal points to think about.
