For over a decade, I worked as a management consultant specializing in team effectiveness and agile frameworks. It's a conversation I've had more times than I can count. A client comes to me, frustrated. “We’ve outgrown our existing issue tracker,” they’ll say, “but when we look at the market, every tool just seems to be a collection of the same things: kanban boards, Gantt charts, task lists. I don't know how to choose because I don't know what makes the difference, and what we actually need.”
Their frustration is understandable. It points to a deeper problem not with the tools themselves, but with how we go about choosing them.
Why most PM tool comparisons miss the point
As of this writing, Capterra lists 1,249 project management tools. That number says a lot about the size of the market — and about how overwhelming the selection process can be.
If you’ve ever stared at a spreadsheet with dozens of tools in the rows and hundreds of features in the columns, you’ve probably felt that sense of paralysis. We don’t need more comparison grids.
More data doesn’t help if you don’t know what matters.
This post is the first in a series that takes a different approach. Instead of comparing feature lists, we’ll start with the outcomes you actually care about — and work backward from there to identify the capabilities you need. Only then do features make sense.
Start with the pain: an impacts-first framework
Over the years, I've found that the most successful technology adoptions don't start with technology. They follow a simple, three-step logic that moves from high-level objectives down to implementation details. It’s a way of thinking that ensures the features you end up with are truly in service of the goals you actually have.
I first encountered this logic in Karl Wiegers' foundational book, Software Requirements, though many successful methods follow a similar path.
I've come to call my version Impacts -> Capabilities -> Features. Here's how it works.
- Desired impacts: This is the why of the work. What is the tangible change the organization wants to see in its operations and results? An example might be 'enhanced accountability and alignment.' The goal is to clarify ownership so everyone knows who is accountable for what, eliminating the friction of finger-pointing.
- Required capabilities: This is the what. To achieve that impact, what must people in different roles be able to do? Think of these as user stories for your process. A team member might need the capability to "see every task assigned to me, from any project, in one place." A manager might need to "discover if any task has been idle for more than two days."
- Enabling features: This is the how, where we finally talk about software. The team member's capability might be served by a feature called a "My Tasks Dashboard." The manager's might require a "Workflow Automation Rule" or a "Custom Report."
Notice the shift. We’re no longer checking boxes like “has dashboards.” We’re asking sharper questions:
Can this tool’s dashboard show me all my tasks across all projects, sorted by due date? Can it flag stale work in a way that’s useful, not noisy?
A feature only matters if it enables a capability that drives the impact you’re aiming for.
Here’s the twist: the desired impacts are often remarkably similar across organizations. Most organizations want similar things like better alignment and efficiency. The capabilities required to achieve those impacts, however, can vary wildly depending on the nature of the work. And that, in turn, changes the features you need.
Mapping the shape of your work
To know what kind of capabilities you’re aiming for, you need a clear picture of the work itself. In my experience, most organizations juggle several types of work simultaneously — each with its own logic. I find it helpful to think about this along a few key dimensions.
The nature of work
Most organizational work falls into a few common categories:
- Large predictive projects. Think of constructing a building, where detailed planning and resource allocation happen upfront. The primary challenge is to stay on schedule and within budget against a well-defined plan.
- Large adaptive projects. Software development is a classic example: the goal is clear, but the path isn’t. Success depends on adapting to new information and iterative learning.
- High-volume, short-cycle work. Short, deadline-driven efforts like marketing campaigns or event planning. The challenge is to allocate resources efficiently and avoid bottlenecks.
- Service management. This is the work that comes to you. Think of an IT help-desk or a legal team reviewing contracts. The process for handling a request is often standardized (predictive), but the arrival of requests is unpredictable. The key challenges are effectively routing work, ensuring compliance, and managing flow.
- Business-as-usual operations. Regular rhythms like recruiting, content planning, or invoice processing. These aren’t “projects” per se, but they benefit from structured workflows and visibility.
External collaboration: who’s involved?
The next critical question gets at the boundaries of your organization: Where does your work end and the outside world begin? How much do you need to collaborate with people outside your company, like clients, partners, or subcontractors? I think of this as a spectrum of transparency. At one end, your organization is a fortress with high walls; at the other, it's an open campus with porous borders.
Let's walk through what this looks like in practice, moving from the most locked-down to the most open model.
- The Mail Slot (Request Submissions): This is the classic fortress model. The walls are high and the gates are locked. Your interaction with the outside world is through a tiny, secure mail slot. Customers can drop off bug reports or feature requests and get a confirmation receipt, but they have no visibility into what happens next. The tool's job is simply to be a secure intake mechanism.
- The Public Bulletin Board (Status Transparency): This is a step toward openness. You've placed a bulletin board just inside the main gate. You're still not letting people wander around, but you are posting public notices. An external stakeholder can look up the status of their request, or you might post a shared product roadmap for all to see. The key here is read-only transparency for specific, curated information.
- The Viewing Gallery (Progress Monitoring): Now things are getting more serious. You're giving key stakeholders—a major client, a funding body, a regulator—a special pass. This pass doesn't let them onto the workshop floor, but it grants them access to a secure viewing gallery overlooking the project. From here, they can get transparent, real-time status reports on progress, track budget spending, and monitor key milestones. They can see the work happening, but they can't interfere with it directly.
- The Workshop Pass (Full Collaboration): This is the full campus model. You've given your external partners a pass that lets them right onto the workshop floor. They are part of the team. A client representative might be there helping to prioritize the project backlog. A subcontractor might be assigned tasks directly within your system. They participate in discussions, approve deliverables, and contribute to the daily flow of work. The boundary between internal and external becomes intentionally blurred in service of the project.
Understanding where your needs fall on this spectrum is vital. A tool designed simply as a "mail slot" will frustrate you when you need to grant "viewing gallery" access. Conversely, a highly collaborative "campus" tool might have security and permissions models that are too complex if all you need is a simple request form. Your choice of tool must reflect how you choose to manage these critical boundaries.
Integrated vs. Interoperable: the cross-functional fabric of work
Every organization — whether a scrappy startup or a sprawling enterprise — shares the same basic set of functions. What changes is how those functions distributed, coordinated, and connected.
In a five-person company, one person might wear five hats in a single day: sales in the morning, finance in the afternoon, IT after lunch. In a large company, those hats become departments. But the work remains the same.
Let’s follow the thread of a single ambitious project and see how these functions intertwine:
- It begins in management, where high-level strategy takes shape.
- Then to sales, where an opportunity is developed and a deal is closed.
- That deal is codified by legal, producing a contract — the source of truth for what the project must deliver.
- From there, project delivery kicks in: timelines, scope, execution plans.
- If new skills are needed, HR steps in to source talent. HR data — skills, roles, availability, compensation — feeds directly into cost and resource planning.
- Meanwhile, IT and procurement provision the tools and materials needed to do the work.
- Marketing begins to craft the story: a launch plan, a customer announcement, a campaign tied to the project’s milestones.
- All along, finance weaves the thread: tracking time, logging expenses, reconciling against the original budget. And in the end, those insights loop back to management, fueling the next strategic move.
What we call “a project” is really a constellation of interconnected functions.
Each of these functions doesn’t just support the project — they operate through their own specific sets of tasks. Legal drafts and reviews documents. Sales tracks the pipeline. HR posts jobs, schedules interviews, processes hires. Finance tracks costs, processes reimbursements, issues reports. These aren't side activities — they're structured, repeatable workflows in their own right.
And crucially, they all feed into the project. Their outputs become the inputs for planning, delivery, and oversight.
No single tool captures it all — but the question is: should it?
That’s why the question of tooling isn’t just about project management in isolation. It’s about how you manage the entire constellation of interdependent work.
This brings us to a core strategic choice:
- Do you want a unified platform — one environment where every function works from the same shared system?
- Or do you prefer a best-of-breed ecosystem, where each team uses its own specialized tools, and you invest in connecting the dots?
And if you go the ecosystem route:
- Will you automate the bridges between tools?
- Or rely on people — conversations, shared understanding, good habits — to move work across the gaps?
There’s no one right answer. But there is a right question:
What kind of collaboration does your organization actually need?
Where this series goes next
So before you open that next spreadsheet and start comparing features, take a step back.
Ask yourself: What job are we actually trying to get done?
Map the shape of your work — its rhythms, its edges, its collaborators. Understand the outcomes you care about. Then and only then should you evaluate tools.
In the next posts, I’ll dive into some of the most common desired impacts that organizations seek when adopting a project management tool. I’ll share examples of how to identify required capabilities in different contexts — and eventually, I’ll look at how well-known tools actually support those needs.
The goal here isn’t to crown a “best” tool.
It’s to build a better way of thinking — so you can find the tool that’s best for you.