Parallel Processing
One of the biggest start-up lessons I’ve had to date is the power of dedicated teams, and a parallel-process approach to product development. Some might refer to this as the “portfolio approach,” but its really more of a component of that approach. The important element is that you have distinct, dedicated teams working on your “portfolio” of projects/products. In the past few weeks, I’ve had 3 or 4 separate discussions with different individuals on the power of this development methodology, and I thought it made sense to put together a post on it. Some of this material was covered in Collaboration Domination (Part 1 and Part 2), but this post gets a bit more detailed with respect to parallel-processing.
When I first moved into product management it seemed like we we’re treading water on our most important projects. We had good vision, a detailed product pipeline, a small, but excellent, team and discipline around the scrum process. However, we could never advance much beyond a few small elements on our major initiatives. For us, those initiatives were an online, self-service product (we were historically an enterprise sales-based organization), and a set of efficiency and automation tools for our analysts. The two projects were critical to our advancement and growth, but we just couldn’t make progress.
I always knew that distractions we’re causing the bottlenecks, but it wasn’t until David Wolfe, a product development veteran, began working with the company and revamped the team did I learn how to manage the problems. When he started, David took one look at our team and knew it needed to be restructured. Given that we were a relatively small-group, in a young organization, we were operating as a single-unit. In doing so, we attempted to complete components of the the two critical projects alongside bug-fixes and short-term projects (usually existing product revisions and client-specific requests).
First, David immediately erased the distinction between “product” and “engineering” and made sure we all understood that we were overall, one cohesive, cross-functional, “product development” team. Then, he split the larger team into three very “slim,” but very focused, project teams. As the sole product manager I operated across all of them, but otherwise team members we’re allocated to specific project teams, focused on specific goals. The online team had a designer, front-end developer (also a UX specialist) and couple of back-end developers. Our internal tools team had two back-end developers (one of which had some front-end skills as well), and our bugs/short-term/special situations team had an in-house developer and an off-site developer. The teams were small, but ultimately contained the required skill-sets, and were only allowed to focus on their respective projects.
Within weeks it was clear that the difference was remarkable; our core projects we’re beginning to fly. In less than 2 months we had built an entirely new, and far superior, web experience, implemented data tracking and analytics, and would continue to advance that project nose-to-tail for the next 9 months. Our internal projects were advancing far beyond our expectations, and bugs we’re getting fixed as needed. It become extremely clear that our challenge prior to restructuring was centered on the short-term requests. In our old model, these would come to dominate each sprint, as they were often handed down from management and sales as important and impactful. Additionally, they were viewed as only “short-term,” and not something that would distract and impact our development process beyond a few weeks. However, the big problem was that there was always another short-term project on the horizon, and ultimately these projects came to eat all of our resources.
Given this dynamic, our efforts we’re not appropriately split between core projects and short-term projects. For example, if a short-term project was worth 40 points of effort, and we had a sprint with 50 points of resources, 40 would be taken-up by that short-term project, leaving only a small sliver of time for the longer-term projects. By parallel-processing the projects across 3 teams, we limited the resources for every project, but in doing so resulted in far fewer distractions. For example, that 40 point short-term project would now need to be completed by a team that maybe only had 10 points of bandwidth, making it a 4 sprint project. Meanwhile, the online team had 20 points of bandwidth and could use all 20 points, each sprint, to focus on the goal of advancing the online product.
While the same principles of “parallel-processing” across distinct teams can be applied to other functions as well, its extremely effective for product development organizations. I fundamentally believe that even for the smallest start-ups it would be helpful to think in this manner, and its critical as the company grows. The primary difference will simply be the number of teams, but each team should strive to be focused on just one project at a time. The projects can change, and the team members can be moved around (not too much, but rotation is OK), as long as at any given time, there is only one project in focus for each project team. Below is a summary of a few of the critical elements of, as I call it, parallel-processing:
Core Elements:
1. “Self-contained” cross-functional teams: Cross-functional teams are an important element of this approach. Even if team-members need to split time (not ideal and should only be done when truly structured), it is important that all skill-sets are represented. First, the dedicated resources ensure that distractions are less prevalent. Second, cross-funcational collaboration is critical to rapid iteration and decision-making. I can’t tell you how many times we hit a roadblock, even mid-sprint, and we’re able to overcome it with a few hours in a conference room white-boarding, discussing and ultimately creating a plan with (what we felt was) the best combination of design, usability and ease-of-development.
An earlier post, Collaboration Domination, Part 2 discusses this further
2. Consistent and Shared Vision: While the team should have the ability to iterate and build as they determine is best, the entire organization should share the same vision for the company, and should be in agreement on what projects/products are most important. Since resources to any one project are going to be less than the overall available resources, without buy-in across the company (particularly across the executive team, but in the best situations everyone is on the same page), the teams are likely be continually distracted, often redirected, and frequently pulled in different directions by different execs/functional teams.
3. Insulation: For this method to truly work, it needs to be adhered to. If the different product/project teams are continually bounced around, or their progress is hindered by interruptions, one-off requests and short-term requests, it will fail.
Benefits:
1. Product Focus: It is a well known tenet of start-up building to focus on one-thing and to keep distractions to a minimum. For every organization, saying “no” to non-core projects is always an option, but the parallel-process approach makes it much easier to limit distractions. In that approach, short-term projects are limited to only a small pool of resources and can’t distract from the primary goals of the company. An added benefit is that if needed, there is room for testing new opportunities and non-roadmap product features both without distracting from the core roadmap and without having to unilaterally say no.
2. Team Focus – Over time, when a team is focused on a on single project, they become extremely focused on that project. I saw it clearly when we restructured. Rather than constantly “switching-gears,” the team was able to throw themselves completely into a single project. Over time, it made it easier to think through problems, more seamless to work together, and made for a more cohesive unit.
This isn’t to say that the team must be static forever, and indeed some turnover and change is good for sparking innovation and creative thinking, but it shouldn’t be frequent. Just like any sports team getting better and more cohesive as they continue to play together – a QB and WR becoming lock-step, a hockey line passing by instinct or a SS and 2B turning a double-play with perfect timing – assuming they mesh, the longer they work together, the quicker, more efficient and better a product team becomes.
