Idea papers
Credit where it’s due. I didn’t have a name for this before I read Effective remote work, by James Stanier. In my teams, we’d just have a generic, unimaginative name for it. You know, something as boring as “shared document” or “wiki page”. I like the term “idea paper” much better. It’s as straightforward as it sounds. It all starts with an idea. The trigger could be something internal, such as a clunky framework that’s causing developers a world of pain. It could also be something external, such as usage data for your product or an insight from competitor analysis. If you believe you have a way to solve a problem for your team or your stakeholders, write it up!
New ideas are fragile. They need care and nurturing. You must develop them without the pressure to explain them with charisma, in a room (or Zoom) full of people. When you take the time to write it up, you can make all your assumptions explicit.
You can enrich it with data and illustrate it if it helps.
Do you expect questions? Add an FAQ!
Are you clear about how to implement it? Throw in some implementation details.
It doesn’t have to be long. In fact, I suggest you make your idea paper easy to scan and as crisp as possible. Once you write things up, everyone learns about your idea in a consistent fashion. None of that blind people and the elephant stuff.
If they have feedback; they add in a comment. You respond and strengthen the idea.
When they have questions, they ask inline. You can then enrich the FAQ.
By the end of a round of feedback, your colleagues have inspected your idea and you’ve had the chance to enrich it. When everyone has the same information, it also facilitates decisions - especially if the team needs to agree to implement the idea.