5 ms·

In the whole first month of Buffer, we had less than 100 signups. For comparison, we now have 560,000 users (2.5 years later). We now sign up 100 people within

by joelg87 14y ago

In the whole first month of Buffer, we had less than 100 signups. For comparison, we now have 560,000 users (2.5 years later). We now sign up 100 people within a couple hours. It amazes me to think about it. I had a previous startup that also started slow, but never really changed. The key difference between the two, was retention. So I would highly recommend anyone who's getting started to closely watch retention. Does anyone keep using the product into their second week after sign up? That's the first thing I'd focus on with what I know now.

adambenayoun 14y ago
Hey Joel, I'm interested to know if the first 100 users stuck with your product over time or you had to figure out how to do retention over time.
- joelg87 14y ago
  What an awesome question Adam. Just had a look at our cohort analysis. Happy to let you know that 16% of the December 2010 cohort (those 100 people) are still using Buffer today (27 months later). It's actually fairly representative of what our retention stabilizes to after 4-5 months for almost every cohort, though 100 is not an ideal sample size! We've certainly worked to improve retention over time, but in addition I think with Buffer I finally had hit upon a problem that was a real pain point. So, there was good retention right from the start.
  - charliepark 14y ago
    Joel, what are you using for your cohort analysis? An internally-built tool? A third-party service?
    - joelg87 14y ago
      Hey Charlie! We've been back and forth on this in the lifetime of the startup, but we're now doing all metrics ourselves, so it is internally built. I built an early version of the cohort analysis (which didn't scale, but that didn't matter) just a few months in and it was massively valuable. It's not too hard to knock something together.
      - adambenayoun 14y ago
        Thanks for the answer Joel! By the way - I'm curious why you guys had to built this internally - I always get the feeling people prefer using a 3rd party service like kissmetrics than building something.
      - charliepark 14y ago
        Solid. Thanks!
      - robertocr 14y ago
        Internal BI is the way to go. It gives better vision to those who make decisions. Congratulations! :)
    - nanch 14y ago
      Would be an interesting third party tool. Does anyone do this already? Something as simple as receiving a list of usernames over time.
      - lubos 14y ago
        MixPanel can do this and they have a free plan. I custom-built my own cohort reports but as number of users grow in my own app, I'm planning to replace it with MixPanel. You don't really want to put stress on your own database servers which are meant for production, not for analysis.
        aaronblohowiak 14y ago
        You should not be doing analysis (OLAP) on your main transactional database (OLTP). Moving from transaction-processing system (TPS) to analysis is done through a process call ETL (Extract, Transform, Load.) You will want to transform your data into facts and dimensions -- this is going from a relational model to a multidemensional model (using a star schema.)
        lubos 14y ago
        but that would be another system to maintain. I'm happy to outsource this to MixPanel or some other company. My needs are pretty generic. I appreciate your response though.
        aaronblohowiak 14y ago
        Yes, I 100% believe in focusing on your core competencies. If the OLAP is self-hosted or external, the key takeaway is to not do analysis against production (once your data set is larger than RAM ;) before that, who cares?)
      - ryanjm33 14y ago
        Cohort.ly does a great job. They are in private beta so you can request access. It has been really beneficial to us. http://cohort.ly/ http://cohort.ly/
shortformblog 14y ago
I think what really helped you guys is that you've always been earnest and have done a good job becoming thought leaders as bloggers. People could learn a lot from the way the Buffer team grew out its product. You guys created a really good template for slow-growth. Props.
- joelg87 14y ago
  Thanks! That means a lot, really appreciate you mentioning it.
chaddeshon 14y ago
Thanks for this helpful and encouraging post. As I was right this the main question I had was how do I know the difference between "Nobody wants what your selling" and "You need to do a better job marketing"? Retention is a great answer to the question.
- joelg87 14y ago
  Indeed, that's exactly right! I think for us, as soon as we saw that people were sticking around we knew we had to switch to "do a better job marketing". With retention, that was validation that there must be many more people out there who would find Buffer super useful, just like the people who were staying active. In essence, we needed to make more people aware of the value we were providing.
  - yoshyosh 14y ago
    That's really awesome to hear. At what point did you start worrying about referrals? Was there a point in time when that naturally started to grow as more users, used it? Or was it something that didn't change unless you were focused on it?
switz 14y ago
I recently hacked together a product that aligns with buffer's philosophy, but is inherently different. I have about 70 users, but zero paid users and not much activity. I've been ignoring it from a development standpoint in favor of other projects. Meanwhile I still use the site daily. I hope I can put some more time into it, but for now I'm just letting it scratch a personal itch. If anyone is interested: https://tweezer.io https://tweezer.io
- joelg87 14y ago
  This is neat. It's a key problem we've spent a lot of time thinking about (that posting the same thing in the exact same way to different networks is not the right thing to do). Good job, and good luck!
- dendory 14y ago
  I was wondering why no one was tackling the issue of posting to multiple social networks, and instead all we saw were services that clone posts from one network to the next, services that usually get shut down from the networks. So I made my own a while back that can post to Twitter, Facebook, G+, etc in customized ways depending if I have a URL or not, automatically shortening it, etc. Otherwise I would give yours a try.
  - Snoptic 14y ago
    Do you have to constantly change your web page scraper to maintain G+ support, since it has no API?
    - darkmagnus 14y ago
      https://developers.google.com/+/api/ https://developers.google.com/+/api/
      - estebank 14y ago
        The G+ API is read only.
