How to Manage Multiple Development Tracks

Multitasking is a way of life, not only for individuals but for companies as well. Most organizations create, nurture, and sell a portfolio of offerings. Part of this is natural segmentation. Not every type of customer needs or wants the same thing. The other driving factor is diversification. Just like we shouldn’t invest all our money in a single stock, companies often can’t afford to stake their entire futures on a single product, niche, or capability. That’s why many pursue multiple development tracks.

The MuST Framework

To probe potential paths to success, many companies create parallel initiatives. They do this to see what’s possible. This approach acknowledges upfront that some, likely most, of these journeys may not pan out. It’s the willingness to fail that allows innovative companies to succeed.

This mindset is why you’re reading this article on an iPad while ignoring your Gmail. These organizations didn’t know exactly what they were setting out to build. Nor were they sure which would find market traction… or even work at all! But it is the appetite for experimentation on a grand scale that significantly increases the odds of discovering a gamechanger.

Unlike a single-track strategy, MuST embraces the unknown and welcomes the unexpected. Different tracks intentionally pursue unique paths, learning as they go, pivoting, and rerouting based on the successes and failures they encounter. There’s no overarching grand vision. There is a belief that these various avenues must be explored.

The final results may be presented to the public as a “fait accompli.” That the accomplishment was the inevitable realization of an inspiring leader’s vision, but behind the scenes lay the abandoned relics of the projects that didn’t have a happy ending. This only works when upfront plans aren’t too defined. The path was not overly prescriptive, and the budgets have the freedom to shrink and grow over each initiative’s life.

Organizations that buy into MuST aren’t just leaving room for rapid iteration on known winners. They’re providing space, resources, and frameworks for spectacular failures as well.

5 Tips for Managing Multiple Development Tracks

Managing one roadmap is tough enough. Often product managers and their colleagues working in project and program management have multiple development tracks. This is a major increase in difficulty and can throw the most organized individuals for a loop.

These tracks represent lots of completely different products or asynchronous development streams working on independent initiatives. It’s easy to feel overwhelmed. But using a few smart strategies can make managing multiple development tracks much easier than it sounds.

1. Break teams into strategic units.

Spotify popularized the concept of product squads. These are cross-functional teams. Usually of developers and a product manager—set up as autonomous units. Each is responsible for a specific functional area of the Spotify platform (search, player, etc.). Releasing new functionality directly to the public, independent of what the other squads are up to.

The popular fantasy sports platform FanDuel takes a similar approach. Product Design Director Chris Leckie described how they use streams. These cross-disciplinary teams include product designers, developers, a business analyst, and a project manager. Each stream works together in a functional area. One such as the platform for a specific sport or the company’s social-media component. (Listen to the full interview.)

These squad and stream methodologies offer many benefits. Each team develops deep domain expertise. They do this while intelligently managing their time and resources. They can do this because hoping they understand their own functional area of the product.

The alternative is a continual reshuffling of resources to whichever tracks need extra bodies. But what you gain in person-hours, you lose in efficiency. Developers hoping from one track to the next do not build up expertise, which begets increased productivity.

There may not always be enough personnel to go around, and a UX professional or architect may need to help out on multiple development tracks. But whenever possible, letting the implementation teams focus on one area pays dividends over time.

2. Mix it up now and then.

While the previous tip is a sound suggestion, occasionally switching things up is also important. If staff never move around, you risk burnout and informational silos forming.

By periodically rotating individuals through different teams, a natural cross-pollination of learned wisdom, techniques, and information is inevitable. That’s a huge benefit for the organization, as different teams share and borrow from each other.

With this two-part strategy, you and your product team will first produce dynamic, expert teams across each area of your product. Then, by regularly rotating staff, you’ll introduce a fresh set of eyes—and a related but different area of domain expertise—to each team.

3. Manage it all in a roadmap.

With so much happening simultaneously, a single source of truth is critical for oversight and communication. Roadmaps provide the perfect blend of clear, concise communication with strategic intent and direction.

