Having led and observed product development initiatives that took years to launch (IBM’s clients, Dun & Bradstreet), quarters to launch (1stdibs.com), and months to launch (KeepRecipes.com, DreamIt Ventures), I’ve been amazed by the productivity of small product teams. The article about PayPal’s reinvention being powered by small product teams, and of Shutterstock’s success being driven by small product teams, comes as no surprise.
If you want a high performing growth company, small teams (typically up to 15 people) is not the only answer. Small teams need to be setup right, with the 4 R’s. They need the Right People, Right Problem, Right Processes, and Removal of All Friction.
Right People. The highest performing product development teams I’ve seen have a mix of skills and attributes. They have someone quantitative, someone logical, someone collaborative, someone artistic, and someone good at user experience. They typically include a full stack of engineering capability, design/ux, a product manager, QA, and part-time marketing insight. On some teams, design and QA can be part time, but once the changes get frequent enough or opportunity is great enough, it becomes very helpful to have both full time if you want more cycles of work released faster. Teams running without design or QA can’t iterate as quickly and are likely mis-using precious development resources, or not allowing the product manager to stay one step ahead.
Right Problem. The highest performing product development teams are focused on the right problem. Typically, it’s quantitative. Low performing teams often have feature launches as goals. It’s too hard to judge success of feature launches, and they don’t drive business results. Launch gets delayed because what matters is how good the feature is, not what results it drives. Resources get allocated to a part of the feature that does not drive business results. Another indicator of low performing teams is a lack of focus on a single problem. If there is not a single job to be done, the team loses focus. If the problem changes to often, there is not a chance to learn and improve. The right problem also motivates the team and provides a rallying point.
Right Processes. Teams need to find what keeps them humming. I’ve seen KanBan work great for very small product teams, as engineers can easily see what everyone is working on and, once finished, pull the next thing off the queue. Agile works well for larger product teams and projects, as the daily stand-up provides a rhythm and sense of shared commitment. Both of these processes focus more on productivity than on overhead. It’s important that the process not require much time spent providing progress updates and deadline estimates, as time spent on these activities doesn’t produce a better outcome faster. Even when working with an outsourced or offshore team, I’ve found KanBan to be better than requirements documents. Development processes also matter–how is code controlled, how is testing done. Teams need to optimize (or ideally eliminate) each step in their processes.
Remove All Friction. Ensure the small teams are not dependent on another team to get something done–put as much as necessary in the team’s control and allow them to work on the end-to-end solution. Try not to have the team dependent on a shared resource, for which they must spend time queuing or requesting. Provide all the resources they need, whether it’s software, testing devices, or stock photography. Organizations of any size have people or processes that create friction. Keep obstructions such as management requests for status updates or reviews to a minimum, or at the very least focus them on a single team member. Give the team goals and not flagpoles, as each flagpole introduces friction and delays progress.
If you follow the 4 R’s — Right People, Right Problem, Right Processes, and Removal of All Friction — your product teams will be motivated and set up for success.