Breaking It Down

You can’t ship what you don’t understand.

I imagine your background doesn’t really matter, breaking down projects into attainable goals is a deceptively hard skill to master. Grouping tasks into digestible chunks may seem simple enough, yet I’m routinely reminded how difficult this idea can be.

It wasn’t until I joined a product team that I found that my perception didn’t line up with reality. Recently I was working on new project. Like any project, grand visions filled my head of the possibilities. This was going to be project that redefined every project hereafter. This was going to set a new visual direction. This was going to fundamentally redefine us as a company!

And… none of that happened.

Instead a project that should have taken a few weeks turned into almost two months of frustrations upon frustrations. Finally we pushed something out, but it missed all the grand visions we had. No one thing doomed our project. Instead our struggle to gain agreement on the problem, solution, and project scope meant the team didn’t always see eye-to-eye. Project planning may seem like busy-work, but by taking a few simple steps, you can help your team stay in sync as you work together.

1. Before you come up with a solution, figure out your problem.

It seems pretty simple, but how many times have you started a project without clearly stating the problem? If a team can’t agree on the problem, then how are you going to agree on a solution? Clearly articulate the problem you are trying to address. If your problem is a fairly large one, state the overall goal and then break it down into sub-problems that can be addressed individually or in groups.

Currently the Stack Overflow Careers product team is in the middle of fairly large project. This is a problem that we’ve known about for years, yet no one wanted to tackle it because it was so big. Finally, we couldn’t push it off anymore. We had to deal with it. Yet to avoid getting lost within the complexities and minutia of this huge problem, we start by writing down our over problem and any sub-issues as well. Here’s an example:

The regular tasks user’s must utilize to manage their product are kept within different areas, some hidden within modals. These tasks are daisy-chained together, offloading the navigation onto the user to remember where things are kept instead of creating an intuitive tool which can manage their product. Besides the extra mental effort it takes to use this product, other adverse effects include feature ignorance, increased user frustration, more maintenance work for the product team, and the sales team most act as customer service representatives with their clients.

As you can we, we have a big problem. There may be trepidation is writing out your problem so bluntly, as if it may be a reflection upon yourself or your team. Until you can clearly state what’s wrong, you’ll never begin to address it.

2. The solution should match your problem’s size.

Once your problem is defined, now comes the fun part: the solution. Before you get too far though, remember that your solution should fit your problem’s size.

What I mean be that is if your problem is to add a search filter, your solution shouldn’t start with redesigning the page. Conversely, if your problem is to address website’s navigation, your solution shouldn’t focus primarily on the navigation’s visual treatment when the problem might be an organization issue instead. Using our problem statement approach, here’s the solution we came up with:

The goal of this project is to centralize the user’s tasks into one area within the product.

It’s not a world-changing statement, but it addresses the problem: things are scattered right now. The solution? Bring it all into one place. How does this actually break down into your daily tasks? We’ll look at that next.

By writing down your proposed solution it can help give your entire team a point to work toward. Also as you move further into a project and your surrounded by details, it’s easy to forget the overall goal your striving for. Having something written down creates an artifact for your team to reference throughout the process to keep from straying to far into the weeds.

3. Break it all down.

Once you have a problem and a solution, now you need to implement it. This is where breaking down tasks comes into play. Every team should figure out a rhythm that works best for them. My team has found weekly goals suits us best. Weekly goals provide just enough room for us explore implementation ideas, loop in team members, and keep a project moving forward. It allows for personal autonomy while still providing team accountability.

When setting our weekly goals, we start by asking ourselves, “What can we realistically get done this week, given everything else I may have to work on?” We try not to think beyond the current week. Doing this allows ourselves room to adjust as we learn new things.

This approach isn’t any different from many agile-like methodologies out there. Some use a Kanban-style or more traditional agile style. Instead of getting caught up in executing an exact process methodology, find one that works well for your team and build upon that.

4. Review often.

We rarely get things right the first time. Teams are made of people, and people get things wrong… a lot. To keep from making the same mistakes, it’s important teams hold regular retrospective meetings. During these meetings, talk about what’s working in your process and what isn’t. Talk about areas where the team is performing well in and where it could perform better.

Candor isn’t cruel. It does not destroy. On the contrary, any successful feedback system is built on empathy, on the idea that we are all in this together, that we understand your pain because we’ve experienced it ourselves. The need to stroke one’s own ego, to get the credit we feel we deserve — we strive to check those impulses at the door. — Ed Catmull, Creativity Inc.

Honesty and candor are important virtues within these meetings. A team is working to a greater goal together. Team members should have empathy for each other, understanding that we have all experience these issues before and our goal is to move the whole team forward.

Breaking down problems into manageable tasks helps your team to keep the overall project moving forward. Understand your problem, agree on your solution, discover how your team work’s best, and keep working at it.