Six roles, one dataset, and a status nobody has to type

Context

Every role on a product team was maintaining its own version of the truth.

The project manager was human middleware — messaging designers and developers each morning to reconstruct where things stood, then retyping it into a status document that was stale by lunch. The designer couldn't see the engineering timeline, so she planned against assumptions and found out too late. The developer built against a design that had quietly changed. QA got surprised by late changes and had no shared definition of "done."

Nobody was doing anything wrong. The seams between them — the handoffs — were where things fell through silently.

The brief was a product and project management tool for internal teams. The obvious version of that is another dashboard. The question worth answering was why the existing ones weren't working.

Observation

12 participants across six roles: executive, project manager, designer, developer, QA, and marketing. Interviews were semi-structured and role-specific, then analysed for patterns that repeated across roles rather than within them.

That distinction mattered. A pain felt by one role is a user problem. A pain felt by five is a market gap.

Six patterns held across every role:

1. Fragmentation is universal. Every participant ran three to five tools at once. The developer ran six to eight. Nobody had a single source of truth.
2. The double-work tax. Project managers wrote the same status twice — once for the team, once for leadership. QA compiled release readiness by hand. Marketing kept a private tracker.
3. "Done" means something different to every role. Developer: code merged. QA: tested, no critical bugs, regression complete. Project manager: signed off and deployed. Designer: approved in the design file. That gap is where releases slip.
4. Trust requires automatic accuracy. Every participant said they would trust a shared tool only if it stayed current without them. Manual updates kill trust.
5. Executives want drill-down, not summaries. The ask was direct access to the real thing, not a curated report.
6. Transparency was the top request from both marketing and leadership — stated independently, in the same word.

Six personas were built from this, each grounded in interview evidence rather than hypothesis.

Competitive analysis covered nine tools across project management, product management, and all-in-one categories, plus how each was applying AI. Each was mapped on core features, target audience, strengths, weaknesses, pricing, and — the column that turned out to matter — common complaints.

What the problem actually was

The assumption going in was that people needed more visibility. More data, better surfaced.

The interviews said the opposite.

The project manager didn't want a richer dashboard. She distrusted curated numbers precisely because someone had curated them. What she wanted was fewer numbers she could verify herself — and a clear answer to "what needs me right now," with a route to the real thing so she could check it.

That one finding reframed the entire product. Her view stopped being an information-dense board and became a decision surface: summarise, route, and get out of the way. It is the single line of research that changed the most downstream design.

The runner-up finding did the same for the developer. His dominant pain wasn't missing information — it was interruption. The most common questions he got were "what's the status," "when will this be done," and "can we release today," several times a day, and the answers already existed somewhere. That reframed his pages to be the calmest in the system rather than the busiest.

So the problem was never visibility. It was that status was manual, and that every role was being shown work at the wrong altitude.

The tool's premise became: derive status automatically from the systems people already use, hold one dataset, and reshape it per role. The same project page is a working home for a designer and a summarised decision surface for a project manager visiting it.

What the competitive research changed

Not the feature list. The anti-pattern.

Across the incumbents, the most consistent complaint wasn't missing capability — it was noise. Activity feeds. Everything visible because it exists. Notifications competing with decisions. Steep learning curves and cognitive load appeared as the top complaint against tool after tool, including the market leaders.

So the research told us what to refuse:

• Summarise and route, don't re-host. If the real thing lives in another system, link to it rather than reproducing it.
• The default flipped from "show it" to "does this help someone decide or act?" If not, cut it.
• No activity feed. It tried to come back three separate times and was cut each time.

It also confirmed the wedge. Every incumbent made people the integration layer. Auto-derived status was the thing none of them did.

The edge case that changed the architecture

A design changes after it has been handed to a developer.

The naïve model treats handoff as an event: the designer hands off, the developer builds. But designers keep working. If the tool let a new version silently replace what the developer was building, it would produce the exact stale-version bug the whole product existed to prevent — except now the tool would be causing it.

The fix was a version-safety model:

• A handoff is pinned to the version the developer accepted.
• If the designer moves ahead, the new version appears as proposed, not applied.
• The developer keeps building the pinned version and sees a flag — adopt the new one, or raise a concern.
• QA inherits the same pinned baseline.
• A returned handoff carries its reason and reopens on the design side. It never vanishes.

Nobody's work changes underneath them.

Catching that one case is what turned handoff from a button into a proper state machine. It's the difference between a tool that looks collaborative and one that survives contact with a real team.

The full edge-case matrix ran the same exercise across each role — what happens when a build is red, when a handoff ages unaccepted, when integration data goes stale, when scope changes mid-sprint, when nothing needs the person at all. That last one produced a rule that shaped every page: an empty state is not a blank panel. "Everything is on track" is information, and it should look like it.

What I got wrong

The artifact model. My first proposal was that the artifact might be the design file page, and that each design change should spawn a task. Both were wrong. A design file page is a container, not a deliverable, and a task per tweak would have buried the project manager in admin.

The model that survived wasn't mine. The artifact is the flow — the login flow, say. Its tasks are the constituent pieces. Artifact status rolls up from them, and small changes become lightweight version entries rather than tasks. I had to abandon my first structure completely.

Over-scoping the visitor views. When I saw the other designer's denser version of the project manager's page, my instinct was that mine was too thin.

I was wrong. Theirs was a beautiful designer's page wearing a project manager's label. The correction was to hold the line on role discipline: the project manager's view stays a summary even when more data is available, because the data exists is not a reason to show it.

That is the exact trap the product was designed to avoid, and I nearly walked us into it.

The through-line: twice I reached for more structure and more content, and both times the right answer was less, scoped to what that person actually needs in order to decide or act. That constraint is the spine of the whole design — and I only trust it because I got it wrong first.

What I'd revise

[to write]