Using a purpose-built roadmapping tool, these tracks can be managed and visualized in different ways. One alternative is creating a separate roadmap for each track. These could be based on products, teams, different aspects of the same product, or strategic themes. For example, you could create roadmaps for the iOS, Android, and web versions of the product.

Another option is producing individual roadmaps for filling the funnel, converting trials, and increasing average revenue per user with dedicated teams for each. These track-specific roadmaps are primarily for those implementation teams themselves to guide their work and measure their progress. They’ll include a detailed level of detail for them to plan their work and allocate resources appropriately. The time horizons can also be adjusted. These roadmaps provide sprint-level granularity when appropriate for Agile teams.

Roadmaps for Executive Reporting

But for executives and other stakeholders, those track-specific roadmaps are far too detailed. They also lack the broader context of how all these independent efforts fit together. This is where roadmapping software really shines.

Individual roadmaps can be automatically rolled up into a portfolio view. The portfolio views display each track as a swimlane on the master roadmap. In one glance, all the various initiatives are visible.  They connect the dots and illustrate how the different streams line up.

This master view is not only great for communicating the larger vision to key decision-makers and other interested parties; it’s also instrumental from a management perspective.

With everything on a single screen, any out-of-sync milestones or deliverables jump out immediately. With that visibility, you can reshuffle resources, adjust priorities, and properly set expectations for key initiatives. Since this portfolio view is generated directly from the individual roadmaps, everything is up to date. Best of all, these views can be generated from within the software without any redundant extra work. So there’s no excuse when it comes to presenting an accurate, comprehensive picture of everything in the works.

4. User stories and themes versus features.

Many roadmaps’ fatal flaw is the obsession with including particular features accompanied by precise release dates.

These roadmaps may help answer questions about when a particular piece of functionality might be available. However, they do a great disservice to the benefits of Agile development.

Feature-based roadmaps are high-level project plans. They talk about “what” and “when,” but completely ignoring the “why.” Organizations are also continually learning from user feedback and analytics. Thus tweaking their thinking and priorities as they go.

Given this reality, plotting out six, 12, or 24 months’ worth of exact deliverables doesn’t make much sense. You’re either locking the company into a path they may soon want to abandon, or you’re stifling the creativity and flexibility Agile can offer.

Planning around themes sets a well-defined strategic direction.  There are also set expectations for individual streams and squads. But it does this without eir hands-on on which functionality they introduce or improve to achieve strategic goals. Within a given theme, assigning user stories versus fully-specified features focus on desired outcomes versus specific implementation.

As Pivotal Tracker’s Dan Podsedly explained in our webinar—How Product Managers and Agile Development Teams Can See Eye to Eye—user stories are the best way to break out work. User stories, he explained, are vertical. They allow developers to focus their efforts on building a complete functionality (even a small one) for the user.

5. Release when ready

Back in the old days, software companies relied on physical media for primary distribution. Eventually, they move to push out minor updates and patches via the Internet. In that scenario, it made sense to wait until everything was done. They could package it all up into one big shipment. It was easier for the user and cheaper for the company.

Although most computers don’t even include a CD-ROM drive, some organizations are still stuck in that monolithic mindset. They wait until everything’s done to slap a “.0” version label on it and ship the whole enchilada in one go.

This leaves a lot of opportunity for growth, learning, and customer satisfaction collecting virtual dust on a shelf, instead of getting new capabilities and improvements into their users’ hands. Whether it’s continuous delivery or adopting a strategy of frequent asynchronous updates, users can realize the value and the hard work teams have put in sees the light of day much sooner.

This is another benefit of structuring implementation and delivery around multiple tracks and individual user stories versus features.

Features represent large functional areas of a product. While a user story often represents a relatively small bit of functionality.

With development broken into user stories, you’ll be able to push out each new piece of functionality more quickly. If each track represents a self-contained entity, treat that track as its own standalone product ready for launch—one independent of wherever your other tracks are in their development schedules.

Part of Agile development’s genius is the ability to deliver new functionality to users faster and more often. Teams can then leverage that user feedback to improve both that specific aspect of the solution and the rest of the product.

Ready to revolutionize your approach to roadmapping multiple development tracks? Check out these helpful templates for managing multiple products.