 So I have not been through this deck before, this is a brand new presentation just for you. I do have a presentation that's very similar to this called Building Better Products. It's mostly about extreme programming. And I touch on product management in it. I think you guys know about extreme programming already. So I figured it would be best to just do something that was more focused. So, extreme product management. Okay, that's me. You guys don't need to know more about me. Alright, these are two of my favorite quotes about that. First off from Eric Brees, the author of the lead startup. Thinking big is not at odds with starting small. This is one of those things that we have trouble communicating to our clients often, right? Because the clients walk in and they're like, No, no, no, not just this, but we have to coach them to get down to this, right? And build lots of little ones and things in order to get to the big thing. The other one that I really like and that I think is particularly applicable to labs is from my friend Dan Ward, who says the most successful project leaders from government and industry alike tend to deliver top shelf stuff with a skeleton crew, a shoestring budget, and a cannonball schedule. When you make everything small and you apply constraints to things, you deliver better products, and that's what we do here every single day, right? We're coaching our clients to make the smallest thing they can make in order to make the best thing they can make. If you like this book, the book Fire that Dan wrote is awesome. It stands for fast, inexpensive, restrained, and elegant. Dan was with the Air Force for 20, 25 years and he worked in procurement, and he did a study where he found that projects that had constrained budgets and constrained schedules and small teams were almost invariably more successful at delivering good outcomes than projects that had huge budgets, long schedules, and massive teams. And the book is all about that, so you should totally agree. All right, everybody here should be familiar with the Agilman Festo, right? This was written in February 2001 as a reflection of the current state of best principles in software development. And it still holds true today, both as a reflection of an influence on modern software development, but in the last five years or so, and really the last two and a half to three years at labs, the values of the Agilman Festo have transcended just the software development side and spread to design and product management as well. And I think this is due in large part to the advent of Bamal's team. As an idea, I'm going to talk about Bamal's team in a while. We can also start at the menu X, those of which were heavily influenced by XP. And as I talk through how product management works here, you'll see how each of these aspects of the Agilman Festo comes through. So I'm going to touch very briefly on this here, because it's at the center of everything we do. So, after the labs, we practice extreme programming. And as we saw in yesterday's lunchtime video, was anybody absent for yesterday's lunchtime video? Everybody was here? Is Ken Peck video endless yesterday? Damn. You got to go see it. So Ken Peck is awesome. Always good to see. So anyway, as we saw in the video yesterday, XP was pioneered by Ken Peck, one of the original signatories of the Agilman Festo. And XP asks, how little can we do process-wise and still build great software, right? We don't want to get bogged down in processes and documentation. So let's always work with the bare minimum that's necessary. Second, building software is hard and often runs into unpredictable difficulties. So how do we make a system that can recover quickly from these missteps and turn failure into something that is more successful? That's not what I wanted. I want to scroll my notes. We also need to be able to provide better options for making business decisions. We can only do that with a flexible system. This whole system is driven by a core set of values. Communication, simplicity, feedback, and courage. If you feel like you need to pressure on me this stuff, as Ken mentioned again yesterday, the second edition of XP Explained. Personally, I think the first seven chapters of the second edition of XP Explained are some of the best business advice that I've ever read anywhere. It's about the socio-emotionally requirements for being a good participant on a team and creating good products. So if you haven't read it, please do not. If you have read it, but it's been a long time, it might be worth revisiting. So with that preamble, let's look at what a pop measure actually does. I'm going to start by looking at a couple of job descriptions. Yes. This I was looking for. For people working, it ends up looking like Burger is mansplaining to Laura, which is not exactly what I wanted, but it was the best one. That seems far me. Far me versus construction. Burger is... Have you met Jonathan Burger? He's a very interesting man. Anyway, so we're going to look at some job descriptions of product managers. What do you guys think you're going to see? Anything in particular that you think you're going to see in these job descriptions? Massive confusion between product and project manager. Slave driver time. Okay. What else? Ridiculous little salaries. The job descriptions seldom include salaries because they wouldn't need to actually come in first and then they'll tell you. So, slave driver of time. Agile certifications. These are from the outside world. These are not our job descriptions. So, it's a good start. I think you're actually going to be a little surprised. These are from a relatively friendly organization though. So this is one of the fairly typical descriptions of a product manager. It has things like develop a product vision, discover a product market fit, know how your products are being used, use data to improve your product in the moment or somewhere. What is dual tracks from? What is what? User testing dual tracks from the second point of the talk on the end of the talk. Dual tracks from. Dual tracks from is probably too extreme. If I had to guess, you've got two work streams. They're managing the mobile back end. Yeah. So this one's actually, it's not so bad. They're looking for a few technical abilities you can see down here. But more importantly, they're asking for an ability to adapt agile methodologies. Just a good sign since we're talking about adaptation and not just adaptation. This is, I was going to say, this is more like growth hacking. And that's not outside the realm of what many product managers do at companies that are full time product companies. So we're a consulting company, we're a little bit different. Some of the things that you can see here are totally normal for product managers, but we just never get the opportunity to do them here to stay with the client long enough. Like finding a product market fit, we're almost never on a project long enough that we're able to guide that product to a product market fit. So for those of you who aren't familiar with the term product market fit, it's where basically demand for your product requires you to scale. So you've gotten to the point where your customers want your product so much that now it's time to scale your operations. We really never see that here. The products that we build are often so at the stage that we don't get to see whether or not there's enough demand for it to keep moving. Anyway, let's take a look at another one. This one's similar, but it has some slightly different words. One of the things I like here is it's asking for the ability to gather and synthesize feedback from customers and use it to define a product roadmap which is something that I agree with a little bit less and functional requirements. Let's say champion customers internally is a nice one and creating a tight feedback with engineering. Those are good. Some similar technical requirements, but it adds things like the ability to think about the vision and an entrepreneurial streak that I created about the Merrill Street, the strong business agreement. These are all good things. A few good things in this one too. It's looking for someone who is a people person who's able to drive large complex projects to completion, although I'd argue that a big part of our job is seeking simplicity in those large projects. I love that this one actually touches on metrics, actually defining metrics. That's a big part of what management should be doing and I'll talk a little bit about that in a while too. Finally, someone mentions collaboration here. I'm not sure where they have it, but I know it's on here. Collaboration is essential to everything we do as you guys should know. This one is a little scary and I put this one on here as a contrast. This one comes from a very large wealth, it says, that comes from city. It's asking for things like driving customer loyalty and driving business value and all those things that should be considered ancillary outcomes of driving customer value. That's not mentioned here anyway. Cities apparently doesn't care if they're providing value to you as long as you're providing value to them. That's not what we do. So here I repeat the last one. About who put the product manager before. You said that they must for somebody to drive. Right, so city groups post for a product manager is looking for someone who can drive customer loyalty. Oh, can you come back? Did you say the city group one? Oh, interesting. They've been looking for someone for three months. Probably a different post. They're looking for a VP of product management in the city board. But that's not the post that I chose for this one. Driving customer loyalty is something that is good for them, but there's no expression of value for the customer. I feel like that's the wrong direction and it's not the approach that labs product managers would typically take. They also talk about driving business value. Again, no mention of the value of the customer. As long as the customer is providing value to the city, they're cool. There are also product managers in the world who can have nothing to do with software. I just wanted to throw this up here for an example. There are products in the world that are not made out of ones and zeros. This is actually for a trade product. It's a trade-related thing. I can't remember what TTS stands for. Treasury and trade solutions. Is there even a situation in Puerto Rico right now that's hilarious? Some of the responsibilities of this person are similar to some of the responsibilities you would see in a software manager, but they are not the same. You guys don't Puerto Rico's bankrupt, right? Puerto Rico's bankrupt. What are the most important things to look for in a product? I already saw that one. What are the most important things to look for in a product manager? First off, she needs to be able to develop a product vision. Actually, seeing what this product could do for customers. Discover product market fit. Again, not a thing that we often get to do at labs, but it is important. And as consultants at labs, we do get to coach our customers to help them figure out what product market fit is going to look like for them. In some cases, not in any case. Understand and advocate for customer needs. So if this is the gathering and synthesizing feedback from customers and championing the customer internally, I think this is a huge responsibility of the product manager, as it is shared with the design team. Understanding product metrics and knowing where to look or go out and spacing on that kind of stuff. So what is it that makes this difference? It turns out, if these are things that product managers do everywhere, what makes this difference? Oh, we also work collaboratively. It's not just the costumes. What makes this difference? This is the PM team from San Francisco about a year and a half ago. Sadly, the only one who's still in San Francisco is Sitchell. He's in Ireland. She's in Sydney. She's in Tokyo. He left. And he left. But we have a new team there that is equally awesome. They just don't tend to wear as many costumes. So the thing that makes us different is we are extreme. That was the highlight of the whole thing. You guys can like focus on your lunches. So what does that mean to be an extreme product manager? First, let's take a look at what extreme programming looks like here. We'll see how this all transfers over. So first off, XP here is team focused. This goes back to the Agil Manifesto. Individuals and interactions over processes and tools. We have small teams. We prepare all the time. We care about each other. We treat each other well. Second, we are values driven. We believe deeply in communication, simplicity, courage, and feedback. There's four things that Kent Beck talks about in XP Explained. We have stand-ups, retros. We sit shoulder to shoulder with our team. All of these things that we do are reflections of our values and reinforcements to this model. So the values are important. We are predictive rather than prescriptive. We don't use velocity as a bludgeon to meet our engineers with. We use it as a predictive tool. At least ideally. We're test driven. TDD to the core. We write the test first. We learn from it. We write our code to pass. This was one of the things that Kent talked about yesterday as being absolutely fundamental to what XP is. And finally, we're iterative. We work in small increments. We deliver the smallest and verifiable units of customer value. So this is what makes our engineering organization extreme. But how do these things apply to product management? First off, we're team focused. And what does that mean here? So let's take a look at how a normal team works. Typical product managers, sometimes called product owners, sit in this awkward middle space between the business interests and the engineering team. You can have agile over here. All the agile in the moment. But your organization isn't really agile and you're not really getting the benefits out of this unless you change the structure of this event. This ends up being a very painful position, right? Because it turns out that you've got all these people who are giving them requirements. And it's your role to pass those requirements under these people who are pushing back on those requirements saying that that's a good way to do that. And so this person always ends up being very unhappy unless they're making a maniac, which some of them are. And then they're just impresant to work with. These people are required to create a long-term product roadmap that's always based on someone else's business vision and then ensure the engineers build that roadmap. So the model that we prefer to appear to here is called Balanced Team. Is anybody familiar with Balanced Team already? You are. Have you been to a Balanced Team meeting or a conference or anything? Balanced Team is a real thing. It's not just a couple of words that are jammed together. This group has been around since 2009, I would say. And they have conferences and they have regular meetings. And one of the things that they were trying to do back in 2010 was figure out how to make design work with agile because the design process has typically been a very waterfall process from ages on. And so this was a group of people who were agile practitioners and experienced designers getting together and talking about how do we actually change the design process to make it fit. And that was where Lean UX was born. So Janice, my wife, was a member of this group and she was going out there and talking to these people and figured out that Lean Startup could actually be the key to make design work better with agile. And so she brought that to them a very long time ago. But anyway, the idea behind Balanced Team is that instead of having one person who owns the product you can call for one second. Anybody here know Ian McFarland? Ian, old school, he probably is the one responsible for opening this office. He was then the one responsible for buying this office for me and Halloween when we started. Ian has this thing. Own. Stands for one. One. Ring of all. Neck. I love that. Instead of being a product owner, being that person who's stuck in the middle between the business and the engineering team, we can have business representation in the form of a product manager working together directly, side by side with engineering and design in order to steward the product to a successful outcome. So this is the product in the middle here. And instead of having one person who owns this thing and everybody else works for them in this command and control of a life relationship, everybody on the team is responsible for producing a successful outcome for the whole team, right? So in service to the team, the engineers get to say, you know what, I have a really interesting technical solution for that problem. I understand that problem because the design team was able to identify the problem with the customer and explore the problem deeply and communicate that well to the rest of the team. Given that information, I have a good solution for it. Product management then gets to say, you know what, the business interests that are involved here actually require this one little tweak and then we can make a solution that's good for everybody, right? We're looking at things that are not only feasible from a technical perspective and desirable from a customer perspective, but they also have to be reliable from a business perspective, right? So each one of these, you know, legs of the stool or blades of the propeller, I guess, is probably better for this illustration. Each one of these has their own area of responsibility that they get to contribute to bringing the product to a successful outcome. But like Kent said yesterday in his talk, no problem at Facebook is someone else's problem, right? This team works together and everyone on the team is responsible for making sure that we're successful. So if you see a problem, you have to speak up about it, even if it's not technically your area of expertise. So, let's see. I think it's really important that the last part is what you mentioned about the ability to speak up and to be able to do so without people feeling like you're stepping on their toes by suggesting something. Yeah. When it's the culture of the team that we're all working towards this one common goal and we're all willing and able to let go of our own goals and let go of our own need to be right all the time about things, then everybody's able to step in when something goes wrong and take care of it, right? But if the people on the team are proprietary, there's things, right? This is one of the things that pairing helps to overcome, right? So, pairing is there for a lot of reasons, but one of the reasons is to prevent coach hoarding, right? When somebody goes off on their own in their own little hole and counts out a bunch of code and says, this is done, I solved that problem. You guys don't have to think about this anymore. Suddenly they've got this little thing that they own, right? And if you start to question it or poke at it, they're going to be all defensive of it. No, no, no, I solved that problem. Let's just move on to the next thing, right? And you don't want that on a team. It's like, it's... That's the one that I used to get a lot about and I used to get a lot in some of the larger organizations that I work with. Ownership. Ownership. Ownership. Yeah. So, the model here is stewardship, not ownership. And that actually comes from Tim McCoy where he was design director at Labs for a while and now he's working in the data group at Labs, but we're not at Labs at the moment. But he was one of the original founders of the balance team to the concept and product stewardship was his, like, one of the big things. So, Kent mentioned pairing in his talk yesterday, right? And it's absolutely fundamental to extreme programming, but it turns out that that this pairing that our engineers do is equally valuable across other rules on the team. So when PMs pair with designers or business partners or engineers, we get the same benefits, right? And those benefits are things like faster, more elegant solutions, reduced errors, better team continuity, and no hand ups. All that makes sense? So, next. So we talked about team focused. PMs here are values driven, right? We believe deeply... It's too bright in here. We believe deeply in communication, simplicity, courage, and feedback. So product managers are often in a position of helping our clients to understand and embody these values. And we're the ones who end up having a hard conversation with them about how their behavior affects the team and ultimately how that effect on the team and how that impact on the product. Right now, you're serving role product manager and you're having to have these hard conversations with your customer. And many of us, even as engineers or designers, we're going to have these conversations anyway or as we are. But it seems, what I've seen in lab's offices back home over the last two years is that somehow it often ends up falling on the PM's shoulders to have these conversations because they're typically the one... Since they're kind of abstracting the client from the anchor, they're the one who spends the most time like sitting shoulder to shoulder with the client and looking at the backlog of prioritizing. So we have to help them simplify. We have to help them give and receive honest feedback and have the courage themselves to tell their stakeholders the truth about the ongoing project. I don't know if any of you have seen clients hide things from their from their superiors. Is this the thing? A nod here or there? Yeah, it doesn't help the project for the long run, does it? So if you're sleeping problems under the rug, they're going to creep out at some point and cause problems later. So we have to help our clients understand and deal with that. Next, we're predictive rather than prescriptive. This is kind of really where the rubber means the road here for our PMs. We have the hardest conversations with our clients in this category. The biggest part of our job is helping the client understand how to manage and prioritize the backlog, right? And understanding that a backlog is a single track prioritized list is revolutionary for most of our clients. And for some of them it's uncomfortable. Like, what do you mean we're not going to parallelize and what do you mean I'm not going to get everything I want? So everybody wants to know that they're going to get all of the things in the amount of time that we have. And we know that promising scope and time is a recipe for disaster. So we say, yes, you will get everything you want in the amount of time we have. But in order to do that, we have to choose what we want. We have to limit what we want, right? And that can be a very challenging conversation. So we work with the client to refine the product vision and pare it down to the bare minimum. And this allows us some room to add in new features at any point in the process as long as we're willing to prioritize other things. And this way of working along with the automated iteration markers in is easy to see the cost either opportunity cost or costing time associated with adding scope. And it lets us incorporate the things that we're learning from our users while we're building the product, ultimately shaping the product into something that is small, simple, and hopefully maximum useful. Next, we're test driven. We do experience, didn't get my experience Yes, to the extent that our clients are ready for it, we work to validate our product vision and features by crafting small experiments. Not every client is going to let us do this, right? A lot of clients are going to come in and they're just going to say we need to build this thing, I don't care if you think it's the right solution or not, that's it. So, this is actually way before product market fit. This is the stage called problem solution fit typically. And there's a good book, if you want to know more about this stuff, called The Entrepreneur's Guide to Customer Development. It's by Grant Cooper and Patrick Blascovitz. It's like the Cliff's Notes and Steve Blank book, four steps to the company, which no one should ever read because it's so awful. And in fact, if you go to a conference and you stand up in front of 400 people and say