When creating a team meant to work in an agile setting, most people remember that there are supposed to be more people in it than developers. They might skim through the Scrum Guide and fill the roles of Product Owner and Scrum Master. What few do is to think about what other roles that are really needed.
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 Dev Ops or similar.
But, if they actually do not know what they are going to build (and my guess would be that this is more 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 business innovation.
This would mean that to create a good product, i.e. take good product decisions, they would need input from at least three different persons; One understanding the viability and the business case, this could be the Product Owner. One understand the technical feasibility, this could be one of the developers. And one understanding the desirability and the usability, this is most likely some sort of User Experience Designer. Together these people will bring balance to the product’s goals and possibilities. Hence, this is what is usually called a Balanced Team (or a product discovery team).
As you can see, understanding all this will most likely require more people than the three mentioned above, at least if the product they are building is bigger than a simple and independent app. 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 Owner. User Researchers should be really good at finding out what users need and get motivated by, Copywriters and User Interface 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.
My suggestion to all ”they” people out there, is to 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?
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. My suggestion to you is to learn how the remedy this situation in the best possible way by attending our Product Discovery course.
I agree with what’s said here, but I’d add the need for a stronger influence from an Operational perspective. In the world of SaaS and PaaS, the team building the software is often the team responsible for running and maintaining it. We no longer just ship software to who-knows-where, we deploy it to a cloud instance, scale it, monitor it and update it on a daily basis.
What this means is that the traditional dynamic of Dev, UX and PO is now evolving to be more like Dev, Ops, UX and PO. The Ops perspective is now so integral to the product that it’s influence is much greater than before.
I love the concept of visually mapping out the roles required within the team, I can see that as a great exercise during product inception.
Thanks!
Thank you James. I do agree with you about Ops when it comes to delivery and continuous running and maintenance, as you say. But do they have to have such an integral role in the Discovery phase as well?