14 min read

Jul 1, 2026

Every project switch is a small act of reconstruction. Reopen the tabs. Find the notes. Locate the files. Remember where you left off. Most people do this dozens of times a day and never name it, because the cost is distributed thin enough to feel like normal friction instead of a problem.

I want to start somewhere specific: an empty Context.

A user opens ABLE. Creates a Context — a named container for one project. Clicks inside. Sees nothing. No files, no notes, no starting point. Just a name and a blank space where the work was supposed to go.

That moment happened more than 80 times during our testing, and in every case, the user left and didn’t come back. Not eventually. Immediately. We had almost 4,000 waitlist signups. We had a 95%+ churn rate between signup and activation. Most people who tried the product opened it once, looked at an empty Context, and never opened it again.

That gap — four thousand people who wanted this enough to sign up, and almost none who stayed long enough to feel why it might matter — is the real subject of this case study. Everything else is in service of explaining it.

Here’s what makes that gap strange: the problem we were solving was real. Validated, repeatedly, across years of research. People do lose hours rebuilding context every time they switch projects. The direction — a single workspace that holds everything for one project — was the right shape for that problem. We built it. People believed it enough to sign up for it. And then almost nobody used it.

So before I explain what we got right, I want to sit with the fact that getting the problem right wasn’t enough. This is a case study about a team that diagnosed correctly and still failed to convert that diagnosis into a product people would return to — and about the specific, nameable reasons why.

ABLE started where the founder felt his own pain: financial decisions, investing, research. He’d spend mornings reconstructing what he’d already read the week before — same sources, different tabs, nothing connecting the pieces. The domain was personal to him, but we weren’t trying to solve his problem alone. We were looking for friction painful enough to matter to more than one person.

We interviewed brokers and managers and learned that a credible product in that space needed deep financial expertise we didn’t have. We let the domain go. What stayed was the underlying activity underneath it: research. The first real signal wasn’t “financial tools are broken.” It was a consolidation problem — information scattered across sources, formats, and tools, with nothing built to bring it together.

Every decision runs the same first step: information search. Investing money, choosing a sofa, planning a week — the mechanics are the same. We focused there. In an in-lab study, we mapped how people manage information across tabs, bookmarks, notes, and documents, and where each one breaks down.

One moment from that study stayed with me. A participant was researching a kitchen renovation. She had a browser tab open with a tile supplier, a screenshot saved to her desktop of a color she liked, and a note in a separate app listing measurements. When we asked her to show us “everything about this project,” it took her four minutes and three apps to assemble a partial answer — and she still wasn’t sure she had it all. Nothing she was using was broken on its own. The tab worked. The screenshot worked. The note worked. What didn’t exist was the thing that held them together as one project.

That’s the principle the rest of the research converged on: operating systems organize by storage location and format — downloads here, browser tabs there, notes in their own app. People think by contexts — projects, topics, the actual clusters of their life and work. When those two logics misalign, you get exactly what she was doing: manually re-assembling a project that the system itself refused to recognize as a single thing.

In parallel, we ran customer development with three landing pages, each targeting a different audience — knowledge workers, students, self-learners. The goal wasn’t to pick a market. It was to test whether the problem held across markets. It did: every project switch meant reopening, re-finding, and reconstructing work already done, regardless of who was doing it.

That’s what led us to the bet: merge a browser with a knowledge base so that web content and knowledge-base objects live on one level, in one place. We thought that alone would remove the friction.

We mapped the core friction into five steps — gap, search, capture, organize, retrieve.

Press enter or click to view image in full size

Search process we discovered through moderated search field studies and desk research.

A third of survey respondents (N=1,240, HubSpot, August 2023) ranked “difficulty organizing” as their top frustration.

Press enter or click to view image in full size

Waitlist surway analises N=1,240, HubSpot, August 2023

We reframed everything around Contexts and shipped the first version. Files stayed local, in open formats. We pushed onboarding and D7 retention as 2026 goals. We collected almost 4,000 waitlist signups and ran more than 40 moderated sessions.

And then: almost nobody who signed up came back on their own.

We tested onboarding changes across three cohorts — a pre-filled “Getting Started” Context for one, a deeper interactive walkthrough for another, the unchanged flow as a rough baseline for the third. We logged signups and surveyed first-session behavior, but we didn’t instrument the flow with funnels or track exactly which step users dropped at. The test was directional, not rigorous. All three cohorts churned at roughly the same rate. Retention didn’t move.

The empty Context was the moment we could point to. A user added a Context, clicked inside, and saw nothing — no artifacts, no structure, no starting point. We have three working hypotheses for why that moment broke trust:

1. Contexts demanded structure before users had earned any value from exploring. A blank Context form asks for a plan before exploration. Real behavior runs the other way — people want to collect a few things first, see what shape emerges, and structure later. We built the product around the inverse of how people actually start projects.

