For years I followed the typical Scrum team model where product owners worked with teams of developers and if I was lucky, testers and designers. Primed with user stories, the teams delivered working software but it rarely delighted. We were falling short of our potential.
The development team needed to share a greater purpose. They wanted to solve problems that mattered to people, not just build what was asked for. They were seen as deliverers of working software, so it follows that their purpose becomes just that. But our deeper purpose is to solve unique problems in novel ways and a typical scrum shaped development team is only half equipped to do that.
I was looking for a complete product team with diverse skills and domain experience to share a common purpose and develop the product together. I wanted to see those that wrestled with the customer problem day-to-day sitting with the people delivering the solution. We needed domain experts, people from support, marketing, sales, customer success and communications as involved in finding solutions as the developers were.
But it wasn’t easy. Silos are stubborn. They plague organisations and cripple the creation of value. Organisations gravitate to structuring people by function because their managers are functional managers. People want to be led by experts in their own field. Matrix structures designed to overcome this are messy and compromised.
A truly cross-functional product team is the most powerful way to deliver valuable software and at the same time the most elusive. Lacking all the knowledge needed to discover and deliver stifles effective creativity. Incomplete teams lack confidence, become frustrated, become defensive and waste time and money.
My first product team experiment began by asking all the people involved in the product and the customers to sit together. This is more dangerous than it sounds. It takes courage to be away from the people who do what you do and to mix with people that you are yet to fully understand. It’s so much easier to stay ignorant and blame them.
It was a rough start. People looked uncomfortable, vulnerable and insecure. They kept busy with their usual work, nervous to reveal too much in case others judge them. After some awkward weeks, familiarity began to ease the fears. Overheard frustrations initiated offers of help. As people became aware that the missing pieces of the puzzle were now within reach the odd request to collaborate began to emerge. Over time collaboration grew and I saw the seeds of the new team forming.
As people joined the team its size grew a little unwieldy, their village became a town. But rather than everybody being involved with every problem people took a lead to solve specific problems and co-opted subsets of the team that crossed the functional plains. We created space for these subgroups to work within earshot of the rest of the team who could volunteer their help.
In time the team settled. Now I’ve moved on and had a chance to reflect on their journey, I have 5 suggestions for forming a product team:
- Start with Why: Why are they together? Why is each person essential?
- Teambuild: Create opportunities for people to learn about each other. Don’t rush this
- Go deep into the problem space: Get everyone as passionate about the problem you are trying to solve as you are
- Psychological safety: Take time to give support and appreciation, everybody is outside their comfort zone and will need reassurance
- Bring meaning: Help the team understand the power they have to make a difference
Transforming the shape of teams takes enormous courage from leadership and team members. We’re asking people to solve problems in new ways that break with generations of tradition. Diverse collaboration is rare, particularly in more traditional siloed organisations. But with the most successful software product companies now working this way, and seeing exceptional growth, your survival depends on it. Diverse product teams are now the only competitive way to innovate. Don’t give up!