Note: this is an old blog post I wrote back in 2021.

Get out of the building is not enough

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.

While 'get out of the building' is valuable advice for product managers, applying it naively can lead to significant strategic misalignments.

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. It overestimates the ability of an individual to solve wicked problems.
2. It creates an alignment problem.

Complex problems can't be solved by one genius

The paradigm 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.

Alignment problem

The paradigm 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.

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.

Getting everyone out of the building

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 vision 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. Encouraging everyone to participate in discovery and shaping work.
2. Looking at requirements as stories that we build, understand and agree collaboratively.

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 should be encouraged to participate in discovery sessions from which customer problems are identified and prioritized against their business objective.

Everyone within the squad should be encouraged to participate in shaping the solutions that they will deliver.

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.

In fact, 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.

It’s actually difficult to look at things this way, especially if you’re used to a way of working that's more hand-off than collaborative.

It’s much easier to treat requirements as something that shouldn’t be questioned, because questioning takes a lot of efforts and can take you to unknown places.

Product managers need to stop focusing on writing elaborate and detailed requirements, and start involving people in the conversations that are messy and potentially full of dissent. That's how everyone's expertise and passion can be leveraged effectively.

Conclusion

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. This significantly 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.

Is this always possible? No, certainly. In certain companies with certain organizational structures, it's not possible to get everyone out of the building.

If engineering and product teams have different KPIs where the engineering function is measured by the things they build, there is no incentive for them to join user interviews and understand their pain points.

However, if you are a product leader or working in startups where such formal structures are yet in place, you have an opportunity to shape the working process and product culture by encouraging everyone to get out of the building.