How to Plan Product Features Asynchronously

I’ve worked as a Startup CTO for the past 7 years. The ability to hire around the world is a key competitive advantage to attract the best people to join my teams. Over the years, I crafted asynchronous processes optimized for my distributed remote work environment.

In my view, meeting-heavy processes totally detract the ability to have people in different time zones working together. Meetings also get in the way of deep work, which is needed in teams of builders such as Software Engineers, Designers, etc. Shopify recently banned meetings with 2 or more people for this exact reason.

I also want to be able to hire the best candidate for any role, regardless of what county they live in. If people were forced to be working at the same time, I would be constrained to hiring within my city or country or time zone. I wouldn’t be able to hire globally.

This transition from meeting-heavy to async-first came with significant challenges. It’s in our nature and in our upbringing to sit together in the same physical space to discuss important matters. Back in the day I used to hire people based on feedback from onsite interviews, and I used to plan new product features using the office’s white board.

Those days are gone, and nowadays my processes are async-first. This means that people don’t need to be working at the same time in order to get the work done.

In this article, I’ll walk you through the principles that guide asynchronous processes in my teams, and we’ll end with a step by step guide of how to plan a new product feature async.

 

 

First, we need a strong Culture of Documentation

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.

Lack of documentation is a big vulnerability for most companies, remote or not. And for async processes specifically, I can tell that lack of documentation is actually a blocker to roll out such processes.

This is one of the core principles I have in the remote work course, which could immensely benefit remote teams across the globe!

 

The 4 risks of not documenting knowledge

Lack of documentation potentially leads to four risks:

1. Knowledge gets forgotten: As priorities change, we won’t recall what we did last month.

1. Knowledge gets lost: People will leave and the knowledge leaves with them.

1. Too many meetings: Lack of documentation means that team members are required to interact live with each other to transfer knowledge. It pushes us into many avoidable meetings that detract from other tasks and priorities.

1. Onboarding nightmare: Onboarding new colleagues becomes much more complex if each time someone joins, they need to extract knowledge from several people in the team. Those people need to jump on meetings with the new person just to transfer knowledge, and it frequently means a major distraction whenever a number of new people join.

Encouraging Yourself to Document

People are lazy by default, so it’s not easy to push yourself to write stuff down or to read stuff.

However, I always tell my teams: “If we want to have this sort of flexible lifestyle where we can live wherever we want in the world and craft our day around our personal life and not like a nine-to-five work schedule, we need to commit to documenting knowledge”.

I also tell them the worst that could happen if they don’t: “Imagine you are leading an initiative and you don’t document it. Next week or next month, a colleague might need something critical about that initiative. They’ll call you at 4:00 AM your time, you might be sleeping, and you’ll be pissed. Without documentation, it’ll happen again and again”.

Using Documentation the Right Way

In my teams, we use templates for different types of knowledge, as a way to reduce barriers. On one hand, it reduces the barriers to production. If you use a template you just need to kind of fill in the blanks when creating a new doc.

And it also reduces the barriers to consumption. It’s always easier to read a document that you already know the structure for. You don’t need to scramble around to find what you need.

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.

This means that if someone asks me: “Hey, I don’t understand our front-end architecture. How is it built?”, I should be pointing them to a piece of documentation, instead of simply texting them the answer. If there isn’t one existing doc already, I’m accountable to make one. I need to write down and send them the link, not just tell them.

So next week, if there’s another front-end person asking for the same info, they can simply search and find the link to the same doc, and my knowledge has just became available 24/7 for my team.

This written knowledge that’s permanently available is fundamental for the asynchronous processes in my teams, including the feature planning described below.

Async Communication is basically a message queue for people

Asynchronous communication is not a new concept. We have been using message queues for distributed systems for decades because they make it more robust, more performant, and more scalable. Async communication is the application of message queues in distributed teams. Not systems, but teams.

Let’s go through a pretty economic example here to lay down the foundation.

Message Queues in Distributed Systems

