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.
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.
Depending on what you're proposing, you might also want to include:
- Some background context.
- Risks and knock-on effects for each solution.
- Solutions you have already discounted, and why.
- The pros and cons of making no decision at all.
- Deadlines, timelines and work dependent on the decision.
- A proposed decision owner who has the final say.
Key Points
- Proposals don't need to be big, scary documents. You don't need to spend hours crafting them.
- Put yourself in the shoes of the people reading it – what do they need to know to contribute to the decision-making process in a useful way?
- Try to anticipate likely questions and objections, and answer them in the initial proposal.
- Ask specific questions so it's easier for people to contribute their thoughts.
Example
Here's a simple example...
Problem
The product team isn't getting enough time to socialize, and it's damaging our sense of "team".
Option 1 - Schedule a 1-hour weekly team social call
Pros: Simple solution. Clearly signals that we care about socializing.
Cons: Takes an hour out of everyone's week. Hard to fit in for Alice and Romeo (they have very busy calendars). Will probably be at an unsociable time for Carlos and Misha.
Option 2 - Replace every other weekly team meeting with a social call
Pros: No extra time. We know this time slot works.
Cons: It's only once every two weeks. Less regular team meets will affect alignment about work.
Option 3 - Do nothing / Something else
I feel like doing nothing isn't really an option here. But am open to any other ideas that might solve this problem.
Questions
- How do we make social calls less awkward? How do we give them some structure? Any creative ideas?
- Who should lead these to begin with?
- Who's the decision maker here? If nobody obvious, is anyone uncomfortable with me making a decision on this after everyone's given their input?
Summary & Key Points
Writing good proposals is a core skill for asynchronous workers, but it should not be scary – some proposals can be very simple!