We have seven methods we're going to focus on over the course of this week. I thought we'd take a minute and talk about how they might apply to you depending on which general quadrant of this matrix you kind of fall into in your current product management role. Agile is an approach to developing product. There's a lot of different flavors but generally speaking, if you're at this lower level of abstraction, so for instance, your P.O. plus PM. product owner and product manager, you're probably, more likely to be on an agile team working day to day. And if you're not, if you're a PM that's not a P. O, you're probably creating propositions and perhaps, participating in story writing or backlog grooming workshops with a P. O. Or a P. O. plus PM. at this lower level of abstraction and that's kind of your interface between these two areas. Agile is intense, so you don't drop in and out of an agile team, you're either in it working with them with tweak or you have some kind of interface to them as a stakeholder sort of, you're giving them the right inputs and they're giving you outputs that you all can work through. But, you're either kind of, in the team or you're not in the team because this idea of whole team in that focus with agile. Design thinking is a very broad, rubric, and it can apply to a lot of different things. If you're at this relatively higher level of abstraction in your business facing, you're probably going to be more focused on going out, learning about the customer, and encapsulating that in personas and problem scenarios or job to be done, as another popular term for that, and then, testing value propositions through Lean Startup and so forth, with the customer and taking your validated learning and passing these down to a lower level of abstraction where they're going to work on, they're going to translate those into things like: user stories, prototypes, and they'll hopefully be doing a lot of user testing. Now, I'll just take a moment and point out that these are matters of degree. The whole point, in an innovation friendly environment, you don't have these kind of strict handoffs and you know Chinese walls, mean, the boundaries are relatively fluid. If you're in an agile team, you're focused on working with them full time but that doesn't mean there isn't, sort of, a fluid interchange of ideas and concepts and things like that. So, take these more as a matter of degree, not some kind of hard boundary between people that should exist because it shouldn't. But your relative focus will be on these things if you're at this higher level of abstraction, if your business facing and probably more on these things, if you're more down in this other quadrant. The hook framework is a way of understanding user habits and how you might need to manage them or change them to make them work with your product, and we're going to go through that this week, but this is something that is particularly useful when you're learning about the user, so you're more kind of, up here, and it's something that you'll want to monitor carefully, if you're more so down here. So, here we kind of ask, Why does the user do what they do and what makes them tick? And then, here perhaps we're more so looking at, what actually happens when we release product to them. How are these habits performing? And, like many of these methods, this is a great way for people working across these dimensions to communicate with each other but your relative focus is probably more on the, why are people doing things? If you're up here and more on, what's actually happening? How is our product performing in the field if you're down there? Lean Startup is very, very useful for testing value proposition, so you don't generate a lot of waste, and it's probably something that you are more executing if you're up here, where you are formulating those value propositions and testing them, hopefully, with product proxies. So, hopefully, we're able to use proxies for the product up here. So, an example of a product proxy is when we took the telephone, a mobile phone, we duct tape it to the bicycle, and we verbally gave the cyclists guidance to see what that experience was like for them and if it was valuable. Whereas, the actual product the talking bicycle compass or perhaps the app that runs on the phone, that's down in this lower level of abstraction. So, if you are doing Lean Startup, you're probably creating validated learning up here. And then, if you're down here, you're probably still using Lean Startup to a degree in the sense that, you are looking at what's happening with the individual features and you're making sure that, as you build stuff, you're instrumenting observation into it. So, up here, you're hopefully working with proxies, down here you're presumably working more with real product. Story mapping is a way to take your agile user stories and lay them out in a narrative that's kind of anchored by a storyboard, so that everybody has, it helps drive to a shared understanding of what are we trying to have happen for the user. And this is again, a great place to drive a more successful, a more fluid interchange between people working at different levels of abstraction. If you are at the higher level, you may be more so, helping create these storyboard squares that tell us what's happening with the user. And if you're down here, you're probably more so, interacting with the user stories and the various outputs from those that you used to translate into working software. Again, this is just your kind of your relative focus. The whole point of the story map is to create a more fluid interchange between people working in different areas, different levels of abstraction. Prototyping, in the sense that we mean here, means you're going to use tools to create kind of fake software that renders the interface that you might actually want to create and it's easier to iterate on, it's very quick and fluid. If you're creating for instance, interactive prototypes to as kind of a precursor to your working software, say, working software, precursor here. You're probably working at this lower level of abstraction. But if you're generating ideas and concepts about for instance, what user interface metaphor might be appropriate for the user here at this point, you're probably working more so up here at this higher level of abstraction. Now, in Lean Startup, we have this idea of a Wizard of Oz, which is we create kind of, almost like a product demo or a version of the product that looks like it works but it's really not working, and that's a product proxy. So that would be more so up here. But, by prototype in this context, I'm more so mean, things that are precursors that are inputs into how you're going to approach the working software. That is more so done here when you're working on the implementation. Usability testing is likewise probably more so done down here, where you're working on those specific details of exactly how you're going to approach the implementation. And at the higher levels abstraction, you're understanding those results and you're interpreting them. These methods, I think you'll find them useful even if your product and what you're working on is more on that engineering side of things. Because remember, even if you're developing things for a relatively technical audience, developers are people too. They have needs, they don't want to have to spend a lot of time, they're very resourceful and very energetic about figuring things out, and they'll do that if they have to, but they don't like to have to spend that extra time any more than anybody else does. For the most part, when they have a job to do, they're under, probably, time pressure, and pressure to get things out. So, I think all these techniques apply because you want to make sure that, that audience still is well understood and that you have the right focus for them so you are building something useful. So I think that, regardless of the product management role you're in, high level of abstraction, low level of abstraction, business facing, engineering facing, there are really useful applications of all these techniques and I think that you'll find them very helpful for your work as a product manager.
