In this DevGuild: Software-Defined Movements presentation, Ashley Smith shares how to monetize a product that devs love without ruining a community you’ve invested so much time and energy cultivating.

  • Our Community Loves Our Free Product: Now What?
    • Goals for the Session
    • Background
    • The Steps to Monetization
    • Moving from Community to Commercialization
    • Recognizing When It's Time to Transition
    • The Best Routes to Monetization
    • Communities: Independent and Enterprise
    • Beyond Research, Pricing and Packaging
Download slides

Our Community Loves Our Free Product: Now What?

Goals for the Session

Today's goal for the session, why is commercial success important? It seems kind of obvious, but I meet with founders every day who are building a community, building a great tool, a great product. "People love our product, people are tweeting about it, people are talking about it. We don't need to make money right now." And I'm like, "You should always be thinking about money from the beginning." So how do you make money without ruining your community?

Community is a sacred thing, I think you all know that, and it's something that you work really hard to build and foster. It's kind of scary when you have to take that jump from community-free product to, "hey, please pay us some money for something we've built." But there are some actual tactics for monetizing your product for a large community. When you're thinking about what your monetization strategy could be, and a lot of it has to do with working with your larger companies who are using your product with larger teams and we'll dive into that shortly.


So who am I? Why am I talking about this? By training, by degree, I'm a biomedical engineer with a CS minor from Georgia Tech. Biomedical engineering is a little bit slow. I'm more on the startup pace, I think. So, moved to San Francisco. My first startup job was at Twilio as the first twenty people, got to work in devrel there, sales, marketing, ops, you name it, at Twilio, I got to do everything. I got to work with the most incredible team and learned from some of the best.

And from there, went to a startup called Parse. Parse is a mobile app platform and I was in the first 10 there. I was the first non-technical hire, if you want to call me that. It was acquired by Facebook and then subsequently shut down a few years later, but incredible communities surrounding both Twilio and Parse. And both of those were able to monetize. GitLab, great community. We were thinking about monetization from the beginning. I was in the first 10 there, was CMO. And then later stage I worked at GitHub on the exec team the 18 months prior to acquisition.

So huge community, huge monetization. There was some pull between the two and we really had to be very thoughtful and intentional about how we thought about those sometimes counter forces. I became a venture partner at OpenView. I was doing investments. I worked on deals Axoniuos with which is a security company here in New York City where I'm based. And I did an investment and I'm also a board member at a company called Buildkite, which is a CI tool based out of Australia. So everything I've done is developer tools.

Everything I've done I think is really about, how do we build a great community around our product, but also, let's please make some money on this because there are some signals that we should start monetizing.

Currently I'm angel investing in a lot of developer tools, data tools, design tools, anything that kind of helps the technical community get work done. I'm advising a ton of startups. I walk around New York City a lot, which is probably my favorite thing to do right now because the city is really coming back. So, excited about that.

The Steps to Monetization

So the title of my talk here is, "our community loves our free product, now what?" Every founder I talk to, like I said, is so excited about, "we've built so many great features, people love it, people are using it. It's on Hacker News. Twitter's blowing up about this thing we launched." I'm like, that's awesome. Okay, great. "We've got something, right? There's something there." They raise a little bit of money, they're bootstrapping. They're continuing to build that great product that solves a key problem for developers.

So a lot of times I'll get a pitch or work with a company and it's always, "we're going to solve this entire thing. We have a platform, we have a layer. We have a thing." And I ask, what is that actual key problem that you're solving? I need to know the specific key problem you're solving. And that's a hard question for a lot of people to answer. So if someone can't answer that question for me and in 10 words or less, I tell them to go figure out what the problem is that they're solving. And let's work from there.

Around that, let's build a community of people that have that problem and need to solve that, and are going to be searching for it or trying to find solutions for that problem, and can give you product feedback, be a champion, has love for your building, will work with you to help understand what you should build next. Really work hard to build that community. And then you want to empower that community to share the product with others.

Word of mouth is the best marketing tactic in an early developer tool.

And almost always, when I'm talking to someone who's built a great community around their product, I'm like, so how did you get this marketing strategy off the ground? It's, "people were just telling their friends to use this or people were telling their colleagues."

Then there's some question marks, step five, which we'll go through and then there's hopefully profit, right? We want to make money at the end of the day, if you're taking venture money, you're probably going to be expected to make money at some point.

Moving from Community to Commercialization

So what do we do to move from community to commercialization? What are the actual steps, right? So the first thing I think people kind of overlook is both your company and your product must be ready to monetize. So what does that mean? We all work with, or have hired or worked for people that are very much community-focused and feel strongly that community is core to what you're building. Maybe they're your first engineer, they're your first product person, your first devrel person. They're not worried about monetization, but they care deeply about features and products.

