A project management tool that multiple roles have to share
Nexlane is a project management tool for corporate teams whose members hold different roles and need different things from the same work. Nothing has been drawn yet. I did the research that decides what it has to do.
Contents
What Nexlane is
Nexlane is a web tool for corporate teams. The people using it hold different roles, and they need different things from the same work.
An executive wants to know whether anything is about to go wrong. A project manager wants the plan to survive a date change. A developer wants to know what to build and be left alone while he builds it. A designer wants to know that the version being built is the current one. A tester wants to know the build he is testing was actually deployed. Marketing wants to know what phase the product is in without asking five people.
The work is identical. The question is not. A tool that answers one of those well and the rest badly is the tool all of them already have.
Where the time goes
Every role I spoke to runs three to five tools at once. The developer runs six to eight. Nobody has a single place where the state of the work is simply true, so everybody maintains their own copy of it.
Nobody is paid to report on work. Everybody spends part of the day doing it anyway.
The co-CEO put the cost of it in a sentence: people should not be spent on checking, they should be spent on figuring things out.
My role
I did the research. All of it, alone. Twelve interviews, a comparison of twelve competing products, the problem definition, the personas, and the role-by-role document the wireframes will be drawn from.
User interviews across six roles, a study of the competing tools and where they leave a gap, the eleven core problems, six personas, the everyday and the awkward cases for each role, and the document the wireframes get drawn from.
Wireframes, interface design, and testing all of it against something real. Nine of the thirteen kinds of user still have no screens defined.
Twelve people, six roles
Three project managers, three designers, three testers, one developer who also leads a mobile team, one marketer, and the company’s co-CEO.
Interviewing across roles rather than within one was the whole method. The premise of the product is that the same work looks different depending on where you sit. Talk to one role and you get a single coherent account of the problem, which is exactly the thing that would have produced the wrong tool.
What I was listening for was not what people asked for. Feature requests are answers, and they arrive already shaped by whatever tool the person used last. I was after the moment before that: the last time someone had to go and find out something they should already have known, and what they did to find it.
I treated a pain felt by one role as a user problem and a pain felt by five as a market gap. Six patterns cleared that bar.
The tools that already exist
I compared twelve products across two categories — the tools teams work in day to day, and the planning tools that sit above them — on features, audience, pricing, stated strengths and, most usefully, their most common complaints.
Project management is one of the most thoroughly built software categories there is. So the honest question was not what to build. It was why anything new should exist.
Two failure patterns run through the whole category. The powerful ones are built for a single audience and hostile to everyone else — excellent for engineers, punishing for the marketer or the executive who has to read them. And the tools that tried to fix that by covering everything did it by piling on features, which left people with more to learn rather than fewer tools to open. Good enough at many things, best at none.
The gap is not better task management. It is the cost of keeping everyone in step, which sits on top of it.
There is a third pattern underneath both. Every tool in this category is an accurate record of the work exactly as often as the busiest person on the team remembers to type into it. Published research puts the share of professionals still compiling reports by hand at 72%. Every participant I interviewed confirmed it from a different chair.
The software is not what fails. The upkeep is.
| Tool | Built for | What people complain about |
|---|---|---|
| Jira | Engineering teams at scale | Complicated, slow as it grows, a poor fit for work that crosses departments |
| Asana | Mid-sized firms working across departments | No sharing a task between people, no built-in time tracking |
| Monday | Marketing, operations, client-facing teams | Visually cluttered once the rows multiply |
| ClickUp | Teams that want every option | Slow under the weight of everything it lets you change |
| Wrike | Large firms with a central planning team | Overwhelming to set up, slow to use |
| Smartsheet | Teams that think in spreadsheets | Expensive, and awkward to talk in |
| Linear | Small product and engineering teams | Poor fit for anyone outside engineering |
| Trello | Individuals and tiny teams | Feels dated, scales poorly |
| Productboard | Startups and growing firms | A lot of manual upkeep, awkward for everyone else invited in |
| Aha! | Enterprise product teams | Heavy to learn and set up, weak once building starts |
| ProductPlan | Large firms working across departments | Struggles to stay in step with Jira and Azure DevOps |
| Tempo | Product leaders and operations | Slow during meetings, unreliable links to other tools |
What everyone said
The work is scattered, for everyone. Every role runs three to five tools. Nobody has one place that is simply right.
Everyone does the work twice. Project managers write each status update twice, in two different shapes. Testers compile bug reports by hand. Marketing keeps a parallel tracker. Every project manager falls back to a private spreadsheet — which, as one of them said, defeats the entire point.
“Done” means something different to each role. Merged, to a developer. Tested with no critical bugs, to a tester. Signed off in Figma, to a designer. Signed off, tested and shipped, to a project manager.
Trust depends on the data staying current by itself. Every single participant said they would rely on a shared tool if, and only if, it stayed accurate without anyone maintaining it. Manual updates do not just go stale; they destroy the trust that makes the tool worth opening.
Executives want to dig, not to be briefed. The co-CEO turned down polished summaries and asked for a way down to the detail itself.
Transparency was the word two roles reached for independently. Marketing and the executive, asked different questions, answered with the same one.
Laid out as a grid, the pattern that matters is which rows run all the way across.
| Pattern | Executive | Project mgr | Developer | Designer | QA | Marketing |
|---|---|---|---|---|---|---|
| Work scattered across tools, no one place that is right | Confirmed | Confirmed | CriticalSix to eight tools | Confirmed | Confirmed | Confirmed |
| The same status typed twice | Not applicable | CriticalAll three | PartialUpkeep, not typing it twice | Partial | Confirmed | Confirmed |
| “Done” means something different | Partial | ConfirmedAll three | Not asked | Confirmed | Critical | Not applicable |
| Trust depends on the data staying right by itself | Confirmed | Confirmed | Critical“Automation” | Confirmed | Confirmed | Confirmed |
| The private spreadsheet is still open | Not applicable | ConfirmedAll three | Not asked | PartialOne of three | ConfirmedPlus Excel | ConfirmedOwn tracker |
| A view shaped to your role is wanted, not feared | Wants to dig in | Wants two views | Wants the reasonsAnd alerts he can turn down | Wants filtering | Wants own slice | Fears scrutiny |
Which problem to solve first, and what I decided
The research produced eleven core problems, which is more than any first release can carry. Choosing between them is the part that is actually judgement, so it is worth saying how I chose: by what a failure costs, not by how often it happens.
Most of these problems cost time. Chasing a status, rebuilding a timeline, asking someone where things stand — expensive, but recoverable within a day.
One of them costs the work itself. A designer updates a design; the developer never learns, and builds the old one. That was the designers’ sharpest recurring pain, and it is the only problem on the list where the output has to be thrown away and done again.
Chasing a version costs an hour. Building on a stale one costs the build.
So the stale-version problem ranks first. The definition of “done” ranks second, because it is comparatively cheap to fix and almost every other confusion follows from it.
What I set aside was prediction. The competitive research is full of tools promising to forecast which project will slip, and it is the most attractive thing to build. It is also the thing that most needs a trustworthy record underneath it, and nobody in this study has one yet. A forecast drawn from figures people already doubt is doubted too, with a bolder claim attached.
A newer design never replaces the one being built. When a designer changes something after handoff, the change arrives as a proposal against the version the developer locked to. He keeps building that one until he takes the update or says why he cannot.
The obvious alternative was to always show the latest — simpler to build, and wrong. Quietly swapping what someone is building, halfway through building it, is the same failure as the stale version with the blame moved. The cost of my version is that it only works if a real change gets a new version number. An edit that keeps the same number cannot be spotted at all. That is a real limit, and it is written into the document rather than hidden.
“Done” is not one state. Rather than force the six roles onto one definition, each handover — design to development, development to testing, testing to release — gets its own sign-off and someone who owns it. Nobody has to give up their meaning of the word. What they give up is the assumption that everyone shares it.
Every role sees the same record, cut to what they need. Written once, read six ways, rather than a project manager writing the same update twice.
That decision was not mine, in the sense that matters. One project manager described a homepage shaped to each role unprompted, in her own words, before I proposed anything. And it answers a fear that only appeared once, from marketing: that being visible in a shared tool means being watched in it. The rule that follows —coordinate, don’t author another team’s work — is what keeps visibility from turning into supervision.
What the design has to handle
The everyday cases describe what a tool is for. The awkward ones decide what it becomes, because they are where a clean idea meets somebody having a bad Tuesday. I wrote both out for every role I covered. The ones that constrained the design hardest:
Nothing needs you. The most common state of any dashboard is that everything is fine, and the honest answer is a calm “development is on track” rather than a screen of empty panels that reads as broken.
A handoff sits unaccepted. Delivered but not picked up, sitting there quietly getting older, is exactly how the space between two teams stalls without anyone noticing. It has to show up on both sides.
The data is out of date, or the link to another tool has dropped. The status has to say so plainly. A tool that shows green when it does not know is worse than one that shows nothing, because the whole product is a claim about trust.
Work with no link to anything. A task with no code attached, or code with no task, is precisely what hides a delay from the person answerable for the date.
A rejected handoff. It goes back with its reason attached and reopens where it came from. It never simply vanishes.
Nexlane will have thirteen kinds of user. Four of them are now fully worked out — every screen that role sees, what they are allowed to act on, what they are not allowed to touch, and what the screen says when something goes wrong. That came to roughly 140 features across the four: the executive, the product manager, the project manager and the designer.
The other nine, the developer and the tester among them, have not been worked out yet. That is the next piece of work.
Where this is now
Nothing has been drawn yet — no wireframes, no interface, no screens. What exists is the research and a document detailed enough to draw from.
None of it has been tested against anything real. The ranking and the decisions in section 07 are arguments, not findings, and the next step is to find out which of them is wrong.
This record stops here on purpose. A research phase dressed up as a finished product is the kind of thing that falls apart under the first real question, and there is more to read in a problem stated precisely than in screens drawn early to have something to show.