Documentation is really important for remote teams. We heavily document every feature before implementation and discuss it async in comments.
Since we link all relevant feedback to Features (How we collect customers feedback) , it is really important (and easy) to review all feedback before we start inventing a solution. Feedback helps to understand the problem better, spot missing sub-problems and give you some ideas.
From time to time we auto-generate initial feature spec version automatically via AI based on all linked feedback. It is especially helpful for problems definitions.
In 90% of cases, your problem was solved somehow in other tools. It is always good to steal good ideas with style. Review competitors or other relevant markets and document your observations, attach this document to the Feature.
We prefer to use problem/solution pattern for the feature description. It helps teammates to understand the root of the feature, why we are going to implement it and even contest the importance of the problems. Sometime we decide to not implement a feature after a discussion.
In many cases there are several possible solutions to a problem. In most cases it is good to enumerate and discuss them. They may provide useful insights and new ways to approach the problem.
As a rule of thumb we try to invent 2-3 alternative solutions for every serious feature.
It's always good to release something useful as early as possible. We try to cut functional requirements and use cases and make the first release very focused and bare. It's relatively easy to add bells and whistles later, but this initial release can generate tons of useful feedback from your users and change priorities of all these bells enormously.
Fibery has a decent comments now, so it is better to use inline and entity comments to discuss things about feature spec, since it will preserve context and it will be easier to make changes.
