Project, Product and Product Building as a whole #290
Replies: 7 comments 5 replies
|
Thanks for digging in, and for the PRs. It's a fair question, and you're right that the trend is real. Our focus right now is getting Devlane fully usable as a solid project management tool. That's the priority before anything else. Once that foundation is genuinely there, we do plan to invest in the "builder tool" direction you're describing. The important part is that we won't trade one for the other. Devlane will stay fully usable as a pure project management tool for teams who just want that, and the builder side will be something we add on top rather than bake in as the only way to use it. So both, but in order: nail the fundamentals first, then grow into the building layer without leaving the project management users behind. Keen to hear your thoughts! |
|
Sounds fair, better to get one thing right, as against try to go in 10
different directions...
That said - my sense is that project management in its existing form seems
to be slowly dying out ( the task management and planning part)
We have a lot of companies now that have "goals" - and what they do is
pathfind tasks to get them to those goals very iteratively / through
discussions .
Basially tightening the loop of "
-- what is the outcome we want to achieve" (E.g. onboarding reduction,
revenue improvement, reducing time for onboarding)
-> here are 4-5 key hypothesis that we think make sense basis customer
feedback
-> lets quickly release and get more data to find if it gets us in the
direction
My hunch, is that woudl require a project management tool alright, but one
of a very different nature, where users collarbaote on creating the
requirement, collabroate on "triggering them off for an agent to do them"
and reacting on the outcomes. .
What made me interested in this project - is that this project was in the
space I was thinking is ripe for transformation in that direction. Which is
a great place to be. Is this a direction that makes sense to you?
…On Thu, 9 Jul 2026 at 00:17, Martian ***@***.***> wrote:
Thanks for digging in, and for the PRs. It's a fair question, and you're
right that the trend is real.
Our focus right now is getting Devlane fully usable as a solid project
management tool. That's the priority before anything else. Once that
foundation is genuinely there, we do plan to invest in the "builder tool"
direction you're describing. The important part is that we won't trade one
for the other. Devlane will stay fully usable as a pure project management
tool for teams who just want that, and the builder side will be something
we add on top rather than bake in as the only way to use it.
So both, but in order: nail the fundamentals first, then grow into the
building layer without leaving the project management users behind. Keen to
hear your thoughts!
—
Reply to this email directly, view it on GitHub
<#290?email_source=notifications&email_token=ADEBO2VSHJW2GMLMB3KHE7L5D3B6XA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVG44DANJRUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17578051>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADEBO2ULLYN4AY5LNLP42CT5D3B6XAVCNFSNUABJKJSXA33TNF2G64TZHMYTCNJYGU2DCNJVGI5UI2LTMN2XG43JN5XDWMJQGM4TINRSGWQXMAQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Agreed that the shift to outcome-first work, with agents picking up requirements and running with them, is where things are heading. Where I'd differ is the tracking part doesn't die,You still need a reliable record of what was decided, what's running, and what shipped, and agents need that structured state even more than people do. So at this point we can build both in parallel. Devlane stays a solid project management tool teams can rely on, and on the same core we grow the builder side: shaping requirements together, handing them to agents, and reacting to outcomes. I see your efforts on the PRs, so If you contribute to build the "builder" side we would love to accept your PRs 🙌 |
|
@nazarli-shabnam What are your takes on this? |
|
If we keep the architecture clean and API-first, we can easily support the agentic "builder" layer on top of a stable foundation. Since the atomic task layer remains our source of truth and system state, we don't need to reinvent our core tracking mechanics to support this. Instead, we can introduce the agent/goal constructs as a modular extension layer. Phase 1: The Abstraction Layer (Data Schema): Define a Goal or Outcome construct that sits above our current task/epic schema. This layer should hold the high-level objective and customer feedback context that a team (or eventually, an agent) needs to pathfind against. Phase 2: The Discussion/Threading Engine: Ensure our commenting/threading mechanics can support collaborative requirement-shaping directly tied to these Goals. Phase 3: Agent Hooking (The "Trigger"): Once the data layer and context loops are solid, we expose webhook/API triggers allowing external agents to read a Goal context, generate sub-tasks, and report back. |
|
Appreciate it. I agree tasks remain the atomic unit of work and will stay
core to any system. I was thinking aloud about a more abstract goal
construct above tasks that enables dynamic task selection and some
agent-native core development that could activate in step one. Much of this
still aligns with strengthening core project-management foundations.
…On Thu, 9 Jul 2026 at 00:40, Martian ***@***.***> wrote:
Sounds fair, better to get one thing right, as against try to go in 10
different directions... That said - my sense is that project management in
its existing form seems to be slowly dying out ( the task management and
planning part) We have a lot of companies now that have "goals" - and what
they do is pathfind tasks to get them to those goals very iteratively /
through discussions . Basially tightening the loop of " -- what is the
outcome we want to achieve" (E.g. onboarding reduction, revenue
improvement, reducing time for onboarding) -> here are 4-5 key hypothesis
that we think make sense basis customer feedback -> lets quickly release
and get more data to find if it gets us in the direction My hunch, is that
woudl require a project management tool alright, but one of a very
different nature, where users collarbaote on creating the requirement,
collabroate on "triggering them off for an agent to do them" and reacting
on the outcomes. . What made me interested in this project - is that this
project was in the space I was thinking is ripe for transformation in that
direction. Which is a great place to be. Is this a direction that makes
sense to you?
… <#m_5646808386451562992_>
On Thu, 9 Jul 2026 at 00:17, Martian *@*.*> wrote: Thanks for digging in,
and for the PRs. It's a fair question, and you're right that the trend is
real. Our focus right now is getting Devlane fully usable as a solid
project management tool. That's the priority before anything else. Once
that foundation is genuinely there, we do plan to invest in the "builder
tool" direction you're describing. The important part is that we won't
trade one for the other. Devlane will stay fully usable as a pure project
management tool for teams who just want that, and the builder side will be
something we add on top rather than bake in as the only way to use it. So
both, but in order: nail the fundamentals first, then grow into the
building layer without leaving the project management users behind. Keen to
hear your thoughts! — Reply to this email directly, view it on GitHub <#290
<#290>?email_source=notifications&email_token=ADEBO2VSHJW2GMLMB3KHE7L5D3B6XA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVG44DANJRUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17578051>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADEBO2ULLYN4AY5LNLP42CT5D3B6XAVCNFSNUABJKJSXA33TNF2G64TZHMYTCNJYGU2DCNJVGI5UI2LTMN2XG43JN5XDWMJQGM4TINRSGWQXMAQ
<https://github.com/notifications/unsubscribe-auth/ADEBO2ULLYN4AY5LNLP42CT5D3B6XAVCNFSNUABJKJSXA33TNF2G64TZHMYTCNJYGU2DCNJVGI5UI2LTMN2XG43JN5XDWMJQGM4TINRSGWQXMAQ>
. You are receiving this because you authored the thread.Message ID: @.*>
Agreed that the shift to outcome-first work, with agents picking up
requirements and running with them, is where things are heading. Where I'd
differ is the tracking part doesn't die,You still need a reliable record of
what was decided, what's running, and what shipped, and agents need that
structured state even more than people do.
So at this point we can build both in parallel. Devlane stays a solid
project management tool teams can rely on, and on the same core we grow the
builder side: shaping requirements together, handing them to agents, and
reacting to outcomes.
I see your efforts on the PRs, so If you contribute to build the "builder"
side we would love to accept your PRs 🙌
—
Reply to this email directly, view it on GitHub
<#290?email_source=notifications&email_token=ADEBO2UXHMGKFVFK4M36MAT5D3EW7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZVG44DCNZQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17578170>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADEBO2V3SBFU5UXXNKXDTPD5D3EW7AVCNFSNUABJKJSXA33TNF2G64TZHMYTCNJYGU2DCNJVGI5UI2LTMN2XG43JN5XDWMJQGM4TINRSGWQXMAQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
@aditya-vithaldas do you want to kick off that RFC with a rough sketch of how you visualize the Goal -> Task data hierarchy? |
|
Sure, let me do that... How do you typically want to visualize something of that nature? on the same note, saw that Notion had also built that end-ed project -> build cycle as well.. https://x.com/NotionHQ/status/2075249002208227743?s=20 |
|
Hey! Can i add issues to the repo and do them, i noticed things we could improve when doing the import for the analytics and want to do that? Also is it the correct thread to ask that? |
Of course you can, thank you for your contributions |
|
Hey Again! Just wanted you to know that you can submit this subject here so more people searching for this kind of software find it! |
Thanks for letting us know |
Uh oh!
There was an error while loading. Please reload this page.
Thanks, this looks like an interesting project, and have started contributing a couple of small PR's. That said, I do have some questions on the overall direction of the project.
Product building clearly, is changing a lot, and we are seeing more and more "end-end product building tools" coming along. E.g. Linear is going down the path of coding sessions (https://x.com/linear/status/2065143118417088981) , which enables people not just to "track" what they are doing, but also do them,
Atlassian is going down the path of adding coding sessions and overall document management in.
My sense, is over time product + project management + dev tools would start integrating strongly into a conversational style tool , which threads requirements and enables discussion
What is the view of the core group, on creating a "builder tool" as against a pure project tool.
All reactions