When creating a team meant to be cross-functional, some people remember that there are supposed to be more people in it than developers. These people might skim through the Scrum Guide and add the roles of Product Owner and Scrum Master. What few do is to think about what other roles that are really needed. And what very few think about is what skills, competencies and even mindset they really need.
The first set of questions they should ask themselves is if they already know exactly what kind of product they should build, if they know the problem statement and if there is a base solution to start iterating and incrementing from. Or, if they have a function in the company that will deal with these questions and prefer working in a waterfall way, delivering some sort of specification to the team. If there is a yes on all (or most of) those questions, then they have a delivery team and the only roles that might be needed apart from the kinds mentioned above are those concerning delivery, such as DevOps or similar.
But, if they actually do not know what they are going to build (and my guess would be that this is most often the case), then they would need people to help out with discovering what to build. One way of finding out what roles that would be needed is to base the team on what is required for great business innovation, according to many sources, one of them being IDEO.
This would mean that to create a good product, i.e. take good product decisions, they would need input from at least three different perspectives; One understanding the viability, the business value, and this could be a Product Manager. One understanding the practical and technical feasibility, and this could be one of the engineers or an architect. And one understanding the desirability, the user value, and this is most likely some sort of User Experience Designer. Together these people will bring balance to the product’s goals and possibilities by covering most aspects of what is needed in a good product but also be able to make great compromises together to create the right outcome for both business, users and organisation. Hence, this is what is usually called a Balanced Team (or a product discovery team or a product triad).
It is not necessary that each of these corresponds to a role, but it is necessary to check what people have their minds set on. Maybe all of the engineers are in the game first and foremost to help their company thrive, maybe the Product Manager is all about attending to the users’ needs, maybe the designer is all about crafting solutions that helps the organisation.
But, as you can well see, understanding what makes a great outcome for each of these three aspects will most likely require more people than the three mentioned above. My suggestion is that they should look at other roles outside of the specified in agile literature that might be good at understanding these product qualities and see them as support to the main role. For instance, Business Analysts together with Domain Experts should be really good at understanding the business case and Requirement Engineers could help combining all the different stakeholder input into something viable. This is something that could really benefit the work of the Product Manageer. User Researchers should be really good at finding out what users need and get motivated by, UX writers and Visual Designers could help making the product be desirable in real life. They should be able to help the User Experience Designer tremendously. Also, accounting for technical feasibility when discovering what needs to be built is a must, and there is a plethora of great minds in the engineering community.
One reason for this not already happening in an organisation might be that collaboration between these different roles can be hard, and this is of course true for adding more people of the same role to the team as well. But, that shouldn’t stop you, should it?
Draw a diagram like the one below and start adding roles or work that might be needed in the circles. This is an easy way to map out possible roles or lack of competencies. When you do this with your team, why not share the roles you find in the comments to this article for others to benefit?