In 2019, a mid-sized product design studio in Berlin decided to get serious about productivity. They had thirty-two people, a healthy client roster, and a workflow problem that everyone could feel but nobody could precisely name. Projects were dropping details in handoffs. Designers were duplicating work. Deadlines were being met, but only just.
So they did what most teams do: they brought in a new tool.
The Setup
The studio’s operations lead (call her Maren, since the team has asked to remain anonymous in the accounts they’ve shared publicly about this period) ran a structured evaluation. They piloted Notion for three months. Then Asana. Then, briefly, a return to plain Trello with a custom card structure. Each rollout came with onboarding sessions, templates, and genuine buy-in from leadership.
After fourteen months and three tools, the workflow problem was still there. What had changed was that everyone was now also tired of switching tools.
The team’s retrospective notes from that period describe a familiar pattern. Each new system produced a short burst of engagement. People would spend the first few weeks customizing their views and exploring features. Then the system would quietly calcify. Important tasks would live in someone’s head instead of the board. Updates would lag. The tool would become a graveyard for intentions rather than a map of actual work.
This is not a story about bad tools. Notion, Asana, and Trello are all genuinely capable products. This is a story about what a team learned when they stopped blaming the software.
What Actually Happened
Maren’s eventual diagnosis, which she’s described in a case study shared among design operations communities, came down to three things that had nothing to do with feature sets.
The system didn’t match how the team actually thought about work. The studio’s designers thought in project phases and visual states. Every tool they adopted was structured around task lists and assignees. The mismatch was subtle enough that nobody named it during the pilots, but it meant every tool required a translation step: take how you naturally think about the work, convert it into the tool’s model, then convert it back when you need to act. That friction compounds across dozens of interactions per day. People eventually stop doing it.
Nobody owned the system’s health. When Maren asked who was responsible for making sure the project boards stayed current, the answer was effectively everyone, which meant no one. Each person maintained their own corner conscientiously while assuming someone else was handling the connective tissue. This is a governance problem, not a software problem. No tool solves it automatically.
The system had no forcing function. There was no moment in the team’s regular workflow where an out-of-date board caused a visible, immediate problem. The consequences of poor maintenance were diffuse and delayed: a handoff got confused two weeks later, a client call revealed a misunderstanding about status. Without a tight feedback loop between system quality and daily experience, the incentive to maintain the system stayed weak.
Why It Matters
The productivity software market is enormous and growing. Teams genuinely believe, based on marketing and reasonable intuition, that the right feature set will solve their coordination problems. This belief is expensive to hold.
The studio’s experience points to something that organizational researchers have documented repeatedly: the adoption curve for productivity tools follows a predictable shape. Initial engagement is high because novelty is stimulating and setup feels like progress. Maintenance behavior, which is what actually makes a system useful over time, requires a different kind of motivation that novelty doesn’t supply.
What does supply it? Workflow integration and visible consequences. When your system lives inside the moments where work actually happens, and when gaps in the system create immediate friction, people maintain it. When the system is a separate destination you visit to record things that already happened, it slowly dies.
If this sounds familiar, it’s because most task lists have this problem. The list captures the things you thought of while sitting at your desk. The actual important work stays invisible.
What the Team Learned
Maren’s team eventually landed on a hybrid setup that wasn’t dramatically different in software terms. They stayed with Notion but restructured it around the concept of project health rather than task completion. The key changes were behavioral and structural, not technical.
First, they mapped the tool to their mental model instead of adapting their mental model to the tool. Project pages were organized around phases that matched how designers actually talked about work in reviews, not around abstract status labels the tool suggested by default.
Second, they assigned a rotating system steward. One person per two-week sprint was responsible for a fifteen-minute board review every Monday. Not updating the board themselves, but identifying gaps and flagging them. The role rotated so it didn’t become a burden, and because everyone took a turn, everyone understood the maintenance cost, which made them more likely to maintain their own sections proactively.
Third, they tied the system to a meeting that already mattered. Their Thursday client prep call required a current project board to run effectively. If the board was out of date, the call was harder. This created the feedback loop that had been missing: system quality had a visible, near-term consequence.
The studio hasn’t switched tools since. Not because Notion is perfect, but because the problems that used to make them want to switch were never about Notion in the first place.
What You Can Take From This
If your team’s productivity system feels like it’s always one good app away from working, here’s where to look instead.
Map the tool to your mental model. Spend an hour writing down how your team actually describes work to each other, not in the tool, but in Slack, in hallway conversations, in review meetings. If those words don’t appear in your system’s structure, you have a translation problem.
Assign system health as an explicit role. It doesn’t need much time. It needs to exist. A rotating steward with a specific, small responsibility beats collective ownership every time.
Find or create a forcing function. Identify a meeting or deliverable that depends on the system being current, and make that dependency explicit. If you can’t find one, that’s a signal that your system isn’t integrated into real work yet.
You can do all of this with whatever tool you’re already using. The system you’d actually stick with is the one that costs you something when it breaks down. If neglecting it feels fine, you haven’t solved the problem, you’ve just moved it somewhere harder to see.
