Our first post on “tools we use” (Trello & Google Docs for product management) was so popular we’d figured we’d do another one. As with Trello, this major internal process was introduced to UserVoice while I was on vacation

This time we’re focusing on what’s arguably the application the UserVoice team spends the most time in: HipChat.

Technically HipChat is a hosted chat service, but for us HipChat truly is our (digital) office. Since we now have team members spread across two offices on opposite sides of the country it’s important to have a space where everyone can be in the same room even if it’s a digital one. In the various rooms we discuss what we’re working on, have meetings, and of course shoot the shit. We’ve also customized some of the team rooms with automated notifications that help the folks in that room do their job.

So before we jump into lessons learned as we’ve shifted the furniture of our digital office around, let’s first take you on a virtual office tour of our various HipChat rooms.

Virtual “Office” Tour

General Rooms

Our less business-focused, more employee-focused spaces.

Team
This is the hangout where people trade jokes, post the latest cat pictures, and generally toe the line on what HR would approve of (more on that in a minute).

Team SF & Team Raleigh
There are also separate team rooms for each physical office which are used to discuss things – like where people want to go for lunch – which aren’t really relevant to folks on the other side of the country.

Functional Team Rooms

These are rooms for specific functional teams. Only the members of that team are to be in those rooms. A lot of these are self-explanatory but it is interesting to note any automated alerts piped into some rooms.

Design, Marketing, Accounts (aka Sales)
Each of these rooms are fairly self-explanatory.

Engineering
Outside of discussing random issues people are running into it’s also where we do our stand-ups on Tuesdays and Thursdays, our quiet days (quiet days are where internal meetings are forbidden and you’re encouraged to WFH or not distract your neighbor; we use Skype on MWF).

Product
Primarily for discussing upcoming projects and specs. Inhabited by our product leaders: PM, Lead Engineer, Head of UX, CEO, etc.

Support
Our busiest room. Support folks + dev-on-call discuss any questions related to customer support tickets. The sales team is also present, so they can get help from the support team and be aware of any issues.

Ad-hoc / Temporary rooms

The nice thing about a digital office is that it’s easy to spin up a new room for things like:

New Product / Feature Launches
Whoever is running a bigger launch (something with blog posts and PR behind it) invites participating team members to the room. This is typically a cross-functional audience of PM, Marketing, whoever is running the deploy (if there is one, hopefully we’re just flipping a feature flag) or the engineer who built said thing (which is usually the same person), and someone from the customer team.

Crises
Did someone just deploy something they shouldn’t? Did the database server just die? Did someone start a flame war with our CEO on Twitter? We’ll raise the digital war room to discuss.

That’s it! Pretty straightforward. Now to the good stuff.

Lessons Learned

On Minimizing Distractions

Keep 1-on-1 conversations out of chat rooms.
HipChat has 1:1 chat built-in (no need to use another service), so it’s easy to take these conversations out of group chat rooms.

Avoid the usage of @all
Why? Because it’s really distracting and often you don’t truly need to notify everyone. If you do have to use it hopefully you do it in the most relevant team room (this is also why we make sure people don’t hover in all rooms so if you do @all only people that truly need to see it will). We also have a team email list for things that aren't time-sensitive.

It’s okay to log off
If you need to get heads down on something (especially on a quiet day) it’s perfectly okay to log off to minimize distractions. We’ve even looked at kicking people out of the team room on quiet days but we haven’t done it consistently.

Limiting the number of notifications
Live notifications are great but alerts might not be ideal for all rooms.
For example, while our Engineering room receives alerts for Deploy notifications, the support team requested removing alerts for new knowledge base articles from the Support room, and completely removing events for new tickets and ticket replies. Support room is probably our most active room — with support agents and other team members constantly discussing issues. Frequent alerts in this room interfered with those conversations and were regarded as a distraction (and the team is always in the ticket queue anyway).

Have a dedicated space to discuss support issues away from the engineers
Initially, there was no Support room, and support staff posted technical questions in our Engineering room. At this time we also didn’t have a dev-on-call, so questions were not aimed at anyone in particular. This quickly turned out  to be a huge distraction as more than one person would start investigating the issue right away. Having a designated dev-on-call who works with support inquiries of the week, and limiting support questions to support room only reduced the number of distractions for our engineering team.

Social Dynamics

Avoid having rooms for cliques
We’ve had people spin up rooms for them and their closest work buddies. This happened because as the team grew some people felt they couldn’t “be themselves” without potentially offending other folks so they wanted a new place to hang out in. This is now not allowed because we feel it takes away from the banter & energy in Team and starts to create cliques. This lead to another issue (see below).

What’s “appropriate” for the @team room.
Figuring out what is appropriate conversation is much trickier in a startup environment. So far we seem to have naturally become less frat-house-y, but that doesn't mean that folks don't still get offended. So far we're basically self-moderating, but at some point there may need to be official rules in place. It's probably the most fragile part of this setup, since folks don't always think before they chat.

