I recently posted about my approach as an alternative to traditional Scrum and got several comments and DMs asking for further clarification.

I got criticism from people who labeled my approach as waterfall.

I also got enthusiasm from people who saw this as the ultimate silver bullet against meetings.

In fact, both are inaccurate. Let's get into the weeds.

How To Plan a Product Feature in an Async-first Culture

In our teams, I use Notion templates for several async-first workflows.

The goals are to collaborate in ways that:

• Foster participation (= people contribute their input).
• Can be done async-first (= without meetings).
• Achieve the company goals (= ships important stuff).

For the feature planning process mentioned above, we aim to achieve these two goals:

1. Built the right thing (achieve the business goal).
2. Build the thing right (don't pile tech debt that detracts value).

So I break those into the 5 questions in the Notion template:

Discussing the right thing to build:

• Why + What.

Discussing how to build the thing right:

• How + Who + When.

You can learn more in further depth here.

Starting With the "Why"

As such, when a new feature is proposed, a new doc is started empty from this Notion template.

A business stakeholder usually starts filling in the Why, which should mention:

• A company goal.
• A clear metric indexed to that goal.
• A clear before vs after.

Here's an example of "Why":

Moving to the "What"

The Why leads to the What, and it raises a collaborative discussion.

The usual flow is:

1. Business stakeholders clarify the "Why".
2. Technical stakeholders ask questions and propose solutions.
3. Business stakeholders add further input ... Until everyone signs off the "What".

This discussion is usually held in the Notion document itself, with a few house rules:

• There's a clear feature owner.
• Participants are identified and tagged when their input is required.
• Feature priority is defined and communicated (along with a deadline, if there is one)

Usually the "What" is kept high level, so that non-technical stakeholders can understand and contribute.

For clarity's sake, sub-pages should be created for research tasks such as design, vendor assessment, technical PoCs, etc.

Here's an example of "What":

The "How"

The How is usually led by technical stakeholders ("Builders"), who discuss implementation details, such as:

• Architectural tradeoffs.
• Partner integrations.
• Data migrations.
• APIs.
• Technical Challenges/Blockers.
• Rollout plans and external dependencies.
• Etc.

An example of "How":

The "Who"

Once the team settles on the "How", it is broken into tasks, which are assigned to team members who have both the knowledge and the bandwidth to tackle them.

This part can be done in Jira or Linear. Or it can simply be a Kanban board in the same Notion template.

An example of "Who":

Finally, the "When"

The When is not a simple task estimation exercise.

Instead, it is a bottleneck assessment that aims to align expectations inside and outside the feature team. Eg: Sales teams need to have a clear go-live date they can promise to clients.

Here's an example of "When":

A Few Considerations

• This process is async-first. Meaning that each participant provides written input in the document and tags their colleagues for their input.
• For graphics and other non-text input, we use Miro and link those in the Notion doc.
• In complex cases when the async loop isn't conclusive, the document is used as pre-work, and a meeting could be used for a live discussion.
• The most collaboration-intensive parts are the Why+What (between business and tech). And the How+Who+When (usually within tech team).

Follow us for more knowledge about remote work

We'll be publishing new articles every week, and new social media content every day. If you enjoyed this article, follow us on Twitter or Linkedin, and stay in the loop. Share our content and drop us a comment there. Let's help more people learn about remote work.