As a social media startup, Buffer is constantly learning about what it takes to build great products.
One of our more recent sources of learning has been the launch of Pablo, our social media image creation app. Building Pablo has been a unique experiment that equipped us with some great product lessons.
In fact, some of the elements of launching Pablo that we initially viewed as mistakes or challenges have turned out to be great opportunities in disguise.
Here’s a look at 4 things that “went wrong” in launching Pablo that later turned out to have been exactly what we needed.
1. We launched way earlier than we planned
The Buffer team started working on Pablo in early 2015.
A task force was formed and quickly built a minimum viable product. The intention was to test it and steadily improve before officially launching Pablo—but that never happened.
Brian Lovin, a Product Creator at Buffer at the time, describes what happened on the Daily Hunt podcast:
“The funny thing is, we actually didn’t really anticipate that we’d get on Product Hunt!…We wanted to learn a little bit more from a few people and interviewing actual customers, but of course someone submitted it to Product Hunt and it took off, so we’re kinda just rolling with it now.”
To some people, this might sound like a really big problem. The product was still in its infancy with a lot of bugs and we didn’t even know if we had product/market fit.
However, releasing it “too early” turned out to be a huge win, for a few reasons:
- The Product Hunt community is full of incredible people who were willing to identify what was awesome about the product and cheer us on.
- We were grateful for early-adopters who were willing to try Pablo, find bugs and let us know where we might need to improve.
Here are some examples of how this played out on the Pablo Product Hunt page (click to enlarge):
Launching on Product Hunt allowed us to accelerate our early product development.
By having Pablo out in the real world, we learned rapidly, shipped bug fixes at lightning speed and built a mini-community of Pablo enthusiasts.
And the benefits of this “mistake” weren’t only limited to Pablo. On the day Pablo launched on Product Hunt:
- The Buffer website exceeded 100,000 visits in one day for the first time ever.
- Buffer had its highest number of sign-ups and trials in a single day.
As Reid Hoffman famously said, “If you are not embarrassed by the first version of your product, you’ve launched too late.”
2. Our numbers flatlined after the buzz wore off
After launching on Product Hunt, a horde of people flooded into Pablo. Here’s what the user numbers looked like before and on launch day—a nice spike!
But that graph only tells part of the story. Here’s what user numbers looked like just a few days later.
Uh oh—Pablo saw a significant dip in usage.
But this big drop turned out to be another great learning opportunity.
At the time, Pablo was a minimum viable product with a limited use case in a field with lots of other options.
Attracting lots of users was positive because it signaled that people were interested in what the product might be able to accomplish.
But as the buzz tapered off, it served as a great reminder that there was still a lot of work to do.
Sean Ellis describes this predicament well:
“Even the greatest marketers can’t sustain growth on a weak foundation. Eventually, their growth curves crater.
“So what is required for a strong foundation? A must-have product.”
Despite the drop-off in users, the initial spike in numbers gave us a large base of users to learn from. Their input played a key part in helping Pablo establish product/market fit and laid the groundwork for Pablo v2.
3. We didn’t know who owned the product
In the weeks after Pablo’s initial launch, there was an undeniable sense of excitement and energy for the project.
Here’s a note Brian wrote about his initial plan to move Pablo forward:
But here’s where a third challenge came in: The Buffer team at this time was experimenting with self-management and working within units we called task forces.
As Courtney describes it:
“(Task forces) were fluid, dynamic teams formed for a specific purpose (for instance, developing Buffer for Video) that could be proposed or joined by anyone at Buffer, regardless of role.”
The task force approach had many advantages, such as allowing people to work on projects that they were most interested in. However, this setup also had significant challenges:
- Task forces were project-based, so once Pablo had launched (i.e. the project was completed) it was a little difficult to determine who was responsible for its continued development.
- Research would often be prevalent early on within task forces. Once product development was underway, research tended to slow down because it wasn’t an integral part of the task force structure. This setup slowed down validated learning within task forces.
This tension played a part in Pablo’s momentary stagnation, illustrated in another Discourse post from Brian:
Examining this situation and others like it eventually led to us moving away from task forces (and a few other elements of self-management) at Buffer.
Our new team structure includes areas and circles, a setup that solves many of the challenges we faced within the task force structure.
So although we might have lost a bit of time developing Pablo further, we ended up unearthing and fixing a central tension that has since allowed us all to work faster, happier and more productively.
4. Our users told us they wouldn’t use it
Most recently, we spoke to dozens of users about their experience with Pablo and other image creation apps.
In those conversations, we started to notice a few themes emerging that gave us pause.
Here are a few snippets from those interviews:
“With our clients, sharing quotes is not the biggie — that’s why we hardly use Pablo.”
“Pablo doesn’t seem to be that beneficial because I’m not looking to add text to my photos.”
“Pablo doesn’t help the company much. It’s very personal tool, not a very great biz/enterprise solution.”
“I don’t like to see the quotes, so please don’t want to start off with quotes. More times than not they’re a nuisance.”
“I really only use Pablo to create quote images. I haven’t need to do that for a while.”
This felt like a big problem: Users were basically telling us that Pablo wasn’t all that useful for them.
But upon closer inspection, we noticed that what they were really telling us was about perceptions of the product.
They were telling us that they didn’t see Pablo as a ‘social media image’ creation app. They saw it as just a ‘quote image’ creation app.
That might not sound like a big difference, but we think it is! In the eyes of our users, Pablo was a great tool for adding text on top of an image. Users created many more types of social media images, so Pablo catered to one of their needs.
This limited use case helped our team realize that we needed to expand Pablo’s functionality if we really wanted to make social image creation easier and more intuitive.
As a result, we’ve been working on adding more images and creating new features like a library, image repositioning and more text options (all coming within the next month!).
We would have never discovered this invaluable information without talking to our users.
In his own words:
“The ultimate ‘win’ from customer development is deep insights into how our customers think, feel and use our app. That insight is absolutely critical to the growth of any business, and it’s the biggest reason I took this project on. It had an immediate impact on how we approach our product roadmap and day-to-day decisions.”
What product lessons have you learned?
We still have much to learn, and you likely have some great lessons to add here.
What are some of your biggest takeaways from launching a new product? Have you ever had an element of a launch that you initially thought was a big mistake turn out to be a great opportunity?
I’d love to learn from you, so please share it all in the comments section!