Not too long ago, the product team at Vox Media was a single, small group of folks collaboratively doing all the things. Today our situation is much different. In the last year alone the product team has grown by nearly 200%, and even 18 months ago both The Verge and Polygon were just twinkles in our eyes. Since then, we’ve launched both sites successfully, and gone through a major redesign and rebrand of SB Nation and its 311 communities. We’ve had to quickly adjust and scale our operation in order to meet the demands of a growing company with many concurrent projects across many teams.
Today we find ourselves nearly 40 people deep, including developers, designers, operations engineers, support, product management, and interns. Those 40 people (and growing) are broken up into six cross-functional teams: one for each of our core brands — SB Nation (which itself is broken up into over 300 individual brands), The Verge, and Polygon — along with a platform team to focus on Chorus (our modern media stack), a (technical) operations team, and an advertising products team. Each one of these teams has resources dedicated to help them achieve their goals, keep the sites running smoothly, and innovate with new features.
Even though we’re organized as separate teams, each is deeply collaborative with one another. Not only is it in our DNA to be this way, it’s an essential requirement as we all share the same platform, and things developed on one of our brands is often rolled out to others as they become available.
To keep things running smoothly in this type of environment, using the right tools is important. Over the years we have tried a number of them: FogBugz, Trello, Agile Zen, Sprintly, Scrummage, BugWire (our first Rails project ever, circa 2004), Google Docs, and likely many others lost from recent memory.
How we came about using (and creating) the tools we settled on and use today has been an organic process; over the last several years we have spent time evaluating and discarding various softwares, taking note of things we like and dislike from each. In the end we found ourselves using a combination of both Trello and FogBugz, along with Beacon — a custom tool we created to organize our sprints, bug queue and production deploys.
Trello for product management
Trello is where ideas begin and grow. Often the best ideas are imagined and brainstormed while not in front of project management software — a conversation might happen while passing someone in the hall, or during a happy hour, over instant message or email. Trello makes it easy to get those ideas into a backlog and keep them organized and prioritized without much effort.
Further, ideas are rarely fully fleshed out at inception — they take time to incubate and grow to become the polished features they are when they hit production. Trello is where those ideas are built upon collaboratively, with stakeholders of all kinds adding to the requirements, brainstorming concepts, attaching wireframes, and helping to bring the idea to fruition.
Most importantly, Trello is easy to use and understand. It’s not a complex bug tracker or sprint planner. It’s interface is logical and simple to modify.
Our structure is pretty simple: we have a product-related Trello board for each one of our teams. Trello is fluid enough to let each team use their own lane structure and workflow for requirements gathering and prioritization. In a world with wildly different editorial teams, forcing everyone to use the same rigid structure for product management would be difficult. Trello let’s us organize ourselves in specific ways that are important to each individual team.
We don’t do project management in Trello, however. That is, when something is ready to be worked on by a designer or a developer, our product managers take the cards from Trello and write out user stories and tasks in FogBugz for development.
Fogbugz for project management and bug tracking
FogBugz is where shit gets done.
Why not use Trello to track the project development as well? We switch to FogBugz as it allows us to group user stories and tasks into explicit objects which can be assigned to individuals and milestones. These user stories have tasks that can be given independent status updates and tracked — something Trello doesn’t do with as much granularity or with a fixed workflow. Even though Trello has a variation of many of these features, any project of notable size or complexity can get messy in the lane and card-based system that makes it so easy to use in other cases. Out of all the tools we’ve used over time FogBugz made the most sense for large projects or otherwise intricate sprint work.
FogBugz also makes it easier to organize our particular project methodology. Generally speaking, we begin large projects by writing epic user stories to communicate the big picture, which are then broken up into smaller, discrete chunks of work. Those smaller chunks are further diced into individual tasks and taken up in priority order. While it would be possible to handle this workflow in Trello, our attempts at staging the work there have been messier and harder to organize than FogBugz.
Finally, we use FogBugz to track bugs and handle our incoming support queue — something Trello isn’t really designed to handle. Bugs come in through email and are handled by our support managers, who communicate back to the submitter and eventually file it away into the appropriate queue to be squashed.
As powerful as FogBugz is, it’s not all roses and unicorns. Its biggest negative (and, I suppose, positive) is its complexity. (For example, Fog Creek offers FogBugz training for $250 an hour.) It’s built to manage large, complicated projects (and track bugs!) and it’s not well suited for communicating the status of a project to people who aren’t a part of the product team. In fact, we found FogBugz so unfriendly in that respect that we decided to spend time building a friendly layer above FogBugz that (among other thing) simplifies the interface and gives a stakeholder a big picture view of what all teams are working on without having to dive into the intricacies of FogBugz. Enter Beacon.
Beacon for transparency and organization
Beacon is a custom internal tool (built at VAX ‘13 by our Director of Engineering, Michael Lovitt, and myself) that serves many purposes.
First, it’s integrated with the FogBugz API to provide insight into all past, present, and future sprints across all of our teams at Vox. It lets the stakeholder get a glimpse of what each team is currently working on, what the overall progress of each sprint is, how many tasks remain, and when it will be released into production — all without needing to dive into FogBugz.
Second, it’s a deploy scheduler. Our developers use it to schedule deploys to production, associate deploys with sprints, and otherwise stay organized when there are five teams deploying hundreds of lines of code to the same application every day. (In the future, we very well may use it to actually deploy, but for now that’s done via Capistrano at the command line.)
Finally, it’s bug tracker. All of our support requests for each of our properties (from both external users and internal staff) land in FogBugz, where they’re dealt with by our support managers. If the incoming request is indeed a bug that needs to be fixed, it gets filtered into the appropriate FogBugz milestone, which Beacon is configured to associate with the proper site. So our staff is able to check and make sure bugs they have submitted are either in the queue to be fixed, or that they’ve already been fixed and are either waiting to be deployed or already in production — all without logging into FogBugz.
This is what we use today, but who knows what the future holds. As we continue to grow and refine our processes, it’s likely our tools will evolve as well.