Be in a Band, not an Orchestra: how to Grow an Agile Product Team "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs September 09 2017 True Agile, Product leadership, Product Planning, Skills, Team Leadership, Mind the Product Mind the Product Ltd 3013 Product Management 12.052

Be in a Band, not an Orchestra: how to Grow an Agile Product Team


Some years ago, I wrote a blog post noting that small teams are more creative and productive than big teams. I suggested that this might be because, like a band, they were self organising, communicated easily and informally and had autonomy over what they played.

Band vs Orchestra

Be In A Band - Product Tank v3.003

I contrasted this to an orchestra, which has a formal hierarchy, where communication happens in a top-down way from a conductor and where the performers, who may be hugely accomplished musicians, are given a part to play.

Be In A Band - Product Tank v3.004

I suggested that as someone in a position of leading a digital product team, you should always strive to make your team feel like they are in a band and not an orchestra.

Growing FutureLearn

I’m now Chief Product Officer for FutureLearn. The company is a little over four years old and I was one of the founding team.

FutureLearn’s mission is to pioneer the best social learning experience for everyone, anywhere. Our aim is to make higher education more accessible, flexible and enjoyable than it has ever been and we do this by working with leading universities and educational institutions from all over the world.

We began by offering short courses, growing out of the Massive Open Online Course movement coming out of the US, dubbed by Clay Shirky as education’s MP3. Earlier this month, we began offering our first pay-as-you go masters degrees. We’re a startup, but entirely funded and owned by the Open University (OU).

We’ve grown in those four years. We now have 120 course creating partners, who have created nearly 500 courses, which have been taken by over six million learners from over 190 countries. We also now have 106 full-time staff, about half of whom are hands-on involved in shipping our product on a daily basis.

As we’ve grown I’ve found myself continually returning to the idea of striving to be in a band and trying to avoid the creation of an orchestra. So here’s my advice for how you go from being a singer/songwriter to – instead of conducting an orchestra – creating a festival instead.

From Singer/Songwriter to Festival


The story begins with me: the only member of the product ‘team’. I was initially brought in as a freelance consultant by Simon Nelson, who had been recently appointed by the OU as CEO of its new venture. My job was to define a vision for the product and create a plan to deliver it.

Product Vision

Creating the vision for the product early was important. It provided a sense of purpose around which to put the band together, hire the team and provide a clear direction for what we would deliver without being specific as to exactly how it would be realised.

The Manifesto

One of the most important sections of the delivery plan was a manifesto of sorts which set out how the team would work. Every good band should have a manifesto. It was the foundation stone that we would continue to build upon. It gave the team autonomy over delivering the vision, what the product would do and how we would build it.

The principles of our approach included:

  • A single, small, stable, highly collaborative, multi-disciplined delivery team in a single location
  • A single product owner with decision-making authority
  • A development team empowered to deliver the product vision based on agreed objectives

Many of these will probably be familiar to you from the agile manifesto but it required some convincing of a large traditional organisation like the OU.

Power Trio

With an agreed vision and delivery plan and with the first members of the team on board, we did was what all good bands do: make a demo.

The Demo

This was close to what you might now call a design sprint. The idea was, as a small team of three, to quickly explore and understand what we wanted to build, ground the conversations with stakeholders into something tangible and test the product with the partners who would create our courses.

The prototype focused the conversation on what our product would be, gave us some ideas about how we would need to approach building it and quickly gained trust with our partners that we could deliver. It’s a technique we still use today.

Three is a great number to quickly build a prototype with. But it’s not enough to build a scaleable product. So next I had to put a band together.


Your first hires are incredibly important. They are the people that will set the tone and decide the sound of the band.

Putting the Band Together

I persuaded people I’d worked with before and trusted to join, including my right-hand in product, Simon Pearson. Through our networks we found some like-minded people willing to take a gamble on a company that had a bold vision but didn’t yet have a payroll. Joel Chippendale and Lucy Blackwell joined as our CTO and creative director.  I would ultimately forge a hugely productive working relationship with them as a product leadership trio.

Good timing was also a factor: as I was desperately casting around to bring more developers into the team, I was recommended the Go Free Range collective of developers. They were available. We met and immediately hit it off. These thoughtful and principled engineers helped establish many of the working practices we continue today.

Purpose: the MVP

The delivery plan set out a clear purpose: deliver the beta version by September. The goals were clear:

  1. To create excitement about FutureLearn among learners, teachers, the media and potential investors
  2. To create an effective learning environment that supports a small number of pedagogic approaches that can be built upon
  3. To lay the technology foundation that allows the product to be iterated rapidly
  4. To test the core features with real learners and teachers and learn from real-life usage
  5. To include a small number of courses that demonstrate best practice
  6. To help identify potential business models and features that could be charged for through observing the actions of real users
  7. To build a small but significant audience of engaged early adopters to become advocates for the product
  8. To encapsulate the key pillars of the product vision, including open to all, anytime and anywhere, celebration and reward, plus social interactions and world-class storytelling

