Ask HN: Do you need a new Issue Tracking and Project Management tool?

Developers I know typically like something simple, flat, and issue-focused. Think GH issues.

PMs tend to want more feature rich tools with advanced reporting and customizable views. Think salesforce.

Product owners (I haven't had many) just want to know "are we there yet?" and will rarely open any tool or learn how they work - they just badger the PM via email or in meetings.

My problem isn't that there aren't tools that I like, its that there aren't a lot of tools that can be "all things to all people."

If a tool was built on something simple (GH Issues) and added a layer of complexity on top for PMs I think you'd have a winner. Waffle (waffle.io) is going in that direction, though they aren't heavy in the PM tooling area yet(?)

In the end, I want an open-source tool with a focus on easy customization with plugins and custom solutions through code itself.

First I planned to make it as a desktop app, but then I realised desktop apps are thing of the past and nowadays you need to make web apps to be accessible and portable.

Then I got demotivated by the number of great and established products.

Now I'm trying to figure out a new (developer oriented?) product to develop in my free time.

It's tough not being among the first at something.

My current employer uses Jira, and I find it to be decent. I've used Asana in the past, and I like it a lot, but it has its own holes and pain points. Same for Pivotal Tracker, Github issues, Redmine, Bugzilla... Every tool I've used has had some strong suits and some drawbacks—mainly related to how well it fits with the project and workflow. A big plus is if the tool has a good API (REST, plugin, etc.) so that I can easily write tooling to reduce friction.

Unless you can find a really strong selling point—and I don't think offline support would qualify, for most people—I don't see it getting much traction.

There's a lot of folks taking on the large scale software space, however I think the non-technical space is still a bit wide open. I think a new Basecamp would do well.

EDIT: Not trying to dissuade you, I guess what I mean is that if you're going to do it you should do it because you're in love with the idea and think you have something new to offer (and can clearly elucidate the problems that other systems don't solve, but yours does)... not because it seems like an easy way to make money. (Which I guess holds true for any business.)

Productivity tooling is a very crowded space. And building you own issue tracker is the very height of yak-shaving. That being said, there's always room for new ideas. I don't need a new tool but I'm building one nonetheless because the solutions that exist now, IMHO, miss out on some really neat ideas. So my side project is more of an experiment, trying to tease out some new UX ideas, rather than a utility to aid in building other projects.

If you need to build some other thing, just use existing tools. Focus on the real work, not the "meta-work." If you think you can make headway into the crowded arena of existing solutions with some out-of-the-box idea, go for it. But don't mix up the two, cause you'll never get anything done... which is the opposite effect a Project Management tool should cause.

TL;DR I'm always looking for new tools. But don't get stuck yak shaving.

Further, a tool that tracks the resolution of issues into a simple to read 'This was just deployed' or some kind of digest would be insanely useful. It's not an easy task, but so often someone is waiting for a fix, or waiting for a feature, and then gets upset or something gets overlooked because they didn't know the feature/bug was deployed.

Something simple, with an app-store style approach to customization could be really handy.

My opinion is that nothing that currently exists really solves the whole problem of information management well (aside from git). Most teams mash together three or four different solutions for strongly related problems. Some teams are as bad as: gitolite for central code repo, a bug tracker for managing issues, a spreadsheet for managing who works on what features, a separate bug tracker for issues found in QA, personally-managed to-do lists for each developer, a Trello, a dozen bespoke reports for status to upper management, and all team communication goes through e-mail. Yes, slack and github would replace about 3 of these, but you still have 5 solutions to the same general problem -- what needs to be done and who is doing (or will do) it, how, and when.

Obviously this is a very hard problem, or it would be solved now. I have tried for a long time to decide what I think would be a good solution, and for all intents and porpoises, I have gotten nowhere.

I really like the approach Trello has taken -- provide a simple, flexible concept and let users build it all from there. Obviously Trello doesn't tick all the boxes, but I wonder if some other deceptively simple idea can accomplish it.

I don't know that this is a huge benefit in a work tracking tool. These features are useful in Slack because it's a real-time communication platform. Work tracking systems are more ok with being asynchronous - there's usually a business function that performs synchronization whether or not your work tracking system does, so having everything update across multiple cached versions in real-time is less meaningful.

I would focus on the process - it sounds like you're just building something to build something. What in the process of software development is broken? Is building a new tool the right solution?

Asking people how they feel generally isn't a great way to evaluate your product -- you have to build it and see how they act. You can ask potential customers what features they would like to help guide you, but I wouldn't necessarily add or cut features based on their answers.

The best way to tell if someone needs your products is to just get it out there and see if people actually use it.

Some anecdotes: I was in a focus group once about cell phones, many years ago. They asked us all if we would want a camera in our phone. All of us said no, it wouldn't be worth the extra expense, because we couldn't think of a single thing we'd use a camera on a phone for. It's a good thing Nokia didn't listen to us!

On reddit, check out the /r/ideasfortheadmins subreddit. It is filled with ideas users think they want, including features reddit used to have that no one used.

What I'm saying can be summarized by the (incorrectly attributed to Ford) quote, "If you had asked people what they wanted, they would have said 'a faster horse'".

I think the other main thing that could be improved is integration with other tracking software.

I work in testing. The main thing I see is projects using more than one project or defect management tool. I feel is an area that could be seriously disrupted.

For example... One project I worked, we had the developers (external company) using JIRA, whilst we used Smartbear ALM.

So I ended up writing something that used both the JIRA and ALM API's to save me updating two systems. Imagine if this functionality was out of the box?

Like many (most?) programmers working collaboratively, I have often wished I had the "perfect" issue tracker, but my version of "perfect" maps very tightly to the way I think software "should" be developed, at least among teams of people working full-time for money.

In spite of my natural tendency to be sure, like every good programmer is sure, that my hypothetical solution is vastly superior to all the horrible, slow, confusing, buggy things that actually exists, I am forced to concede that the corporate software world is not following my implied instructions.

So, in all seriousness, I think there are three huge challenges facing the would-be creators of an issue tracker that would be $GREAT:

1. You have to either accommodate a bunch of different workflows and be good at most of them, or commit to One True Workflow and hope you can convince people you're right.

2. Even if you actually do make one that's more $GREAT than anything else, the Enterprise world will not care -- and that's where the only serious issue-tracking money is, so you'd better do this for love and/or have a very long runway. And if you get so far that they ever do care, you'd better have a bunch of data-migration "whitepapers" ready.

3. In order for anyone on a small team or open-source project to switch to your software, you will have to convince them not only that it's better than whatever they're using now, but also that it won't be offensive to people with longstanding allegiances to other software. And making it unoffensive is likely to contradict your definition of $GREAT.

All that said, go for it! You might be your only customer, but if that means you've got the greatest issue tracker in the world then it might be worth it.

I think lots of people are, or could be, but the deciding question is what makes what you are thinking about different? What's the unique benefit you plan to offer?

On my side project I'm using Trello, and for the issue tracking bits, it's not perfect, but it's fine, if there was something better and free I'd use it, but I like that it's SaaS and I don't want to install a native app.

but you're not a startup cto if you use those dinosaur tools. just like you won't use awk or make. because 1. it's not sexy 2. you're too lazy to learn your job properly. 3. nobody gets ridiculed for selecting the sexy tool instead of the right one, but the opposite is almost sure.

-Lightweight -Easy to use -Has a desktop client

Everything is oriented around being cloud driven, complex team-based features I don't need, and just generally being more overhead than it's worth for what I need.

But more importantly, it's a hook. It's what would differentiate you from other issue trackers. It's distributed issue tracking that allows you to take advantage of all the infrastructure that's been built up around the underlying DVCSs. Right off the bat, you have a reason for your project to exist.

- Cross-Platform - well, web based applications all are - Offline - that would be extra value, Trello for example does not offer that

But neither of these two reasons alone would encourage anyone to get a new project management tool.

You need some standalone features or feature a workflow that noone features so far. Focus!

Here are some questions you might ask yourself or the community:

- Do we need an issue tracker or a complete PM? This will determine your target market - For how many people do you need a PM? Single developer? Group of 5? Group of 100s? - Which type of projects do you work on? Software? Marketing? - How does your typical project workflow look like? - Which part of the workflow is still cumbersome, even when using software? - What's the one thing that a new project management tool should me with? - If the new PM tool was to do only one thing, how would you know that it does it perfectly?

You should probably come up with even more questions. Your goal must be to find a use case and a market and find out what pains are not solved yet. The more time and hence money a pain causes, the better you might create a product that sells.