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

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

One of the ideas I’ve taken seriously is “Get out of the building”. When I transitioned into product management 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 but could be subtly harmful.

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.

Something like this:

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

1. It overestimates the ability of an individual to solve wicked problems.
2. It prevents us from creating true alignment.

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 prevents us from creating true alignment

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

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.

Encourage 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 can 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.

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. A user story has three parts:

• 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.

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.