2021
Making my team more user centred at BT
The My account alliance is one of the largest and most complex in BT and EE and accommodates roughly 200 people. Our alliance is accountable for customer journeys that include changing your settings and marketing preferences, checking your data usage (phone or broadband), buying an add-on (Now TV pass), and controlling your costs (setting up direct debits).
For a company like BT and EE, with over 45 million customers (combined BT and EE), goals, and needs change frequently and it’s up to us to continuously meet those new demands and try to exceed them where possible.
In order for us to keep doing this, we need to continually improve on the way our organisation is structured. Below is a snapshot of how the team was structured. The team consisted of 17 Product Designers and 4 Content Designers.
The challenge is that our customers view our services as one singular journey, indifferent to the department or team(s) that are involved in designing and building that service. So, to ensure our teams are more focused on customer goals and less on platform technology and product features (as they are today) we needed to better organise ourselves around our customer lifecycle model.
To ensure our teams are more focused on customer goals and less on platform technology and product features (as they are today) we needed to better organise ourselves around a customer lifecycle model. This directly corelated with our UCD Language definitions, which are below:
We decided to lean on the LBGUPS (learn, buy, get, use, pay, support) framework.
Taking a service design approach to our organisational re-design using the LBGUPS framework
The LBGUPS (Learn, buy, get, use, pay & support) framework gives us a very high-level view of the various stages and touchpoints that a customer will experience during their journey as well as the ability to evolve the way we organise our people by mapping our existing alliances against each step in the journey, and sharpen our squads’ focus on the things users need to do from initially learning about us and our services, to buying them, using them and any support they might need before finally reconsidering their relationship with us (beginning this lifecycle again) or leaving us.
Mapping our existing alliance to the LBGUPS framework
With My Account having a wide range of customer goals, it seemed fitting that our alliance would connect to the use and pay steps in the LBGUPS Framework, and just like that, we were transformed into the GUP alliance.
Each alliance also consists of what we call an ALT (Alliance leadership Team) where I represent Product Design. ALTs are a cross-functional group of discipline leaders who are jointly accountable and responsible for the alliance’s performance and wellbeing. This is across Product, Design and Engineering.It was our responsibility as an ALT to collaboratively create an organisational model that would enable our squads to design more focused customer-centric journeys.
Week 1: Establishing our objectives & principles for change
Our first priority as an ALT was to reach out to each squad in our alliance and understand how people were feeling and listen to any ideas they might have. It was important to develop a shared understanding of why we were about to make changes and how this might impact our current way of working.
During week 1, I hosted an all-day virtual workshop where the ALT and a diverse group of product, engineering, and design leads from our existing tribes established our principles for change, the risks we’d likely encounter, and our objectives for this organisational re-design.
.Principles for change:
👉 Squads need to be more focused on end-to-end journeys and customer goals and less fixated on platforms and products.
👉 Each squad needs dedicated engineering resources to empower them to deliver in a continuous iterative cycle instead of using pooled resource when demand appears.
👉 If we can, squads need to be brand agnostic (across BT and EE) and share research insights across similar problems that we’re trying to solve so that we can avoid duplication of effort.
Our areas of risk:
👉 We’re not sure if we have the right skills or brand knowledge across design (product and content) to support platform and/or brand agnostic squads.
👉 Combined platform and/or brand agnostic squads would be too large (20 + people) and too much work for one single Product Owner (or Designer) to manage.
👉 Each brand (BT and EE) has very different tech stacks and will require an enormous amount of onboarding and learning for our engineers — this might impact our squad velocity.
Our objectives:
👉 Increase volume and share in our digital channels.
👉 Exceptional customer experiences that will generate better CSAT, NPS, conversion and task completion rate.
👉 A continuous iterative approach to our organisational re-design where feedback is shared freely so that we can adapt when necessary.
Week 2: Defining customer goals for our alliance
In week 2 we ran a number of virtual workshops together with our alliance leads to try and establish all of the customer needs we could think of across Get, Use and Pay. We then prioritised these needs, grouped them into themes, and passed them through our customer goal engine.
The customer goal engine (see right) is a simple tool that asked 3 simple questions about the need that you had identified with an easy-to-follow ‘yes’ or ‘no’ track. The purpose of this exercise was to generate a comprehensive list of customer goals across the GUP alliance that we could group and use to form the skeleton of the squads we’d need to stand up.
See customer goals created below.
Week 3: Ideation
The following week, we broke out into separate, cross-functional groups in an attempt to generate some ideas that might work whilst considering the various constraints (tech and budget) that we had previously established.
1. Brand & Platform Agnostic Squads:
Customer journeys across BT and EE really aren’t that dissimilar. On the face of it, both brands offer our customers broadband, mobile, and TV packages with varying price points and perks yet the customer goals across each are almost identical.
Removing the brand from the experience we’re designing for brings us closer to one single system of design, engineering, and product that can scale seamlessly.
Opportunities:
👉 Avoids duplication in effort across design, product, and engineering.
👉 Allows for better alignment and communication across the squad.
👉 Greater flexibility to move people to different squads in any alliance as we’ll have more common ways of working between squads.
Risks:
👉 Onboarding engineers to new tech stacks will take some time and that may subsequently impact velocity in our sprints.
👉 Managing such large backlogs that involve so many stakeholders across multiple brands is a lot to ask of one squad.
👉 Squad sizes might become unmanageable considering we need enough engineers to develop solutions for both BT and EE, web and app.
Verdict:
👎 This felt like too much of a departure from our current way of working and would have required a long period of onboarding new tech stacks across both BT and EE for our engineers.
2. A Multi-Tribe support squad:
This squad would be responsible for managing release cadence, iOS/Android fixes and updates, merging and rejecting pull requests across the alliance, and monitoring the standard of code across our engineering team.
Opportunities:
👉 Alleviates these responsibilities from our product squad engineers and enables them to focus solely on delivering against their sprint goal(s).
👉 Ensures that the products we build are both secure, flexible, and accessible to other engineers who might need to clone it in the future.
👉 Theoretically, with more people and more a more considered governance process, this squad could be expanded across the department managing code across our entire digital department.
Risks:
👉 We currently don’t have enough senior engineers to staff this squad so we’d need to embark on a recruitment drive to ensure we get the right people in place — this could be costly and take a lot of time.
👉 A governance process for merging and rejecting new code is currently unique to each squad and there is no standard way of doing this across the alliance. Setting this unified governance process will take time and may impact the velocity of our product squads in the short term.
Verdict
👍 We loved the flexibility that this squad would give us and the freedom it’d give our squad engineers so this was an idea we wanted to include in our final proposals.
3. A special projects squad:
A solution that highlights the imperfections of the LBGUPS framework but nevertheless gives us the opportunity to potentially pivot where necessary and explore unique customer problems that could fall between the gaps of the LBGUPS framework.
Opportunities:
👉 Covers a broader range of customer goals that don’t necessarily fit within the LBGUPS framework.
👉 Supplements existing product squads to cover holidays or absence if needed.
👉 Helps our existing product squads to conduct more long-form qualitative research that could help us uncover more in-depth customer insights.
Risks:
👉 Becomes abstracted from the alliance and our existing product squads.
👉 This isolation and possible lack of communication could unknowingly lead to duplication of effort.
👉 Continues to encourage us to think about our products as projects and not the other way around.
Verdict:
👎 We felt that this idea didn’t fit within the LBGUPS framework and would have become too abstracted from the rest of the squads in our alliance.
Week 4: Defining our alliance model
Now it was time to combine our ideas into one that we could trial and adapt when necessary.
Here’s what we committed to:
Opportunities:
👉 Our squads have a clear and focused view on the customer goals they are designing for.
👉 A separate multi-tribe support squad can help us manage pull requests, define release cadence, and iOS/Android maintenance for the entire alliance enabling squad engineers to dedicate all of their time to each sprint.
👉 We won’t lose domain knowledge (tech stacks and stakeholders) as our squads will remain brand-specific (for the time being).
Risks:
👉 How do we effectively communicate the opportunities, risks, and differences to our existing way of working?
👉 People will take time getting used to this new way of working and may initially impact the velocity for our squads.
👉 Recruitment for new roles that we need to recruit for in this model could take more time than we anticipated and delay day zero activities for a number of squads.
Measuring the impact of our changes
We decided to measure the success of our changes against 3 different pillars:
1. Positive impact on our customer experience. We’d measure journey CSAT, NPS, and also task completion rates (change of settings, buying an addon, paying a bill, or setting up a direct debit).
2. A convincing majority of positive feedback (observed through squad or alliance retros and bi-annual employee surveys) from our people about ways of working.
3. Velocity in sprints would eventually (2–4 months) recover and exceed our previous velocity rates.
Additionally within Design
Within Design further changes we're made to enhance the shared thinking around User goals and being Platform Agnostic. Additionally to share learnings, design patterns and testing cross brand.
This was done by changing the way we share work in crits, creating a space for sharing work around similar customer journeys, creating virtual/hybrid breakout spaces for more focused sessions around customer problems and more general visibility on how to create a more coherent customer experience.
Snapshot view of our chapter meetings below:
How everything is today?
Since making these changes, there's been an increased velocity in the squads output, more coherent customer experience, regardless of what platform they enter from.
Additonally from CSAT has continued to decrease, brand NPS has increased. (See below)