Imagine this simple distributed system with three services, A, B, and C. Let’s say service B isn’t available for some reason.

This degrades the performance of service A as it doesn’t get feedback from service B. Similarly, the performance of service C is degraded as it doesn’t get input from service B.

But when we change it to a message queue architecture, service B’s absence is not even noticed by the other systems because service A keeps posting to a message queue.

And service C keeps consuming from the message queue unless the outage of B is too long. The backlog is still filled, so the services keep running.

Message Queues (Async Processes) In Distributed Teams

In a team, it’s basically the same thing. Let’s have a look at this team of Mary, Oleg, and Kumar.

Oleg is out today or right now is unavailable. So again, Mary doesn’t get the feedback for tasks which might slow her down, and Kumar doesn’t get input, which might render him very inefficient that day.

If we work asynchronously, Oleg might be out, and Mary just keeps pushing through Oleg’s message queue. Kumar, on the other side, will keep consuming from his backlog as well.

A few very common reasons why Oleg might be unavailable:

• Could be on vacation or on sick leave.
• Might be working in a different time zone and it’s night time there.
• Maybe he’s in a meeting and he can’t reply now.
• Or he’s working a deep focus task and he’s just marked himself unavailable for a couple of hours to do it.

Mary might be pushing PRs or opening bugs, waiting for Oleg when he’s back. And Kumar could be consuming or reviewing a PR that Oleg processed for him before or writing code according to the input Oleg forwarded to him before he went unavailable.

So none of the team members are blocked.

This has been a game changer for me since my teams are very distributed and people are otherwise constantly blocked.

My Approach to Meetings

First, there are two types of meetings, in my opinion:

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

In my teams, we try to reduce transactional meetings as much as we can, by replacing them with async processes.

On the contrary, social meetings are encouraged and planned by the company (eg: retreats, etc).

Replacing Transactional Meetings With Documentation

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

And a Notion doc is created to host the knowledge about that specific process, feature, and anything else related to it. So one team member is the owner of that doc and all other team members need to collaborate in the doc itself. Team members don’t need to collaborate live at the same time, but usually each document has a decision deadline (eg: a feature needs to be ready for development by a certain date). Each document has a clear owner, who makes sure the right people collaborate and the decision is reached.

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.

Cutting down the scope for Inconclusive Discussions

If these discussions turn out to be open-ended or inconclusive even after all async-first practices, then we’ll jump into a meeting. In such a case, the written discussion we had earlier will be used as prep work for the meeting, which will be made more efficient and shorter with a clear goal and agenda.

In any case, we aim to eliminate meetings, since bringing people around the world into a meeting is sometimes very hard to do, even if it’s only a 15 minute meeting.

Whenever the scope of discussion is too broad or open ended, we break it down into smaller discussions. Eg: Many features need a separate research task before going into technical architecture discussions.

In my teams, we usually only need such meetings for around 10% of the discussions (the bigger ones). Everything else we manage to tackle asynchronously.

If you’re interested in further reading about how I reduce meetings in my teams you can read more here.

Planning a Product Feature Async

Bringing together everything we’ve mentioned so far, let’s take a look at a practical example for planning a product feature.

First of all, after having used Scrum for a few years, I abandoned it when I started making my processes asynchronous. That’s because Scrum comes with lots of recurring meetings as a process boilerplate.

The lighter-weight process I use starts with a Notion document template that is comprised of these five questions: “Why”, “What”, “How”, “Who”, “When”.

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.

Although this may sound a bit waterfall-y, it’s actually quite collaborative. The most intensive part is usually the actual definition of the feature scope to fulfill the business goals. Another part that creates a lot of back and forth is the implementation tradeoffs.

The ‘Why’

As an example, imagine we work for a SaaS company that wants to tap into the healthcare vertical with our product.

For this, we need to be HIPAA compliant. And our business stakeholders would describe it as, “We need to comply with HIPAA so we can sell to clients in the healthcare industry.”

