Validating an Adobe iPhone app
When it comes to app idea validation, many people still question the feasibility of the approach. As I’ve written about in my email course, idea validation is important. It’s the best way to de-risk your app idea before spending months on coding, marketing, and launching it to an untested market.
Over the past few months, many readers of my email course have asked me about real world applications of idea validation. There’s been enough interest that I decided to put together a case study of one of the projects I did at Neo (now part of Pivotal Labs). Neo used to be a consulting company that validated new app ideas for fortune 500 and start-up companies. Clients would often come to us with fully baked, but untested app ideas. The question we would first ask, however, is why. Not surprisingly, they would oftentimes not have a convincing answer. Our job was to put together an ad-hoc start-up team of an engineer and designer. The team would employ a range of tactics to validate the idea, leading to the building of a Minimum Viable Product (MVP). The goal was to walk into building the final product with full confidence that the markets indeed needed the solution.
So today I want to present a case study of one of the projects I did at Neo. The project is for Adobe and the product that it ended up with is Adobe Post. As it stands now, Adobe Post is an iOS app that creates social media graphics, which can then be posted to all major social media platforms. As of today the app has over 800 reviews on the App Store, at a 4.5 stars average rating. Since I don’t have access to their financial information or download numbers (I don’t working at Adobe), I can only use ratings as a proxy for how well it’s doing. By that measure, the app is doing pretty well.
So how did Adobe arrive at this app idea? Did somebody at Adobe have a light bulb moment? Was there overwhelming user requests from the community? Did they absorb a startup that was working on this idea? Or did they go out and validate the need for it in the market?
You guessed it, it’s indeed the last one. When Adobe first came to us, the stakeholder actually wanted to build an infographics generator for “constant communicators”. Two questions jumped out at us immediately–why infographics and who are the constant communicators? Since the client was working on another product full-time, he had done very little research–he was purely going off of his hunch. It was going to be our job to figure outs if infographics generator is a good idea and who exactly would use it.
To clarify our initial confusions, we sat down with him for an entire day, digging into the specifics of his idea. We learned that Adobe was interested in capturing non-professionals who had design needs. These people communicated online, mostly visually, and should ideally have some kind of business goals. While this was a lot more concrete, It was not enough for us to build a niche market around. In my opinion, a niche market should be small enough to at least justify a meetup group, Facebook group, or a subreddit. By this definition, what we had was still too broad.
After some brainstorming, My partner and I set on the market segment of social media managers at small-to-medium businesses (SMB’s) who lack design support. We chose this group because their job was to communicate on behalf of a business/organization; they needed to do it every single day; and they understood the importance of communicating visually on social media. While the definition of being a social media managers shifted quite a bit over the years, it has become a necessary position at almost every single company with an online presence. From our research, most SMBs either managed their social media with a full-time staff, freelancer, or the founder him/herself.
Since my partner and I have never been social media managers ourselves, we reached out to our network and gathered about 15 interviews. With each interview, we tried to understand their problems, how they got around those problems, and how painful each problem felt to them. With these learnings, we quickly invalidated the infographics generator idea. We invalidated it because:
- most people did not know what an infographic was,
- if they did, they did not have the time to gather up the necessary data and facts to create an infographic
Most of them needed to post three to seven times a day to three or more social media platforms. They needed a tool that would help them create shareable assets quickly and efficiently. The biggest commonality among all interviewees was that they needed to post to Twitter before they posted anywhere else. Each post also needed visual assets, since plaintext tweets get very little engagement. Because they lacked in-house design support, many of them were hacking together assets with whatever simple design tools they had access to (including MS Paint).
Given everything we had learned, we prototyped a few different solutions and showed them to our interviewees. The idea that gathered the most excitement was a Twitter image creator. (Note it’s important to come up with as many ideas as possible in the brainstorming stage since the first idea you come up with is rarely the best one.)
Now that we have a solution we wanted to validate, it was time to see our target market truly felt the need for this tool besides the team and the interviewees. So to recap:
- The problem: creating eye-catching Twitter images quickly was difficult
- The solution: an image creator that can rapidly create engaging Twitter-optimized images
Since we were makers, we wanted to make something right away. Curbing our urges to build out a full-blown app, we decided to build a concierge experiment with the explicit goal of validating whether people truly had the need for a better Twitter image creator. We decided to use the web as our prototyping platform, since it’s much better suited for learning and iterating (no review process, instantaneous updates, etc).
For our first experiment, we wanted to make something we could ship in a day. The constraint kept us away from building features to instead focus on doing the least amount of coding/design to extract the most amount of learning. Our learning goal was to figure out:
- Whether our target market was remotely interested in creating Twitter-optimized images.
- If they were, what type of images did they want to create?
We set up a static site that only had the value proposition and a submission form. On the site, we promised the visitors that they could submit a request for a Twitter image with any specifications, and we would send a hand-crafted image to them for free within 24 hours.
What happened under the hood? The form submission triggers the creation of a Trello card with the visitor’s information and her request. My design partner would then take the request, and come up with a design in his design tool (Sketch).
Launching a brand new site, we didn’t have any organic traffic coming in. Luckily we had a marketing budget, which allowed us to accelerate the process by running paid ads to drive traffic to the site. Below are some of the ads we ran:
Pretty quickly we were driving about 100 targeted clicks to the site per day. We received requests (a conversion) on about 25% of those clicks, which was decent considering some of the ad clicks weren’t relevant. The requests usually consisted of text over an image or vector icons. Sensing this pattern, we became quite efficient at creating them. Fulfilling all daily requests only took a couple of hours.
After running the experiment for a week, we learned that while many people were requesting for these images, not very many were posting them. This wasn’t a great feeling–the effort my design partner put into creating these images seemed wasted. Not letting this minor setback bring us down, we reached out to people who requested the images but didn’t post them. We learned that people had specific things in mind when they requested the images, which they didn’t know how to articulate in a tiny input box. Some of them wanted their brand logo or color while others had specific types of images or icons in mind. Furthermore, the visitors who requested images needed them at that very moment. When they received the image back hours laters, they no longer needed to post.
To recap, we learned:
- people were enticed by the value prop,
- people were interested in creating marketing images for Twitter,
- people had a hard time articulating in words what they wanted, and
- an overwhelming number of the requests were for text-over-image.
At this point, it made sense to finally build out a proper MVP so we can start getting usage data. Given that most visitors wanted the text-over-image format, it felt natural to focus on that as our first step.
The text-over-image format was further validated by our research into the social media manager community. We learned that the format was becoming a very popular among the community–it was visual enough to grab someone’s attention while also short-circuiting the 140 character limits.
With all the learnings in our back pockets, we went back to the drawing board to create a MVP. Again, we wanted to do the least amount of work possible to learn the most. In a nutshell, the MVP was a web app that pulls images from Flickr based on the user’s search queries; the user picks the image from the Flickr results and type in the message they wanted to convey. To save time, we only offered the ability to download the image.
Throughout the process, we stayed close to the usage data and consistently reached out to people who posted Spruce images on their Twitter feed. We tried to learn about their likes and dislikes about the product, what they wanted to see more of and what features felt unnecessary. To avoid building features off of anecdotal feedback, we monitored the usage data and watched our funnel like a hawk. Each new feature was designed to raise conversion rate of downloading or tweeting the image.
It’s better to use feature requests as a backlog of ways to improve the products. What ultimately stays in the product should be backed up by data.
Using this approach, we steadily improved the product week by week, until we were consistently converting over 30% of all visitors on the site. We also built in viral features like individual pages for shared images and automatic crediting of Spruce in the tweets. Combined with paid ads, we were receiving a decent amount traffic everyday, much of which recurring.
Small amount of fame
For the majority of the time we worked on Spruce, we never expected any major spotlights on it. We were getting enough traffic to validate the idea, we were happy.
This all changed the morning we appeared on Product Hunt. We sped through the ranks to the top rated product of the day until Google’s Inbox beat us to the #1 spot. We ended up receiving a huge surge of traffic as blog sites and news outlets wrote about the product. Over the course of the week, our traffic surged and thousands of images were created.
The tool also inspired others. Below is Buffer’s Pablo, which came out not long after Spruce’s Product Hunt debut.
Since the project concluded, not much more was done to tryspruce.com. It stuck around for a while until it was taken down recently (or so it seems). The key outcome is that Adobe took the learnings from the project and made Adobe Post with it.
Certain part of me does feel sad that Spruce is gone. But the important fact is that it was a MVP. It was meant to be a throwaway project to pave the way for the final product. Was all the code and design wasted? Absolutely not. Tons of code and designs are wasted everyday by makers who only build products on hunches. The end goal isn’t to make a product, the end goal is to make a product people use. If we keep that in mind, then code and design simply become a mean to that end.
Questions or feedback? Email or tweet me.
Some of the image assets were taken from David Bland’s post on Spruce