How to Grow a Multi-Sided Platform: Start with Single Player Mode

Ben Halpern on June 20, 2019

I got this question in a DM and felt like answering it more broadly. Obviously by founding DEV, I have some ideas on this topic. It started by ... [Read Full]
markdown guide
 

First:

It's always a pleasure to read an opinion from a source whose opinion you can trust, as credibility is a difficult thing when the source does not reveal their background.

Second:

But it was all with the feeling that it's hard enough to even get your friends and family to actually use things you've built.

Been there.

 

We're still there in some ways.

We still have a long way to go, but it's funny how no amount of progress can convince some people that your thing is useful. Skepticism is basically a law of the universe. πŸ˜„

But we've always just embraced skepticism as a very healthy reaction. People should be skeptical about new things to a pretty decent extent. It takes a long time for things to really get to the point of delivering value and a lot of people give up and shut a project down before they get to that point.

We also have the issue where some folks probably remember old, crappier versions of our platform as what the platform is all about. It's almost better if they forget they ever created an account.

 

There's a lot I can say on the phenomenon you're describing, but I believe my personal anecdote regarding dev.to may be more relevant:

  • I found dev.to when someone wrote an article about my work last year, as I noticed the site as a source of inbound traffic. I didn't know what it was beyond a webpage, but that's how it got on my radar.
  • After finishing my last project, I wanted to document my process so that when I'm coaching developers in the future, I have material I can refer them to that would give them the foundation of a conceptual process for building an app. I decided to cross-post from my blog on other platforms so I picked the obvious choices of Medium and LinkedIn. I then remembered dev.to and looked to see if it was a blogging platform. It was, so it got added to the list.
  • My articles had no practically no engagement on any platform, but since it wasn't my main objective I didn't worry about it. However, in setting up my dev.to account I learned more about the platform's intent to be a dev community, not simply a blogging platform.
  • I've dabbled in several online communities for developers, but inevitably the signal-to-noise of useful conversation grew exponential worse at a rate that I found too tedious to warrant my further attention. It seemed that the intent of dev.to was to build a dev community without that characteristic.
  • I took the approach I always take with new communities: I watch for the latest discussion posts to get to know the type of people in the community, as watching curated feeds tends to skew your view of the community due to the Mathew Effect. I engaged to see what the response would be. So far, I have been pleasantly surprised.
  • I've enjoyed engaging for the last few days, and so far, so good.

I'm only one person and am far outside the standard deviation on several attributes. However, I believe my general experience will be repeated by people like me, and you will continue to see your community grow.

No one likes change and people fear what they don't know. Over time, however, a new solution can tip (in reference to the thesis of "The Tipping Point"), and people wonder how they ever did anything else. My theory is that staying the course will yield the best outcome for dev.to, as time is on your side.

Very self-aware! I think a lot of people go through a similar journey, but I think with less general intentionality. I think there's a lot of repeat exposure learning with our platform.

Knowing that so much of our community's content is distributed broadly to the greater web, we can trust that you'll probably stumble on the platform a few times before it starts to click, and we're okay with that. We could probably speed up the conversion cycle by being more in your face with our messaging to sign up, or by restricting content in some way, but that would be incredibly counter to what we're about.

So we've sort of settled on just going with the flow, creating gentle nudges to get more involved without interfering with the main purpose of just letting people read useful content. And then we allow the chaos of "word of mouth" do do its part. Someone might share a post in their team's Slack and someone else might say "oh what's this dev.to thing all about anyway" and there is some possible aha moments thereβ€”but we try not to over-manufacture this kind of behavior. If we stick to delivering value, we grow.

 

I'm starting an ssh chat nowadays, hope you guys ready to experience and try it out. Meanwhile it runs only locally, but I'm almost done setting up the server. :) You're all invited!

 

Sounds cool, let us know if it is ready to try πŸ˜‰

 

Hi it's ready!!!!!!!!!
Come overhere :D

ssh chat:@77.138.137.24

 

Cool stay tuned! In the next few days the final stage will be over and I'll share you guys the command line on how to connect to from every computer/shell/terminal.

Sounds cool. What dev stack and are you open sourcing it?

Yes it will become open source. You will connect through ssh with a single command line, no ssh key/ssh gen, single line, you will recieve a gui written in Perl Curses library and you will chat with me and everybody else whereas there's also a tiny Python web server for security reasons that writes down the messages you send me to the server :)

