For more than eight years, I was lucky enough to work at a software company focused on vertical markets. I didn't step into the company with any expectation that it would be any different from any of the software companies where I'd worked before that.
I was wrong.
It was a software company, like many others. And we faced all the normal challenges of building software. But it was there that I learned of network effects. And that wasn't something I was particularly used to.
Let me explain a bit about how it works before articulating a straight definition of the term: network effects.
What happens in a normal software company
We were in several vertical markets, with different products. When I say vertical market, think “specialized industry.” So in public housing, or in housing finance, our product was in the top two or three products that any company could purchase.
In most software companies, when you're in the top 2 or 3 choices that prospects have to choose from, you normally hear a lot about differentiated features.
- We're the only one that can do this kind of reporting.
- We've created the best algorithm for calculating that kind of thing.
- We have more integrations via our API than anyone else.
The problem with differentiating on features is that someone else can build a similar feature. Or worse—they can announce that they'll soon have a feature (whether they're building it or not) and stall any efforts you might have to win new customers based on that feature.
Another problem with relying on feature differentiation is that you stand the chance of adding more and more features for a fixed amount of money—making that kind of investment painful. When others are doing what you're doing, plus a little more, you feel the need for feature parity without raising prices—and this lowers your margins.
I say all of this to explain what is normal. But that's not what this post is about.
Building software to leverage network effects is anything but normal.
Selling software a different way
Like I said, in most companies, you sell based on features. It's a bad call, but it happens. Others sell on benefits—where most of the benefits are derived from features. I'm not talking about that either.
I'm talking about a sales approach that focuses on, for lack of a better phrase, “joining the family.” Let me show you what I'm talking about.
When I would be in a meeting with a prospect, they'd ask me a question about a problem they were having. Instead of responding with a common, “we have a feature that solves this…” I would respond by talking about our customers. “We have a customer that faces that exact challenge…” and then I would explain how they used our software to fix it. Then I would end with, “…and they created a report that you might find useful.”
That last part is key. Because it's not about my features. It's about something my customers have created.
Imagine what happens in a meeting like that where a prospect asks me 10 questions and each question points to a different kind of customer who has solved it, and the resulting artifacts that might help them.
They walk away hearing two things:
- They can solve our problem
- They have customers just like us, and they've figured out how to solve our issues
It's that last part where everything changes.
Because imagine that I answered the initial questions with feature descriptions. I say nothing about the customers I already have. They only know that their specific questions have been answered.
But by talking about the constellation of customers that use our product, I'm describing a network. And that, in and of itself, is a moat. It's something my competitors couldn't easily replicate, like they could a particular feature.
If I have more customers than you, and my customers are creating artifacts or resources that you can access – but only if you're part of the family (a customer)—then I'm no longer selling you my software or my features. I'm selling you access to my network.
Understanding network effects, therefore, is critical to designing your software in a way that helps you create that growth while also creating a moat (a competitive advantage).
So what are network effects?
Network effects are dynamics where value is increased with each additional participant.
Think about the internet. Or email. Or Facebook. Would any of those be awesome if it was only you on there? Nope.
Try thinking about selling the first phone line. What's your pitch?
When I was sitting in that boardroom making a presentation, you can trust I wasn't pitching feature parity. I was talking about the value of our customer base. The size and variety that would bring immediate benefits to this prospect. “You are not alone,” is a powerful message.
Leveraging Network Effects
Now that we're all clear about network effects, let me ask you this: how do you build products that leverage this dynamic?
I want to give you a couple of examples from the world I live in regularly, WordPress, that might help you think about it.
StudioPress & the Genesis Framework
If you go back in time, in the WordPress world, there were few players creating commercial themes. The Genesis Framework was one of them; iThemes was selling Builder, and WooThemes had a ton of themes.
iThemes built and sold Builder, and sold child themes for it. And they created and sold plugins that worked with their themes—for sliders, and more.
WooThemes sold a theme subscription with tons of different (and often fully-featured) themes. In some cases these themes were applications (they had themes for help desk tickets and more).
In a way, both iThemes and WooThemes killed off network effects by delivering too much. They didn't mean to do so. Nor do I think they were thinking about things that way.
But by selling Builder, it's child themes, and all the plugins you would ever need—iThemes created a marketplace where you could get everything you wanted there. From one source. Why would anyone else create anything iThemes related? They'd just wait for iThemes to build it.
The same is true for WooThemes. With a theme for every possible thing, why build something for WooThemes when you just assumed they would soon build it themselves?
But Brian Gardner and StudioPress built a framework (mind you, WooThemes had a framework too, but it just came embedded in their themes). Sure they rolled out some child themes, but the framework solved some low level dynamics and left everything to others.
[tweet “There's a difference between incomplete products and half-baked products.”]
So what happened? Developers created child themes. But they also created plugins. And as they did so, each brought with them more resources and their own audience to the table. Genesis grew because the community around it invested itself and brought their own customers.
And with each additional person using the framework and adding features via plugins, they increased the value of the entire network. In the end, “join the family” was and is an easy pitch for people who regularly recommend StudioPress and the Genesis Framework.
Beaver Builder
In the WordPress space, if you've not heard about or tried Beaver Builder then it's clear I have more writing to do. It is an incredible product in a sea of competitors. Drag and drop theme and page builders have been around a long time. And the new set of page builders that have appeared in the last year or two is staggering.
But none have found the same level of success that Beaver Builder has.
One might think their success is based on their code base or set of features. But that's not how I see it. Instead it's the implicit humility of its lead developer and their founders that have made it a success.
The key to their success is an open module and template system that lets others build things the founders hadn't thought about. In other words, while they created a feature-rich product, they didn't assume it was complete. They left it open for others to extend.
And the extending has happened.
There are, off of the top of my head, half a dozen sites that are selling Beaver Builder add-on modules. There are another half dozen sites providing articles that help you create customized templates or integration points.
Every person that buys their product becomes part of the family. Every person then benefits from what any other family member creates. People share templates. They share modules. They sell them. They give them away for free. It doesn't matter.
What matters is that the success of Beaver Builder isn't simply reliant on how hard their own developers work. The network effects of a community that is building third-party resources for the product will drive the success of the product faster than other competitors.
WordPress & its plugin model
I'd be remiss if I didn't point out that in 2005 when I was having conversations with my brother about the CMS he was working on, and the stuff I was playing with (WordPress), the key differentiator wasn't the code or features. Instead, I simply asked him how many plugins his CMS had. It was a proxy for community engagement. It was a proxy for productivity. And it was a proxy for future success.
Open source has a way of allowing this to happen. But this isn't an open-source thing. There are tons of open source products that feel complete and have little or no way for you to engage or extend them. That won't lead to network effects like those I'm talking about here.
Are you building products?
If you're building products, are you taking these network effects into how you design them? If you want to chat about your product and product development, you can always reach me on Clarity.
If you're building products—writing code—and want to level up your coding, you should follow my friends Tom, Pippin, and Tonya.