We broke this into two milestones: we would deliver an alpha to a small audience after three months and then spend another three months before launching the beta. This way we would give ourselves enough time to deliver something of value but not go too far wrong or lose sight of the original vision. It would allow us to learn from real users how we needed to focus our efforts for the second three months.

We launched the website on time in September, and ran our first course in Oct 2013. Where next?

Big Band

This is where the story gets interesting. Post-launch was a transitional point in our life. What was a ragtag crew of freelancers who were delivering a project, morphed into committed, full-time employees iterating a website and finding a business model. I created our first product roadmap and this continued to provide a sense of purpose.

The team, once we had transitioned to staff, continued to grow. Simon, our scrum master, switched to a product manager role. We hired our second product manager, Tess Cooper.

And then things started to go, very slightly, almost imperceptible at first, astray. We were now over 20 people. Still trying to be a band. Doing daily standups, planning and retrospectives, all as one team. Communication was becoming harder. People were feeling less of a sense of ownership and understanding of what they were building and why. We were too big and stuff was breaking. And I was beginning to feel like the conductor of an orchestra. Something had to change.

Lesson 1: Keep changing and change sooner than you think

Jam sessions

By this point we had started to do what we called ‘exchanges’: a few of us would go and spend a morning or an afternoon with other companies to see how they did things and invite them to come back and visit us. For example, we visited the Government Digital Service and the Guardian.

I also used the excuse of curating a Product Tank meetup to speak to people like Michelle You, CPO at Songkick. And I spent time reading some thought-provoking pieces on team organisation published by companies like Spotify. These were invaluable insights that helped to work out what to do next.

Lesson 2: Seek inspiration from outside and learn from others


The solution, of course, was to make people feel like they were in a band again. So we decided to turn one big team into three small teams.

Giving Purpose to Three Teams

The question was how to split up the work and give these teams a purpose. We discussed a team focus on projects but quickly discounted this as it wouldn’t give the team a sense of real ownership and would create a large amount of management overhead.

We’d recently outlined a new strategy, still pretty tactical a few months after launching, which we boiled down to:

  • Growth: grow the number of learners and enrolments
  • Experience: continue to develop the learning experience
  • Commercial: start to find the business model

So we focused our new teams on each of these goals.

The Friday Meeting

As we’d gone from building a website to launching it, our sprint review had evolved from a standard sprint review into an all-hands meeting, of which I became the default host. As we began running courses, it became the forum to report on and review these as well as the product.

Soon, every team in the company got up and presented progress from the last two weeks. And in a rapidly growing team it became a crucial way for everyone to know who everyone is, what they do and all of the important stuff going on. On a Friday afternoon, with a beer in hand, it became a great atmosphere of camaraderie and celebration of progress.

However, we’d lost the opportunity for conversation, questions and critique that you need in a sprint review. So as we introduced three teams, we kept the old all-hands sprint review, and reintroduced a sprint review for each team.

The only problem was, we didn’t know what to call the all-hands meeting. So, because it happened on a Friday, it became: The Friday Meeting.

The Roadmap

At this point each team had its own roadmap, but they were agreed together on a three-monthly cycle and shared with our partners in a nicely transparent document.

Be In A Band - Product Tank v3.032

Despite each team having a product owner, with whom I would closely collaborate to arrive at the roadmap, I still was very much seen as the owner of the roadmap. The teams didn’t feel close enough to it and didn’t always have a clear understanding of why things had been prioritised.

The number of stakeholders had grown in such a way that all had input but no one could see their influence. Instead of providing a sense of purpose, it felt like a straitjacket. Rather than give autonomy to the band it was providing too much top-down direction, much like handing out sheet music for an orchestra to perform.

It was time to change again. I’ll come back to how we fixed it in the next section.


We’ve now grown beyond the three-band gig. What we now have is more like a festival. Before I talk more about that, I also want to mention another important change that we made last summer.

Cross-Discipline Teams

We’d always worked as multidisciplinary product teams, by which I mean product managers, developers and designers working together. But last summer, we took this one step further and organised our whole business around a few strategic objectives and created a cross functional team, tasked to deliver them.

Rather than have a marketing team, a content team and business development team working with product teams, we created teams made up of both product people and other disciplines including copywriters, partnership managers and business development.

The aim was to focus, align objectives and break down the traditional conflicts that you get between product and disciplines like marketing and business development. Each of these teams should be self-sufficient, have autonomy over how they achieved their goals, and worry less about involving everyone in the organisation – something that was becoming time-consuming.

Lesson 3: Keep teams small, but make sure they can play all the parts

