Thanks for the feedback! It's really great to hear appreciation like that.
This is an awesome point, and one which we're keenly aware of. This is how we think about this:
Constructor must serve different roles with their own notions of success, and those notions may be at odds. That is, there are some tensions and tradeoffs within teams that exist independently of any tool, e.g., managers want stuff reported but developers just want to build software and not fill out TPS reports.
So our approach to solving your biggest problem is to try to create the best UX for each role, period, which implies Constructor must mediate these tensions where possible. For instance, our approach to blockers is very lightweight and we saw immediate uptake from devs when this was released, indicating they saw it as a help, not a burden. And of course it makes it apparent to managers what's going on without having to pester anyone. So we consider this a feature that helped both managers and devs do their jobs better without imposing an unwelcome burden on anyone. We're looking to extend this pattern in much more clever ways to get managers the facts they need without burdening developers with housekeeping tasks to provide those facts. It's a tough problem but we're optimistic we can make headway here.
Thanks for raising this point; it's really, really important.
We don't disagree and we've heard from non-technical managers and designers that Constructor has the potential to be simply "a better Trello for everyone". This is probably because despite being designed for software teams we try to serve all roles equally well, i.e. make sure we create an outstanding UX for the non-developers on those teams. Something we've seen happen at a lot of places is a "tool schism" where part of the team (design or PM) will cleave off and use Trello or Basecamp and leave the devs to Jira because they find it unusable, but the devs need their Jira for various good reasons. Constructor is designed to prevent tool schisms.
Your 80% observation is if anything an underestimate; there's almost nothing in Constructor that makes it dev-specific beyond the GitHub and devops integrations that are mostly absent if you don't activate them, and would be easy for us to make totally optional. This surprised us when we realized it, because we are quite devoted to serving software teams specifically.
- List view is on the roadmap but not designed yet; we'd love to understand your needs in more detail if you'd be up for dropping us a line at research@constructor.dev.
- By prioritize I presume you mean set an absolute priority? Priority right now is explicit in the ordering of tickets within their respective columns, but it's relative, not absolute. We're open to adding absolute priorities.
- You can search tickets with the search in the navbar, or filter the board to show a subset of tickets with the filter box.
- We haven't embarked on i18n/L10n yet but it's just a matter of prioritization – what language(s) do you require?
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.
Thank you for the feedback, and I completely understand and share this sentiment. We're very cautious when adding new features and are obsessed with keeping the out-of-the-box experience utterly simple and tuned to exactly what a small team needs. It's a major design consideration for us that as much as possible, complexity is opt-in.
Linear's a great step forward but too prescriptive and still too heavyweight for lots of teams. Our focus is on dramatically simplifying, and aligning the core conceptual models with how teams actually want to work, e.g. threaded comments, flexible blockers, user-defined work structures, etc.
Thanks! We have the exact same complaints, and that's why we invested so much effort in this approach. I think a lot of companies would never do this because they'd fear adversely impacting their conversions metric, but our goal is to just get people to understand our product as quickly and easily as possible and hopefully get feedback.
We also really don't like product tours that lock you into an endless sequence of modals, so we came up with this "overlay" that users can turn on and off, inspired by museum audio guides you can hold up to your ear whenever you like, or ignore entirely.
1. We have something in this direction already in the form of "guest users" that can be added to your boards and don't count as a seat. They currently have full privileges on the boards they can see, though – our permissions model isn't fine-grained yet.
2. Sounds like we may need to improve our description of this feature, but right now, we're optimizing for small-PR "trunk-based dev" [1] workflows where a ticket can have several PRs, but a PR always maps to a single ticket. We push the ticket info onto PRs in GitHub so code reviewers don't even have to click through to Constructor to get the context they need to do their review. We'll definitely support use cases like yours in the future, though!
This is an awesome point, and one which we're keenly aware of. This is how we think about this:
Constructor must serve different roles with their own notions of success, and those notions may be at odds. That is, there are some tensions and tradeoffs within teams that exist independently of any tool, e.g., managers want stuff reported but developers just want to build software and not fill out TPS reports.
So our approach to solving your biggest problem is to try to create the best UX for each role, period, which implies Constructor must mediate these tensions where possible. For instance, our approach to blockers is very lightweight and we saw immediate uptake from devs when this was released, indicating they saw it as a help, not a burden. And of course it makes it apparent to managers what's going on without having to pester anyone. So we consider this a feature that helped both managers and devs do their jobs better without imposing an unwelcome burden on anyone. We're looking to extend this pattern in much more clever ways to get managers the facts they need without burdening developers with housekeeping tasks to provide those facts. It's a tough problem but we're optimistic we can make headway here.
Thanks for raising this point; it's really, really important.