Most of the points raised in the article are opinions based on a limited understanding or use of issue trackers. For example:
One can easily ask, "why can’t issues represent outcomes?" They can, but they are not designed for it
Issues typically have only one assignee.
They don't give you ample space to describe the problem and solution
Issue trackers focus more on metadata and workflow than on supporting the team in collaborating, reaching decisions, and shipping to our customers
Some issue trackers will even actively suggest scoping issues to be as small as possible, which is the opposite of what a sound product development framework will suggest
First, we should be aware of the shortcomings of the issue tracker. [...] The challenge is that you will end up tracking work in two systems.
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)