Menu

Subscribe

Get everyone out of the building - or how Product Managers are like Fire Fighters

on 2021reflection, Product-management

Introduction

It has been (almost) a year since I’ve become a product manager. The journey has been nothing short of fun and excitement. I learned a lot of things along the way, and I also shared many of them (on Product Strategy and Product Development Frameworks).

Last week, I was reflecting on what are the most important ideas that will become my closing remark on 2021 with respect to my professional life. Some ideas came to mind, and I’ve been trying to flesh them out and combine them into something that sounds profound (lol). Though, I must say I’m quite amused by what I’ve come up with, regardless of how profound it actually is.

Hopefully, by the end of this blog post, you would share some of my amusement.

A naive application of “Get out of the building” is subtly problematic

One of the ideas I’ve taken seriously this year is “Get out of the building”. I had to shift from building software according to requirements to determining what is the most important thing to build. This means to get out of my own head, get in touch with customers and try to understand their problems as clearly as I can.

But that’s not the main idea I want to talk about. In fact, I want to warn you against a naive application of this advice. If we naively try to apply “Get out of the building”, we may end up with a paradigm that isn’t wrong in any obvious way. It doesn’t result in dismal failures, but it also doesn’t lead to a sustainable impact either.

In this paradigm, product managers “get out of the building” and go talk to customers to understand their needs and pain points. Then they come up with an idea about a solution. Then they work with designers to create mockups, and work with business analysts to create detailed requirements. These artifacts then are handed off to engineers who will build the software. There are testers who make sure that all the requirements are strictly adhered to. We may also incorporate usability testing, as well as gathering feedbacks to validate our solutions.

While it isn’t wrong in any obvious way, there are two problems with this paradigm:

  1. A naive application of “Get out of the building” overestimates the ability of an individual to solve wicked problems.
  2. A naive application of “Get out of the building” creates an alignment problem.

It overestimates the ability of an individual to solve wicked problems

One problem is that it overestimates the ability of a product manager (or any individual for that matter) to be able to identify the right user problem, come up with the right idea for a solution that addresses both customer and business problems, without invoking a wide range of expertise that’s most likely only possible by involving others early on.

Of course, a good product manger must have sophisticated mental models about the business as well as the users. But even then, choosing which problems to pursue, deciding which ideas are testable, usable, lovable are wicked problems that require more than one person.

For example, if you want to build a delightful product, you must have a delightful user experience. While PMs need to know about UX, it’s not exactly our expertise. On the other hand, designers know a lot of things about UX, but they can’t exercise their expertise optimally if they’re working on prescribed solution ideas.

It creates an alignment problem.

It also leads to an alignment problem, because we’re cutting everyone else from accessing the understanding acquired from talking to customers. As a consequence, it isn’t clear how our work affects our customers, or whether what we do is worth doing at all.

There probably are engineers who only enjoy solving technical problems and don’t care much about anything else, but it’s safe to assume that most people are more motivated to work when they understand the bigger picture of which user understanding forms an important part. Otherwise, it is very easy to feel disconnected and disempowered, especially when we’re doing hard things such as product.

Having a team that’s not properly aligned doesn’t have immediate consequence, but silent disagreements, lack of a reason to do their best work, and other subtle side effects will ultimately manifest in very real ways.

It prevents everyone else from building up shared user understanding

By assigning the responsibility of talking to users to PMs only, we’re preventing everyone else from building up user understanding themselves. It may work for a short period of time, but such a configuration is fragile in the long run. What happens if the product manager leaves? The user understanding in that person’s head will also be gone. It’s a single point of failure system that becomes stale or chaotic whenever failure occurs at the critical point. The cost of hiring and training new product managers to obtain the equivalent level of understanding is sometimes prohibitively expensive, especially if your product exists in a niche category.

Taking the idea of “Building shared understanding” seriously

A naive application of “Get out of the building” is subtly problematic. One such problem is the alignment problem that results from a lack of shared understanding. The idea of building shared understand isn’t new, but I think it hasn’t been taken seriously enough. Cedric at Commonplace wrote a wonderful blog post on taking a simple idea and take it seriously . When we have an idea that’s simple and useful, we should examine the second and third order implications before moving on.

Building shared understanding requires you to shift your perspective from “how do I enable everyone to work as effectively as possible?” to “how do I empower everyone to participate and co-create the picture that we’re building towards”.

Implementing this would run into practical constraints real quick, but it’s important to fix the idea and work around the constraints, rather than distorting the idea itself.

  1. Taking the idea of building shared understand seriously means encouraging everyone to participate in discovery and shaping work.
  2. Taking the idea of building shared understanding seriously means looking requirements as stories that we build, understand and agree collaboratively.

Seriously encouraging everyone to participate in discovery and shaping work