2. The interaction model required users to already understand a model we hadn’t taught them. Collapsing OS logic into a new mental model is real cognitive work, and we underbuilt for it. How local files appeared in the sidebar, how a URL got added to a Context, how search surfaced content — every one of these assumed familiarity with a system the user had never seen before. For a new user, every action required inference instead of recognition.

3. We onboarded toward an aspiration instead of a Tuesday-afternoon problem. People who signed up were curious about the idea of unified research and knowledge — that’s why they signed up. But their actual, immediate problem was narrower and more urgent: “I have a project due next week and I’m drowning in tabs right now.” Our onboarding said, “This is how you’ll organize everything.” It should have said, “Let me get you out of this mess today.” We onboarded toward the pitch, not the pain.

We had the research. We had the problem validated. We had built what the research said would work. We still couldn’t convert interest into daily use. Resolving these three hypotheses with confidence would have required isolation experiments that hold Contexts constant while varying only the empty-state design, funnels that show exactly where users drop, and cohorts large enough to read signal through a 95%+ churn baseline. We didn’t build that instrumentation. So these remain hypotheses, not conclusions — and that gap, between what we suspected and what we could prove, is itself part of the failure.

“The scope wasn’t right” is the easy version of this lesson. Here’s the version with teeth.

The bet ABLE was built on had one moment at its center: resumption. The claim was that if people grouped their work into Contexts, switching back into a project would feel instantly faster than reopening tabs and re-finding files by hand. Everything else — the local-first file system, the knowledge base, the browser integration — existed to make that one moment real.

We spent years matching basic browser and knowledge-base functionality instead of proving that single moment.

That happened for three concrete reasons, not one diffuse one:

Timeline pressure rewarded visible breadth over proven depth. Shipping “a browser” and “a knowledge base” produced demoable progress every sprint — new panels, new views, things you could screenshot. Proving that resumption actually felt faster than the old way required something slower and less visual: instrumented user testing against a specific time-to-resume metric, which doesn’t produce a demo until it produces a result. We chose the work that showed progress over the work that proved the bet.

Founder ambition and the original domain pulled the roadmap wider, not narrower. The product’s roots in financial research meant the founder’s intuition consistently ran toward “and it should also handle X” — more source types, more integrations, more of the surface area a true research tool would eventually need. Each addition was individually defensible. Collectively, they meant we were building toward the eventual product instead of testing whether the core mechanism worked at all.

Nobody owned the decision to cut. Engineering had a defensible view (build the infrastructure properly, or you’ll rebuild it later). Research had a defensible view (we don’t have enough signal yet to commit to one onboarding path). I had a defensible view (ship something testable in one sitting, even if it’s narrow). The founder had a defensible view (the product needs enough surface area to be worth signing up for). Every view was reasonable. None of us had the authority to tell the others “we’re doing this and not that.” So the roadmap became the union of four reasonable opinions instead of the intersection of what the bet actually required.

The cost wasn’t abstract. It was 2–3 years spent building infrastructure for a product whose core hypothesis — does resumption actually feel better? — was never isolated and tested on its own. By the time we had a version focused enough to test that question cleanly, we’d burned the runway and the market window that a sharper, earlier test would have protected.

The thinking here started from one concrete failure, the same kitchen-renovation moment from the in-lab study: a tab, a screenshot, and a note, each living in a different app, none of them aware the other two existed. That was the seam we were trying to build a primitive for.

Walk through her options and each one breaks somewhere different. A tab group would hold the tile-supplier tab open alongside whatever else she was browsing, but it couldn’t hold the screenshot or the note — those live outside the browser entirely, so the tab group simply has no slot for them. A folder fixes that: drop the screenshot, the note, and a shortcut to the tab into one place, and now all three exist together. But the folder lives in one location, which means the moment she wants to reference the project from her notes app, or from a chat with the contractor, she either duplicates the files into a second location or breaks her flow to go dig through folders instead of staying in the app she’s already working in. Symlinks solve the duplication problem in theory — link instead of copy — but they require exactly the kind of technical fluency a renovation researcher doesn’t have and shouldn’t need. Three primitives, three different ways of falling short of the same job: hold a tab, a screenshot, and a note together, without forcing a choice between duplication, technical overhead, or losing the thread of whatever she was doing when she needed the file. A named container was the only shape that cleared all three bars at once — it could hold files and links side by side like a folder, it could be referenced from anywhere without duplicating anything like a symlink was supposed to, and it required nothing more technical than naming it, something closer to giving a project a name than configuring a system.

The principle underneath all this was the same: every existing unit broke at the same seam, where OS logic, app logic, and work logic stop overlapping. The fix wasn’t a better folder or a better tab. It was a container that sat above both kinds of logic instead of trying to be a better version of either.

