Cross-functional teams for learning products
Why cross-functional teams are fundamental for creating transformative learning experiences. Part four in my series on product thinking.
🧩 This is part four of my series on product thinking for learning.
Product thinking and cross-functional teams go hand-in-hand.
Why is this?
In the first article in this series I said that product thinking is good for building new solutions and tackling complex problems where there is a lot of uncertainty.
This is also a situation where cross-functional teams work well.
Let’s unpack the reasons for this.
We should also reflect on when working cross-functional working might not be the answer.
Then we can explore the roles in cross-functional teams and how this plays out in the world of learning and edtech.
When you need cross-functional teams
Delivery and Development work have very different demands. They work on a different cadence. Both are important. But we need to think clearly about how they are distinctive. Here’s my definitions.
Delivery work
Delivery work is typically well understood. There are existing solutions and you know what outcome you’re aiming to achieve.
This kind of work often makes sense to give to specialists who understand these solutions working on their own or in teams. They are the experts. Adding the additional demands of collaboration can make this kind of work less efficient without sizeable benefits.
Sometimes this work is a complex problem requiring deep technical work. This is often best tackled by a small team of specialists who can collaborate easily.
Examples of this might be designing a curriculum or breaking down a monolithic web application into a service-oriented architecture.
Let’s call this Architecting work. People doing this sort of work are looking for improvements with a medium-to-long time horizon.
More often, it is a well defined problem and predictable Execution work. This could be something like delivering an existing programme, tech support, marketing or sales campaigns.
People doing this sort of work are focused on the impact they can make today or this week.
Development work
Development work, on the other hand, is typically about creating new solutions. The outcome and how you get there is probably uncertain.
This is where bringing different skills and perspectives together to tackle a shared goal pays dividends. It enables you to rapidly cycle through different approaches and synthesise the expertise of the team to come up with innovative and novel solutions.
Where a complex problem requires a new solution, this is often about making big bets. How could something be ten times better? This might be developing a new learning experience or application.
This is Pioneering work. It’s high risk. This best done by a small and nimble team. The impact they will have is likely to be long term, potentially years, even though to get their they need to work in quick cycles.
Once the problem becomes less complex and better defined - once you have product-market fit - then it becomes about scaling the solution and making incremental improvements. 10% rather than 10x, but lower risk.
This is Iterating work. This might require bigger and often multiple cross-functional teams. Typically these people are looking for impact in the medium term, say next quarter.
Development vs delivery work
The different time horizons and nature of these different kinds of work is why you often see clashes between product teams and marketing and sales teams.
Marketing and sales will often be frustrated that product can’t help them deliver on their numbers this quarter. Product is frustrated by the short term thinking and unrealistic demands.
Mapping Architecting, Pioneering, Executing and Iterating work
Here are these four kinds of work visualised on a 2x2.
If the kind of work you’re doing is on the right hand side, then a cross-functional team is likely to beneficial. As is product thinking.
Since, we’re interested in product thinking, let’s focus on the righthand side and development work.
Roles and responsibilities in a cross-functional development team
The key thing with a cross-functional team is that everyone is working towards a shared goal.
It’s all about collaboration and pulling in the same direction.
But it is also helpful to understand where different roles and skills should take the lead and have the deciding vote. This can be helpful to understand the role each person plays and their responsibilities.
For this, it’s helpful to go back to the Desirable, Viable, Feasible and Usable framework that I explored in earlier articles in this series. One 2x2 is never enough after all! But don’t confuse them.
Desirable: This is research and strategy work
Viable: This is work to understand if you can find and keep people and make a profit
Feasible: This is engineering and operations work
Usable: This is design work, learning design, product design, service design
The role of the ‘product manager’/‘generalist’
If you’re reading this, this is very likely to be YOU.
I’ve said before that product thinking is about keeping all four of these qualities in your head at once and collaborating with experts to find opportunities and solutions that satisfy all four.
In product-led technology companies, the role of the product manager is typically to focus on the top two: uncovering opportunities for desirable solutions and ensuring that they are viable. They are likely to collaborate with research, strategy, sales and marketing to do this. They work closely with designers and engineers whose focus is the bottom two.
The recent debate about Airbnb’s approach to product management is because often PMs can get sucked into the bottom two, become too focused on the product delivery and disempowering engineering and design or become too closely aligned with them.
This can also lead to a lack of focus and ownership of the products viability. PMs can be caricatured as obsessed by the user needs and not focused enough on profit and sustainability.
This can also happen when the team is not empowered by leaders to find new solutions but are instead given them to deliver. What Marty Cagan would refer to as feature teams, rather than product teams.
The role of the educator
In education, the role of the educator is often expected to cover many things: learning design, content creation, facilitation and delivery, marking assignments… to name but a few. This is often a combination of development and delivery work.
Learning design is about developing something that practically works and delivers the learning outcomes (Usable)
Content creation is about developing something is needed/wanted (Desirable)
Facilitation and marking is about delivering these things in repeatable and scalable ways (Feasible)
I would suggest that it is healthy to be clear about these different roles and educator plays and not necessarily expect them to be done by a single human. This is the direction that many start ups are taking in contrast to more traditional institutions.
The relationship between development and delivery people
It is often helpful to involve specialists that will ultimately help deliver solutions in the development.
If you don’t, development teams can feel arrogant and like they are in their ivory towers dictating solutions. Educators and sales people may think they can see obvious solutions that development teams are ignoring.
However, doing both development and delivery work at the same time is hard. It requires a different head space and rhythm. It’s a constant tradeoff between the urgent and important. And if you’re on the hook for delivery work, urgent always wins.
Putting someone whose primary role is doing delivery work in a team of people doing development work is unlikely to work and will feel distracting to them. As a big advocate of cross-functional working I have made this mistake a number of times.
There are couple of solutions that can work though:
Create a strong stakeholder relationship between individuals doing delivery work and a development creating new solutions. Invite them along to ideation, get their feedback on potential solutions, sit in on sales calls, go to their classrooms
A specialist with delivery experience being seconded into a cross-functional development team and relieved of much of their urgent day-to-day work
It’s important to involve specialists with delivery knowledge in cross-functional development work. But being clear about if they are a member of the team or a stakeholder of the team and where they will spend the majority of their time is an important distinction to make.
Communities of practice
Before I finish, a final brief note on how different specialists develop and get support when they are doing cross-functional development work.
I always find it most helpful for specialists like designers, engineers, educators and product managers to be line managed by people from the same discipline. This is important for career development and expert support. It can lead to unhealthy and unhelpful dynamics for another role like PMs to manage engineers or designers for instance.
As well as this, creating strong communities of practice alongside cross functional teams can help support and stop unhelpful silos developing. For example, design critique sessions, software architecture discussions, faculty meetings alongside cross-functional working are all important features of a healthy organisation. This matrix structure can build a strong supportive community.
Creating transformative learning experiences
To do something transformational, you’re often working with complexity and uncertainty. That’s where product thinking can help.
Cross-functional teams and product thinking go hand-in-hand because to effectively create Desirable, Viable, Feasible and Usable solutions you need to involve the specialists that are experts - and can take the lead - on each of those aspects.
The role of the product person is to ensure all four of these is kept in balance. Be careful not to over index on usable and feasible. Take ownership for viability as well as uncovering opportunities to create desirable solutions. Make sure you understand the market.
As a product-thinker, be careful not to force cross-functional working in to places where it is unhelpful and inefficient. This is typically well understood delivery work.
And if you’re trying to do transformational development work and find new solutions in uncertain situations, make sure that you’re creating cross-functional teams to do it.
Let’s finish with a quote that nicely brings to life the opportunity here.
“Interdisciplinary collaboration is the key to solving complex problems. When we bring together minds from different fields, the solution isn’t just a patchwork—it’s a breakthrough.” - Fabiola Gianotti, Director-General of CERN
I’m still developing this thinking and would love your feedback. This is a subject that I am aiming to tackle in a new fellowship programme, alongside my existing programme on Finding Product-Market Fit In EdTech. Feedback very gratefully received.
Next week, I’ll look at how metrics for learning products and how they map into this framework.
If you’re interested in Finding Product-Market Fit in EdTech, my next cohort starts in March.