I think this looks great but "process-neutral" gives me pause. Process is important, and hard, and in practice "process-neutral" means "process by committee within each customers organisation" and naturally, that committee probably hasn't designed a great process before and so they're going to end up designing a subpar process... and for people subjected to that process, it'll reflect on your software.
For example, Jira isn't itself bad, Jira is quite nice in a vacuum, but Jira in the hands of an organisation is a nightmare because of the incoherent methods of working layered on top of it by well meaning but inexperienced process administrators who think configuring Jira is the solution to every delivery challenge faced in their org.
I've worked at half a dozen places I can think of off the top of my head where they've excitedly jumped into using a new (to them) issue tracking product, everyone loved it because it was new and exciting and empty and solved a problem... for a few months, and then people grew to hate it because it becomes an esoteric mess again. For example, Trello -> Notion -> Coda in the space of 18 months.
The decision to be process-neutral is a valid one and can be a very powerful foundation of a product, so my question is: do you have any specific thoughts around how you're going to be process-neutral while also stay loyal to the commitments you've made to being pleasant to use? If you can achieve that, a product that doesn't reflect the bad choices of administrators, I think you have incredible potential.
Thank you for this thoughtful comment, I’m happy somebody challenged us on this controversial point of our philosophy.
I disagree that a tool being process neutral implies anything about how the process ends up being designed, e.g. “process by committee within each customers organisation”, other than it won’t be decided by the tool. Process neutrality removes a set of constraints that in our experience add a lot of friction when teams want to work differently (and makes designing a great UX harder because of combinatorics).
There are indisputably tons of teams that seek and benefit from process guidance, including the ones I’ve run, but we think that should come from mentors, books, blogs, etc. – not the tool.
I agree that a lot of issues in Jira stem from wretched implementations, but I lay the blame for those implementations squarely at the feet of Jira. If most of the programs written in a language were impenetrable and borderline non-functional, would you blame the users, or the language?
Our biggest beef with prescriptivism in tools is that it impedes exploration and evolution of process changes that we feel are important to teams adapting well to growth and changing circumstances. It’s a much harder proposition to build a flexible tool, but we feel it’s necessary for this reason.
For example, Jira isn't itself bad, Jira is quite nice in a vacuum, but Jira in the hands of an organisation is a nightmare because of the incoherent methods of working layered on top of it by well meaning but inexperienced process administrators who think configuring Jira is the solution to every delivery challenge faced in their org.
I've worked at half a dozen places I can think of off the top of my head where they've excitedly jumped into using a new (to them) issue tracking product, everyone loved it because it was new and exciting and empty and solved a problem... for a few months, and then people grew to hate it because it becomes an esoteric mess again. For example, Trello -> Notion -> Coda in the space of 18 months.
The decision to be process-neutral is a valid one and can be a very powerful foundation of a product, so my question is: do you have any specific thoughts around how you're going to be process-neutral while also stay loyal to the commitments you've made to being pleasant to use? If you can achieve that, a product that doesn't reflect the bad choices of administrators, I think you have incredible potential.