There comes a time in most B2B agency or software development company’s lives where a decision has to be made: Do you allow strategic customers to pay for specific new features on your product/offering?
This leads to an existential question within software companies: do you build features for a single user/company to maintain that strategic relationship, or do you say “no”? The answer to this question defines whether you are a product company, or an agency and you have to weigh the scales.
The fundamental difference is that one of these companies builds a product and sells it to multiple people and charges on a value based structure. The other sells their time for a set amount of money and uses that time to develop bespoke, custom software for each customer. Therefore, a Product scales exponentially and an Agency scales linearly.
So what’s the answer? You can’t just say “no” to a strategic partner that makes up a large portion of your revenue. Instead, put on your product management hat and ask the following questions:
If this one customer is asking for it, does it have value for other customers?
If yes, then how can you build it as a ‘core product’ feature such that it delivers value to more of your customer base?
If no, how can you make your product extensible?
Extensibility adds a new dimensions of value to your product. A well crafted API strategy at an appropriate level of abstraction that is integrated into your product roadmap will allow you to:
Address the “must have” needs of your VIP customer by allowing an agency to use the API to build that custom feature
Deliver additional value to all your customers
Add revenue streams to your product that were previously not possible.
Offload responsibility of maintaining anything built with the API to the team building it - whether that’s a “services” division of your company, or a 3rd party.
The diagram above shows a really good example of this. Even with all of Google’s vast and seemingly unlimited resources, they can’t realistically build software for every single end use and customer (no matter how big they are). So they’ve set up a core API team to build the company APIs, and rely on third party developers to unlock the value in those APIs and in Google’s vast store of data for their specific use cases and customers.
You can go further beyond API level abstraction by laying the foundation for UI level extensibility which would add another dimension of value for agencies and customers alike. Ultimately, this sets the foundation for a “partner” ecosystem (e.g. Microsoft Partner Program) which can unlock another growth lever and allow the impact you are delivering to be magnified.
Product companies solve problems, Agencies delivery custom solutions.
Examples
There have been many well-known organizations that have transitioned from agency to product, and they all follow very similar journeys. Two that I will mention briefly in this article are Mailchimp and Moz.
Mailchimp
Mailchimp started as an email marketing agency in 2001, and its primary focus was providing email marketing services to clients. Over time, the company began to realize that its clients had similar needs and pain points when it came to email marketing. In response to this, Mailchimp began to develop its own email marketing software, which eventually became its primary focus. In 2007, the company launched its email marketing software, and the rest is history.
Moz
Originally known as SEOMoz, Moz started as an SEO consulting agency in 2004. Their knowledge, proximity to customers, and ongoing client relationships and management built up the knowledge that would eventually lead to the launch of their SEO software in 2008. The transition from an SEO consulting agency to a product company required a deep understanding of the needs of their customers, significant investment in product development, and a willingness to iterate and evolve their product offering over time.
Common Trend for Growth
Agency: Both Mailchimp and Moz started as consulting/agency/service businesses that built/provided solutions to clients.
Hybrid: Over time, their expertise and knowledge allowed them to solve common pain points by building software to solve these issues.
Product: Ultimately, both companies focused their efforts on the software due to the greater scalability and greater impact they could achieve by doing so. Their software allowed them to scale their services beyond what their time allowed.
API: Both companies recognized that although they had a great product, they couldn’t solve every single customer need with the resources available to them. So they included API strategies as part of their product roadmap and are able to unlock new revenue streams, and deliver greater impact to their customer base as a result.
Additional Thoughts
I spent most of this article talking about why a product team should avoid building bespoke features for high value customers, and should instead consider strategies for extensibility and focus on core product development. However, an organization with the right resources can capitalize on both sides of this problem. If your organization is structured to support core product development with additional add-on services delivered to specific clients, then you can get the best of both worlds.
“I think that services businesses can sometimes build great software products on the side, and offer those and have them be a part of their competitive advantage. And I think that software businesses can offer services, and have that be part of their competitive advantage.” - Rand Fishkin, Co-Founder of Moz
So, what do you think? Have you gone through this kind of decision making yourself? Have you been a part of a company that has or is going through this type of evolution? Let me know in the comments!