Thanks for sharing your learnings! One possible missing component - understanding the user journey and motives of the people you were building for, and potentially not defining segments of users very clearly. You're looking at problems and thinking of ways to solve them, but that route leaves out many nuances that can be important to adoption and retention.
It sounds like you want to build a 'utility' app (something that's for 'everyone') but usually products don't start this way successfully, especially thoughtful products like what you're building. Network effects are more easily built within groups of people who have some kind of connection. If you had a more particular use case in mind, you might be able to make the app work for long enough to nail it for that use case, grow within that segment, and then branch out.
Fundamentally, a product might be a great idea, but if you take the time to understand what people care about, then you might discover gotchas before you build., or understand that with tweaks, you can avoid some of the problems.
One of the failures I see in the social space in general is the (to my mind anti-prosocial) notion that one size should fit all, that there are or should be norms and practices that are universal. Could you build something that was prosocial in context and not require it to be something that can 'take over the world?' It's something I think we need to reckon with, myself included!
I did more of that than the article talks about (space constraints and all that), but still probably not as much as I should have done.
There is definitely an argument for allowing different communities to do different things. indeed many of the most successful products succeed because they give different people the ability to use them in different ways - but grounded in very specific example use cases that work.
Possibly the biggest mistake I made was in jumping too quickly to building a new product for a community of people, rather than first working with people to see if I could do stuff in their existing tools to make their existing use cases work better.
The great thing about helping people manually is that it forces you to actually understand what the problem really is. It's also much easier to rapidly adapt what you are doing if you are doing it manually. I wonder how many successful products started out as "super manual with existing tools"?
This may be the one advantage to being a non-technical founder; trying to figure out if there’s any way to use existing tools and investigating how people are trying to solve the problem is illuminating! It’s still possible you’ll end up building something novel, but it will be a lot easier to help people understand the value, I think!
Interesting journey! But what I would really like to learn is how you put together a slick multi-platform apps in React and Firebase. Please explain in one article, ideally with a backing github repo!
React Native makes the multi-platform stuff pretty easy. There were only a few cases where I needed to use different code for the different cases. If you use react native web then you get a web app too.
Firebase is really nice when you want something that reacts live to data changes - as is common in chat apps. I built my own data connection layer (using hooks) that makes it super easy to drive a react app from firebase.
I might open source some of the libraries I built if there is broader interest.
You made me think about Don Quixote fighting 'annoying opinionated people with too much time on their hands' (and Elon Musk)
There are too many annoying opinionated people, I wish they could be blocked out, or more or less silenced like we seem to be slightly more successful in physical settings.
Along the lines of your comment, I'm considering writing a follow-up post that goes into more detail on the "Tyranny of the Annoying", how it manifests, and the various strategies that get used to combat it.
This was a great read. My friends and I have been in an extended Slack-universe for about 7-8 years now. Started with a core group of friends from high school which then extended to friends of friends. It became like a mini-Reddit but with people you have 1-2 degrees of separation with. Categorical channels emerged like #sports, #music, #philosophy, #politics, #finance etc. And then our private channels also existed for our core friend group's chat.
Initially, it was incredibly engaging and fun to start meeting the extended networks of our friends and acquaintances in a digital space. But it soon become a few loud voices dominating certain channels, discussions tended to become arguments between those loud voices, and the constant chatter during the workday led to me muting almost all channels (and keeping them muted to this day). Some channels are still very active like #sports and a few private group channels.
My retro on what happened:
- no moderation in channels. it was too easy for certain people to control the narrative by being the most active, loudest, or argumentative. Did not feel like a welcome space for others to join the dialogue, especially if you were new to the entire Slack workspace.
- thought bubbles. given the group started with our high school group and extended friends, I think we missed out on an opportunity to engage with more diverse thought and opinions. Though I'm not sure how you create a safe space for that when our invites were based on degrees of separation.
- overwhelming amount of discussion during the day. real-time chats were hard to jump into unless you were there at the start of the discussion. some people just had way more free time during the workday and if you step away for a few minutes, you could miss 100 messages and lose the thread.
overall it is still where we host our private group chat and Slack has been a great way to even create private channels to engage our partners/wives/husbands without destroying the sanctity of the core group chat. It is still a great space for the more active, daily topical channels like #sports or #music or private channels for extended acquaintances like a book club channel.
Yeah. I've heard similar things from other people. Definitely a trend for new social spaces to start out great, and then gradually get taken over by the most annoying people.
I've got a rough plan for a future post titled "The Tyranny of the Annoying" that explores this ideas further.
I would be curious if you identified a common set of features / APIs / capabilities across the apps, that could be built into something existing, so that future experimentations like yours are easier to do. E.g. if we built this on top of the fediverse protocols, can we get the social network for free? Or using OAuth and sharing connections? A way that makes some of the results visible to the world and puts them into the record? Etc. Whether that is a set of APIs or some common open source foundation, or proposals for protocols. I certainly would also be interested in the Native React / Firebase foundation you describe in the other comment.
I considered implementing some of these on top of Mastodon, but I got the impression that ActivityPub assumes that your social network will be more Facebook/Twitter like than what I was building, and so that peering with things like Mastodon would be more confusing than helpful.
That said, I'll admit that I didn't look into using those protocols super-closely (this was before Mastodon got serious usage in the Twitter meltdown) and it's likely I'm wrong.
I'm definitely very much in favor of open protocols vs centrally controlled systems.
Hey Rob! Thanks for talking through your learnings!I’m curious what the UX was like for Slowtalk? Public feed with all your friends updates that would then turn into a private chat if you sent a reply? Do you have any photos of the UI you could possibly share? It sounds exactly like what I’m looking for in a social product! Also was this a standalone social network with a social graph?
Thanks for sharing your learnings! One possible missing component - understanding the user journey and motives of the people you were building for, and potentially not defining segments of users very clearly. You're looking at problems and thinking of ways to solve them, but that route leaves out many nuances that can be important to adoption and retention.
It sounds like you want to build a 'utility' app (something that's for 'everyone') but usually products don't start this way successfully, especially thoughtful products like what you're building. Network effects are more easily built within groups of people who have some kind of connection. If you had a more particular use case in mind, you might be able to make the app work for long enough to nail it for that use case, grow within that segment, and then branch out.
Fundamentally, a product might be a great idea, but if you take the time to understand what people care about, then you might discover gotchas before you build., or understand that with tweaks, you can avoid some of the problems.
One of the failures I see in the social space in general is the (to my mind anti-prosocial) notion that one size should fit all, that there are or should be norms and practices that are universal. Could you build something that was prosocial in context and not require it to be something that can 'take over the world?' It's something I think we need to reckon with, myself included!
I did more of that than the article talks about (space constraints and all that), but still probably not as much as I should have done.
There is definitely an argument for allowing different communities to do different things. indeed many of the most successful products succeed because they give different people the ability to use them in different ways - but grounded in very specific example use cases that work.
Possibly the biggest mistake I made was in jumping too quickly to building a new product for a community of people, rather than first working with people to see if I could do stuff in their existing tools to make their existing use cases work better.
The great thing about helping people manually is that it forces you to actually understand what the problem really is. It's also much easier to rapidly adapt what you are doing if you are doing it manually. I wonder how many successful products started out as "super manual with existing tools"?
This may be the one advantage to being a non-technical founder; trying to figure out if there’s any way to use existing tools and investigating how people are trying to solve the problem is illuminating! It’s still possible you’ll end up building something novel, but it will be a lot easier to help people understand the value, I think!
Interesting journey! But what I would really like to learn is how you put together a slick multi-platform apps in React and Firebase. Please explain in one article, ideally with a backing github repo!
React Native makes the multi-platform stuff pretty easy. There were only a few cases where I needed to use different code for the different cases. If you use react native web then you get a web app too.
Firebase is really nice when you want something that reacts live to data changes - as is common in chat apps. I built my own data connection layer (using hooks) that makes it super easy to drive a react app from firebase.
I might open source some of the libraries I built if there is broader interest.
Interesting read and impressive work!
You made me think about Don Quixote fighting 'annoying opinionated people with too much time on their hands' (and Elon Musk)
There are too many annoying opinionated people, I wish they could be blocked out, or more or less silenced like we seem to be slightly more successful in physical settings.
In any case, I hope you continue this fight! (-;
I'm pleased you liked it.
Along the lines of your comment, I'm considering writing a follow-up post that goes into more detail on the "Tyranny of the Annoying", how it manifests, and the various strategies that get used to combat it.
This was a great read. My friends and I have been in an extended Slack-universe for about 7-8 years now. Started with a core group of friends from high school which then extended to friends of friends. It became like a mini-Reddit but with people you have 1-2 degrees of separation with. Categorical channels emerged like #sports, #music, #philosophy, #politics, #finance etc. And then our private channels also existed for our core friend group's chat.
Initially, it was incredibly engaging and fun to start meeting the extended networks of our friends and acquaintances in a digital space. But it soon become a few loud voices dominating certain channels, discussions tended to become arguments between those loud voices, and the constant chatter during the workday led to me muting almost all channels (and keeping them muted to this day). Some channels are still very active like #sports and a few private group channels.
My retro on what happened:
- no moderation in channels. it was too easy for certain people to control the narrative by being the most active, loudest, or argumentative. Did not feel like a welcome space for others to join the dialogue, especially if you were new to the entire Slack workspace.
- thought bubbles. given the group started with our high school group and extended friends, I think we missed out on an opportunity to engage with more diverse thought and opinions. Though I'm not sure how you create a safe space for that when our invites were based on degrees of separation.
- overwhelming amount of discussion during the day. real-time chats were hard to jump into unless you were there at the start of the discussion. some people just had way more free time during the workday and if you step away for a few minutes, you could miss 100 messages and lose the thread.
overall it is still where we host our private group chat and Slack has been a great way to even create private channels to engage our partners/wives/husbands without destroying the sanctity of the core group chat. It is still a great space for the more active, daily topical channels like #sports or #music or private channels for extended acquaintances like a book club channel.
Yeah. I've heard similar things from other people. Definitely a trend for new social spaces to start out great, and then gradually get taken over by the most annoying people.
I've got a rough plan for a future post titled "The Tyranny of the Annoying" that explores this ideas further.
I would be curious if you identified a common set of features / APIs / capabilities across the apps, that could be built into something existing, so that future experimentations like yours are easier to do. E.g. if we built this on top of the fediverse protocols, can we get the social network for free? Or using OAuth and sharing connections? A way that makes some of the results visible to the world and puts them into the record? Etc. Whether that is a set of APIs or some common open source foundation, or proposals for protocols. I certainly would also be interested in the Native React / Firebase foundation you describe in the other comment.
Good question.
I considered implementing some of these on top of Mastodon, but I got the impression that ActivityPub assumes that your social network will be more Facebook/Twitter like than what I was building, and so that peering with things like Mastodon would be more confusing than helpful.
That said, I'll admit that I didn't look into using those protocols super-closely (this was before Mastodon got serious usage in the Twitter meltdown) and it's likely I'm wrong.
I'm definitely very much in favor of open protocols vs centrally controlled systems.
Hey Rob! Thanks for talking through your learnings!I’m curious what the UX was like for Slowtalk? Public feed with all your friends updates that would then turn into a private chat if you sent a reply? Do you have any photos of the UI you could possibly share? It sounds exactly like what I’m looking for in a social product! Also was this a standalone social network with a social graph?