| Congrats on finding a real problem and building something to solve it. You're about to fight an uphill battle. Here's my feedback (from someone who currently leads the leads of 7 remote engineering teams): • Not knowing if someone is available and if they will get back to you soon is very very bad for many conversations. For example, when you have a C-level asking for rapid turn around on something that needs to be done by someone multiple levels away from you. • In remote teams, sometimes people disappear (e.g. car accident or civil unrest in a random country), and if you have no way to know, you'll eventually get fed up. • The feeling of cohesiveness that comes from having realtime conversations, brainstorms and other collaboration is very important to managers (especially in remote teams) and convincing them that realtime talk is not a good default is going to be quite hard. • As a result you will never be their default communication channel - at most you'll be the place they discuss bigger problems. But because you're not the default, you'll get destroyed by slack, who is the default. Most times people use the tool at hand that they are most familiar with, not the best tool for the job. I would encourage you to write a slack bot that reminds people to use you & helps them easily experience value from your product without you having to win the default spot. • Finally, most people will have serious difficulty seeing the difference between your product and other product management tools that allow commenting in detail on issues being discussed. |