Why We Prioritize Hiring People Who Use Our Product

May 19, 2015 5 min readOpen

When we wrote previously about how we hire at Buffer, one key component was that everyone we hire have usage of and experience with the Buffer product.

new buffer

That’s still the case today.

In the past we have asked folks to use the product for at least 2-3 months consistently before we would consider them for a role. This feels a bit limiting, and discounts the fresh perspective a newcomer to a product can bring.

Today we are a bit more flexible with this requirement, though we would definitely expect that a candidate has spent a good amount of time exploring the product and would be prepared to talk about the positives and challenges of their experience with Buffer’s tools.

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!

Note: A big thanks to Joel, Courtney, Carolyn, Kevan and Sunil for helping with drafts of this post and making valuable additions.

Brought to you by

Try Buffer for free

140,000+ small businesses like yours use Buffer to build their brand on social media every month

Get started now

Related Articles

OverflowJul 12, 2024
How We're Preventing Breaking Changes in GraphQL APIs at Buffer — and Why It's Essential for Our Customers

As part of our commitment to transparency and building in public, Buffer engineer Joe Birch shares how we’re doing this for our own GraphQL API via the use of GitHub Actions.

OpenApr 24, 2024
TikTok 'Ban' Bill Signed into Law: What It Means for Buffer and How Creators & Marketers Can Prepare

TikTok's parent company must divest the app or face a ban in the U.S. Here's everything we know, plus how to plan ahead.

woman examining a floor to ceiling bookshelf
OpenMar 29, 2024
Lessons from Unreasonable Hospitality: A Favorite Read From Our Customer Advocacy Team

How the Buffer Customer Advocacy Team set up their book club, plus their key takeaways from their first read: Unreasonable Hospitality by Will Guidara.

140,000+ people like you use Buffer to build their brand on social media every month