Methods and PMs

We have seven methods we’re going to focus on over the course of this week. I thought we would 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 you’re PO 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 PO, you’re probably creating propositions and perhaps participating in story writing or backlog grooming workshops with a PO, or a PO + PM, at this lower level of extraction. 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 week to week, or you have some kind of interface to them as a stakeholder, so that 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 there’s this idea of a whole team and 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 and you’re 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 is 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 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 hand-offs and Chinese walls, meaning 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 well, 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 then 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 forming?

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 the what’s actually happening, how’s 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, the mobile phone, we duct taped it to the bicycle, and we verbally gave the cyclist 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 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 story board 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 use to translate into working software. Again, this is just your kind of relative focus, the whole point of the story map is to create a more fluent interchange between people working at 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 easy to iterate on, it’s very quick and fluid. If you’re creating for instance interactive prototypes as kind of a precursor to your working software, let’s say working software precursor here.

You’re probably working at this lower level of abstraction, but if you’re generating ideas and concepts about what, 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, that’s a product proxy. So that would be more so up here, but by prototype in this context I more so mean things that are precursors that are inputs into how you’re going to approach the working software.

And so that is more so down 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 level of abstraction, you’re understanding those results, and you’re interpreting them. These methods I think you’ll find useful. 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. 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’re 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.