574 Flares 574 Flares ×

Last fall I returned from vacation to find that UserVoice‘s Product Manager, Dejana, had replaced my precious Google Doc “Roadmap” with a Trello board.

It should be noted that my initial reaction to this new process was not positive. My issues weren’t really with Trello but rather how we were using it. Trello is a VERY open ended product. Trello, purposefully, doesn’t prescribe a “right” way to use it so it requires you to get inside and move the furniture around a bit to get it feeling like home.

However after much experimentation, I think we’ve finally arrived at a process we’re very happy with and I thought we should share how it works and what we’ve learned along the way. This will be a longer post than usual and, if you’re not into the process of delivering web products, probably a bit dry. If you prefer to skip directly to our lessons learned, I’ll be sad but not offended.

Our Process

Our development process spans 6 different Trello boards. The focal point of all of these boards is the Current Development board. The goal of all the other boards is to feed cards (representing either an enhancement or a bug, more on these in a minute) into the Current Development board and specifically into its Next Up column. The Next Up column is THE single prioritized list that all of the product team (developers & designers) looks at when they’re ready to take a new card to work on.

UserVoice product process

Before we dive into the role of all these different boards let’s talk about the blood cells in our product development circulatory system: Trello cards.

Cards

UserVoice Trello card

A card represents a single story to be implemented. It could be a new enhancement, a refactoring task or a bug.

Enhancement cards start out as a simple idea, 1-2 sentences long. But before they can move in development they’ll be expanded to include a link to a full-blown Google Doc “spec” and a set of wireframes or (rough) mock ups.

We use the term spec fairly loosely here. These aren’t the specs you remember from your college project course or that crappy enterprise IT consulting company you worked for right out of college. The spec explains the high level customer story, why (from a business perspective) we’re addressing this, what we hope to achieve, and maybe some notes on suggested implementation (though engineers may take or leave this section at their discretion; it’s supposed to be helpful not prescriptive). A good spec will also include first-hand customer stories and a link to the related idea on our UserVoice forums.

If the card is a bug then it simply has steps to reproduce the bug (which hopefully includes a screencast) and a link to the UserVoice Helpdesk ticket that originated it.

UserVoice spec

Here’s an example of what an actual “spec” looks like.

How the sausage is made

UserVoice current development Trello board

The Current Development board is the “where the magic happens” board. It has the following columns:

In addition we use 3 labels that can be applied to a card:

That was easy right? It’s very much a Kanban style approach to development. Now let’s dive into how cards get onto this board in the first place.

Mommy, where do cards come from?

New cards can come from one of 4 different boards:

Who said central planning doesn’t work? (Planning board)

UserVoice planning Trello board

The Planning board is where myself, our PM, and head of UX spend the majority of our time. It has the following columns:

On every other board cards move almost exclusively only from left to right but not on the Planning board. It’s not uncommon for a card to go from Design or Ready back to Spec one or more times before it’s finally moved to Current Development.

Our Meetings (or How cards get to moved between Boards)

We only have a few regular product meetings per week:

That’s all of our “official” regular meetings but it’s worth mentioning that myself, our Head of UX & PM will often have impromptu 3 hour meetings where we have in-depth design discussions spanning multiple cards on the Planning board.

These impromptu design discussions usually happen later in the week (Thursday/Friday) once it’s clear there’s a difference of opinion on a couple cards we’ve been working on. These are some of our most productive (and for me: most fun) meetings that we have. Outwardly they may even seem less than productive as we often end up coming full circle on a design decision and end up right back where we started. But really it’s a (positive) sign that we truly understand the trade-offs we’re making with the path we’ve chosen: we’re making a decision from a position of understanding rather than blindly rushing in.

Lessons Learned

Always @mention someone in a card comment if you actually want a response :)
If you write a comment without mentioning someone then that means you just meant this as a footnote for yourself for later. If you actually want someone to pay attention, you need to specify whom.

Have a single prioritized list for the product team to work from.
Initially there was a column of prioritized cards for each area of the product (admin console, onboarding, widgets, iOS, end-user web portal, emails). That might work if we had separate product teams for each subsystem but we don’t and it just lead to confusion about what really should be the next thing people should work on. It also was very unwieldy to look at and figure out what exactly the team was focusing on. (Protip: if you find yourself using a horizontal scrollbar often in Trello then you’re probably doing it wrong.)

Don’t have a separate system for bugs
Initially we maintained our previous bug tracker and used Trello for new product dev. This became problematic for many of the same reasons that the multiple columns failed us: once we have more than one list then prioritization breaks down.

Have a set amount of time per week that will be spent on bugs
We have roughly achieved this by setting a limit on the number of bugs we’ll accept into Next Up per week. This was a bit contentious at first but has resolved a lot of strife about whether a bug is worthy. The customer team is now empowered (or burdened) with choice of choosing which cards will move on. It’s the product development version of the Hunger Games.

Only add new cards to (and re-sort) the Next Up column once a week
This prevents Next Up from becoming a constantly shifting sand dune. Once the new projects are presented during the Monday morning you know where they are in the queue for the rest of the week. You don’t have to worry about the project you wanted to do falling to the bottom of the heap (and thus not actionable) in the middle of the week.

Good specs tell the (customer) and business story rather than act as an implementation recipe
For everyone to give a project their best they really need to be sold on why they’re doing it. This means trying to bring the customer pain point (or business pain) to the engineer that has to fix it.

Don’t try to do project estimates
Before, when we did actual sprints, we’d spend a LOT of time (almost a whole day per 2-week sprint) doing estimates and planning in a futile attempt to draw a line and say “We’ll get through all of these cards in the next two weeks”. It was a lot of work and it was almost always wrong anyways so instead we decided to embrace the uncertainty.

Try to celebrate what gets deployed
It’s easy to put people on a treadmill where there’s always something else to work on. We create a separate column for the cards that went live every week so it’s clear what we achieved this week. We also have the pictures of everyone who finished a task and a screenshot as part of our Monday morning meeting.


I hope you’ve found this useful. It’s one of those things that you evolve over time to the point at which every point in the process seems almost obvious but clearly isn’t. Well-deserved kudos to Dejana Bajic (PM), Joshua Rudd (Head of UX), and Jonathan Novak (Lead Engineer) for building such a solid process.

So what’s your product development process? What tips or hard lessons learned could we benefit from?