Apr 4, 2017
The benefit of a small product team
In an organisation, when a decision to create a new product is made, there is a high chance that one of the existing teams will be allocated to the task right away. Management expectation is always high, and it’s usually assumed that the team can shift gears immediately and become productive in a matter of days.
Unfortunately, it doesn’t work this way. And let’s not forget that it takes much longer for a completely new team to jell and perform.
The challenge is that in the first few weeks the engineers and testers won’t have much to do. It’ll take a couple of days to set up their environments, tools and other magical artefacts. After this they’ll be spinning their wheels and there’s a good chance they’ll become demotivated.
The goal is to gather a full-time team only when you have a good understanding of the first iteration of the product. You can then provide clear direction and share any customer and business problems with the team. Preparation sessions with the tech people can happen in the lead-up to this without having them deployed at full capacity to the product.
It is often useful for a product and UX, to complete the initial “Problem / Solution fit” phase first and only add people with other skills as you need to. Even if you think you need a team of 6 you’d be surprised at how much you can get done with the initial few people.
The final team set-up should have the right mix of the required skills to minimise the number of dependencies and allow it to deliver value to the customer fast. How many people? That depends on many factors, but the rule of thumb is, the smaller, the better.
Remember, as your team starts forming, aim to build a ‘jelled’ team. People in a jelled team are committed, excited, generating ideas, thinking about the customer and loving working on the product. Jelled teams dramatically increase the probability of success. Take a look at my post “How to encourage collaboration” to get some tips on how to get your team to think about the customer and the business.
The next challenge you’ll face is dependencies. Let’s figure out how to deal with and remove dependencies in the next post.
Feel free to get in touch on Twitter @_maxantonov if you have any questions or find yourself simply stuck!
Unfortunately, it doesn’t work this way. And let’s not forget that it takes much longer for a completely new team to jell and perform.
The challenge is that in the first few weeks the engineers and testers won’t have much to do. It’ll take a couple of days to set up their environments, tools and other magical artefacts. After this they’ll be spinning their wheels and there’s a good chance they’ll become demotivated.
The goal is to gather a full-time team only when you have a good understanding of the first iteration of the product. You can then provide clear direction and share any customer and business problems with the team. Preparation sessions with the tech people can happen in the lead-up to this without having them deployed at full capacity to the product.
It is often useful for a product and UX, to complete the initial “Problem / Solution fit” phase first and only add people with other skills as you need to. Even if you think you need a team of 6 you’d be surprised at how much you can get done with the initial few people.
The final team set-up should have the right mix of the required skills to minimise the number of dependencies and allow it to deliver value to the customer fast. How many people? That depends on many factors, but the rule of thumb is, the smaller, the better.
Remember, as your team starts forming, aim to build a ‘jelled’ team. People in a jelled team are committed, excited, generating ideas, thinking about the customer and loving working on the product. Jelled teams dramatically increase the probability of success. Take a look at my post “How to encourage collaboration” to get some tips on how to get your team to think about the customer and the business.
The next challenge you’ll face is dependencies. Let’s figure out how to deal with and remove dependencies in the next post.
Feel free to get in touch on Twitter @_maxantonov if you have any questions or find yourself simply stuck!
About Max Antonov
I’m Max - father of two, Product Director and Product Coach.
I write about leadership, product management and whatever else is on my mind.
Feel free to reach out at [email protected]
