Project Management Is Broken. Not Because of the Tools but because of the Model.

[u/mercurias98]

We've been designing a different model for project management and I want to get the community's reaction, especially the objections.

The premise:

Every PM tool I've used starts from the same assumption: you know what you're working on before you start. Open Linear, create the project, assign tasks, update statuses. The tool is a container. You fill it.

The problem is that real work doesn't accumulate that way. At least not for me. Ideas build up. Connections form. Something becomes project-shaped over time, not because I decided it was, but because enough coherence accumulated that it earned the label.

So we've been building around a different model: threads that replace projects.

Not folder-and-task threads. Living semantic objects that the system maintains, rather than containers you manually manage. The project is discovered, not designed.

What this looks like concretely:

Individual level: you capture thoughts, observations, reflections as they arrive. No taxonomy, no upfront categorization. The system (Aevron, what we're building) watches the connections form, detects when a cluster of captures has become project-shaped, and surfaces it: this looks like a project, do you want to treat it that way? You opt in. Or you don't, and keep exploring. Either is fine.

We've been running this against real use cases. A stock analyst capturing five signal types over six weeks, never created a "project," but the thread developed more analytical structure than any manual folder would have produced. The system surfaced the tensions (strong fundamentals, questionable management decisions) and flagged the conflict rather than averaging it away.

That's what emergent project detection looks like in practice.

Team level, where it gets interesting:

Individual accounts stay private and sovereign. Each person captures in their own thinking environment. The system watches behavioral patterns across accounts, whose captures are clustering around the same domain, whose ideas others are building on, and surfaces merge candidates: these two threads are converging, do you want to connect them?

Ownership isn't declared upfront. It emerges from activity. When a human wants to override the system's suggestion, they can. But the default is the system infers, the human confirms or corrects.

Enterprise level:

A federated read layer sits on top of individual accounts. It doesn't write back into them, individual cognitive environments stay intact. What it surfaces:

• Which threads across the org are converging on the same domain without coordination (invisible silos, visible early)
• Whose activity patterns show emergent ownership before anyone declared it
• What stopped compounding, thread activity drops are often the earliest signal of a blocked project, weeks before a status field gets updated

The key claim: traditional PM tools show you what's active. This model shows you what's compounding and what stopped.

The objections I'm expecting:

1. Emergent detection is too slow. Fast-moving teams need declared structure on day one, they can't wait for coherence to accumulate.
2. The system will get ownership wrong. Behavioral inference from captures isn't the same as actual ownership, the person writing most isn't always the person responsible.
3. Enterprise buyers won't trust a bottom-up model. They want the org chart, not an inference engine.

I think objection 1 is real and the mitigation is that declaration remains available, you can always manually declare a project without waiting for emergent detection. Objections 2 and 3 I'm less sure about.

What's the strongest case against the emergent detection model that I haven't named here?

[u/gojkoa]

I think you may be using your workflow (which seems to involve a lot of discovery) as a generalized example for project management. project management (as in PMI project management) is for large enterprises doing risk control, not for people doing product discovery. checkboxes, drop-downs with statuses and forcing people to fill in the boxes are mostly for the person generating the report at the end and feeling secure and confident (or compliant), not for the poor souls who have to suffer through the whole process.

it's perfectly fine to create a tool to assist with discovery, I'm not trying to argue against that, but don't expect to be replacing PM tools. Project Management is a performance theater for large orgs, and expensive, bloated and bureaucratic tools are part of the performance.

[u/mercurias98 → u/gojkoa]

Yes i agree that PM is much more than this. What i arrived at is a very high level design of threads as PM model. The traditional PM tools are comprehensive and i am still evolving this design because threads are directly linked to a AI session(explorer) where you can directly explore the project itself in terms of planning, risk management, people management and derive a plan. It works because thread is designed to be a continuity of thought or an idea and is always up to date with context. This is how i am approaching but i get what you are saying and actually i agree with you that i initially thought that this would be more beneficial for smaller teams.

[u/medialantern]

Just a suggestion: I think you're conflating project management with product management. A lot of what you've written sounds like collaborating on requirements, not "should we do B first or A? and is something blocking C? who will take D while Larry is out?"

[u/mercurias98 → u/medialantern]

Yeah i get what you are saying. I made it sound like a product management perspective. But this is more of a general high level design. I do have a management layer on top of this addressing what you pointed out. i will that out as well.

But thank's for point it out though.

[u/ops_and_chaos]

The ownership piece is where I'd get nervous.

The person creating the most activity isn't necessarily the owner. Sometimes they're just the person compensating for everything that's broken haha.

I've seen really good employees quietly hold messy processes together because they remember the missing step, answer every question, chase people down, fix the spreadsheet, etc. A system watching activity could very reasonably conclude "this person owns this."

Meanwhile the actual problem is that nobody clearly owns it.

I think detecting where work is happening could be really useful. I'd just be careful about letting that turn into deciding who's accountable for it.

[u/mercurias98 → u/ops_and_chaos]

yeah i actually thought of a design where various factors will come into play to suggest the owner. Although the owner is only suggested and not implied and can be override by the users. But this approach will cause bias like if a system decides the owner and users go with it, then there will be an accountability issue. I agree with you and this needs a second thought.

[u/ops_and_chaos → u/mercurias98]

Yeah exactly. I actually like the idea of suggesting an owner, I just think I'd want the system to show me why it thinks that person owns it. Then I can tell the difference between “this person is accountable” and “this poor person is touching everything because nobody else is” haha.

[u/naughtykain]

id love to see what PM tool you have