Why say "Let's sleep on it!" as a product manager?

I recently finished facilitating a conversation at work that left me confused. We explored multiple architectural solutions to support an exciting feature. Some technical directions were subtly different, while others differed significantly.

Frustration crept up on me. At the end of an hour-long meeting, I just want The Right Answer. So sometimes, I simplify. I sweep edge cases under the rug. I act like there is a decision or clarity where none is yet.

Yet this almost never helps in the long run. As a PM, I break trust with my team when I misrepresent what was discussed and decided. When I paper over unanswered questions, I notice someone always needs to return later. Someone will drive over the pothole. A lacuna can show up as a user experience deficit that customer support needs to assuage, or as faulty business logic we need to amend in code. This is like the Babadook: the monster is there whether or not I'd like to acknowledge it on some particular afternoon.

In "10 Traits of Great PMs," Noah Weiss writes:

Great PMs drive a fast pace of high-quality decisions. They make two-way door calls quickly, and help the org make one-way calls judiciously. They care about getting to the right decision, not whether they are right.

In Quaker business practice, there's a term called "sense of the meeting." The assembled group comes into accord about what was discussed and the way forward it will take. But any Quaker will tell you: for any issue of import, it can take many hours of concentrated discussion to get to unity.

Recently, I tried a new approach when I realized the fastest way I could help my team to make a high-quality decision was to make no decision at that time. I said "Let's sleep on it!" Later that week, a few more conversations later, the right path forward was clear.

Costs of the need for speed

Technology companies value velocity in software product development. In startup settings where I have worked, there is an emphasis on speed. We would like to see our ideas in the wild, for customers to use the interfaces we have crafted for them. We would like our businesses to enjoy the positive financial impacts of our work. If time-to-market is too long, we may fold as a whole.

Sometimes a suggested feature will be driven through the software development lifecycle inside this mental model: How many days, or hours, elapse between the initial articulation of the feature and its deployment in production?

Yet when the need for speed structures a team's focus, we can miss out on activities that generate long-term value for the company, and which avoid potentially costly downsides.

• A designer may not be able to collect full context on the user journeys where the feature intervenes. So they may not formulate and articulate concerns that, if addressed, would enhance the usability of the prototype they provide.
• A technology lead may not intuit to ask a PM where—or if—the feature fits into a long-term product vision. As a result, we may make architectural or data modeling choices that impede future extensibility.
• A PM may think they understand the reasoning that supports the suggested feature better than they actually do. They may fail to confer with a cross-functional stakeholder about the true intent and impact of the feature. What is built may have unexpected negative downstream effects on customers or on people with whom customers interact via the product.

Factors that support product velocity

As a team, we climb the mountain one step at a time. My belief is that velocity grows out of an empowered and expert team. Instead of focusing on speed itself, we have the immediate power to work on the quality of our collaboration as we ship ambitious products. Speed falls out as a consequence.

1. Individual team members carry domain, technical, and experiential knowledge, creating the requisite conditions in which we may discover satisfactory solutions. Thus, activities where we build individual and shared knowledge enable long-term velocity.
2. Trust and warmth in a team's interpersonal relationships speed the resolution of ambiguous issues as well as the delivery of hotfixes. Building trust is not possible through superficial ceremonies (beer, ping pong, ...), but rather happens as a result of showing up for each other every day and paying attention to each other.
3. Operating within those relationships—but a separate outcome and observable phenomenon in itself—is the quality of a team's communication. Standup should be a ceremony with real listening. Without, it is stultifying. Domain-area meetings should see us find our way through conflict and emerge with similar understandings of proposed solutions. Otherwise, incompatible mental models can block later work. Hand-in-hand communication generates startling efficiency from microscopic (getting help on removing blockers) to macroscopic (service and schema design) scales.

Why sleeping on it helps

Sleeping on it lets the team put together our thoughts. We can collate the information we gathered the previous day. We can understand new technologies, terminology, or domain information teammates introduced. We can synthesize tradeoffs and weigh alternate approaches, sometimes without even consciously trying to.

In an asynchronous organization, a teammate who could not join the previous discussion can review documents and give feedback.

What had seemed urgent, incompatible, or inconvenient might not anymore.

So I offer "Let's sleep on it!" as a tool that has helped me move forward with others faster, by not moving at all in the moment.