One choice here was deliberate, not incidental: files stayed on the user’s machine, in open formats. If ABLE disappeared tomorrow, the folder and the knowledge base inside it would still be intact, still openable, still theirs. No migration, no lock-in. Beyond that, the system organized files in the same motion a person used the app — not as a separate filing chore afterward.

The Context Picker is the surface you touch every time you switch projects — the part of the product that had to carry the entire promise of “switching feels instant now.” We iterated through three shipped versions. A fourth was explored seriously and never shipped.

This came out of the first wireframes, when the concept of a Context was still raw — we wanted to fix switching first and figure out the rest later.

Hypothesis: if Contexts live in a panel users already navigate, switching will feel natural.

V1 sidebar dropdown — Two clicks to switch broke the flow.

In practice, switching took two clicks and broke flow, and the sidebar was doing two jobs at once — navigation and context management — which felt overwhelming rather than convenient. Users couldn’t form a clear model of what a Context was, because the mechanics of managing one were hidden behind a dropdown they rarely opened.

What I learned: switching needs its own dedicated surface. It can’t be a secondary function of something else.

We explored roughly six different forms the picker could take and landed on a fixed rail to test whether giving Contexts a permanent position would build muscle memory.

Hypothesis: a fixed position with one-click switching lets users stop thinking about where they are and just act. Single-click switching worked.

V2 navigation rail — Single-click switching, but truncated labels and density issues at scale.

But labels truncated and became hard to read, and the rail-panel-content stack felt dense — after 4–5 pinned Contexts, users had to scroll.

What I learned: the idiom doesn’t scale past a handful of items, and readable labels aren’t optional. The deeper insight: users needed room for 9–10 active Contexts, organized in tiers — 3–4 core projects pinned permanently, a dynamic middle tier surfaced by calendar events or recent activity, and the 3 most recent unpinned, temporary contexts below that. A flat pin/unpin list couldn’t carry that structure.

Users and the team both kept asking for a faster way to switch, and our in-product search was weak at the time, so I combined both asks into one: a single overlay that handled search and Context switching together.

Hypothesis: people who already know what they want will type a name rather than scan a list. Power users loved it. Almost nobody else discovered it existed.

V2.1 CMD+L overlay — Power users loved it. Everyone else never discovered it.v

What I learned: shortcuts accelerate people who already understand the system. They don’t teach the system to people who don’t.

The rail was fast but illegible at scale. The founder pushed for a tab-like surface where both names and icons stayed visible at all times.

V4 horizontal tab bar — The version that stuck. The one that looked like browser tabs.

This version had the highest qualitative preference in user sessions — it was the one that stuck. But in daily use, users (myself included) read it as browser tabs, not as project containers, because that’s exactly what it looked like.

In our last round of Context Picker exploration, we tried repositioning the picker and rethinking its logic at the same time: instead of a static surface anywhere on screen, the system would infer the right Context from calendar signals, to-dos, and recent activity, so switching stopped being entirely the user’s job. The insight was real — manual switching was always going to be a tax, and removing it would have mattered more than any layout change. But making that inference reliable wasn’t a UI problem anymore. It was an AI infrastructure problem we didn’t have the time or team to build properly.

V5 bottom picker — Same concept, different position. Moved away from the browser tab metaphor.

What worked: people understood the Context concept the moment they saw it explained. The local-first model resonated strongly with users who had already rejected cloud tools on principle. And resumption — when people actually used it — was visibly faster than the apps-and-windows or tabs approach it replaced. The core bet, on the rare occasions someone got far enough to test it, held up.

What didn’t: activation. Most people who signed up opened the product once after a demo and never returned. A small number came back after guided, hands-on onboarding — but they used the knowledge base, not Contexts. One person built a daily note-taking habit and kept it. That’s a real outcome, but it’s not the bet we were testing. The bet was that people would group their own work into Contexts, unprompted, and feel the resumption benefit on their own. Nobody got there without us walking them through it by hand.

Manual setup was too high a bar, especially for people who came to us already exhausted from rebuilding their systems every time they switched tools — the exact audience least willing to do more setup work, even setup work aimed at eventually reducing setup work. We spent years matching basic browser and knowledge-base functionality instead of proving the one moment, resumption, that the entire bet depended on. During my tenure, we validated the core problem and built initial traction, but the product was still in early-stage development when I departed. The project has continued to evolve since.

Validation isn’t the same as activation. A real problem and a focused solution aren’t enough if you’re testing the wrong variable first. Next time, I’d design around the core moment — the empty Context — before building anything else, and I’d be ruthless about what ships before that bet is proven.

This is the principle I carry into every product now: prove the moment that matters before you dress it up. It’s tempting to build breadth — more screens, more polish, more “complete” features — because breadth feels like progress. But breadth is a hedge, not a hypothesis. The real work is finding the single moment where the product has to earn the user’s trust, and refusing to move past it until you know it holds.

I left this team in February 2026 for a role in Barcelona. What’s here reflects my contribution up to that point — the team has continued building since.