0:00
/
0:00
Transcript

I Spent 100 Hours Designing a Slack Killer

Beyond the Channel: A First Principles & JTBD Takedown of Aging Team Collaboration Concepts

The Practical Innovator's Guide to Customer-Centric Growth is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

Introduction: The Illusion of Connection, The Reality of Chaos

Let's be honest. You've been sold a story.

The story is that a decade of innovation in collaboration tools—Slack, Microsoft Teams, Google Chat—has made your team more productive. You're more connected, more agile, more "in sync" than ever before. Your screen is a vibrant mosaic of channels, threads, DMs, and notifications. It certainly feels busy.

But what if that feeling of constant connection is an illusion? What if the very tools designed to bring us together are, in fact, the primary source of the chaos, distraction, and fragmentation that defines modern knowledge work? Deep work feels impossible, clear progress is elusive, and the simple act of finding a final decision can feel like an archaeological dig.

If you're feeling this, you're not alone. The problem, however, isn't that Slack needs a new feature or that Teams needs a better interface. The problem is that these tools, and our entire mental model of collaboration, are built on a fundamentally flawed premise. They are designed to optimize for communication, a proxy for the real job, when they should be designed to optimize for the job itself.

So, what is the real job? It's to advance collective work with clarity and velocity.

In this deep-dive analysis, we're going to do something radical. We're not going to compare features or talk about "best practices" for managing your channels. We're going to use First Principles thinking to tear down our inherited assumptions about collaboration. We'll deconstruct the job to its absolute core, identify the metrics you and your team use to measure success (whether you know it or not), and then reconstruct a new, more powerful paradigm from the ground up. This is a comprehensive guide for leaders who are serious about building a high-performance organization and are willing to question everything they think they know about how teams should work together.

Get ready to move beyond the channel.

Part 1: Deconstruction - Finding the First Principles of Collaboration

To reinvent something, you first have to understand it at a foundational level. You have to strip away the paint, the chrome, and the conventional wisdom to see the raw chassis underneath. For team collaboration, this means we must stop talking about products and start talking about the job.

What is the Real Job? Elevating the Abstraction

If I asked you why you use Slack, you'd likely give a solution-based answer: "To talk to my team," or "To get quick answers." This is reasoning by analogy. You're describing the tool's function by comparing it to known concepts, which is the most common way we make sense of the world. But it's also a trap. When you define a market by a product category—the "chat app market"—you can only ever create incremental improvements on that category. You get a slightly better chat app.

To break out of this trap, we have to use First Principles thinking. We must elevate the level of abstraction by repeatedly asking "Why?" This is the Socratic method in action, a simple way to drill down to the foundational truth.

  1. Why do you use Slack? -> "To communicate with my team."

  2. Why do you need to communicate with your team? -> "To get answers, share updates, and give feedback."

  3. Why do you need to do those things? -> "To make decisions and ensure our project moves forward."

  4. Why do you need to move the project forward? -> "To accomplish a specific, collective goal for the business."

  5. And what defines the successful accomplishment of that goal? -> "That we advance our collective work with clarity and velocity."

There it is. That's the real job.

This isn't just semantic. It's a seismic shift in perspective. It moves the unit of analysis from the person (and their communication habits) to the work (and its progress). No one gets a bonus for "sending 50 Slacks today." You get a bonus because the project shipped on time (velocity) and on budget, without costly rework (clarity).

This is our first principle. From here, we can map out what success looks like in excruciating detail.

Mapping the Job of "Advancing Collective Work"

Every job, from making a cup of coffee to launching a rocket, can be broken down into a series of process steps. The Outcome-Driven Innovation (ODI) methodology provides a universal "Job Map" that gives us a framework for deconstruction. The eight stages are: Define, Locate, Prepare, Confirm, Execute, Monitor, Modify, and Conclude.

Let's use this map to dissect our core job. For each stage, we'll identify the "desired outcomes"—the metrics that your team uses to measure success, whether they realize it or not.

Stage 1: Define — Establishing the Plan and Scope This is the initial planning phase where the objectives, scope, and approach are established. Success here is about creating shared understanding and minimizing ambiguity from the outset. It's about ensuring everyone is rowing in the same direction before the boat even leaves the dock.

  • Minimize the time it takes to get all stakeholders to agree on the final scope of the project.

  • Minimize the likelihood that key stakeholders have conflicting understandings of the project's primary goals.

  • Increase the speed at which a clear owner can be assigned to every major workstream.

  • Minimize the time it takes to identify all dependencies required for the project's success.

  • Increase the confidence of the team that the defined plan is achievable within the given constraints.

  • Minimize the effort required to document the final plan in a way that is accessible to everyone.

