Team Hub

Team

• 1 x Product manager

• 1 x Product designer

• 2 x Front-end engineers

Role

• Research

• Lead Designer

• Design System

Context

At Progression we realised that we were not delivering the core experience that larger organisations need in order to feel confident that their content can be built, managed and rolled out in Progression. We broke this large overarching problem down into 3 parts.

Problem 1 — Management

Difficult to manage cross-team build and track progress, so many orgs spin their wheels, take build activity offline, or fail to get there at all.

Problem 2 — Content

Content is not scalable and reusable and should be supported by productising our 'human' advice which we know gives orgs a high confidence boost that they're building right.

Problem 3 — Settings

A lot of people touch the content and we have increasingly complex org settings to manage, so simple, reliable permissions, people and preferences management is important.

Supporting context

We know all this from the extensive customer interviews each team was doing, and were able to spot patterns across all the insights we were getting.

Brainstorming

All team got together to lay these problems out on an opportunity tree. We mapped out our desired outcomes and under each outcome listed the opportunities (customer needs, pain points, desires, and wants) which would drive us to those desired outcomes.

We then had a brainstorming session to generate ideas on how to address the opportunities. We then prioritized on effort, impact etc. and voted on some starting points. Doing this made it so everyone has a really good idea about what we hope to achieve by exploring these ideas, and this gives us a nice set of ideas to start exploring

Problem 1 — Management

My team were given problem 1 to tackle first — it's difficult for customers to manage cross-team build and track progress, so many orgs spin their wheels, take build activity offline, or fail to get there at all. Customers may never see any value.

What does success look like

• Adoption and engagement with tools

• Positive user feedback

• % teams moving through implementation stages = reduced time to roll out

If it’s simpler and quicker for customers to build and launch a team, the path to value will be clearer. Progression will then be adopted by other teams in the org increasing engagement, retention and subscription value.

Constraints

Over a 2 week sprint we aimed to build quickly and reuse existing components where possible, enabling simultaneous design and development with frequent feedback loops, aiming for a release-and-learn strategy.

Customer journey

To help us understand this problem more, along with our customer service team we defined a set of 'implementation stages' to better understand the steps a customer takes to build their team(s) and roll them out company wide. By understanding this process more we can offer appropriate guidance where necessary, understand at what stage people where stalling or failing. There are 6 implementation stages:

1. Explore

2. Learn and practice

3. Build, create, tailor

4. Initial pilot / stress test

5. Full team roll-out

6. Roll-out complete

As a bonus problem, it was hard to know what stage a customer was in without reaching out to every customer individually. The most critical stage was moving from 3. Build, create, tailor → 4. Initial pilot / stress test. This was the point a customer went from building their teams to sharing and testing with the rest of the organisation or team members. It's so critical as it directly relates to customers moving from activation to retention. If they never transition from one stage to the next or the transitions goes badly they might churn or the build process stalls and puts them at risk of churning.

There are many problems that arise at this stage, which we divided into Customer Pains and Product Pains:

Customer Pains — issues that customers have going through this process

1. Lots of decisions around content that is not necessarily owned by one person

2. How do the team get aligned on content and process??

3. Visibility of how complete a team(s) is/what 'done' looks like

4. Impact of team launch (salary/benchmarking/skills gaps)

5. Getting buy in (how to/who with/when?)

Product Pains — issues with the app or features

1. Skills duplication

2. Everything feels permanent so building is scary

3. Collaborative build experience not great

To sum-up customers have a hard time understanding what a complete team looks like and with skill creation and team building being handled by different people in different teams, it's very hard to keep track of if something is 'done', especially if you don't know what 'done' looks like. Many customers where creating their own workflows in spreadsheets etc. to solve this problem.

Jobs to be done

I talked to a few customers who I know have created their own workflows in spreadsheets to find out a bit more about what they’re trying to achieve. Using that information I started thinking about jobs to be done of an Admin (the person responsible for building/project managing team building) are, and how we could help them to complete them. This was a useful exercise as it really helped to make some nebulas problems into very tangible tasks. A lot of the jobs could be achieved by making things that admins were doing in the app more visible to other users. This might be a thing that has been completed, a situation which needs addressing or simply who is working on what.

This process was then repeated from the point of view of an editor (someone who can edit specific teams they are assigned to help build but not create anything new ones), with a lot of crossover in JTBD as an Admin and Editor need visibility over the same things during the build process — with Editors only slightly limited on what they could do.

Explorations

At this point I talked with the squad about some starting points and we wanted to explore the idea of statues. Currently the teams each have statuses — Draft (visible only to Admins and Editors), Live (visible to everyone) and Public (visible to everyone and published to an external URL). I wanted to change these statuses to align more with each implementation stage. This way we would have a clear idea at what stage each customer was at and an Admin/Editor would be able to clearly show what state the framework was in. If we were to then make these statuses visible from a central place it would be much easier to see the overall progress of framework builds.

The statuses are:

1. Stage 1-3: In progress — in the process of being built

2. Stage 4: In review — the team is ready to be checked by others

3. Stage 5: Live — this would show the team is complete

4. Stage 6: Live (public) — the team is complete and live to an external URL

