We honestly started this company because there is a big gap between best practice product development and the tools that were available. I hope that if you read the article that you'd at least find some interesting (maybe provocative) content there. It's not intended as clickbait.
0xbadcafebee|3 years ago
Most of the points raised in the article are opinions based on a limited understanding or use of issue trackers. For example:
You raise a point only to dismiss it and then defend it again. Yeah, because the assignee is the person working on it, managing it, owning it, etc. What good is it to list 5 people's names on an issue? If it's just to track it, you can already do that without assignment. If it's just to record "these 5 people are working on it", you can do that with a comment or in a description. If it's for change management, that's what a change management system is for, or you can use the issue tracker in lieu of one by adding subtasks per stakeholder. What issue trackers have you been using? Jira gives you tons of space. Maybe because those are all very different things? Collaboration involves chat, video conferencing, document sharing/group editing, email, using various enterprise systems, etc. Reaching decisions it actually can help with, but whatever. Shipping to customers involves delivery management software, customer support specialists, customer-centric portals, etc. Trying to build one thing that does all of that is insane. Even Microsoft wouldn't bloat up a single product like that. Because an issue tracker is for tracking issues... not... oh nevermind. Yeah, because there is a lot of complex and different kinds of work out there, and building one system to do everything is a bad idea. A carpenter has multiple kinds of hammers. That's not a bug, that's a feature.kevsim|3 years ago
That's exactly the point we are trying make. Issue trackers are good at tracking issues, but now people use issue trackers to track everything, from product development to task tracking, which they're often sub-optimal for.
> Yeah, because there is a lot of complex and different kinds of work out there, and building one system to do everything is a bad idea. A carpenter has multiple kinds of hammers. That's not a bug, that's a feature.
That's the bit I think we disagree on. My co-founder and I have both managed very large teams at large organizations. If you start splitting up everything into different tools, suddenly product is entirely disconnected from development and vice versa. We've seen it over and over where a tool becomes a "PM's domain" and is totally disconnected from the reality of the developers' work.
Now obviously you can make it work with discipline, but you can make anything work with discipline. We think Kitemaker makes it easier for product/development/design by creating one place for them all to meet. I agree that there are different types of hammers, we do not try to replace git/figma/slack but rather integrate with them.
I think we mostly agree at a high level, we just disagree where the split should be between different tools and you don't like the click-baity style of the article (that's fair and we'll try to work on it next time)