If you're building an app or website, you're likely using a tool to manage the process, such as Basecamp, Trello, Pivotal Tracker, GitHub Issues, or Sprintly. Some teams use a combination of these (one for big picture planning, one for specific tasks, for instance) and also incorporate more specific apps like InVision for design feedback.
Each of these has its own approach to tracking tasks and progress, sharing images and documents, and enabling discussion. Once you choose the best tool for your team and establish a workflow, you can turn your focus to building great products.
A few months later, it's common to encounter increasing frustration with your choice and start to wonder if you made a mistake. Conversations start happening in other tools, a Google Doc becomes the de facto backlog, and people start adding work to the project tool after they've finished it. I've had this experience many times over the years, with a variety of products and team sizes.
In these moments, changing the tool is rarely the right decision. I've seen teams fall into a cycle of evaluating, choosing, trying, and discarding tools. We blame the tool for what are really team issues, dysfunctional processes, or simply a failure to be persistent and consistent in how we use it. More often than not, changing how we define features, discuss them, make decisions, and communicate is what's required to improve things. The tool has only shined a light on something we'd rather not face.
That said, I've recently become convinced that it's time for these tools to evolve. They do an excellent job of providing a centralized place for project tracking and discussion, but there's been little innovation outside of increasing flexibility (for example, making it possible to group tasks in different ways).
There's a missing piece. These tools are enabling discussion, but they're not helping with decisions.
What needs my attention?
In a large project, conversations are spread across hundreds of tasks. One person may be responsible for a task, but the discussion is where decisions are being made: from defining the feature initially and finalizing copy to debating design and implementation details. Inboxes overflow with notifications about these conversations, but unless you respond in realtime, it's very difficult to know where your attention is needed. Which update was just to keep me the loop, which is asking for my opinion, and which is waiting on my decision? Every comment is treated the same as every other comment.
What was the decision?
The result is that the only way to find the actual decision within a discussion is to read the discussion. Making it possible to revisit the reasoning behind a decision is a great thing; requiring that someone read through the debate about button color and placement to find the moment when an option was chosen is silly. Offering the ability to close a discussion or mark it resolved is of little use if the resolution isn't clearly documented.
Whether the discussion is tied to a feature or page, or something smaller, it's common to have multiple questions and answers in the conversation. Sorting through this is a time-consuming challenge. Are we waiting for someone else to vote? Which decisions have been made and which are still being debated?
The result is:
- Time wasted going through every discussion and image or document someone was notified about to see if they need to comment
- A lot of people chiming in, but little clarity on decisions
- Too much notification noise, making it easy to miss critical updates
- The true status of a task is hard to discern, as the complexity and outstanding issues are surfacing within the dicussion
There are manual processes that help with each of these things. You might make sure that a story or task is small enough that lengthy discussion and multiple questions are unlikely. Anytime a decision is made in a thread, you could add special formatting and update the beginning of the topic, the story description, and/or the original spec.
But our tools should be smarter, too. Choosing who to notify on a comment is an example of a helpful bit of flexibility that does little to solve the underlying issue. It isn't any more effective than it is with email threads; there's no clear responsibility and people tend to err on the side of including anyone remotely involved.
A few ideas:
- Add different comment types, such as Question, Answer, and Vote
- If someone wants to quickly survey the team about something, provide a simple thumbs up/thumbs down interaction and vote tally, instead of the weight of 8 different +1 comments and notifications
- Provide the ability to assign a question to someone within a discussion, while adding others who need to be aware
- Require a summary when a question is marked closed or resolved, which is displayed next to the question, with the discussion hidden by default
- Provide a dashboard view of discussions that are in progress, prioritizing those that are awaiting a decision, as well as ones that require a response from you
The next evolution of project tools might be found in one of the current offerings, a product already focused on team communication like Slack, or an entirely new app. Whichever it is, I can't wait.
Note: This is just a start. There is much that could be done for product management generally, from improving the spec process to shepherding an idea through definition, writing, design, development, testing, releasing, and sharing. If you and your team have come up with clever solutions to these sorts of challenges, whether manual or technological, reach out on Twitter or by email. Also, if you work on a project tool and want to talk, I'd love to lend a hand.