Here at Signal Sciences, our development teams are broken down into what we call “bands,” who each own a theme. (My band, Run-DMC, handles Domain Management and Customization.) Bands set their own cadence and processes. Some bands do daily standups, while others do them twice a week. Most track work with Zenhub, while others use a spreadsheet.

While every band is different, we all follow a cohesive workflow among product, design, and engineering that allows us to launch features quickly. This year alone we’ve launched over a dozen new product features, from a revamped user management system to new tools to view and filter security events. Below, I’ve broken down how we’re able to do this.

Value autonomy, ownership, and communication

We’re a highly autonomous group of people. It’s one of my favorite aspects of the culture at Signal Sciences. Combined with a number of remote employees and a flexible work from home policy, we place a lot of trust in our teammates to take ownership over what they’re working on.

As a product manager that means I’m fortunate to work with designers and engineers that I trust 100% to build features quickly, because they know how to ask the right questions and challenge my assumptions. If I’ve done my job, the vision and strategy for the feature have been set, so my teammates are empowered to propose and implement tech and design choices that they believe best serves the user.

While we’re highly autonomous, we also aim to be highly communicative. We share documentation, announce significant updates or launches broadly, and make our hours of availability open so people know when to expect answers to their questions.

Maintain one source of truth

With everyone working so quickly on loosely related projects, I think a lot about how to keep everyone on the same page. We use Github as our ticketing system with Zenhub as an additional layer of kanban-style project management. We organize all projects—big or small—as epics. To make sure everyone can find the information they’re looking for about a project—and find all the tickets related to it in a sea of thousands—we use the main epic ticket as the source of truth. It’s the atom around which all of our work orbits.

A few things I include in each epic:

• The problem statement
• The solution
• The product vision and strategy statement that enables the solution
• A pretty prosaic breakdown of the product requirements, complete with annotated diagrams
• Checklist of specific must-haves
• Links, links, links

On that last point: because we’re dealing with so many tickets, and since we use Google Drive (which makes it nearly impossible to find old documents), we add a lot of links in a given epic to make sure people can easily find, say, that wireframe or that slide deck they opened last week.

Flexible feature flagging

Once product development is in motion, we use a very flexible feature flagging system to test the product while it’s being built. Our staging environment lets us opt in or out of basically any feature. We also create “development groups,” which allow us to separate our users across a variety of conditions. For example, we’ll turn on features for staff development groups or for enterprise customers of a certain size.

This is really helpful in a few ways:

1. It’s easy to undo a problematic release. Stuff happens. And when it does, it’s a simple process of turning off the feature flag for the affected group—whether it’s one customer or many.
2. Some customers require a little more time or testing. For example, we’ve been making big changes to our user roles and permissions in order to enable some cool new features. Some of our more sensitive enterprise companies needed more time to go through internal change processes before adopting the new updates. In that case, as the PM on the project, I teamed up with the Professional Services team to maintain a development group made up of these companies.

Launch to bigger and bigger test audiences

We generally release new features in 3 stages. Using feature flags, we roll out features to:

1. The staff development team (Team Launch)
2. The entire staff (Staff Launch)
3. Customers (General Audience)

In each stage we increase the scope of users able to interact with the feature in their daily workflow. Features do not graduate to the next stage until all feedback has been addressed from the previous stage.

During Staff Launch, users interact with our dashboard to monitor and configure their prospects and managed customers. They see exactly what the customers see. So, when we move a feature to the Staff Launch phase, we tend to run into most of the bugs or usability problems and deal with them. After about a week or so of regular staff use, we’re usually able to graduate the feature to the General Audience stage, where all customers can use it.

The payoff

Our culture of being able to “own” projects, respect others’ judgements, and over communicate has huge payoffs. The result is that we’re able to spend more time doing work and having meaningful discussions, and less time blocked by uncertainty.

The few formalized processes we do have—employing features flags and launching features to groups in stages—gives us constant visibility into all of our in-progress features at any time.

If you’re interested in shipping features alongside our product managers, check out our job openings. We’re hiring!