Effective teams don’t just get things done — they also know why they’re doing things, and how what they’re doing feeds into a longer-term vision.
Effective teams are flexible, they can pivot when they need to. And finally, effective teams realise that each of them has a specific role to play.
Here are eight things I think contribute to creating a fast, effective product team:
1. Creating strategy together
One of the best product managers I’ve worked with understood that to get the team invested in the product strategy and vision, they had to be part of creating it. We collectively created a ‘North Star’ for the product, and each quarter we would — together — look at our business targets, then explore what opportunities we had to improve the product experience to achieve those goals. This meant our backlog was shaped and defined by the team. We also had the opportunity to add things to the backlog that maybe weren’t contributing towards our immediate goals, but that we thought would get us towards our North star. These could be picked up from the backlog when we had time in between the more business-critical items.
Understanding how our work directly contributed to business goals meant we all knew the purpose of our work, and kept us fully aligned.
2. Collaborating
Anyone who’s worked in a full multi-disciplinary team will appreciate how much more efficient you become when you have the right skills in place. It’s really hard doing things outside your area of expertise, so if for example, a designer has to also think about the copy, it’s going to take them a lot longer to get the job done. Enabling equal collaboration and leveraging different skills not only makes the team super-effective, but it also makes team members feel their contribution is valuable and gives them confidence.
Confidence is essential for a team to push forward innovative ideas and take considered risks.
3. Having a stepped process
Effective teams understand that it’s virtually impossible to go from zero to hero overnight. Sustainable and effective change is a gradual process. It might sound counter-intuitive to speed to evolve something slowly rather than completely renovate it, but it’s often the small incremental changes that add up to a big overall impact.
In the process of making small optimisation tweaks on one part of a product, you’re also learning a lot that will feed into the bigger innovation projects or new features. The team that works most efficiently works on a combination of small changes they can learn from, and more strategic, bigger projects which they can enter into with the confidence of learning from the small things.
4. Making things measurable
Having a purpose is important, but it’s just as important to track progress against targets.
The teams I’ve worked on who regularly see how they’re tracking against their goals are the ones that keep up momentum.
Making goals and current results visible in a place where the team meets regularly is one way to make sure everyone’s engaged. It’s also really helpful for individuals to be able to go into monthly review meetings with a clear idea of how they’re contributing to the company’s targets. The shared accountability of targets means that everyone has the power to make an impact, and everyone can share the success when things are going well.
5. Testing and learning
Running A/B tests and split tests is one of the easiest ways to test an isolated change such as copy or visual design. It’s also a great way to test a hypothesis before you commit to bigger changes.
Teams that don’t have the ability to test can run up against opposition to changes they suggest because there’s no way to justify the effort and resources needed to make the change. This leads to frustration within the team and resentment, which always slows down velocity.
When small tests can be run, it enables teams to put a value against a change, which can then be used to estimate the incremental impact of rolling out the change permanently. This may only give a quantitative view of changes, but when teams have the opportunity to test, they feel much more empowered to come up with solutions.
It’s also true that a team who have clear recommendations based on user research need to be given the space to iterate accordingly. If research has shown something to be a suboptimal solution, then any user-centred design team worth their salt will want to make sure they can amend it. Leaving enough time for iteration after research is vital for a team to feel confident in their solution. This can be hard to do when you have engineers itching to build, but I’ve found that the most effective teams get their design team running two or three sprints ahead of the build team for this very reason.
6. Knowing when day two is
Nothing is more demotivating to a team than the expression ‘Let’s look at that in day two’ when they know that day two will never come. Shipping an MVP is one thing, but taking away the ability to iterate is super-frustrating.
Effective teams accept that they might need to postpone some things until after launch, but they have a backlog of prioritised items ready to go just as soon as they can. Of course, all backlogs are subject to change and refinement, particularly if there are teething problems or more urgent bugs that need fixing. But it’s helpful to set a ‘day two’ date, or a target date to get the first round of iterations made by, even if it’s more of a window than a deadline.
Allowing a team to see there’s a future vision for the product and that their ideas haven’t been parked indefinitely is really important if you want the team to feel enthusiastic, motivated and inspired.
7. Shipping regularly
Designing but never shipping is really demoralising for a team. This can happen for many reasons in businesses, but it really damages productivity and morale. Nothing makes a team drag their feet more than the lack of a deadline. It’s also heartbreaking to invest time and effort into something which then sits on a Jira ticket or in a forgotten file for the rest of time.
For this reason, it’s not a good idea to get the design team out too far ahead of development. When designs happen too far in advance they can get put on a development backlog then superceded by other things.
Finding a balance between longer-term strategic work and short term tactical changes is hard, but also one of the reasons why allowing testing is so important. Tests may seem small, but just the fact you’re putting changes live can be enough to keep a team motivated and moving at pace.
8. Acting on regular retros
As with testing and learning, retros allow you to get feedback and make small calibrations to your team’s ways of working. Effective product team leaders create psychological safety for team members to speak their minds in retros and really say what is or isn’t working. They then actually assign actions to the team (or themselves) to make the necessary changes.
The teams that regularly feedback, listen, and take steps to make things better, are the ones which over time will move from storming and norming, to performing. And top-performing teams are those which create brilliant work together.
This post was originally published on Rachel's Medium.