On the flip side of that coin, there are people who really like to make money, right? They care about the community but they care about features, but they care about features that we can ship to actually make money. You need both of those kinds of people on your team. You need to have a good balance within your team of both minds. And so that's something that if you have everyone thinking about, " all I care about is the free product" and no one thinking about monetization, you're never going to be able to monetize.

Also, your product has to scale. This is one that you would be surprised. If your product doesn't work, no one's going to want to pay you for it. If they do pay for it, it's going to be kind of a nightmare. So make sure your product scales, create a culture where you can ship a ton of things, but let's make sure they work or there's some great beta testing process that happens there.

Recognizing When It's Time to Transition

So what are the signs that we should be thinking about, pricing, packaging, monetization? It always happens that customers will say to you, "I would want to pay you money. Please let me pay you money." I can't even remember how many times I've been at an event or something. And I'd have someone come up to me that worked at a big company and they'd say, "You're not charging enough for the product." And that's always a very loud and clear signal that either you're not charging enough or you're not charging for the thing you should be charging for.

Generally a team of like five to 10 people. If you're series seed round, pre-seed, just before A, maybe you should be thinking about developing a lot of the community then. But as you start to scale your company up, start, like I said, hiring people that can be thinking more about monetization and building the other half of the business beyond just the community side of it.

The other loud, and potentially the loudest, signal is, investors that invest in your company will begin to ask about revenue metrics. Seed investors, pre-seed investors are all about, to build developer love, build your community. When you get to series A and B, and I'm sure a lot of you know this, and you're in a board meeting, they're going to ask a lot about developer love and community and active users and things like that, but also revenue metrics. And if you don't have good answers for that early on, you will start to have some really messy board meetings, I can promise.

The Best Routes to Monetization

So some modernization routes, these are just four that I know that work. You can use multiple ones in this list. There's things outside of this that would also work for monetization. But these are the four that I have the most experience with. So I'll talk about these. Enterprise scale. Collaboration features. Managed services. And support. So let's start with the easiest one first.

Support and Services: It's easy in the sense that you can launch this and then have some engineers answering questions. It's not easy to scale, but it's something, it's a quick way to make money. So if you're really trying to just make some money, maybe in your first or second year of monetization, come up with an enterprise support plan, its enterprise feature, come up with a way to train people on how to use your product. Do not rely on this as your only monetization strategy, because it's really expensive to scale a support team globally, and a services team globally, without some other way to monetize.

One caveat here is I think everyone deserves good support, for users, paid users, doesn't matter. The better support you provide for your community and your product, the better your product is because you can get so much more feedback from all types of users into your product roadmap. So give everyone good support, but also understand that enterprises are used to paying for support and services. This is a pretty easy thing to get off the ground. It's as easy as a landing page and email address or a slack channel.

Collaboration features. I love these. So collaboration features, a basic product is still going to be free in this case. But whenever someone's moving up to working with a team, they're going to need to unlock a bigger functionality. Is it commenting? Is it team roles? Is it permissions? What are these things that you need to have if you're working within a team? People will pay for those because in most cases, not all cases, in most cases, if they're on a team working, using a product, they're working in a bigger company and they have the money to pay you.

Great example here, HashiCorp. Terraform has this wonderful free tier. And then the Team and Governance tier. I won't talk about the business tier yet because I'm talking about that in a little bit, but the Team and Governance tier for HashiCorp's Terraform Cloud is all about collaboration, how to manage users, and enforcing provisioning policies if you're working with a team. A great way to understand and learn more about pricing and monetization is going to look at pricing pages of companies you admire in the space. HashiCorp obviously is a great one. As you can see here, they've started to think about a team approach, a collaboration approach to pricing.

Hosting. This one's fun. This one you can make a lot of really good money. Managed services is something that I think is becoming a bigger and bigger deal every day. DevOps is something that not every company has or can't afford a giant DevOps team. And so if you want to actually sell expert DevOps experiences.

I think someone who's doing this really well is Armory. If you look at this Managed tier on the right, you're getting everything that you'd get on the team enterprise plan, but you're also getting Armory's spinnaker experts around the clock. And that's just something that if you don't have a dev ops muscle in your corporation, this is a great way to get it. This monetization strategy is wonderful whenever you know that your product is very big for the enterprise and you can monetize that idea of a managed service.

Enterprise scale. This is the one you should be thinking about from the beginning, it's something that is the hardest to get right. But when you get it right, you make a ton of money. The only people paying you for this, it's not your community paying you for this. It's a giant corporation or a big company, which is great. SSL role permissions, enterprise support. A lot of things we just talked about actually fall under this. But enterprise features are so great and a good way to make money off of companies that are employing the developers that love your product.

So you're monetizing the developers when they go to work, you're not monetizing the community.

When they do go to work at these big companies or medium sized companies, you're able to charge their employer so that they can use the best tool. And the thing that they love the most. And I really like this approach.