In a big team, not everyone can and should be involved in everything. But if you take this idea seriously enough, you will split the team into smaller squads, each responsible for a business objective. Everyone within the squad must be encouraged to participate in discovery sessions from which customer problems are identified and prioritized against their business objective. Everyone within the squad must be encouraged to participate in shaping the solutions that they will deliver. Participation isn’t a “nice to have” thing, we must go out of our way to encourage and enforce it whenever possible.

Seriously means looking requirements as stories that we build, understand and agree collaboratively

It also requires you to stop looking at requirements as something that need to be strictly followed, and start looking at them as “stories” that we collaboratively build, understand and agree upon. It’s the story conversations which produces user stories that matter the most, not the user stories themselves, which are merely the outputs.

Shared documents aren’t shared understanding. Effective story conversations build shared understanding, and a user story acts as a placeholder for conversations.

This idea is built into the user story itself:

  • Card. A written description of the story used for planning and as a reminder (originally written on paper note cards).
  • Conversation. Conversations about the story to flesh out the details. Development team and customers should discuss details only when details become important.
  • Confirmation. Tests that convey and document details to determine when a story is complete. Test descriptions are meant to be short and incomplete. They are to convey information so that the developers will know when they are done.

From User Story Mapping - Jeff Patton

It’s actually difficult to look at things this way, especially if you’re used to certain rigid ways of working. It’s much easier to treat requirements as something that shouldn’t be questioned, because questioning may open the door to a world of unknown, which is frightening. It also requires product managers to stop focusing on writing elaborate and detailed requirements, and start involving people in the conversations that are messy and potentially full of dissent.

Trying to impose order on a complex domain doesn’t great

I suspect the underlying reason is that it’s just easier to impose order on a complex situation than facing it head on. This also aligns with The Cynefin Framework. Here’s an excerpt on the characteristic of the complex domain, as characterized by The Cynefin Framework (emphasis mine):

This is the domain of complexity, where patterns emerge through interaction of sub-systems. Emergent patterns can be perceived but not predicted, and understanding only happens in retrospect. The range is defined by a number of key metrics, but the outcome may lie anywhere. In this context, a leader should patiently allow the path forward to reveal itself rather than imposing a course of action. Create probes to make patterns more visible before taking any action. Then stabilize desired patterns and destabilize undesired ones. Leaders must allow patterns to emerge, detect them and then discern which one should be allowed to continue growing. In this domain, we should fail fast, learn fast, and fail safely.

In this domain, the performing methodology is an evolutionary approach, where systems are developed while acknowledging that the user need is not fully understood. User needs and requirements are partially defined up-front, but then refined in each succeeding build. Customer feedback should be used to enhance the capabilities of a future version of the system.

The dominant leadership style in this domain is adaptive leadership. A representative model of adaptive leadership methodology is the OODA loop (observation, orientation, decision and action). In exercising adaptive leadership, the goal is to make observing as objective as possible. Once observed, a leader must interpret the observed data from many perspectives. The decision and action should reflect the leaders’ hypotheses about the problem.

In this domain it’s impossible to do detailed planning. Leaders should encourage open discussions, where people generate innovative ideas in order to overcome entrenched thinking. Authentic dissent and diversity are also encouraged to push the emergence of well-forged patterns. Leaders should watch for starting conditions and monitor the emergence of patterns.

The primary risk in this domain is falling back to command-and-control style of management_. Desired results in complex domain are very difficult to be put forth, therefore resulting in impatience which cause leaders to fall back to inappropriate methods to demand safe fail. They may be too sensitive to failure which is require for experimentation._ Leaders who try to impose order in a complex context will fail, while those who set the stage, step back a bit, allow patterns to emerge, and allow the desirable ones to grow will succeed_._

Fierro, Davide & Putino, Stefano & Tirone, Lucio. (2018). The Cynefin Framework and Technical Competencies: a New Guideline to Act in the Complexity. INCOSE International Symposium. 28. 532-552. 10.1002/j.2334-5837.2018.00498.x.

Conclusion

In conclusion, if we try to apply “get out of the building” in a naive way, we may run into at least two problems. I think incorporating the idea of “build shared understanding” would address both of them. By encouraging everyone to participate in the discovery and co-creation process, you no longer rely on a single individual to come up with solution ideas. It will vastly increase the chance that you’re building the right thing. With everyone understanding the customer problems being solved, they are empowered and thus feel more responsible and connected to the work that they’re doing.

I realize that “get out of the building” is probably already an advice that’s meant for everyone. But If I may rephrase the advice so that it incorporates a bit better the nuance that I’ve observed, I would call it “Get everyone out of the building”, which sounds like something that a Fire Fighter would say. Perhaps in this sense (and in many other senses in which both roles have to fight different kinds of fire), Product Managers are just like Fire Fighters.

Well, that’s it! I hope everyone has a great 2022.