Wednesday, 29 May 2013

Organisational Structure: Product Teams

There are two ways of running your organisation. The more common of the two is to do some form of project-based planning. In this model, the management of the company defines the roadmap – they come up with a prioritised set of projects and allocates time and people to them. For example, they may decide that a team will spend two months on some new search functionality. The team will likely not change, but the project and domain typically changes frequently. If you were to look at this roadmap, you would see different projects typically with rows per team and projects “assigned” to them.

Due to the nature of software engineering, it is rare that a week goes by without this roadmap changing significantly. New business opportunities come along, priorities change, and the plans have to change accordingly. Alternatively a project will take longer than anticipated so all subsequently planned work has to get pushed back.

These roadmaps are usually filled with an abundance of assumptions, and are typically created without any solid information or knowledge of what needs to be done or how much it will cost. This often results in the plan never being truly realised. This can be a massive source of frustration for businesses and development teams alike. These assumptions are often made from people outside of the teams and are done in a very dictatorial way, which can quite easily and effectively quash both innovation and collaboration.

The alternative to the above is to move across to a product team based organisation. This is the way forward, and an option that companies are increasingly turning to in order to try and improve how they develop their products.

In this model, the focus is instead around which areas of the business the company wants to invest in. This removes the focus on projects and instead allows each product team to be able to focus on what is best for it. It is important that the product teams are given space and freedom in order to innovate and collaborate effectively. This means that the business should present a problem to the relevant team, and allow them to come up with the solution.

The teams should be cross functional, composed of members who are capable of carrying out any and all of the tasks that may arise. Over time they will develop a deep understanding of the domain of their product, meaning that the longer they are kept together on the same product, the more efficient they will be become. Tie this in with the concept of continual improvement and you have a recipe for success.

Making It Work

There are a number of key points that I would advise you to follow if you truly want to make the move to product focussed development teams a success.
  • Do not prescribe a solution to a product team, give them the problem you are trying to solve and work with them to come up with the best solution
  • Resist the urge to be dictatorial and tell people what to do. This quashes innovation and collaboration
  • Allow the product managers to be fully accountable and responsible for what happens in their product. Give them steer in order to ensure they are working towards the overall company objectives, but allow them to decide how they will get there
  • Give everyone an equal voice – collaboration is key to success
  • Limit the amount of people involved in making decisions. The more people involved, the more painful and difficult the process of agreeing a way forward
  • Agree on a scorecard for giving backlog items, which will effectively highlight which work will give the biggest ROI
  • Do not follow ‘Agile’ like a religion. Every company is different, and whilst the core message will be the same for everyone, the best way to implement this will vary


  1. Great post Lee, and completely agree.
    I think its important to have a vision board, but the vision board should not be a road-map of projects. Instead, it should define in a very clear way what are the targets and goals a business wants to achieve.

    Product teams should be empowered to do whatever they think is the best approach to achieve those goals.

    I also think that if there is communication and true collaboration between Product Teams, the risk of waste by having product teams working on the same thing reduces significantly.

    Independent battalions autonomously fighting for the same cause, clearing the way for one another..that's definitely the way forward.

    1. Thanks for the support Pedro. You are right about the teams needing to be coordinated. Communication is key to ensuring the teams all run at the best possible efficiency.

  2. I like the idea of product teams, but what would you think of having product leaders and forming teams underneath them as and when needed.

    This means you still retain the domain knowledge in the leaders, but can be more flexible in the team requirements to fit the current work? Its also more practical for smaller teams. I'm a big believer in mobile desks and shuffling people to fit current projects.

    1. I quite like this idea! I think you are right that it suits a smaller more fluid company more than a larger one.

      The only problem I could potentially foresee from this would be that if anything were to happen to the person fulfilling the product leader role, there would be a huge risk of that knowledge being lost. A well established product team should be able to function in the absence of a member, mitigating this potential single point of failure.

      I do agree with you around the mobile desks and flexing of teams to fit the business requirements. Maybe there could be some kind of middle ground where you have skeleton teams when the business is investing elsewhere?

      One to ponder :)

  3. I have a model for you. Just get it fucking done and stop chatting bubbles. :)

  4. This comment has been removed by the author.

  5. Nowadays product team structure is pretty standardized and depends only on the size of the company. In small company one man can combine functions of few people from big company, that's the main difference. I'm looking on it from te inside, because i've worked in since it was small company.