Stage 2: Locate — Gathering and Organizing Inputs Before work can begin, team members need to gather the necessary information, assets, and resources. This is the scavenger hunt phase, and the goal is to make it as short as possible. Success here is about frictionless access to inputs.

  • Minimize the time it takes to find the latest version of a required asset (e.g., design file, document, dataset).

  • Minimize the need to ask a colleague where to find a specific piece of information.

  • Increase the speed at which you can identify the subject matter expert for any given topic.

  • Minimize the time it takes to get access permissions for a required tool or file.

  • Minimize the likelihood of starting work with an outdated or incorrect version of an input.

  • Reduce the time it takes to find the context or history behind a past decision.

Stage 3: Prepare — Setting Up the Work Environment This stage involves configuring the tools, resources, and environment needed to perform the work. For knowledge work, this is often about setting up digital workspaces, repositories, and communication channels. The goal is to make the "workshop" ready for work.

  • Minimize the time it takes to set up a dedicated space (e.g., a project folder, a code repository) for a new initiative.

  • Minimize the number of separate tools that need to be configured to work together for a single project.

  • Increase the speed at which team members can be onboarded to the project's specific tools and workflows.

  • Minimize the effort required to ensure all necessary templates and boilerplate are in place before work begins.

  • Reduce the friction of integrating a new team member into an ongoing project.

Stage 4: Confirm — Verifying Readiness to Proceed This is the final checkpoint before execution begins. It’s about ensuring that everything is in place and everyone is ready to go. It's the "point of no return" where the team commits to moving forward.

  • Increase the confidence that all prerequisites and dependencies have been met before starting a task.

  • Minimize the time it takes to get a final "go-ahead" or approval from a stakeholder.

  • Reduce the likelihood that work needs to be stopped shortly after starting due to a missing input or unresolved question.

  • Increase the clarity for every team member on what their first execution step should be.

  • Minimize the need for a formal "kick-off meeting" to confirm readiness.

Stage 5: Execute — Performing the Core Work This is the "doing" phase, where the actual tasks of the project are performed. Success here is about enabling focused, high-quality work and effective micro-collaboration at the point of action.

  • Minimize the time it takes to get timely and specific feedback on a piece of executed work.

  • Maximize the clarity and actionability of the feedback received.

  • Minimize the number of interruptions encountered while performing a focused task.

  • Increase the speed at which a decision can be made when a blocker is encountered.

  • Reduce the effort required to hand off a piece of work to the next person in the process.

  • Minimize the friction of co-creating or co-editing a work asset in real-time.

Stage 6: Monitor — Tracking Progress and Status While the work is being executed, the team and its leaders need to understand its status relative to the plan. Success is about effortless, real-time visibility that doesn't require manual reporting.

  • Minimize the effort required for a leader to understand the current status of all project workstreams.

  • Minimize the effort required for a team member to communicate their progress.

  • Eliminate the need for dedicated status update meetings.

  • Increase the speed at which a potential delay or bottleneck can be identified.

  • Maximize the accuracy of progress-tracking information.

  • Reduce the time it takes to see how one team's progress is impacting another team's dependencies.

Stage 7: Modify — Making Adjustments and Corrections Inevitably, things change. This stage is about making course corrections based on feedback, new information, or performance monitoring. Success is about agility and minimizing the cost of change.

  • Minimize the time it takes to decide on a course correction when a problem is identified.

  • Increase the speed and efficiency of incorporating feedback into a work asset.

  • Minimize the effort required to communicate a change in the plan to all affected stakeholders.

  • Reduce the risk of team members continuing to work based on an outdated plan.

  • Maximize the ease of reverting to a previous version of a work asset if a modification proves to be a mistake.

Stage 8: Conclude — Finishing the Work and Handoff This is the final stage, involving completing the work, gaining final approvals, and archiving or delivering the output. Success is about a clean finish and preserving knowledge for the future.

  • Minimize the time it takes to get final sign-off from all required stakeholders.

  • Reduce the effort required to archive project assets and conversations in a way that they can be easily found later.

  • Minimize the ambiguity about whether a project or task is officially "done."

  • Increase the speed of handing off the completed work to a downstream team (e.g., from development to marketing).

  • Maximize the ease of conducting a post-mortem or retrospective to capture learnings for future projects.

This Job Map represents the first-principles reality of team collaboration. It is a stable, solution-agnostic framework. Any tool, process, or strategy that claims to improve collaboration can be rigorously judged against how well it helps a team achieve these 40+ desired outcomes.

The Anatomy of Failure: Scoring Current Tools Against the Job Map

