Funny thing about juggling: It looks far more complicated and impressive to the untrained eye—or, more accurately, to the untrained hand—than it actually is. (Five balls, two hands? How does he do that?) The truth is, a juggler is simply catching one ball at a time with each hand while keeping the remaining balls in the air. With a little practice, we can all do that.

And that’s good news for you as a product manager. (Also as a juggler, if you decide to give that a try, too.)

If you’re about to begin a complex product management initiative that will involve driving multiple development tracks simultaneously—say, the web and mobile versions of a new product—that aspect of the project can seem overwhelming at first. (Two development teams, two schedules, two sets of features? How will I do that?)

But, as with juggling, managing multiple development tracks simultaneously for a product (or even for several products) can be made a lot easier than it sounds, if you follow a few smart strategies.

5 Tips for Managing Multiple Development Tracks

1. Break your teams into strategic units.

Spotify popularized the concept of product squads. These are cross-functional teams, usually consisting of developers and a product manager, that are set up as autonomous units responsible for a specific functional area of the Spotify platform (search, player, etc.) who are able to release new functionality directly to the public when they deem it ready.

When we interviewed Chris Leckie, Product Design Director for the popular fantasy sports platform FanDuel, Chris described a similar development methodology at his company, called a stream. Each stream is a cross-disciplinary team (product designers, developers, a business analyst, a project manager, etc.) working together on a functional area such as the platform for a new sport or the company’s social-media component. (Listen to the full interview.)

The squad and stream methodologies both allow a company to develop deep domain expertise in all functional areas of its products, while at the same time allowing these teams to more intelligently manage their time and resources—because each team knows how to progress in its own functional area of the product.

Yes, you could work with your development manager to simply divide up a multiple-track initiative by assigning whatever dev resources are available at the time, and moving people around based on the immediate needs of a given schedule or task.

But if you’re overseeing multiple strategic components of your product’s development, breaking your teams up in such a way that allows them all to go deep in a specific area of functionality can often pay greater dividends over time.

The squad and stream methodologies both allow a company to develop deep domain expertise in all functional areas of its products, while at the same time allowing these teams to more intelligently manage their time and resources—because each team knows how to progress in its own functional area of the product.

Tweet This:
“The squad methodology allows a company to develop deep domain expertise in all functional areas of its products.”

Yes, you could work with your development manager to simply divide up a multiple-track initiative by assigning whatever dev resources are available at the time, and moving people around based on the immediate needs of a given schedule or task.

But if you’re overseeing multiple strategic components of your product’s development, breaking your teams up in such a way that allows them all to go deep in a specific area of functionality can often pay greater dividends over time.

2. Shift people to a different strategic team every now and then.

One word of caution with the first tip—organizing your product development teams as cross-disciplinary squads or streams—is that if these teams work together on the same functional area for too long, they risk becoming information silos.

This could mean that although your product is benefiting from a set of teams each working with deep domain expertise, you might be missing out on the even greater benefits of cross-pollination. Developers or designers assigned to your mobile platform, for example, may not be communicating some of the knowledge they’ve learned that could benefit the web version of your product.

So our second tip is to occasionally move one or more members of each of your teams (or squads or streams or tribes, or whatever you call them) to a different team—and allow some of that knowledge-sharing to happen.

With this two-part strategy, you and your product team will produce dynamic, expert teams across each area of your product, while regularly introducing a fresh set of eyes—and a related but different area of domain expertise—to each team.

3. Manage your multiple development tracks strategically with the right product roadmap.

Fortunately, tools now exist to allow you to easily manage and communicate the strategic details of separate product development tracks in whatever way makes the most sense to you.

You could organize all of your development tracks into a single product roadmap, for example, perhaps breaking each track up into separate swim lanes.

If your different tracks—say, iOS vs. Android vs. web—cover functionality across multiple products, you might instead want to break them up accordingly and create a multiple product roadmap that lays out how these tracks will progress across all of your products.

Or, if you’d prefer to organize your separate development tracks into plans covering shorter time horizons—more like sprints—you can also create an agile roadmap for strategic planning with your teams.

The key is, organize your separate development tracks in the way that works best for you and your team, and then capture and maintain that strategic plan using the right product roadmap template for you.

4. Organize each development track into user stories—not feature sets.

Creating cross-functional teams, each responsible for a given functional area of your product, can quickly generate in-house expertise (and development speed) across as many areas of your product as possible. If the circumstances at your company allow it, we believe this strategy can be invaluable.

But don’t shortchange your efforts here by organizing each team’s work into a set of features. As Pivotal Tracker’s Dan Podsedly explained in our recent webinar—How Product Managers and Agile Development Teams Can See Eye to Eye—the smartest way to break up development work is into user stories, not features.

Dan pointed out several reasons that user stories are the most effective way for your development team to approach its work. User stories, he explained, are vertical—meaning they allow developers to focus their efforts on building a complete piece of functionality (even a small one) for the user. And unlike features, Dan explained, stories capture intent and desired outcomes—which leaves the development details to the developers themselves.

If you’re going to break your product development down into separate development tracks, then you’re clearly thinking strategically about how best to carve up and assign this big, complex initiative that will include many interdependencies and require plenty of domain expertise.

Now it’s time to take your planning to the next step—breaking your big-picture product strategy into actionable chunks. And the best way to share this work with your development teams (or squads or streams) will be to let them start tackling their areas of responsibility by working toward completing user stories.

5. Release each completed project track when that component of the product is ready.

Another reason it’s a great idea to break your product development into user stories rather than features is that it allows your team to release updates to your products more frequently.

Whereas features typically represent large functional areas of a product, a user story often represents a relatively small bit of functionality—but still a complete one—that your team can build quickly. With your development broken into user stories, you’ll be able to push out each new piece of functionality sooner.

This is part of a larger development philosophy. When you’re managing multiple development tracks, each track progressing on its own schedule, you’ll often find that some of those tracks have matured into release-ready product elements before others. This is a good thing—release them!

If each track you’re managing represents a self-contained entity—functionality for a new sport, in FanDuel’s case, for example—you should treat that track as its own standalone product ready for launch, independent of wherever your other tracks are in their development schedules.

Part of the genius of agile development is that it allows you and your team to deliver new functionality to your users more quickly and frequently—and to leverage that user feedback to improve not only the specific functionality they’re telling you about but the rest of your product as well.

Tweet This:
“When managing multiple development tracks, take the opportunity to release elements from some tracks rather than waiting for everything to be finished, so you’ll have the benefit of user feedback.”

So if you’re managing multiple development tracks, and you take the opportunity to release elements from some tracks rather than waiting for everything to be finished, you’ll have the ongoing benefit of user feedback that can help inform the work your teams are doing on every other development track.

And that means a better product.


Do you have tips for simultaneously managing multiple product development tracks? Please share them in the comments section.