1. The users 2. Their needs 3. Value chain 4. Evolution 5. Sociotechnical system 6. Buffer’s gameplay 6.1. Expanding into revenue 6.2. Channels expansion gameplay 6.3. Ecosystem (new thanks to Amanda from Buffer clarifications)
⚠️Disclaimer. All the content, assumptions, claims, and so on I do on Buffer are my own interpretation, and it doesn’t represent the company’s reality. This post is an open practice on Wardley Mapping for PLG products to understand how more open products are easier to map compared to more closed ones.
🎉Update 16th December 2024: Amanda Marochko, Staff Product Manager at Buffer, reached me after reading the post, and share clarified in some areas that I was mistaken/had the wrong information. Amanda, thank you very much for your time!
I will mark the previous info and the new info so you know the difference before and after the conversation. Plus the Amanda’s clarifications. The words are mine, and might not be 100% accurate due to making a summary of the conversation.
I use Buffer to schedule some of my content for Bluesky and LinkedIn, and I wanted to learn more about this product because it has several interesting traits.
Product-led Growth approach. Which helps me identify the customer, and their needs easier as I don’t need to speak to sales.
1. The users
Learning which is their customer is quite straight forward using key sections of any landing page.
The testimonials.
The pricing page.
Use cases.
Buffer has the first two.
Based on these two sections, we can determine that the users are:
Individual content creators due to the Essentials plans.
Marketing/content teams.
Amanda’s clarification: You are right. We have these two user personas, we have aimed to attract SME businesses, but we found out that individual content creators, such as thought leaders as you, are the main user persona that we are attracting. More focus on them will be put into 2025.
2. Their needs
Understanding the user needs is quite straight forward for individual content creators out of the Tools navbar menu.
On the other hand, content team owner can be inferred from the pricing page, but I tried the organization features to be sure those are the main ones for teams. Thanks to the free trial, I was able to verify those needs.
3. Value chain
Buffer has a quite interesting approach on the subdomains, almost a subdomain per navbar item.
Create and Publish sharing the same subdomain can determine a legacy constrain due to the company probably started with a monolith providing creation and publishing posts, and later-on has evolved into their own products, but the code probably being coupled kept them together.
At components level, we can identify few, but they vary a lot depending on the channel and post type. I consider them to be like a pipeline, where we have several components evolved differently
Let’s explore it directly into the Wardley Map with the evolution.
Amanda’s clarification: Yes, the subdomain approach is a legacy decision when we had a subproduct approach. Right now, we are considering Buffer as a one product to have a unique experience. We are working on this for 2025.
I identified some key components like Ideas, Posts, and Reports. Those looks like they have been a pillar for Buffer. When navigating the product, I could see how the channels influenced the post types, as well as the feature maturity beyond create and publish.
I could identify text and image posts to be well establish, and be part of cost of doing business, while video is part of the new offering. On the other hand, polls posts aren’t supported (AFAIK).
That’s why I create a pipeline for the Channels, where the channels that support more features are more evolved than the ones that aren’t that evolve like Bluesky. It has been interesting to find that Meta products, Facebook and Instagram, are quite evolved, but Threads don’t. The evolution Thread’s API could benefit Buffer to extend the use cases for Threads as well.
Other channels are keeping most of the API restricted to publish, and few are opening for analytics.
5. Sociotechnical system
By looking at LinkedIn, we can infer the amount of teams, and how that affects their domain structure.
I did this exercise after the Wardley Map, so, let’s see how by knowing the team size can help us identify which domain boundaries they could define, and how that can evolve in the future.
Total: 226
Operations: 58
Engineering: 40
Customer success: 27
…
Product management: 7
LinkedIn isn’t accurate on the numbers, but based on them, we can assume Buffer has around 5-7 product-engineering teams.
Amanda’s clarification: This is the part of the post more wrong. We aren’t +200 people, we are 80 people company.
Total: Around 80 people
Operations: 5 people
Engineering: 25-30 people
Customer success: 27 people
People department: 4 people
Marketing: 15 people.
With 4 product-engineering teams:
Apps, channels, and platform.
Consumer experience.
Audience engagement.
(another I don’t remember the name) 😅
They leverage multiple providers, such us:
A lot of customer success tooling like HelpScout, Klaus, Pendo, Retool for internal dashboards probably
All connected with tools like Fivetran.
Even though it looks like they have the approach of buying off the shelf as much as possible, they also do custom build solutions. Those are made with:
Web and API: ReactJS, NodeJS, Typescript PHP, GraphQL and MongoDB
iOS: Swift, SwiftUI & Objective C
Android: Kotlin, Java and Jetpack Compose for Android
I didn’t identify the need of providing an iOS or Android app.
Regardless of that, it seems like they have a full-stack mindset, and everyone is expected to help everywhere when possible.
Because of the usage of K8s, and the stack, and the URL composition, it is quite possible that they are using a microservice architecture.
It doesn’t look like they have a platform team, even though a candidate can be the channels component.
The channels component needs to provide connect to all the social networks, and that would require a unified API, but at the end, and because of the post topology, encapsulating that can be complex. So, I’m quite sure some common stuff like Authentication, OAuth2, and alike are shared components of that microservice, but then each channel has its own implementation, and that’s exposed to the different components in some degree.
I believe the teams aren’t per user need/domain.
I believe that the teams might have some degree of influence based on the product structure per subdomain, but I think the teams work on domains that overlap, and they share some components, to deliver product increments.
Those shared user journeys, or shared components, are beyond the channels. They also have the components of:
Organization, user management, and permissions.
Payments processing.
Landing page.
Internal tools for customer success.
Internal data tools for high visibility and decision-making due to the product-led growth approach, and the need of optimizing the right user funnels to make it as low touch as possible.
6. Buffer’s gameplay
Buffer biggest constrain is the social-network API’s dependency. As long as social networks don’t support posts formats or key APIs for engagement/analytics, they are unable to offer a value add on the new features such as analyze and engage.
The bet on Buffer’s AI is key for the creation/idea phase, and also as engagement.
If they are able to augment the personal brand by, instead of generating out of the blue content, creating tailored content based on previous posts, understanding the tone, the audience, and so on, it can be very beneficial.
Combining Buffer’s AI with:
Current posts to understand the brand tone.
Understand which posts brought more engagement.
Provide insights on industry trends…
can be awesome.
6.1. Expanding into revenue gameplay
Engaging and growing the social networks might not be enough, and the customers need to understand if that converts to revenue.
Right now, Buffer is solving the content creation pain. If they are able to extend that into understanding revenue via Shopify APIs for example, it could provide in-app insights on which pots provided bigger ROI.
That bet would require bigger understanding of their user base, and start by a concert segment of their user base.
This can position Buffer’s as a NoCode application from building an audience, to creating a sustainable business guided by data.
Amanda’s clarification: We won’t do that specifically due to the risks you are mentioning. Expanding into this area is a huge bet, instead, we will do (See point 6.3. Ecosystem).
6.2. Channels expansion gameplay
Keep integrating with other places where content creators audiences could be, such as Quora, Redit, WhatsApp channels, Telegram Channels, …
It is a well understood gameplay by Buffer’s team, and probably following the same strategy in terms of go-to-market, engineering, product, etc.
Amanda’s notes: Yes, being the first ones to adopt new APIs for channels to expand the channels feature is a strategy we keep. That’s why we are close to those channels to be the first ones to implement.
6.3. Ecosystem
This point is thanks to Amanda’s clarification. Thank you for allowing me to share this insightful strategy with my readers 🙌
Betting on new lines of business, and user needs, have a high risk.
Instead of betting on certain new user needs, and limiting the innovation. Buffer’s 2025 strategy is focused on creating an ecosystem to help other’s build on top of Buffer.
In order to do so, they are working on three main “new” components:
Buffer’s external/public API to access all the components like channels, and so on that I mapped previously.
Buffer’s marketplace to help Developers publish their products, let’s call them power-ups following the Trello’s terms, and Buffer content creators customers to find new ways to engage, and reach a bigger audience.
Buffer’s new pricing model to support the marketplace approach.
If you are from Buffer, drop me an email, a comment, or a DM, to know much right and wrong I was!
Thank you a lot for reading this post 😄.
I love to read your feedback and opinions to help me improve. You can DM at my LinkedIn or just leave a comment using the following links:
