Product management tools typically handle this. Jira Product Discovery and tools like Kitemaker keeps that information close to where the rest of the team works :)

I spent less than 5 seconds in the prompt. Dall-e is quite politically correct, I guess :)

Thanks for the comment. And I completely agree. Incentives shapes so much of how people work. I tried to capture that in the 3rd bullet, but your comment is more on-point :)

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.

The title is definitely provocative; "considered harmful" posts have been considered harmful for a while: https://meyerweb.com/eric/comment/chech.html

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

You raise a point only to dismiss it and then defend it again.

  Issues typically have only one assignee.

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.

  They don't give you ample space to describe the problem and solution

What issue trackers have you been using? Jira gives you tons of space.

  Issue trackers focus more on metadata and workflow than on supporting the team in collaborating, reaching decisions, and shipping to our customers

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.

  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

Because an issue tracker is for tracking issues... not... oh nevermind.

  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.

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.

> Because an issue tracker is for tracking issues... not... oh nevermind.

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)

Thanks for your feedback! What about task trackers do you think we fail to articulate very well?

We try to explain how the design of issue trackers fail to address the needs of how best practices of product development are described by certain authors (Marty Cagan, John Cutler, etc.). I think we support everything you mention here, but at the same time removing some of the hurdles that many teams experience in getting an empowered team to work well together.

Just like every issue tracker. The distinction is nonsensical to me. They are all item trackers. You define what the items mean to you; not the other way around.

I've used everything from post-its, spread sheets, text files, jira, and all the rest. It doesn't matter what you use; just how you use it.

What I value is low friction usage. It's why I hate Jira because all the key operations involve modal pop ups and a generally high level of friction, lots of waiting for stupidly slow APIs, etc. Sucks all the momentum out of any meeting where you want to focus on content rather than stupid tools. What I explain in 3 seconds shouldn't require 3 minutes to mirror in the tool. It's what I love about Asana. Because it's just type, enter, type, etc. to create issues. Multi select with the arrow keys or control clicking, and boom labels, assignees, etc. added. That's low friction.

GH issues strikes a good balance. Create a ticket, add some checkbox list, convert individual list items to issues by clicking them. Nice. Could be better but it works.

I have zero experience with Kitemaker, so I'm not going to criticize it. But to me it looks like just another tool. What's so great about it? The article just descends into a nonsensical and completely artificial distinction between issues and goals. Why not do both? Why have two tools? Sounds like friction to me. Or impedance mismatch.

I promise we know a great deal about what we're talking about in this case :)

Well sure, but by co-opting a strategy used by people who don't, it doesn't paint the best first impression.

Thanks for you comment! Gitlabs issue tracker is one I'm not super familiar with. There are definitely other popular and well-known issue trackers which would, by design, make it harder than it should be.

Thanks for the feedback! Great point!

Thanks for your comment! The main point we wanted to come across is that issue trackers are _not_ designed for best of practice product development practices. Still, teams use the for product development, and there are challenges to that.

Using issue trackers to track bugs is great.

That is a great way to frame it!

And yeah, the title was written in a way to be a bit provocative, but also pointing at that many (maybe most) teams use issue trackers for their product development flow.

Trouble with the title for this site is that a very significant fraction of the users will approach it from the open source perspective where bug tracking is what you want. :-)

I might perhaps title it “bug trackers aren’t good for tracking work” or “bug trackers aren’t good for product development workflows”. I like literal and direct (and often verbose!) in my titles.

Yeah, that is a great point!