Accidental Success

Lessons learned from launching a new product that wasn’t supposed to exist.

When we launched Trusted News — a brand new desktop extension that has nothing to do with ad blocking — my expectations were low. One or two articles from any publisher would have been enough to make me happy. Instead, a total of 78 publications wrote about the product, including TechCrunch, Fast Company, c|net, and engadget. Meanwhile, over 5,000 people are now actively using it 😀

Being the first product I’ve ever worked on that went from nothing-to-something, I credit any success to the team, timing, and our communications department. Still, it would be wise to reflect on what went right, since developing new products will be important to eyeo’s future success.

LESSON 1: Passion is paramount

I remember our very first meeting as an unofficial project team vividly. Having identified those who were potentially interested in embarking on this experiment, I presented the problem (disinformation on the web) and asked everyone lots of questions:

  • Did we genuinely care about this problem? Yes.
  • Did we fully understand the problem? Sort of.
  • Could we build something that would actually benefit users? Maybe.
  • Since this would be an unofficial project, were we willing to devote our free time to this, without knowing how long it would take or what challenges we would face? Hell yes!

Step 1 of our journey, therefore, was nothing more than declaring our willingness to work together, and commit to the experiment. A few people dropped out, either due to lack of time, interest, or technical experience. Those who remained were both passionate and ready to roll up their sleeves.

This inherent desire was our secret sauce. It’s what kept us going during many nights and weekends, got us through uncertainty, and helped us forge the right partner relationship to deliver a real solution.

LESSON 2: Partners are pivotal

About that partnership. It was pure serendipity that Paul Walsh, CEO of MetaCert, and myself happened to meet at the exact right time. Our marketing agency out in California, Rocket Science, introduced us shortly after we established a voluntary project team. Paul and I both worked in San Francisco, so we met for coffee and started talking. It turned out we both cared intensely about the same things, and his company could provide the data solution needed to build a functional product.

It wasn’t until much later that I realized how important — and exciting — this partnership would be. Not only did they create a custom technology solution (for free), they then figured out how to scale that solution for sustainable growth (again, for free). They were in this for the long haul, and they had our backs. As a result, our product would have actual, immediate potential for long-term success beyond its initial launch. That’s more comforting than I can fully express.

Only now do I understand the essential qualities any partner should have. Namely, they should genuinely share your vision, fully understand the problem you’re trying to solve, and be capable of delivering a sustainable solution. Everything else is about alignment and coordination, and takes a lot of work on both sides to get right.

LESSON 3: Size matters

Few people knew about the project internally. Those who did know doubted that we’d succeed in the end. So when we announced that Trusted News was going live — after just 11 months of semi-secret work — many people were caught off guard, and nobody knew how we pulled it off. This was actually intentional.

There were a lot of unknowns in the beginning, but there was one thing I was sure of: the fewer people involved, the better. If you know anything about working at eyeo, you know such thinking is blasphemous. We generally don’t do anything without involving anyone/everyone with an opinion to weigh in, debate about every single potential problem/solution, and then spend months in code review or QA.

But I wanted speed. We had to deliver something sooner than later. And that something didn’t need to be perfect. It just needed to work. If we could do that, then we could make it better over time. This is why I kept the team as small as possible, the scope of our vision limited, and the user experience super simple. If we didn’t know how to build something, we learned. If the vision was too ambitious, we scaled it down. And if the user experience could be trimmed down further, we did so without mercy.

By working as a small team under the radar, we avoided any bureaucratic pitfalls. By committing ourselves to creating a true “minimum viable product”, we could focus on delivering something of value now, instead of trying to build the perfect thing later. As a result, we introduced an entirely new product in less time than it took the rest of the company to build a single new feature for any of our existing products.

LESSON 4: Timing is everything

There was another reason it was important to prioritize speed over perfection. Since the 2016 US Presidential Election, “fake news”/disinformation had become a hot topic, and the media was paying a lot of attention to it. In less than one year, the issue had gone from a fringe issue that nobody cared about, to a one that’s generated endless headlines in the press. In other words, a lot of people already cared about the very problem our product was intended to address, and there likely wouldn’t be a better time to capitalize on that attention.