I'm going to talk about Orbit. You've got the starter plan, which is free, but then you've got the growth plan, which really is like an enterprise plan where you're getting priority support, SLA, SSO. You're getting increased API rate limits, which is really important for big companies up to a hundred thousand members in the community. That's really large scale. And when you're at that scale, in most cases, it's okay to pay some money. And so I love this monetization route and I think Orbit's done a good job with it.

So, when you're thinking about, how do we price? What do we price? What do we build? Don't be afraid just to actually ask your community. People are so excited to give you opinions. Your community is there to help you survive as a startup, as a company. And so come up with a list of questions. They can be open-ended or in a survey form. I like survey forms for bigger audiences.

If you're doing a list of questions, get different types of community members, but 10 to 20 people and just ask, what would you pay for it? How much would you pay for it? What pricing models do you like? What do you think your company would pay for it? Just ask these questions and you'd be so surprised how much insight you'll get into how you should be thinking about monetization for your product.

Communities: Independent and Enterprise

And I want to be clear, when I talk about community, I'm not just talking about the indie developer or indie hacker. Those people mostly go to work somewhere. We all have been the person working on something at home hacking away, but then when you go to work at, wherever your job is and not always, but a lot of cases, that's when you become this enterprise developer concept but it's all the same community. It's a lot of times it's a crossover. It's all the same person.

So a lot of people talk about them being very separate, but in a lot of cases, sure, whenever they go to work, the needs are different. You do need different features, which again, people will pay you for. But it's all one community. And I think that's really important to know.

Today's independent developer, someone who's been working on some product at home or a student or whatever you are doing at that time can be tomorrow's internal champion at a large company.

So it's so important to really foster a strong community and care about your community and make sure you're listening to them because those are your internal champions at large companies.

Every day, always, when you're closing large deals, when you're getting into actually making a lot of money at a startup, the product got in the door because someone there loved your product, talked to people, the team started using it and then IT or the CTO or the head of engineering or something looked and said, "What are you all using? What is this thing?" And you got it from that internal champion.

Another thing, most community members want your company to succeed. There's always this fear that the community's going to get so mad at us because we're trying to make money. And that's not the case for most people. People understand that modernization is a key part of startup survival and it's totally normal. You just have to be pretty careful about how you do it. Sometimes people monetize their own features.

And so what this looks like, and the one that hurts the most, I think is you'll see a product roadmap where you're going to work six months for something you're building something. And you're sure is the thing that everybody wants. It's going to be so exciting. It's going to change the way your company monetizes and it launches it and no one cares. And that's the worst. So that's probably my... We've all done it, but that's when you're monetizing the wrong features.

The flip side of that coin is when you're taking free features, because you built something really cool and you give it to everybody. And then there's no way to make that into the paid product without taking it away. And so from the beginning of your startup, try to be very intentional about what you're putting into what I call the core product or the free product, community edition, whatever it's called.

Really be thinking, okay, should this be a paid product at some point? And if so, is there a level two version of it that we can charge for, but try to give as many features as you can in that free version and save the paid product for things that should actually be paid for.

Beyond Research, Pricing, and Packaging

So beyond research pricing, packaging, which are all huge undertakings, build a team that understands we're a business, that kind of comes from the top. It's very hard to work in a company that the execs or founding team aren't saying very clearly, "We're a community-driven product, but we need to monetize." It's both. It's not either/or. And so that should be coming through in all columns, when you're interviewing people, when you're doing 1:1s, don't be afraid to introduce this concept of monetization early on in this business's journey.

Don't let sales and marketing be looked down on. I have worked in organizations where, there's engineering and product and then there's sales and marketing. It's so separate. It needs to all work together. It needs to all be one cohesive unit. One can't exist without the other. And everyone is important in an organization. And so, really work hard to make it clear that go to market and R&D are equally as important in the business.

And again, community is extremely important and monetization is extremely important. And back to my earlier point on thinking about team and how you're building it. Hire engineers and product leaders that understand monetization, but also hire people that, or keep the people around that built the original community to love the product that got you to where you are and your community to where it is.

Those blend of people will be so important to make sure there's a perfect balance of free features, community features, community love, and monetization enterprise, et cetera. So it's a balance, but you can definitely do it. So what are our steps to monetization? Again, raising a little money, you're bootstrapping. You're building a great product that solves a key problem for developers. You're creating a community of people that absolutely love your product. You're empowering that community to share your product with others.

And then that next monetization step is you have to research and build pay features that larger companies need. I think that's kind of succinctly what we should be doing here. Profit. And then repeat, try again and repeat. You're going to fail a few times. It's okay. But you'll figure it out at some point. And if you don't go back to the drawing board there, go talk to your community and see what else you can do. I love talking about this topic so it's been a real pleasure to be here today, talking about both community and monetization because it's so near and dear to my heart.