Now, let's hold up our current tools—Slack, Teams, even project management apps like Asana—against our map. The results aren't pretty.

  • Failure in "Define" and "Locate": Where does the "plan of record" live? In a Google Doc? A Confluence page? A pinned message in a Slack channel? The very act of creating a plan immediately fragments it from the place where it will be discussed (the chat app). This forces a constant, frustrating consumption chain job on your team: the job of finding the information needed to do their actual job. Every time someone asks "Where can I find the latest deck?" in a channel, your tool has failed the "Locate" step. Decisions are made in threads, context is scattered across DMs, and the official plan becomes a stale artifact, disconnected from the living reality of the project.

  • Failure in "Execute": Chat apps are interruption factories. They are designed around a chronological stream of ephemeral messages, which is the antithesis of deep work. The red notification dot creates a culture of manufactured urgency, rewarding the fastest response over the most thoughtful one. Feedback on a design mock-up is given in a channel, completely disconnected from the mock-up itself. This creates a new, painful "Modify" job: the developer or designer must now manually collate, interpret, and transfer that feedback from the chat app back into the design file, hoping nothing is lost in translation.

  • Catastrophic Failure in "Monitor": How do you know the status of a project in Slack? You call a status meeting. Or you create a dedicated #project-x-updates channel that no one reads. Or you just DM people individually, interrupting them to ask for information that should be ambiently available. These tools have zero concept of a project's state or progress. They are "state-blind." This is their single greatest failure. The entire industry of project management software exists primarily to compensate for this one massive gap, forcing your team to do the work in one place and report on it in another.

  • Failure in "Conclude": A decision is made in a thread. Is it final? Who saw it? Where is it documented? The ephemeral, un-archivable nature of chat makes it a black hole for decisions and context. Trying to find out why a decision was made six months ago is nearly impossible, destroying organizational memory and forcing teams to solve the same problems over and over again.

The fundamental flaw is now clear: Communication-centric tools break the link between the conversation and the work. They create two parallel universes that must be manually synchronized by your team, adding immense cognitive load and friction at every stage of the Job Map.

Part 2: Reconstruction - Building a New Collaboration Paradigm

Having deconstructed the job and diagnosed the failure of our current tools, we can now begin to build a better model from first principles. If the old paradigm was communication-centric, the new one must be work-object-centric.

The Foundational Shift: From Communication-Centric to Work-Object-Centric

This is the core idea: The conversation should live with the work.

Instead of a chat app being the hub and work assets (docs, designs, spreadsheets) being spokes, we must invert the model. The "work object"—the document, the design file, the code branch, the task—must become the primary interface for collaboration.

You don't go to a channel to talk about the proposal; you go to the proposal itself, and the conversation is an integrated feature of that object. It has its own version-controlled discussion thread, its own task list, its own approval flow, its own history. The work object is no longer a dead artifact being discussed elsewhere; it is a living, breathing entity that contains its own context.

This single shift solves for dozens of our desired outcomes simultaneously. It eliminates the "Locate" job of finding conversations. It ensures feedback is always in context, simplifying the "Modify" job. And, as we'll see, it can completely automate the "Monitor" job.

Grounding the Future: Applying Doblin's 10 Types of Innovation

The shift to a work-object-centric model isn't just a change in software; it's a fundamental change in how a team operates. To structure our thinking about the future, we can use the Doblin framework, which organizes innovation into ten distinct types across three categories: Configuration, Offering, and Experience.

  • Configuration: Innovations focused on the innermost workings of the enterprise and its business system. (e.g., Profit Model, Network, Structure, Process)

  • Offering: Innovations focused on an enterprise's core product or service. (e.g., Product Performance, Product System)

  • Experience: Innovations focused on customer-facing elements. (e.g., Service, Channel, Brand, Customer Engagement)

Our novel concepts for collaboration don't just touch on one of these areas; they are powerful because they combine multiple types of innovation to create a cohesive, superior system.

The Future: Novel Concepts for Flawless Collaboration

The async-first movement shows us what's possible today. But if we apply our creativity and the full power of modern technology to our Job Map, what does the truly novel future of collaboration look like? Here are three concepts that get the job done completely differently, better, and at a lower cost of complexity, grounded in both the Doblin framework and specific creativity triggers.

Novel Concept 1: The "Living" Work Object (Process & Offering Innovation)

This is the ultimate evolution of the work-object-centric model. Imagine a system where the work object is a smart, self-contained entity.

  • Description: When you create a new "work object"—say, a "Q4 Marketing Plan"—it's not just a document. It's a container. This container has built-in, version-controlled modules for discussion, tasks, approvals, and dependencies. All elements of the work are unified within a single, coherent interface.

  • Doblin Lens: This represents a fundamental Process Innovation, changing the core method of how work is executed, monitored, and modified. It is also an Offering Innovation, specifically in Product Performance and Product System, as it integrates what are currently separate tools (docs, tasks, chat) into a single, superior product system.

  • How it gets the job done better: When you update a task's status to "Done," the work object's overall progress bar updates automatically. This progress then ripples up to a central project timeline. The act of doing the work is the act of updating the status. It completely eliminates the "Monitor" job for team members and makes status meetings utterly obsolete.