Stay tuned, I'll let you know even perhaps in this very comments thread at the first days.

 

This is honestly the exact way it is done if you are going to do it yourself initially. If you have lower resources but lots of willpower & a very strong work ethic. You will sacrifice almost every hour of life to reading, learning, moderating, creating, answering, analyzing etc.

In return you will have something of value or something people want to invest in that is very low risk (you can then keep more equity/control which matters long term). Most startups fail, but investing in devto rn is low risk because the risky parts are working (mostly).

It's generally better to learn this way than raise for a shiny new idea, never tested unless you have the correct experience/funding.

Notice the patience to wait for solid numbers before making moves.

 

Yes, definitely.

Given the track record I'm pretty confident somebody would throw money at a new thing I was doing if I ever go off and do a new thing. I'd be curious to see whether it's a road I'd even be interested in venturing down if the opportunity presented itself. Hard to put myself in those shoes without literally being presented with the scenario.

As it stands now for DEV, we just take each next step as an opportunity to choose to do what's ultimately right for the community and the company which shifts a bit from opportunity to opportunity.

 

Yes. You could raise well already from the serious ones based off current performance. 😳

People raise on much less experience & skill. It's not needed if you can do the early work (code, content, traction).

Money is control in these kinds of scenarios (it's clear you could repeat what is happening here, regardless of raise). MZ can do what he wants with FB due to early retention (look at fb cap table or whatever).

For dev, communities tend to run naturally in cycles a bit like product. The concerns become non-technical usually: "I remember the old days when Ben & team would answer & say nice things but nowadays you only see them on a yacht on IG & Ive been banned on DEV 3mths for calling it an ice-cream horse!!". It's more often mismanagement + some competitor pressure (medium?) not technical issues or missing features. Usually, those issues were always there underneath the whole time. The great digg > reddit migration was mostly that (the v4 redesign didn't help). Look at what happened to other big communities to determine the fate of yours, there are a bunch of cases.

Fb is an example of how to extend lifecycle (know existing ageing audience, capture new ones by being well monetized to take competitors, pivot whole org etc).

trends.google.com/trends/explore?d... product lifecycle.
trends.google.com/trends/explore?d... when you drill down.
trends.google.com/trends/explore?d... devto is pre Aug 08 here it seems (in the cycle, not scale).
trends.google.com/trends/explore?d... you can just see it lifting at the end.
trends.google.com/trends/explore?d... + power marketing
trends.google.com/trends/explore?d... saturating what's next?

Everything like goo & craigslist followed this adhoc style to some degree as people were making things up as they went (Apple being a key exception).

Arriving in tech today seems way more intimidating than watching the useless nonsense as it turned into 'industry standard' ways of doing things. To anyone new reading this, free up 18mths (ramen startup), copy Ben's technique of rolling start & be fearless. πŸ‘

Start soon as change is underway. 😊

 

@ben , great post and I love how engaged you are with the DEV community :)
This reminds me of cdixon.org/2015/01/31/come-for-the...
Ideas for "single player mode" that have worked / could work today? I'm focused on product / marketing / growth content and want to create a community like you have for DEV.

 

I thought this was going to be a post about videos games.
Though to speak about building video games, build with multiplayer in mind first because it will force you to make your game deterministic which will save you a huge re-write.

When I was building Swap-N-Pop (Tetris attack clone) so many other people tried making clones as well and they stopped when the found out that their game was non-deterministic and they'd have to overhaul their game to achieve their goals (community multiplayer game).

Also, write test code on day one this will help you hold less state making debugging easier as well.

 

This is very similar to the concept of developing something based on a personal need. Once you've developed something that solves your personal needs and does it well, then you can release it to others who may also have a similar need. Taylor Otwell does this constantly with his projects, and it's how Laravel became what it is today.

 

@ben great post. I love the fact that post on DEV does well on google.

Recalling, from this line:

Here's a trick: People are pretty willing to say yes to being interviewed if you make it easy for them.

How does one make it easier? I find it difficult to interview someone I have no previous connection with.

 

Great insight, thanks for sharing. I've been following Nick and Ernesto at switcherstudio.com and their ride. So good to see things get up.

 
code of conduct - report abuse