Yet it wasn’t just about delivering something soon. We didn’t want to just hit the “UPLOAD” button the first moment we could and call it a day. That’s why we developed a communication strategy and waited until an agreed upon day and time to have maximum impact. A few of us wrote blog posts about the launch, the vision, and technical details. Our marketing agency wrote a press release and lined up interested publishers. Ben, our Director of Communications, pre-pitched the story to the press. Then, at 3:00 pm CET on a quiet Tuesday, we collectively announced Trusted News to the world.

If we had waited until everyone else in the company understood and agreed with our plan, or the product was “perfect”, we likely would have missed the fake news party. And if we didn’t wait to launch at the right time with the right message, either the press would have missed it, or totally mangled the message. Instead, the launch itself has had a meaningful impact that we can easily build upon (instead of struggle to recover from).

LESSON 5: Downtime doesn’t have to be a downer

Truth be told, we probably could’ve launched a few months earlier. What held us back was our partner. It took them longer than anticipated to deliver the technical solution and relevant data. This was to be expected, though. MetaCert has a core business with existing, paying clients to take care of. The company is also growing like crazy, and they’re working on big, interesting stuff (like an initial coin offering for their new, proprietary cryptocurrency). The fact that they dedicated resources to build anything at all for us is amazing, and a testament to their passion for this project. And the fact that they thought about a long-term solution is proof positive of their ongoing commitment.

Still, one must remember that “downtime” is inevitable when working with a partner. Sometimes they’re ahead of you, sometimes you’re ahead of them. The important thing is to remain flexible. While MetaCert was working on the stuff we needed for launch, we spent our time studying the issue of disinformation more extensively, identifying potential issues, and conducting user research. Now that the product is live, all those investments we made during that downtime have provided the information required to develop a roadmap and a solid plan for extending the product beyond Chrome on desktop computers.

LESSON 6: Embrace your base, but mind the masses

There’s one lesson in particular that product companies often forget: There’s a huge difference between the early adopters of a product — your “base” — and the masses you want to reach. In our case, we didn’t do any actual marketing for the launch of Trusted News. Sure, a few people probably downloaded the product after finding it by chance on the Chrome Web Store. Most of them, however, learned about Trusted News from a news article. This means that many of our first users read about technology and/or new web products regularly, and likely have a deeper understanding of the “disinformation problem” than the average person. Being more educated also means that they will have higher expectations of our product, and are therefore going to be the most critical…and vocal.

The best thing about the “base” is that they already “get it”. Their feedback is extremely valuable, and the problems/issues they complain about are often things you need to improve anyway. Ignore them, and they will punish you. Embrace them, and they will become your future evangelists. But don’t make the mistake of trying to serve them.

The ones you should actually be serving are the masses — the millions of people you want to reach, but who don’t understand the problem you’re trying to solve very deeply. They have a simple need or pain point. They stumble upon your product by accident, learn about it from social media, or hear about it from their friends. Then they either find immediate value in your product (and continue using it), or they don’t (and never use it again). Interestingly, what they need/want is rarely want your base needs/wants. Early adopters want granular control, broad functionality, and the ability to influence the future of your product. The average users just wants shit to work, and don’t want to think very hard when using it.

So listen to your base, and then translate that feedback into a product experience that will appeal to average users. It’s simple in principle… but really, really hard to do in practice.

LESSON 7: Haters gonna hate

This is the most obvious, but difficult lesson every product manager has to learn.

When we announced the product internally, there were plenty of colleagues who thought it was a poor solution, doubted anyone would actually find it useful, or complained about the things that didn’t work exactly right. When the press wrote about it, some of them focused on the imperfections of the initial experience rather than the overall intention of the product. And dozens of users who disagreed with the label for a particular website immediately gave it a one star rating, left negative comments, and/or uninstalled the product.

Sure, these reaction hurt. But the feedback is usually valid, and it all confirms what we already knew about the product’s current shortcomings.

Yes, I’m sad that some users were so disappointed that they abandoned the product. But we know it will only get better with time. (We also see that the current retention rate is around 90%, so we’re doing something right.)

And yes, those in the technology industry who say our solution is limited, imperfect, or lame wound our egos. But you know what? Until they put some skin in the game and build something better, fuck them. At least we’re trying!

+++++

There will be many more things I have yet to learn (like how to scale a product that demonstrates early success). I certainly don’t want to loose our momentum, or make anything worse. I’m hopeful, however, that the lessons we’ve learned so far, and the one’s we’ll learn in the future, will arm us with the experience and knowledge we need to successfully launch other products in the future.