Missions, Sensemaking, Structure, “Agile”, and the Why

This is Part 2 in a great conversation I had with Annie Dunham, ProductPlan’s Director of Product. I love chatting with the folks at ProductPlan as they are diehard product nerds.

The original version of Part 2 is available here. Part 1 is here.

Annie and I delve into the changing landscape of product management, sense-making, missions over projects, and org structure.

Dana Solomon from ProductPlan tossed out some great questions.

But first an obligatory quirky doodle from my 100 Day Doodle Challenge (aka my quirky Medium cover photo respository) so that Medium actually lists this as a new post, and 3x+ more people actually give it a chance.

BTW. Thanks Dana!

Earlier, you both referred to the idea that there’s been a shift in product management, that due to the evolution of technology, the rise of SaaS, and other factors, many product managers are more accurately managing product “systems”. If you’re a product manager managing a product system, what else changes beyond the “product” itself?

John Cutler: Practically, you’ll also see the rise of mission-based teams, rather than the older notion of a project-based team that “completes” a project or product at some point and is “done.” The concept of a product development process that has a beginning, middle, and end is now basically defunct, especially in the context of SaaS. Your product is never complete, and the ongoing user experience associated with it is now part of your product.

Annie Dunham: At this point, you have a product team with a shared mission and a shared sense of responsibility. You have a product process that doesn’t end the day you launch a product or feature. This means that everything from the way you think about your product, the way you quantify and measure success, and the way you structure your roles and teams, fundamentally changes.

How does this shift change the way you approach your environment?

John Cutler: Sensemaking becomes critical. You need to know what your environment is like in order to figure out when you need to let something go or cut your losses. You can think about the product team as being a team that makes bets. The more a team understands their environment, the more likely they are to successfully gauge demand, risk, etc., and make successful bets.

There are two ways to think about the broader role of a product team. The first is that product needs to just keep their heads down and work on a product. The second perspective is that product needs to be involved in and understand the bigger product system we’ve been describing. The less isolated the product process is from the broader context, the more room there is for innovation.

If you move away from that first feature-focused product development model, and move toward the second option, how does your criteria for success change? You’re describing a state in which there’s no objective endpoint, i.e. ship a product or feature and move on. How do you know what you’re doing is working if your product is an ongoing system?

John Cutler: Well, one way to get this wrong is to assume that because a company is doing really well, it somehow means they’ve got the perfect system; they might just be doing well at the time, for now, and could probably do really well for a while, but eventually, at a certain scale or pace, things will start to break down. Don’t mistake current success (revenue, PR buzz, etc.) for the ability to adapt and succeed in the long term. As a product manager, you have to realize that each company is really playing their own game.

Annie Dunham: Are you a successful product manager if your company made a lot of money but everyone at the company resents the product organization and product development is a miserable process? Or, if you create a completely nimble environment in which everyone is agile and happy and can jump on any project that comes up, but you’re maybe in the wrong market or solving the wrong problems. You need broader, heads-up awareness to create processes that can scale, adapt, and hold up in the long run and align with changing customer demands. The more you’re thinking about your product as a living system that’s addressing an equally evolving market, the more likely you are to adapt gracefully.

How does this impact how you think about the role of the individual contributor or the team as a whole?

John Cutler: When I was at Pendo and AppFolio, I often found myself aligning around and thinking about engineers. Engineers are often some of the people on the frontlines that feel the pain of decisions made without much situational awareness. Recently, I wrote an article called “12 Signs You’re Working in a Feature Factory” that generated a ton of interest from engineers in particular. It showed me that people genuinely care about the work that they’re doing and don’t just want to show up and keep their heads down. They want to be creative and they want to think about their work in terms of the bigger picture.

Annie Dunham: Agile started to really take hold about 10 years ago and people were excited not because it was a perfect solution but because it gave people a starting point to think about working iteratively. Now there’s more of a nebulous answer to how people are thinking about and approaching product development. You might have a situation where one person is great at this methodology, and another person is more familiar with another one, and these 3–4 engineers are used to working as contractors, and so on. How do you make the most of your team? The answer is not necessarily to shove them into a specific framework. You might need a more flexible methodology to balance individual creativity and experience with the broader goals of the team and organization.

John Cutler: Some of that flexibility and innovative thinking would be well-applied in operations. There’s a lot of overhead in operations. It’s a commonly misunderstood idea, but Agile is really less about moving quickly, and more about moving frequently. The more rigidity there is in terms of operations, bureaucracy, etc., the less likely an organization is to adapt and remain agile.

Annie Dunham: Another way to approach the topic is from an enablement perspective. Are you structuring your product organization in a way that opens the door for novel thinking, organization, activity, etc.? Is product leadership exposing key people directly to what they need to be exposed to? Rather than being the owner of this or the communicator of that, are you opening yourself up to something bigger and cooler? Are you getting more into design thinking, observation, innovation, instead of just saying “Here’s what the customer says, let’s just do that.” It’s important to leave space for the kind of emergent thinking or behavior you see in dynamic systems. That’s how product teams can break into new territory.

John Cutler: I think part of the right way to approach individuals and teams working within these new systems is about creating valuable contexts. Set the context in terms of threats and opportunities, and then help people play the game, manage resources, and get work done. The product team doesn’t need to constantly hover and provide micro-prescriptive boundaries but they certainly can provide valuable context and understanding. Systems thinking and sensemaking help you devise and wrap your head around the bigger game we’re all involved in.

So what do you tell new product managers entering the field, or veteran folks wondering how to best approach these new shifts?

John Cutler: If we’re shifting away from tactical user stories, traditional development processes, etc., and you have a junior person coming into the product world, you’re kind of throwing them into the deep end. We should really be focusing on and teaching the core principles of product management. For new people, I want to help them build first principle skills: can you communicate to customers, can you do awesome interviews with customers, can you map the competitive ecosystem we’re working in, can you help facilitate activities that help with sensemaking, i.e. story-mapping activities? In the long term, these first-principle skills will help them as speed and complexity scales up.

Annie Dunham: More than ever, product folks need to understand the “why” of what they’re doing. The basics are definitely still there in the systems context, but helping new product managers develop skills to keep the bigger picture in mind will provide the best type of orientation. Here, “bigger picture” is the broader product system we’ve been discussing: the individual product or feature, the customer challenge, the business case, ongoing updates and support, the feedback process, competition, changing markets, and so on. The core lesson is that none of the work they’re doing will be happening in a vacuum. It can be tempting to have a product manager start with a specific feature or component and work up from there, but that kind of bottom-up approach can be a disservice in the long run.

John Cutler: Another useful shift in thinking is the idea of a product manager owning an actor or a set of actor goals in a system, instead of just owning product modules or components. A product manager might be the product person for the customer success team with the goal of helping that team reduce churn through changes to the product. That’s a very different way of defining how you bring people up to speed in product but it’s an effective way to illustrate the idea of the product system and help encourage the kind of sensemaking we discussed earlier.