Fostering Better Communication

Make sure that if you need something you @mention someone
If you don’t mention someone then you’re essentially saying “I hope someone sees this but if not then that’s okay too”…you could just be talking to yourself. If you actually need to talk to someone, you @mention them. If you’re not sure who to @mention, try one person first and then another person if that doesn’t work out. Avoid @mentioning multiple people at once if it’s possible you only need 1 of them.

Never report bugs in chat rooms.
Proper channel for reporting bugs is our bug tracking system (Trello). This rule is hard to obey People still often pop into one of the rooms and share their excitement of finding a tricky bug.

Use away statuses
If you’re away from your desk (lunch, meeting) or busy (phone call), update your status to Away or Busy so that people are aware that you might not respond soon.

Requests for feedback on big things should be done via email
Chat rooms are great for collaborating with co-workers who are currently working on the same project as you (or are expecting your interruptions). It’s quicker than email and probably the next most “natural” mode of conversation after phone call. However, chat is a bad idea if you’re simply seeking feedback on a project you’re currently working on (unless it requires immediate attention). Email is probably a better channel to ask for feedback.

Not a place for heated debates.
Hipchat is good for information transfer, but (as with any textual web medium) it can get pretty heated during a debate, with no physical cues to work off of. If something is controversial, it probably needs to be taken offline.

Just do it

The biggest lesson learned was that the best way to enact big change like this, for us, is to just do it. The team signed up, sent the link around, and within a day said “ok, this is the new spot”. It threw me for a bit of a loop when I got back from vacation, but it avoided the awkwardness of official discussion, debating, etc.

Is HipChat right for you? That's going to be very determined by your company culture, number of employees, locations, etc. We've found it a great way to stay connected to our teams and our customers, and I hope this post will help you if your team decides to give it a try.

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.

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

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.

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

How the sausage is made

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

• Next Up
  • Prioritized list of all cards vetted and ready for design & development.
  • It’s worth noting that as a engineer or designer you’re not required to take the top card off the stack but rather the top card you feel most apt to handle.
• In Progress
  • These are the cards that are under active design or development.
  • Once you take a card you “put your face on it” (assign it to yourself). Dev etiquette is that you should never have your face on more than 2 cards at a time: 1 major project and 1 minor.
  • When an engineer takes a card they assign a due date on it to let others know the “expected” delivery date of this card to QA. A quick scan of our board tells me that this rule is more aspirational than executed upon.
• QA
  • When the engineer thinks they’ve completed the story, they’ll deploy it to staging (or sometimes to production but hide the feature behind a “feature flag”) and drag the card to QA.  At this point it our QA manager and Head of UX are responsible for taking a look and verifying that everything looks okay for this to go live.
  • As mentioned previously, If the card is an enhancement project that’s quite large we’ll spin up a whole new board dedicated to issues that came up during QA of that project. The project card will stay in QA until all the cards on the project specific QA board are done.
• Launchpad
  • These cards have been reviewed by QA and are ready to be deployed (but not necessarily launched, but more on that in a minute) and there’s probably a GitHub Pull Request associated with it (which will be merged into master by the person that opened the pull request. It’s worth noting that there is no central chokepoint for merging into master: everyone can do it).
  • If the card is a bug or refactoring task it will be deployed to production immediately (but not after 3p PST unless you, as the deployer, are willing to be around for the next 90 minutes to monitor any issues that come up).
  • If the card is an enhancement then it will be deployed to production but will be hidden from end-users by a “feature flag”. Feature flags are named conditional bits that can be turned on, on a per-account basis, to grant access to the new feature. We’ll immediately turn it on for our own UserVoice account and any customers selected by the customer team for early access but otherwise it falls to Marketing to turn on for all accounts when it’s officially launched.
