Evernote Web & Growth

Moving metrics to help more users remember everything

Evernote is an is a note taking and productivity application that helps you remember everything. As a product manger at Evernote I had the opportunity to work on everything from managing negative user feedback due to a product redesign, to introducing a new plans and paywalls, to building out a new cross-functional team. On a typical day, you may have found me gathering lists of bugs from our customer service reps, running SQL queries to map out dropoffs in a flow with an analyst, meeting with a user researcher to get the latest test results, giving feedback in a design review, or even putting out an engineering firedrill, all while creating and rearranging JIRA tickets in between meetings. PM life was busy, but things got done.

Building a Growth Team

Evernote worked on growth for 3 or 4 years prior to the creation of our first growth team. Up until then, there had always been a PM dedicated to identifying areas of opportunities for growth experiments, however, no dedicated resources or teammates. As a result, growth experiments were often deprioritized or delayed because other features stacked ranked higher on each platform team’s list. To address this, there was an attempt to build a temporary team by requesting each platform team loan a developer towards growth projects every quarter. Although in theory this gave resources to focus on experimentation, none of the developers had much say in the experiments or cared to suggest new ones. In general, no one was invested in the team or the mission outside of the PM.

When I become the Growth PM, we decided that if we wanted to truly focus on growth and make an impact on the metrics, we would have to build a healthy and effective team from the ground up. After chatting with colleagues and advisors at Facebook and Sequoia Capital, here are some of the principles we encouraged the team to embody:

• Think big, think outside of the box, be audacious

• Be tactical 

• Optimize for results, velocity, and learning

• Do what’s right for the customer

• Be data driven, own the metrics

• Everyone owns growth. Everyone owns the ideas & solutions

In practice this meant the following:

• We hired for a growth mindset - Whether it was an engineer or designer, it was important that every team member had a problem solving mindset. If you had a sense of curiosity, were self-motivated, proactive, and quick to come up with many varied solutions to solve a problem, you were sure to fit for our team.

• Ideas came from everyone - Everyone on the team is encouraged to contribute to the experiment ideation and actively give both visual and experiment design feedback. To facilitate this, the entire team attended and collaborated during design reviews and experiment result readouts.

• We optimized for velocity - Working under the assumption that only 1 out of 10 tests will yield in positive results, increasing the number of experiments and learnings was one of our highest priorities. The team was encouraged to be proactive in removing roadblocks and creating workarounds whenever possible.

• We strove for quality, but were scrappy when we needed to - It’s okay to be scrappy and find shortcuts to reduce development time if it doesn’t affect the quality of the test or the product. 9 out of 10 of the tests will probably not pan out and will be thrown out so too much unnecessary investment is not good.

Our first team consisted of only 3 developers, 1 designer, and 1 UX writer. To create a strong team dynamic and facilitate collaboration, we created our own team space in a downstairs conference room and sat with each other everyday. Since the creation of the original team, the Growth team has expanded into 4 separate full-stack teams, 3 focusing on growing different areas of the product and 1 infrastructure team. It now has its own dedicated AB test system, analytics dashboard, and continues to follow the same principles we initially outlined. On top of this, the team has one of the strongest team cultures in the company.

Role: Principle Product Manager
Team: 1 PM, 3 developers, 1 UX writer, 1 Designer
Platform: Web, Mac, Android, & iOS
Timeline: July 2016 - Sept 2017

Introducing the Device Paywall

At the time this project started Evernote had 3 available pricing plans for the consumer product with Evernote Basic being the lowest and only free plan. Through focus groups and research we learned that the Basic tier was too full featured and there was no clear incentive for the majority of users to upgrade to a higher plan. As one of the product managers who helped lead the effort to introduce a new plan, I faced the challenge of having to figure out how we could take away something away from our users that has always been free without loosing a significant amount of the user base. How we messaged the user base about these changes in both legacy and new clients was crucial. Would users understand the changes being made and how it impacts them? As a result of this project, a new paywall was introduced that limited the Basic tier to use Evernote on only 2 devices. Paid plans were allowed unlimited devices. To this day, this paywall is Evernote’s most successful paywall at converting users to a paid tier.

Role: Senior Product Manager
Team: 3 PMs, 10+ developers, 5+ QA, 2 UX writers, 2 Designers
Collaboration: 6 product teams across the company
Platform: Web, Windows, Mac, Android, & iOS
Timeline: April 2016 - July 2016

Evernote Web’s Redesign: Managing customer love & hate

When the newly redesigned version of Evernote Web was launched in 2014 it received rave reviews and awards. Compared to its clunky predecessor that looked like it was built when Windows 95 was around, the new sleek and modern UI felt like a huge leap forward. Inc wrote, “The new version is so clean and uncluttered that it makes me want to take more notes, keep track of my day, post notes to social media, and attach more files to keep my day from spiraling out of control."

Unfortunately, the reality was that the redesign upset a majority of our existing web users and broke many workflows. New users loved the new design for its simplicity while existing users grew extremely frustrated and did not feel they were able to do basic tasks such as opening a note as efficiently as before. Users either loved it or hated it and those that hated it were our most active multi-client users.

As the product manager who inherited this problem the first week I joined Evernote, I quickly learned that what we think is best for the user isn’t always what every user needs or wants. Incorrect assumptions were made about the usage of the web product and the team overlooked the existing user workflow. My biggest challenge during this project was figuring out how to we please two separate user bases with different use cases without throwing out the baby with the bathwater.

Role: Senior Product Manager
Team: 1 PM, 5 developers, 1+ QA, 2 Designers
Platform: Web
Timeline: Oct 2014 - Jan 2015