Novel Concept 2: AI-Powered "Collaboration Synthesis" (Service & Process Innovation)

The problem with most "AI for work" is that it's just a chatbot, adding another layer of communication. A first-principles approach uses AI not to chat, but to synthesize and reduce cognitive load.

  • Description: Imagine an AI agent that has read-only access to all the discussions happening within every "Living Work Object." Its job is to act as a universal project manager and information synthesizer. You can ask it natural language questions and get answers with direct links to the source conversations. For example: "What are the currently open questions on the 'Website Redesign' project?" or "Summarize the key decisions made about the 'Q3 budget' this week."

  • Doblin Lens: This is a powerful Service Innovation, offering a new capability—"synthesis-on-demand"—that simplifies the user's life. It's also a Process Innovation, as it automates the manual, time-consuming process of locating and understanding project information.

  • How it gets the job done better: This AI automates the most painful parts of the "Locate" and "Monitor" stages of the job. It eliminates the human effort of searching, collating, and synthesizing information that is scattered across a project. It provides perfect information awareness on demand, allowing leaders and team members to make better, faster decisions without ever having to interrupt a colleague.

Novel Concept 3: The "Dynamic Team" Interface (Organizational Structure & Process Innovation)

Our final concept reimagines the org chart itself, moving from a static hierarchy to a dynamic, real-time map of collaboration.

  • Description: This is a visualization layer built on top of the "Living Work Objects" system. Instead of showing who reports to whom, it displays a real-time network graph of how work is actually getting done, showing nodes of people connected to the work objects they are contributing to. The thickness or color of the lines could indicate the intensity of their contribution.

  • Doblin Lens: This is a direct Structure Innovation (a type of Configuration innovation), as it changes how the organization is arranged and how talent and assets are aligned. It visualizes the informal networks where real work happens. It is also a Process Innovation for management, providing a new way to monitor organizational health and resource allocation.

  • How it gets the job done better: This provides an unprecedented level of "Monitor" capability for leaders. It's a true, real-time view of the organization's collaborative health. It allows leaders to manage the process of collaboration, not just the people. They can spot overloaded team members, identify isolated teams that need more support, and see how strategic initiatives are translating into actual collaborative effort across the company.

Part 3: The Path Forward - How to Start Today

Rebuilding your company's entire collaboration stack around these novel concepts is a long-term vision. However, the journey towards a calmer, more effective, work-object-centric future can begin today. You don't need new tools; you need new principles and new discipline.

Making the Transition: A Practical Guide

Here are three actionable steps you, as a leader, can take to start shifting your team's culture and processes right now:

  1. Conduct a "Collaboration Audit." For one week, ask your team to map their most common workflows. Have them identify every point of friction where they have to switch tools to talk about the work they are doing. Where do they have to manually copy-paste information? Where do they have to ask for a status update? Make the pain visible. This creates the shared motivation for change.

  2. Enforce "In-Context" Communication. This is the most powerful and difficult step. Make a rule: All communication about a specific work object must happen on or in that work object.

    • Feedback on a Google Doc? Use the comments feature, not Slack.

    • Discussion about a Jira ticket? Use the Jira comments, not a DM.

    • Questions about a design? Comment directly in Figma.

    • This requires you to actively police and redirect conversations. When someone asks a question in a channel that should be a comment on a work object, your response should be: "Great question. Can you please post that in the Google Doc so the context isn't lost?" This will feel painful at first, but it is the essential first step in re-linking the conversation to the work.

  3. Champion Asynchronous Work. Explicitly redefine what "urgency" means in your organization. Create processes that don't depend on someone being online right now. Encourage detailed, thoughtful written communication over quick, reactive chats. Protect your team's focus time as a sacred resource. This isn't about working less; it's about working better.

Conclusion: Stop Chasing a Better Chat App

The next great leap in productivity won't come from a "Slack killer" that is simply a better chat app. True innovation in collaboration will come from eliminating the need for a chat app as the central hub of our work lives.

The future of high-performance teamwork is not more channels, more integrations, or more AI chatbots. It is calmer, more focused, and more deliberate. It's a future where the work itself is the interface, where context is inherent, and where progress is visible to everyone without a single status meeting.

By deconstructing the real job of collaboration and rebuilding from first principles, we can see this future clearly. It requires a shift in mindset from optimizing communication to optimizing the work itself. It's a harder path, one that requires discipline and a willingness to challenge the status quo. But it's the only path that leads to a place of genuine clarity and velocity.


Discussion about this video