Before we sketched Burndown, we sat down and talked about what key philosophies are driving us to make a new tool. What are we looking for in a project management tool that we haven't found? How will we decide what features we should and shouldn't add?

The first big one is: Keep The Big Picture Separate

There are a lot of ways to slice the features of a project management tool. Gartner has a breakdown that includes dependency management, bug tracking, and communication while project-management.com suggests support documentation and document management should be included in the list.

I'm sure there are many more views on it, but for our purposes a project management tool can solve for

• the big picture
• the details
• both

The Big Picture

The big picture covers high level questions like

• Is this particular project on time?
• Are all of the projects on time?
• If not, when are they likely to be delivered?
• How can I fit in this new project? What are the consequences to the projects already scheduled?

You probably don't want to look at the big picture every day, except to briefly make sure things are still going well.

When you do want to answer those questions, what kind of tool would you want? To us, the most obvious tool is a burndown chart: a visual representation of work left versus time. The standard burndown chart has problems we'll talk about later, but we think a few changes can turn it into a simple way to answer those questions at a glance.

In addition, when you're working on the big picture it's important you have accurate and up-to-date information or you'll likely make big mistakes. You may need to share the big picture with people that can't or don't understand the day-to-day work of the project.

Our experience, and the experience of the people we've interviewed so far, is that there's a significant lack of tooling for answering big picture questions. To our knowledge, there are no tools that exclusively solve big picture problems.

The Details

The details are the opposite. It's everything you need to know and want to interact with every day while actually making the project happen. Things like

• What else do I need to do to finish the authentication system?
• Refresh widget after deploy
• Whatchamacallit should only notify users on Thursdays
• Has Bob answered my question about the widget refresh?

You've probably seen a bunch of tools that tackle the details. Maybe you're thinking of JIRA, Basecamp, or GitHub. In any case, you know what it looks like. There's a way to make a ticket/task/todo. You can have a conversation with teammates on the ticket to resolve any questions. There's a way to order the tickets and organize tickets into groups (e.g. sprints, milestones, etc).

When you're working on the details, you don't intend to show it to people that aren't actively working on the project. There's usually too much context to explain to someone that's not fully engaged with the day-to-day work.

¿Por qué no los dos?

There are a lot of reasons not to do both, but I'll cover three.

First, there are already a lot of good tools for handling the details. We use and love Basecamp for tracking todos and communicating about our day to day work, but answering the Big Picture questions (even with their recent "Lineup" feature) is far too hard.

Second, it's our experience that tools that try to do two hard things well don't end up doing two hard things well. It's usually zero things, or maybe one thing if they're good or lucky.

Third, tools that try to do both inevitably end up unintentionally bleeding one kind of thinking into the other. When you're doing the day to day work, it's a waste of time to think about the big picture. If making a new ticket involves potentially assigning it to a milestone, you're making a big picture choice whether you mean to or not. We'd like to avoid that kind of entanglement.

Bottom Line: We need a tool to solve our big picture problems, so that's what we're going to make. I'll talk more about how Burndown will work with details systems in future posts!