So what we are essentially trying to achieve is help people move from In Progress → In Review. A user changing the status of their team in this way would tell us they are moved from Stage 3 to 4. We could then start to get a clearer understanding of the customers who had stalled (no teams In Review), customers who were moving through the process smoothly (lots of teams In Review) and customers who might be struggling (teams moving back from In Review to In Progress regularly). We could now reach out to them and offer assistance at the right times.

Team Hub

I created an overview section within the app which we called Team Hub, this would be a central place that an Admin or Editor could view and access all their teams from. Each team has a status as mentioned earlier, an assigned Editor(s) and a 'last edited' time stamp.

Comments in Progression can be made within a team on positions and skills. These already provide a great way for editors to collaborate. The problem is you need to go into a team to be able to see them. The Team Hub brought these unresolved comments into one place so Admins and Editors could then get a good idea of what type of problems (if any) Editors were having.

These small additions in of themselves do not seem much but combined would give an Admin a clear overview of what was happening with each team and unlock a whole new way of providing feedback for customers. For example if the team was in progress and hadn't been edited in a while it was easy to see which editors you needed to reach out to, or if a team was in review with a lot of unresolved comments it is clear that people are engaging with the process.

I put these ideas in front of some customers to see if we were on the right lines and see how they aligned with some of the things they had been doing in their spreadsheets.

From talking to customers I tried a few quick ideas based on some feedback and suggestions. Some of this proved too complex or not necessary to create that core value.

Much like other projects at Progression we wanted to work quickly and get a rough version built so we could see how it feels to use. We decided to stick with a table component we had already used throughout the app, with a simple graphic to show the ratio between statuses. Once we had established the data the table would show it was quite quick to put together. We could then substitute columns or add/remove them to test different things very easily.

Organisation rollout progress

I also added a chart which displayed the ratio of statuses — with this you can see at a glance how far the organisation is from a fully rolling out all the teams. The idea was to add some urgency to the build process and encourage people to get their assigned team over the line. For example if they see their team is the only one which hasn't been completed this could provide some motivation.

Optimised volume of content

Another idea which was floating around at this point was the idea of content quality. This was linked to the problem of not knowing what done looks like, and encouraged editors to aim for optimum volumes of skills and examples. This acted as another indicator of were work needed to be done. The general concept seemed to resonate with customers we showed it to but it proved too complex for this MVP. The plan was to revisit this as a follow up.

Feedback loops and testing

We built and designed simultaneously, having regular conversations with the engineers and feedback sessions to make sure we were aligned. Usually in the form of a video which people could feedback on in their own time. High context on the problem is really important for all team members, so everyone can express their ideas and make more logical decision around scope in order to move quicker, encouraging a release and learn approach. The aim was to keep cutting down the idea to the core value. Engineers started building the core of this Team Hub as I ironed on flows.

This process was helped by having a constant stream of calls with customers. We walked them through these ideas and compared them to the processes they’d created themselves, and tested some real-world scenarios. Helping us to narrow down on an MVP.

Impact

General feedback from user testing was very positive with people immediately finding the concept useful and exciting. Especially those from larger organisations where losing track of progress is a bigger problem and harder to wrestle back under control.

“This is brilliant, I can get rid of my spreadsheets now!”

“Just what I needed. We’ve already seen people start to engage more, especially with the comments.”

“I think this is the start of something really powerful. This along with the templates is making a big difference.”

Something to note is that as an early stage startup we didn't get a lot of traffic so it took weeks before any quantitive data became useful so we mainly relied on customer feedback as a way to measure impact.

As squads we set up our own dashboards to measure anything we might find useful beyond these metrics. This was a great way to give ownership to the squad and create excitement.

After launch the Team Hub started to get a lot of traction with people visiting it regularly. This was a good start but of course doesn't necessarily mean it's working as intended, just that people could find it easily. We knew who to reach out to as well to get some feedback.

However, it was positive to see that customers started to interact with the statuses and start to adopt the workflow. In just over a two week period there were 262 status changes, with 36 (14%) going from In Progress to In Review. It also proved very useful as an internal tool for customer service to pinpoint which organisations might be struggling and need some help, if for example they had a lot of teams all In Progress for a long time. Overall it was a positive outcome with lots of ideas for how we can build on top of this strong foundation. It was also satisfying to see how quickly it came together.

Conclusion and learnings

The Team Hub felt like a great foundation to build on, and the quick exploration of other ideas in this area meant we had some nice ideas to revisit as a potential next step.

Perhaps we could have learnt quicker that things like the content quality idea was too big to explore at this stage but it didn’t feel like wasted work more an excitement to keep exploring.

The speed in which we worked and the design and build simultaneously actually freed up time for design to try a few ideas. I think in general this approach is great for this very iterative way of working but does need practice to get to a high level of efficiency. But great to see the enthusiasm of engineers in the customer calls and how much context they had of the problems.

As we explored we found a lot of hidden issues such as how much of a mess the settings were in just by attempting to move some features to the Team Hub, which stopped us being able to do everything we wanted. As this was just an MVP though, it was something we can live with. The navigation remains a big problem and the position of the Team Hub felt a little bit plonked on but again, ok for now.