How Notion Used JTBD Thinking to Beat Evernote

In 2016, Evernote was the undisputed king of note-taking. 200 million users. A $1 billion valuation. The app people assumed you meant when you said “I’ll save that to my notes app.”

By 2023, Notion had become the default. Not by making a better Evernote, but by solving a completely different job.

This is a JTBD case study of what happened—and what it teaches us about product strategy.

The Job Evernote Owned

Evernote dominated a specific job:

“When I come across something I might need later, I want to quickly capture it, so I can find it when I need it.”

This is a collection job. Grab the article, clip the recipe, save the receipt. Dump it in the “second brain” and trust you can search for it later.

Evernote did this brilliantly:

Web clipper that captured anything
OCR that made handwritten notes searchable
Sync across every device
Powerful search that found anything

The core promise: “Remember everything.”

And for years, this job was enough.

What Changed

Around 2015-2018, three shifts happened:

1. The Job Shifted From “Collect” to “Create”

Knowledge workers stopped needing a place to store information. Google, Slack search, and browser bookmarks made retrieval easy enough.

The new struggle was using that information—turning notes into docs, docs into decisions, decisions into shared context.

The job evolved:

Old job: “Capture things so I can find them later” New job: “Organize my thinking so my team and I can work effectively”

Evernote was built for the old job. The architecture assumed one person collecting things. There was no concept of shared workspaces, linked databases, or collaborative editing.

2. Work Became More Collaborative

In 2010, your notes were personal. By 2018, remote work and distributed teams meant your documentation needed to be shared.

A new job emerged:

“When my team is scattered across tools and locations, I want a single source of truth, so we can work together without constant sync-ups.”

Evernote was fundamentally single-player. Sharing was an afterthought—you could share a notebook, but you couldn’t work together in it.

3. Tool Fatigue Set In

By 2018, teams were drowning in tools:

Docs in Google Docs
Tasks in Asana or Trello
Wikis in Confluence
Notes in Evernote
Meeting notes in various apps

A new job emerged:

“When I’m constantly switching between apps to find information, I want everything in one place, so I can stop wasting time looking for things.”

Evernote was yet another app in the stack—not the central hub.

The Job Notion Chose

Notion didn’t try to out-Evernote Evernote. They identified a different cluster of jobs:

Primary job: “When my team’s work is scattered across tools, I want one flexible workspace, so we can collaborate without losing context or time.”

Secondary jobs:

“When I’m building a process or system, I want to structure it my way, so it actually fits how we work.”
“When I’m documenting something, I want it to be both a document and a database, so I don’t have to choose.”

Notice what’s different:

Team-first, not solo-first. The core use case assumes collaboration.
Flexible structure, not rigid formats. Databases, pages, and blocks that combine freely.
Replace the stack, not join it. Docs, wikis, tasks, and databases in one.

How Notion Executed

1. They Built for the New Job, Not the Old One

Notion didn’t add better clipping or OCR. They skipped those features entirely.

Instead, they built:

Linked databases (same data, multiple views—tables, boards, calendars)
Blocks (modular components that combine freely)
Shared workspaces (team-first by default)
Templates (so teams could adopt patterns quickly)

These features made no sense for “capture things for later.” They made perfect sense for “help my team work together.”

2. They Targeted Job Performers, Not Demographics

Evernote targeted “professionals who want to be organized”—a demographic.

Notion targeted people experiencing specific jobs:

Startup teams drowning in tool sprawl
Remote teams needing a shared wiki
Ops people building systems and processes
Individuals who wanted flexible personal organization

Same tools, but marketed to people feeling specific job pressures.

3. They Accepted Different Trade-Offs

Every product strategy requires trade-offs. Notion chose:

Evernote optimized for…	Notion optimized for…
Capture speed	Organizational flexibility
Solo use	Team collaboration
Search/retrieval	Linked structure
Simple note format	Block-based composition
Broad use cases	Workspace consolidation

Notion deliberately made capture worse. No web clipper for years. No OCR. Slow mobile app. Because these weren’t the jobs they were solving.

4. They Competed With the Real Alternatives

Evernote thought they competed with OneNote and Apple Notes.

Notion understood their real competitive set:

Google Docs (for team docs)
Confluence (for wikis)
Trello (for project tracking)
Airtable (for databases)
Spreadsheets (for everything else)

By positioning against tool sprawl rather than note-taking, they expanded their market.

What Evernote Got Wrong

Evernote’s failure wasn’t about features. They added plenty of features—tasks, calendar integration, collaboration. The problem was deeper.

1. They Defended the Old Job

Evernote kept doubling down on capture and search while the job shifted to creation and collaboration.

Their 2018 CEO said: “We’re the place where you capture your most important information.”

But users were asking: “How do I use that information with my team?“

2. They Added Features Without Changing the Architecture

Evernote’s architecture was fundamentally notebooks → notes → content. Every feature had to fit that structure.

When they added collaboration, it was sharing a notebook. When they added tasks, they lived inside notes. The underlying model couldn’t support the new jobs.

Notion started fresh with a flexible block-based architecture that could accommodate any use case.

3. They Confused Retention With Value

Evernote had incredible lock-in. Years of accumulated notes. But locked-in users aren’t happy users—they’re trapped users.

When an alternative finally emerged that solved the new job, users fled despite switching costs.

JTBD Lessons From This Case Study

1. Jobs Evolve Faster Than Products

The job that made you successful can shift. If you’re not actively tracking how your customers’ circumstances and desired outcomes are changing, you’ll miss the transition.

Question to ask: “Are our customers still hiring us for the same job as three years ago?“

2. New Jobs Create New Markets

Notion didn’t steal Evernote’s market. They created a new one around different jobs. Evernote’s “remember everything” market still exists—it’s just smaller and less valuable.

Question to ask: “What adjacent jobs are emerging that we could own?“

3. Architecture Constrains Strategy

Your product’s fundamental architecture limits which jobs you can solve. Evernote couldn’t pivot to team collaboration without rebuilding from scratch.

Question to ask: “Does our architecture support the jobs we’ll need to solve in 3 years?“

4. Compete With Alternatives, Not Direct Competitors

Notion won by replacing the stack (Docs + Wiki + Trello + Airtable), not by beating Evernote at note-taking.

Question to ask: “What else are customers ‘hiring’ to solve this job? What’s the full competitive set?“

5. Winning the New Job > Defending the Old Job

Evernote tried to hold onto existing users while the job shifted. Notion ignored the old job and went all-in on the new one.

Question to ask: “Are we building for the job that’s growing or the one that’s shrinking?”

Applying This to Your Product

Here’s a quick exercise using the Notion/Evernote lens:

1. What job do customers currently hire you for? Write it as: “When [situation], I want to [motivation], so I can [outcome].”

2. How is this job evolving? What’s changing in your customers’ circumstances? What new outcomes matter more?

3. What new jobs are emerging? Are there adjacent jobs that customers increasingly care about that you don’t solve?

4. What would a Notion-like challenger build? If someone started fresh today, solving the new jobs without your legacy constraints, what would they build?

5. Can your architecture support the new jobs? Or would a real pivot require rebuilding?

The Notion/Evernote shift wasn’t about features. It was about recognizing which jobs mattered and building an architecture that could solve them.

Next steps:

Learn the complete JTBD framework
Run your own JTBD interviews
Build job statements with our JTBD Statement Builder