• Live (Week #)
  • These cards have been deployed and are no longer hidden behind feature flags.
  • The only people who move cards to “Live” (essentially our Completed list) are the Product Manager (for enhancements) and the Bug Reporter (for bugs). This helps ensure that the feedback loop is completed before cards move out of sight.
  • Each week has it’s own Live column so we can track what got launched when.

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

• Bug
• Staging – Deployed to staging
• Production – Deployed to production

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:

• Product Roadmap
  • This has all the major projects for each quarter looking roughly 3 quarters ahead. These big projects are moved to the Planning board once that quarter begins.
• Inbox
  • There are two columns on here: one for ideas from anyone in the company and another for customer ideas (related to UserVoice Helpdesk support tickets or ideas submitted to our UserVoice customer feedback forums).
  • The ideas on this board are reviewed once a week during our Inbox Review meeting (see below for more details).
• Bugs
  • There are 3 columns here:
    • Inbox – unvetted reported bugs.
    • Needs input – We’ve had issues reproducing the issue and the original reporter needs to provide more info.
    • Accepted – Yes, this is almost most certainly a bug.
  • If a bug moves to Accepted and is considered “Critical” by the customer team (you can see how we decide that by reading our critical issue escalation process) then it moves immediately to the Current Development board and the “dev on call” is alerted.
  • If the bug is not critical it stays in Accepted until the Head of Customer Service moves it into the Next Week column which is the bugs that will be fixed next week (duh). The caveat is that he’s only allowed to pick 7 bugs per week. Why only 7 you ask? Because there are always bugs and the customer team always wants them all fixed but one of our major learnings was to set a constant throttle of how much time we’d devote to (non-critical) bug fixing.
• Engineering
  • We keep a list of areas that we think might need refactoring.  Each list is a category (eg, Backend, Frontend, Tests, Infrastructure), and each card is a refactoring project or other non-customer-facing project.
  • Engineers take small cards when they feel like it and add them to in progress; larger cards need to be planned in the Next Up list

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

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

• Next Up
  • This is our roughly prioritized list of the next projects we want to spec out for development
• Spec
  • This means “someone needs to write a spec”. The card at this point is usually just a rough idea.
  • We use Google Docs for specs and heavily rely on contextual comments to asynchronously discuss any contentious points with other members of the team. Any sufficiently complex contentious concept will be fleshed out in an impromptu design meeting (more on this in next section).
• Design
  • Means that the card needs a designer to take a look at it, duh. This doesn’t necessarily mean that a wireframe or mockup will be made as the design stage isn’t just about the look of it, but very much about taking the spec requirements and ironing out design concepts, usability, workflows, and impact on existing functionality – essentially vetting it and hammering out any show-stopping kinks before it goes into the dev cycle. (Also, if the spec needs to go back to the drawing board, it’s sent back to the Spec list.)
• Ready
  • We have spec that’s been reviewed by the idea creator and by the design team. We optionally have a wireframe or other needed artifacts. This is ready to be moved to the Next Up column on Current Development (after it’s reviewed at the Product Planning meeting).

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:

• Monday morning – Product Meeting (30 mins)
  • Attendees: Everyone in the company
  • This is our big all-hands meeting designed to make sure everyone knows what’s going on with the product and to celebrate the work of our product team members that went live. Our PM runs this meeting and it’s the only meeting that has a presentation built for it.
  • We’ll use one slide to review all the bugs that were fixed last week with avatars to show by whom. There’s a sense of pride of seeing your picture next to a big list of bugs fixed.
  • Each enhancement has its own slide that includes the avatars of all people involved in the project, the number of points this project was worth and a screenshot or (increasingly) a video. Whoever worked on an enhancement will take 20-30 seconds to explain what exactly was built.
  • PM or CEO present any new projects moved into Next Up and provide insight into what these cards are and why they’re a priority (the business case).
• Friday morning – Inbox Review Meeting (30 mins)
  • Attendees: PM and Head of UX – mandatory; everyone else – optional
  • If you submitted a card to Inbox board, in either the Customer or Internal column, you are expected to attend this meeting and introduce the story behind the card (you can learn more about how we think customer feedback processes should work here).  The goal is to help the rest of the team understand the associated use cases and pain points. In order to make sure we’re looking at the most pressing issues of the week, we limit the number of cards per person to 3.
  • The key to keeping this meeting focused: solutions are not discussed, only problems.
• Friday afternoon – Product Planning Meeting  (1 hr)
  • Attendees: CEO, PM, Head of UX, Lead Engineer
  • The goal of this meeting is to review all cards from the Planning and Engineering boards ready to move to the “Next Up” column on the Current Development board. For each card we move we’ll make sure there are no outstanding questions or concerns and we may discuss what the next step is (ex: do we need to build a prototype first?). Once all the “ready” cards are moved to Next Up we’ll re-sort the entire Next Up queue according to priority (yes, even cards that were at the top of the list last week may now be moved to the bottom).
  • We’ll also assign a level of effort estimate to each card. We measure the effort in terms of easy (1 star), medium (2 stars), hard (3 stars). This estimate is based on previous experience (as a company, not individuals): have we done anything similar before, how familiar are we with this domain, do we have any in-house experts, etc. We’ll use the cards to give engineers a sense of how much work is beyond this card and also we use it as a signal to the rest of the team how big of a deal a card is (during the product meeting) and to celebrate progress.
  • Finally we’ll review all the bug cards the customer team promoted to “Next Week” status. If a card doesn’t have enough info or if it’s going to take significant development time (more than a few hours) we won’t move it to “Next Up”. All cards we do move to “Next Up” go to the top of the queue before everything else. Above all else we want to make sure we’re always fixing what’s broken first.
• Every morning – Standup (10 mins)
  • Attendees: All product team members (designers, engineers & QA)
  • We do these over Skype MWF (we have two offices) and via HipChat on T-TH (our “quiet” days where no internal meetings are scheduled).
  • We try to drive standups to be discussion of what people need to accomplish their task rather than a boring “I did this; I’m doing this”.

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?