Be In A Band - Product Tank v3.036

Purpose: Mission and Metrics

We provided purpose to each team by setting them a mission and giving them ownership of one of the key company metrics.

For example our Learner Sales team mission is:

Make FutureLearn commercially sustainable through paid-for products and services that help learners achieve their goals and celebrate their learning.

…And their metric is Revenue Per Active Learner.

One of my recent recruits asked me soon after she started, “So what product do I own?” My answer was that the product was but what she owned was the mission and metric and she and her team could touch any part of the product to achieve it.

However, there was one condition, they should communicate with others, not ask permission but always ask for help. They should feel free to do what was required to meet their own goal but be good citizens and communicate what they are doing and why.

Lesson 4: give the team purpose and autonomy

Team Culture

The teams have developed their own cultures. Team nicknames have emerged. For example, Discovery and Activation are affectionately referred to as “Disco”. They have their own mascots, often this is the conch that is handed around at the morning standup. Discovery and Activation’s mascot is a mini disco ball. And each team now has its own badge.

Be In A Band - Product Tank v3.042

All these things should emerge naturally and, when they do, be supported and encouraged: like it would for a band, it gives a sense of identity and shared purpose to a team.

This culture should extend to letting teams do things in ways that work for them. For example, some of our teams use Pivotal Tracker as their main project management tool, others use Trello. I was initially worried about this fragmentation but the benefits of autonomy and identity trump it.

Lesson 5: encourage all things that provide a sense of shared identity

The Owned and Organic Roadmap

Each of our teams is responsible for their own roadmap – not me. It’s down to them how they achieve the mission they’ve been set and move the metric that they are accountable for.

Instead of it being one nicely presented document that is ‘published’, they are now an organic, living breathing thing on Trello, where each item has a thread of evidence and collaborative commentary.

The key thing to remember with a roadmap is that the document itself is uninteresting. It’s the process of understanding and negotiation that the team goes through to own the problems and commit to solving them that is its real purpose.

Lesson 6: Let the team own its own roadmap

Keeping it Coherent

So if everyone is in their own band, with their own sense of purpose and autonomy, how do we keep it coherent? How does the festival come together?

Firstly, you have to accept that the benefits of speed and a sense of ownership are worth the price of a few inconsistencies that inevitably emerge. What’s important is ensuring that the missions you set teams don’t lead to the seams being visible in your product. And you need to provide space for teams to clean up the inconsistencies that occur.

The second is to create forums for collaboration. We do two key things here:

  1. Most discipline teams have team meetings and other activities as a team. As a product management team we have a fortnightly team meeting, a fortnightly standup and a monthly retrospective. The design team has weekly critique sessions. The front-end team has a fortnightly meetup.
  2. We have created a pattern library that all teams use. When designing new things the starting point is to use atoms and molecules that already exist. If you need new ones, you contribute these to the library.

People also sometimes change teams. This gives individuals the opportunity to develop, and allows us as a management team to decide to put more emphasis on a particular thing by temporarily making one team bigger. It allows members of the team to take with them knowledge from another team, and to share best practice.

And finally, the Friday Meeting is now the Thursday Meeting. But it still happens every fortnight and is as important now as ever as a way for all the bands to understand what the others are doing. Now each strategic team presents in its own way, with little hosting required. And that host is no longer me. In the style of UK TV show Have I Got News For You, we have a guest host from elsewhere in the company every fortnight. And it’s all the better for it.

Lesson 7: Create ways to communicate and collaborate across teams


So, what lessons should you take away from this? Keep letting go is a key one. And do it sooner than you think or feel able to. It’s a cliche but, trust the brilliant people that you’ve hired. It’s your job to find ways to give them autonomy, a sense of purpose and space to do their best work.

Here are the seven lessons:

  1. Keep changing and change sooner than you think
  2. Seek inspiration from outside and learn from others
  3. Keep teams small but make sure they can play all the parts
  4. Give teams autonomy and help them find purpose
  5. Encourage team everything that creates shared identity and purpose
  6. Let the team own its own roadmap
  7. Create ways to communicate and collaborate across teams

Oh, and of course the most important one: Be in a band, not an orchestra.

One thought on “Be in a Band, not an Orchestra: how to Grow an Agile Product Team

  1. The key is understanding how an orchestra is organized. Not how they perform. Those are 2 different things. Understanding how they are organized allows you to see there are leads among groups of instruments and it goes to a skilled musician. Its no different in design and development, everyone is “involved” at some level but you should always want the individual who is most skilled for that group task to take the lead. This does allow for spontaneity because that will show in rehearsals and the conductor can decide to switch who plays lead. The risk of having someone as things are going into production go rogue is the exact opposite of what is needed for a product.

Leave a Reply

Your email address will not be published.