When we wrote previously about how we hire at Buffer, one key component was that everyone we hire have a consistent usage of and experience with the Buffer product.
That’s still the case today. We conclude that if someone has at least used the product for 2-3 months consistently, then they have gotten value out of Buffer and are likely to keep using it.
There are often wonderful candidates with amazing skills and great cultural alignment who are interested in joining us. As soon as we see they’re not using Buffer we send them a friendly note that we hire on the basis that everyone use Buffer as one of 4 key components:
I realize that the reasons we do this aren’t always entirely obvious. Recently, a few candidates replied to my note asking for more information to understand why that is something we look for.
I thought that this might be a great opportunity to share more widely about why we prioritize hiring people who use our product. In short, there are 2 key reasons to this:
1. It’s highly motivating and fun to work on something you use
The first reason I think it’s so important for people to have a clear and good understanding of what it means to use Buffer is that it simply makes working at Buffer more fun.
If you are building and improving something that you yourself enjoy using and that solves a need for you, it instantly creates a more motivating environment. It’s exciting to ship something new that you yourself have tested and can put to use for yourself.
Another side of this is that it reminds you that what you’re building is valuable. Whenever I’m using Buffer myself, without forcing myself to do so, I’m reminded that this is something that makes my life easier, and that gives me confidence to keep working on it.
2. It helps us create a better experience for our customers
If you know what it’s like to manage your social media accounts with a product like Buffer, I also think you have a more empathic understanding of what’s the best solution for our customers. When Joel initially had the idea for Buffer itself, he had discovered a problem and solved it for himself. It brought him a lot of joy to both create a product to solve a problem he himself had, and also discover that many others out there had the same problem and could now benefit from the solution. In the same way, every single person who is part of the Buffer team discovered their need for a tool like Buffer from many different angles, and it is quite special that we have all come together based on our love of social media and need for the functionality the product provides.
It’s a way to relate better to others who have the same problem as you do, aiming to grow and manage their social media presence with us. The line “be the best user of your own product” is something that I keep coming back to in order to truly build a world class experience.
I think this applies to all areas of Buffer across the board, whether that’s the happiness team, the marketing team, community, engineering or product:
- For the happiness team for example, they can start answering questions and helping customers on day 1. If someone is brand new to the product, then they’d need to spend the first few days, if not weeks, of bootcamp in training. This way, they already know the basics and can start helping customers immediately. Of course they still learn a ton in the first 6 months, so I don’t mean to imply that it alleviates the need for training. It does make onboarding Heroes a lot smoother and better sets them up for success in that role.
- The Buffer blog for example, is partially successful I believe because we’re using and experimenting with Buffer the product itself so much and sharing all our learnings there. Out of all the people on the team, Courtney and Kevan are likely the most proficient Buffer users because of that. It’s one step beyond “eating your own dog food”. What we’re showing with our blog is the success of usage of our own product, which is the best testimony for using something that one can find.
- I have the same feeling for Moz for example – their blog dominates keywords on Google, like “Google algorithm”, where they rank above Google itself. That blow my mind and make me think…well, if I ever use any SEO product, I better use theirs.
- I think I’d like to contend the same is true on the engineering and product side. There is just so much to learn when starting at Buffer, (how to remote work, how to communicate, how to self-manage, how the code base is structured). Knowing the product, how it and the API works ahead of time has made it for one less large thing to get comfortable with for the engineers. I feel like knowing the product sets us up for success because we’re all thinking of the many different ways we’d like to see Buffer personally grow.
Internal discussions on whether it’s the right thing to do
Although this is something we’re firmly focusing on right now for our opportunities to join the team, we have on quite a few occasions had internal discussions on whether this is the right approach.
After all, there are tons and tons of amazing companies out there that work without that mindset—in fact, it’s not even possible in many cases. Take any enterprise software tool, for example: It’s almost impossible to use it yourself as an individual. And yet, clearly someone can be excited to work for that company.
Even at Buffer, that is partially the case. Our metrics show us that some of the most engaged customers (meaning, those that take the most actions inside the app) we have are brands, startups and small businesses managing their social media presence with us, as well as social media agencies.
We also have a lot of individuals as customers who find Buffer helpful, although I wonder whether we bias ourselves towards that particular group with this setup.
And vice versa, if we’re not focusing enough on the features that these other types of customers would really need, since it’s not something we ourselves need.
Someone who hasn’t used Buffer at all and is still excited about working with us might have a more unbiased way of looking at things, without being attached to focusing on Feature A compared to Feature B.
We’ve been discussing this a lot internally too, bouncing back and forth on it a few times, so getting more insights from anyone reading this would be great.
I’d love your insights as to what you’ve found to work best at your company and which direction has helped you the most!