I’d like to recommend “Dogfooding”. GitLab uses this to build their product.
GitLab Handbook Link
The best way to understand how GitLab works is to use it for as much of your job as possible. Avoid dogfooding antipatterns and try to find ways to leverage GitLab (instead of an external tool) whenever possible. For example: try to use Issues instead of documents or spreadsheets and try to capture conversation in comments instead of Slack threads.
As a PM, but also as any GitLab team member, you should actively use every feature, or at minimum, all the features for which you are responsible. That includes features that are not directly in GitLab’s UI but require server configuration.
If you can’t understand the documentation, or if you struggle to install something, would anyone else bother to do it? This hands-on experience is not only beneficial for understanding what the pain points are, but it also helps you understand what can be improved and what features GitLab is missing.
With AnyType being as flexible at it is, I think it’s a prime candidate for this sort of thing. Now, this of course, does require some non-trivial features like collaboration, public sharing, etc.
Things I think AnyType could be used for regarding meta/internal management:
- Feature requests
- Bug reports
This very well may be already happening internally, but I think having public visibility would go a long way. It also helps with rapid feedback of the product. If the developers have to use the product, bugs and features can be prioritized in a more thoughtful and useable way.