rayhano 14y ago
Retention vs sign ups. Interesting. Are we talking LinkedIn style link-bait and endless 'notification' emails? Or Dropbox/Mailbox style gamification to get more free by being 'part of the club'?

by joelg87 14y ago

adambenayoun 14y ago

Hey Joel, I'm interested to know if the first 100 users stuck with your product over time or you had to figure out how to do retention over time.

joelg87 14y ago
What an awesome question Adam. Just had a look at our cohort analysis. Happy to let you know that 16% of the December 2010 cohort (those 100 people) are still using Buffer today (27 months later). It's actually fairly representative of what our retention stabilizes to after 4-5 months for almost every cohort, though 100 is not an ideal sample size! We've certainly worked to improve retention over time, but in addition I think with Buffer I finally had hit upon a problem that was a real pain point. So, there was good retention right from the start.
- charliepark 14y ago
  Joel, what are you using for your cohort analysis? An internally-built tool? A third-party service?
  - joelg87 14y ago
    Hey Charlie! We've been back and forth on this in the lifetime of the startup, but we're now doing all metrics ourselves, so it is internally built. I built an early version of the cohort analysis (which didn't scale, but that didn't matter) just a few months in and it was massively valuable. It's not too hard to knock something together.
    - adambenayoun 14y ago
      Thanks for the answer Joel! By the way - I'm curious why you guys had to built this internally - I always get the feeling people prefer using a 3rd party service like kissmetrics than building something.
    - charliepark 14y ago
      Solid. Thanks!
    - robertocr 14y ago
      Internal BI is the way to go. It gives better vision to those who make decisions. Congratulations! :)
  - nanch 14y ago
    Would be an interesting third party tool. Does anyone do this already? Something as simple as receiving a list of usernames over time.
    - lubos 14y ago
      MixPanel can do this and they have a free plan. I custom-built my own cohort reports but as number of users grow in my own app, I'm planning to replace it with MixPanel. You don't really want to put stress on your own database servers which are meant for production, not for analysis.
      - aaronblohowiak 14y ago
        You should not be doing analysis (OLAP) on your main transactional database (OLTP). Moving from transaction-processing system (TPS) to analysis is done through a process call ETL (Extract, Transform, Load.) You will want to transform your data into facts and dimensions -- this is going from a relational model to a multidemensional model (using a star schema.)
        lubos 14y ago
        but that would be another system to maintain. I'm happy to outsource this to MixPanel or some other company. My needs are pretty generic. I appreciate your response though.
        aaronblohowiak 14y ago
        Yes, I 100% believe in focusing on your core competencies. If the OLAP is self-hosted or external, the key takeaway is to not do analysis against production (once your data set is larger than RAM ;) before that, who cares?)
    - ryanjm33 14y ago
      Cohort.ly does a great job. They are in private beta so you can request access. It has been really beneficial to us. http://cohort.ly/ http://cohort.ly/

shortformblog 14y ago

I think what really helped you guys is that you've always been earnest and have done a good job becoming thought leaders as bloggers. People could learn a lot from the way the Buffer team grew out its product. You guys created a really good template for slow-growth. Props.

joelg87 14y ago
Thanks! That means a lot, really appreciate you mentioning it.

chaddeshon 14y ago

Thanks for this helpful and encouraging post. As I was right this the main question I had was how do I know the difference between "Nobody wants what your selling" and "You need to do a better job marketing"? Retention is a great answer to the question.

joelg87 14y ago
Indeed, that's exactly right! I think for us, as soon as we saw that people were sticking around we knew we had to switch to "do a better job marketing". With retention, that was validation that there must be many more people out there who would find Buffer super useful, just like the people who were staying active. In essence, we needed to make more people aware of the value we were providing.
- yoshyosh 14y ago
  That's really awesome to hear. At what point did you start worrying about referrals? Was there a point in time when that naturally started to grow as more users, used it? Or was it something that didn't change unless you were focused on it?

switz 14y ago

I recently hacked together a product that aligns with buffer's philosophy, but is inherently different. I have about 70 users, but zero paid users and not much activity. I've been ignoring it from a development standpoint in favor of other projects. Meanwhile I still use the site daily. I hope I can put some more time into it, but for now I'm just letting it scratch a personal itch. If anyone is interested: https://tweezer.io https://tweezer.io

joelg87 14y ago
This is neat. It's a key problem we've spent a lot of time thinking about (that posting the same thing in the exact same way to different networks is not the right thing to do). Good job, and good luck!
dendory 14y ago
I was wondering why no one was tackling the issue of posting to multiple social networks, and instead all we saw were services that clone posts from one network to the next, services that usually get shut down from the networks. So I made my own a while back that can post to Twitter, Facebook, G+, etc in customized ways depending if I have a URL or not, automatically shortening it, etc. Otherwise I would give yours a try.
- Snoptic 14y ago
  Do you have to constantly change your web page scraper to maintain G+ support, since it has no API?
  - darkmagnus 14y ago
    https://developers.google.com/+/api/ https://developers.google.com/+/api/
    - estebank 14y ago
      The G+ API is read only.

rayhano 14y ago

Retention vs sign ups. Interesting. Are we talking LinkedIn style link-bait and endless 'notification' emails? Or Dropbox/Mailbox style gamification to get more free by being 'part of the club'?