This was a guest post I wrote for the Validately blog about the app they built called Just Not Sorry which was an instant internet success. We love how Tami and her team developed and launched their app using solid Lean practices and are excited to share their story with our followers.
We launched JustNotSorry a few weeks ago and oh what a journey this has been! In a matter of days, we have had tens of thousands of installs of this application. We’re pretty sure that if the app worked on more than the combination of Gmail + Chrome that the usage would be even higher. (We have the dozens of emails and tweets requesting it to work on Outlook as proof.)
How does an app or anything else go viral? The instant success of JustNotSorry is a testament to a number of things.
First, this app is FREE! JustNotSorry is a Gmail plug-in that helps you be a better communicator. If you are trying to get ahead in your professional life, downloading this app provides some of those “smart is simple” moments where it is essentially a no brainer. [Just Not Sorry underlines words that tend to detract from a reader’s confidence in your message such as “just”, “sorry”, and “I think”.]
Second, it was a slow news week when we launched and hundreds of blogs, radio shows, and even some TV shows picked up the story because there wasn’t much competition. I’ve learned to never underestimate the power of press and good PR to spread the word.
Third, and potentially most importantly, we designed the app using Lean/Agile principles. Here are the steps we took that are based on solid Lean and Agile practices that led to the successful launch:
Quick idea validation : When we first thought of the idea, we told a dozen people about it. Everyone said they loved it, but only when Kara Silverman offered free PR services from her company for the app did we know we were on to something. As Steven Cohn(the Founder of Validately) said at LeanUX15, unless someone is willing to provide you their time, money, or social capital, they don’t really love your product. Kara was willing to give us all three. As we shared the app with some beta users, the most common response was “when can I share this with my whole team?”. That’s pretty strong validation.
Know your ideal user : Can Just Not Sorry be used by anyone? Sure! Did we build it for everyone? Absolutely not! The key to any MVP is knowing your ideal customer and building something to meet their specific need. Our product design centers on a 25–35 year old woman, working to advance her career but weak communication is getting in the way. She wants to change, and we built a tool that nudges her to be more mindful about word choice in email. Knowing our target user also led to very focused marketing for the launch. (Possibly too narrow as it created a backlash against us for policing women’s speech when that wasn’t our intention… but that’s a story for another blog post.) We tailored the messaging and the outreach to women in this age range and encouraged them to spread the word to their friends. Some of the emails we sent were opened over 400 times thanks to key people forwarding them.
Build small : The app only works on Gmail on a Chrome browser. Could we have built it for a variety of email clients and browsers? Of course! But, why would we invest that time and money unless we were sure it would take off? When people complain that Outlook isn’t supported, we show them that we’ve open sourced the code for anyone to leverage and build it if they want. If there’s a real need for the product, others will make it a priority to help. I’ve often said an MVP should be able to be made within 6 weeks, Just Not Sorry took only 4 days before it was ready for beta testers.
MVPs aren’t perfect : As Lauren Gilchrist preached at Lean Startup Conf in 2014, “Be a scientist, not an expert, and ship imperfect products. We knew that there were some conflicts with other gmail plug-ins that would cause the app not to work all the time. Rather than try to fix all of the issues ourselves. We shipped it anyway, knowing only a small percentage of people would be impacted and that they’d help us diagnose the issues if we were responsive.
Test with actual users : Every step along the way we spoke with potential users about their thoughts on the app. We gathered feedback from our target market to ensure we were headed in the right direction. A “short” list of some of the things we tested:
The name — It was originally “Don’t Say That”, can you imagine the hashtag or the backlash that would have created?
The look and feel — We switched from highlighting to underlining the trigger words so that it looked like spell check. We were having difficulty explaining that the highlight wouldn’t be visible once the email sent, it wasn’t intuitive. By using a familiar element, we took away the need to explain. We received not a single question about this.
Marketing e-mail subject — If you were part of the 10k people we emailed on day 1, you saw “We’re Just Not Sorry” in your inbox. Our tests that led up to that had longer subject lines that mentioned Gmail, they didn’t create as much intrigue or as high of an open rate. Many of my friends reported opening the email simply because they wanted to know what I was sorry for.
Landing page content — At launch there were three versions of www.justnotsorry.com built on Instapage each with different copy but identical layouts. Within a day, one of the variations was a clear loser so we paused it. After the press picked it up, we added references to the press coverage and created two one more variations: one with logos and one without. The option with no logos performed 1.3% better for conversion, but we decided to keep the logos anyway.
Iterate often : The app went through 3 iterations during the 7 days we built it. Aside from the highlight to underline switch above, big changes included the addition of helpful hints when you hover. This came from the realization that most people who use the phrases at the inappropriate time don’t realize why it’s a problem. One week after launch, based on feedback we’ve received, we changed the color of the underline to make it more distinct from spell check and added “trying” as a trigger word.
Tie into human behavior : The promotions we did for JustNotSorry are attractive to the top of Maslow’s hierarchy of needs; people want to feel part of something bigger than themselves (esteem and self-actualization). One of our advisors suggested that we make this a New Year’s resolution, part of someone’s annual routine. Similarly, we noticed that more shares happen on Twitter and Facebook when there’s a common goal, so we created a target of 10,000 signatures by NYE. Hooks, such as these, attach people to a greater purpose and often creates virality.
Guide people : Good user experience design is all about getting a person to take the right action without instruction. When the first visitors on our site didn’t do anything more than provide their email, we moved the download link to action #1 and providing email to second place. Similarly, rather than only encouraging tweeting, the redirect after providing your email goes to a ClickToTweet pre-formed, “lazy” tweet, which takes only a split send to post.
Measure the important stuff : We spent over a day adding Google Analytics so we could track the number of installs. It was really important to be able to know that, not only for ourselves but for the marketing campaign around getting a certain number of signatures by New Year’s Eve. Instapage tracked pledge signatures, but only Google Analytics could track all of the downloads from all sources. By keeping track of these figures and promoting them, we were able to get users and the press pretty excited and our app virally spread across the world, 200 countries and counting!
JustNotSorry has been a huge success. We’ve been covered everywhere from the BBC to the Today show, every women’s magazine, and even some newspapers in print. We had tens of thousands of downloads in a matter of 2 weeks for something that only a portion of the population can even use. We attribute our success to building a smart simple product and using the Lean methodologies of validating, testing, and iterating. Could we have been wrong? Absolutely! But we only spent a week or two working on it, so there wasn’t much to lose.