<aside> <img src="/icons/info-alternate_yellow.svg" alt="/icons/info-alternate_yellow.svg" width="40px" /> This page is part of The Toolbox by Danny Smith.

</aside>

When you hear the word proposal, you probably imagine a long and complex document. But proposals don't need to be complex.

In an office environment people make small proposals all the time during meetings or hallway conversations: "Hey I think we should do X because Y. What do you think?"

The discussion that follows will normally involve a bunch of back-and-forth which touches on pros & cons, as well as some alternative solutions.

When working asynchronously these kind of discussions happen much less naturally. Timezones also mean that the back-and-forth discussion takes much longer, so we need to minimize this wherever we can.

Example of a very simple proposal in slack.

As with most things in async teams, we need to be much more intentional about how we make proposals than we would in an office environment.

Because of this, learning how to write good proposals is an important skill for distributed working. And if you're good at writing simple proposals, you'll also write much better formal proposals when you need to.

You might need to write a proposal...

• When quickly suggesting something on Slack.
• When suggesting improvements to process or documentation.
• When proposing a new product feature (or a refactoring of some code).
• Before Decision Meetings.
• When proposing something big, like a new strategy.
• Etc.

How to write proposals

Most proposals should include:

• The problem (usually expressed in terms of business value).
• Your proposed solution, along with its pros and cons.
• Alternative solutions and their pros and cons.
• The people who should be involved in making the decision.