Article

Notion Mail and the Cost of Building What Nobody Asked For

Author

Oleksandr Kotliarov

Date

July 31, 2026

Reading Time

8 min

The story everyone is telling about Notion Mail is the shutdown. That’s the wrong end of it. The expensive decision was made 16 months earlier, when someone signed off on building an email client at all.

Here is the sequence. In February 2024 Notion acquired Skiff, an encrypted email and productivity startup with funding and paying users. Notion shut down Skiff’s email service. Then, in April 2025, it shipped Notion Mail — a Gmail client, built largely by the people who had joined through the Skiff deal. This past June it announced the shutdown of that client. The inbox closes on September 22. Notion is, in its own words, “going all in on using agents to run your inbox.”

The reason Notion gave is the part worth sitting with:

As Notion agents have gotten more capable, we’ve seen more users hand off email workflows to them. Today, more than half of Notion Mail users manage emails without ever opening their inbox.

Read that as an engineering leader, not a product-marketing one. More than half the people who installed the thing you built never used the thing you built. That is not a story about agents getting good. It is a company telling you, on the record and against its own interest, that it shipped a product the market did not want.

The shutdown was the cheap part

Killing a feature is close to free. You post a note, you set a sunset date, you keep the data somewhere the user can still reach it. Notion did exactly this — email history stays in Gmail, where it always was. A deprecation is a paragraph and a calendar entry.

The build is where the money went. Sixteen months of an email client is design, iteration, QA against Gmail’s API, mobile and desktop apps, launch coordination, support tooling, and — the line nobody costs — the senior attention that went into all of it instead of into whatever Notion’s core product needed. None of that is recoverable. The shutdown doesn’t waste it; the shutdown is the moment you finally stop paying for it.

So when a build like this ends, the reflex is to admire the discipline of the kill. Sixteen months is fast; plenty of orgs would have let it rot for five years. That’s true, and it’s the wrong lesson. “We’re good at shutting things down” is a fire-safety skill. The interesting question is why the building caught fire in the first place.

This is the default failure mode, not a Notion one

It would be easy to read this as one company’s misstep. It isn’t. Unused software is the median outcome, not the tail. Pendo’s feature adoption data, drawn from aggregate usage across roughly 180 million users, found that about 80% of features are rarely or never used, and only around 12% get used often. That’s not 80% of failed products. That’s 80% of the features inside the products that shipped, that someone scoped, staffed, and defended in a planning meeting.

Proportion bar: 80% of features rarely or never used in black, 12% used often in orange, with a small remainder — source Pendo Feature Adoption Report

John Cutler named the machine that produces this a feature factory: an organization optimized to ship features, with no equivalent rigor for deciding whether a feature was worth shipping. His sharpest observation is about asymmetry. Engineers have tests — a build either passes or it doesn’t, and everyone can see which. Product bets have no such gate. They ship on assertion, on a strategy deck, on “we own the team now so we should own the surface.” The code that made Notion Mail was validated line by line. The decision to make Notion Mail was validated by nobody.

That asymmetry is the whole problem. We built an entire discipline — CI, code review, test coverage — to stop bad code from reaching production, and almost nothing to stop a bad product bet from reaching engineering. So the bet sails straight through to the most expensive part of the company and only gets tested by the market, a year and a quarter later, when the answer is unaffordable.

Two lanes: code passes through a solid CI / review gate to production, while a product bet runs through a missing gate — drawn as an orange dashed outline — straight into an engineering quarter

Notion Mail also carries a second tell: the acquisition-shaped roadmap. Skiff had proven demand — funded, paying users who wanted encrypted email. Notion bought the team and inferred that the demand came with it. It didn’t. Owning the people who built a thing is not the same as owning a reason for your users to want that thing. “We have the talent, so we should have the product” is a reorg wearing the costume of a strategy.

The signal was there before the shutdown

The thing that makes this worth writing about: Notion did not discover the problem at shutdown. It discovered how far the problem had already run. “More than half never open the inbox” is not a number you learn on the day you decide to kill something. It’s a number that was climbing for months, readable the whole time, saying “don’t scale this” long before it said “shut this down.”

Usage telemetry is a leading indicator that teams treat as a lagging one. The data that justifies a kill in month 16 was, in a quieter form, available in month 3 — the shape of the retention curve, the fraction of installs that reached a second session, the number of people who opened the client twice. The decision to keep building was made against that data, or without looking at it. Either way the failure isn’t the shutdown. It’s that “keep going” was the default and “the numbers don’t support this” never had a place to be raised.

Telling demand from decoration before you commit the quarter

The useful version of this post is not “validate more.” Everyone says validate more. It’s a short list of checks concrete enough to actually gate a build, because the point is to catch the Notion Mail decision before it becomes a Notion Mail. None of these is novel. That’s the point — the tools existed and the build happened anyway.

Would anyone pay for it before it exists? A paid beta or presale at your real target price validates the problem and the willingness to pay in a single move. If you can’t get 20 to 50 of your actual customers to put money down for early access, you have your answer, and you have it for the cost of a landing page instead of a quarter. This is standard customer-validation practice; it is skipped mostly because the answer is often “no” and “no” is inconvenient.

Do early cohorts come back, or try it once and leave? Week-two retention on the new surface, measured against a mature product you already run, is the honest read. Early churn is not a rough start you’ll polish away later. It is the market voting, quietly, in the only currency that matters.

Would anyone notice if you removed it? The reversibility test. If you deprecated it next week, would support light up, or would it be silence? Notion’s users ran their own version of this experiment and returned a verdict: half of them had already removed the product by never opening it.

Can it plausibly reach the 12%? Only about one feature in eight becomes something people use often. Before the build, make the honest argument for why this one clears that bar in your actual market — not in the addressable-market slide, in the base of users you have. If the case rests on “people will discover they want it once it’s in front of them,” you are not describing demand. You are describing decoration, and decoration is what you shut down 16 months from now.

What to do Monday morning

Put a gate in front of the build, not just in front of the code. Before a feature gets a quarter, make someone write down the one number that would prove the demand is real, the threshold that number has to clear, and the date you’ll check it. If nobody can name that number, you are not ready to build — you are ready to guess, and a guess at the scale of an engineering quarter is the most expensive thing your roadmap can hold.

Notion caught its guess in 16 months and killed it cleanly. That’s the good version of this story. The better version is the one where the number gets named in week three and the quarter is never spent — where the discipline you’re proud of is the build you didn’t do.

References

WEEKLY NOTE

One note per week.

One short note from current work plus 2–3 outside links worth your time.

Oleksandr Kotliarov

Oleksandr Kotliarov

Founder · Engineering Lead · Kraków, Poland

I build engineering teams that ship — from MVP to Series A delivery.

Need help with your technical challenges?

Let's discuss how we can help you build better systems.