Knowledge that is documented is available 24/7, as opposed to knowledge that lives in someone’s brain, which is only available when the person is:

Awake,
Not on vacation or sick leave,
Still working for the company,
And realistically, only for as long as the person remembers it.

In order to keep the Culture of Documentation alive and top of mind, I instill as a rule of thumb to always search before asking and write before telling.

Async Communication is basically a message queue for people

there are two types of meetings, in my opinion:

Transactional meetings, which are about work tasks and getting stuff done.
Social meetings to have fun and to bond with others in an organization.

My teams operate async-first. That means that any process is started as a Notion document.

In case text isn’t enough, we use Miro for things like drawings, workflows, etc. Or Loom for screen recordings. Those non-text materials are linked in the main Notion doc.

Whenever the scope of discussion is too broad or open ended, we break it down into smaller discussions.

Here are a few rules of thumb:

We can only define the what, like, “what we are building?” after we understand why we are building it. Why stands for business goals, client requests, etc. that index to the business itself and to the company’s goals.
We can only plan how we build it after we clearly understand what we need to build in the first place.
And when we define how we build it, it affects massively and creates trade-offs that we need to decide on, like, who will build it, available resources, and other constraints.

The “How” section is where we explore the implementation trade-offs.

A Product Manager is often looped in the technical discussion here, especially to discuss trade offs. With many features, there’s the fast way to build a mediocre solution and the slow way to build a robust solution

I like to end the how part with a clear outline of the technical tasks that need to be conducted and also buy-in from whomever wrote the why to confirm this is  a viable approach to solve the task.

The ‘Who’
From here, this gets more into typical project management territory, which is the who.

One typical reason why big features are so open-ended is because we are still figuring out what is the goal we are trying to fulfill with them, what the approach will be, or what the possibilities are.