In this “Why” section, we describe the company goals we need to fulfill, and the metrics that we will use to track the success of this feature.

The discussion here is only business oriented, no technical details nor implementation trade offs should be added at this point. However, the language should be accessible to any stakeholders, including the technical team who will use it as functional context for the implementation discussions.

And this ultimately builds the why of the product feature.

The ‘What’

The “What” section is where a Product Manager gets into the weeds of the feature. It usually includes a fair amount of research, mockups, user journeys, partner integrations, etc.

The aim is that technical stakeholders can understand what needs to be done while the non-technical stakeholders don’t get lost in technicalities. Everyone should be able to collaborate, and the focus is the feature scope. Having said that, for technical features the doc can get pretty technical already at this stage (eg: integration with a partner’s API).

So usually there’s some research work being done here. In the same Healthcare example, that could be research on detailed IPA requirements or auditor procurement.

All these things typically go into the what.

The ‘How’

The “How” section is where we explore the implementation trade-offs. This section is normally led by a technical stakeholder like myself and the Engineers in my teams, and the section gets into the weeds of technical implementation. We go into the details around API integrations, we dig into payloads and field names, data migrations, error handling and such implementation technicalities.

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. Even business stakeholders can be included in these trade off discussions, as they can impact not only the delivery of the given feature, but also future commitments to refactor and solve the tech debt created by a rough solution in the short term.

As a result, some trade offs emerge. Such as a quicker implementation option that creates significant technical debt. Or a lengthier implementation option that’s much cleaner and that fits future requirements better. On several occasions, this discussion produces some trade offs on the “What” as well, such as cutting scope, or including some more scope that wasn’t considered before.

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.

See the How for the Healthcare example:

The ‘Who’

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

I like to break it down into individual tasks, assign them to people, have their understanding of what needs to be done, etc.

I have had teams where this is done in Notion, but frankly, Notion is terrible for this type of work. I usually prefer Jira or Linear for their integrations with GitHub and for matching tasks with PRs and having a shared view of status and dependencies.

The ‘When’

The when is not a simple task estimation exercise. I typically like to outline dependencies here.

For instance, in this Healthcare example, there would be an audit and the auditors typically have backlogs, so they can only audit in two or three months. That is a clear dependency that needs to be outlined. That is not a technical task, but just an external dependency we all need to account for.

And we don’t need to jump on meetings for this kind of stuff most of the time. Obviously, exceptions exist and exceptions are what we use meetings for.

Breaking up Big Tasks Into Smaller Ones

Bigger, more grandiose tasks are more challenging to be planned using async processes. For those features that clearly will not survive the kind of non-live discussion I presented in this article, I usually break them into smaller feature sets. Either vertically (branch into several sub-features), or horizontally (branch research out as a separate task, then different layers of technical discussion, etc).

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. In such a case, we’ll probably end up branching out a research task on its own, like, someone or some team needs to take that away. This smaller piece of the big grandiose feature is now an initiative by itself, and maybe that smaller scope can be done in this async manner.

Ultimately, it’s a big exercise of breaking things down into smaller scope things that can be done in this form.

Conclusion

Keep in mind that I chose to build my teams globally distributed. As such, I purposefully forced my teams into operating async-first. In any case, I believe this mindset can be equally applied to teams that are all in the same time zone. And even to teams that sit in the same physical office.

Asynchronous processes can bring tremendous benefits to any team, such as:

• Hiring from a global talent pool (vs constrained to a country or time zone).

• Fostering a diverse team distributed around the world.

• Processes that don’t require people to be working at the same time, all the time.

• Employees are in general happier and stay longer with the company, meaning less churn and longer lasting teams.

• A higher standard of documentation as a perk of async, which removes bottlenecks and single point of failure.

• Performance is measured based on the outputs (eg: features released) instead of inputs (eg: attendance), which indexes closer to business success.

Take these ideas to your team, and please let me know how it goes. My DMs are open on Twitter and Linkedin, I look forward to connecting with you there. You can also subscribe to my brand new Newsletter.