What can product teams do when they’re suffering

Originally posted at "What can product teams do when they’re suffering" in albuquerque.io

This is the follow up to the post “What makes young product teams suffer”. Here’s a TL:DR of the 7 scenarios mentioned in that post:

1. Weak communication between engineering, product and design teams 
2. Projects, tasks, code and dependencies are disconnected 
3. Teams care about dependencies too late 
4. No thinking, planning and mapping before execution 
5. Different processes even within small teams 
6. [Design/Product/Frontend]-Driven Scoping 
7. Scope-rigid and timeline-rigid

Before acting: make the issues clear to everyone

Leaders tend to jump straight into solution-mode, but driving cultural change requires everyone’s buy-in, otherwise it’s just another top-down policy. Show the issues the team is suffering from, give space for reflection and drive them to the same conclusions you reached. Make them say “Yes, this is happening, and yes it needs to change”.

So what can be done?

Your first thought is probably “let’s just implement a tool and it will solve every issue”. It won’t. It might even generate more chaos (learning curve, process disruption, weak migration…). What you need to do is change the operating system itself: the execution culture. Here’s some actionable pieces you can apply and move your team into a healthier place:

1. Make people feel like they’re in a squad, one team 

Bring everyone under the same roof, get a team acronym (eg: PED for product, engineering and design) instead of three teams. Get a group slack channel for all these members. Give them a team @ email or slack handle that pings everyone. Kick off team meetings where everyone is invited. Do a group offsite, team dinner, anything that makes people realise they are one team.

2. Implement daily stand-ups

“Stand-ups” or “Dailies” are common rituals in agile, but here their importance is about bonding, breaking silos, fostering collaboration and letting communication flow. It also imposes rhythm, as everyone wants to run as fast as the person next to them. It’s a great opportunity to evangelise the product mindset of “paddling together”. Make it daily, same time, everyone participates, and as short as possible (45 seconds per person).

3. Create your version of sprint 

Small teams don’t need the agile formalities, your focus should be around shipping, delivering, running fast and learning. But some parts of the agile theory are ROI-positive even at small scale. Create your own type of sprint: a specific time-box, a clear selection of issues being tackled in that time, a scheduled moment to plan together what these issues are, and a short moment to reflect on what went well or not (retrospective). This shouldn’t take you more than 2 hours a week and the alignment benefits are quite tangible.

4. Get everyone under the same process 

Align all teams by making them follow the same process. This way you can plan at the same time, as a squad; you can sync and collaborate on what is blocking each member, identify dependencies and have a common method of assessing who is slowing down the group.

5. Get a tool in place, but keep it simple 

Yes, the tool matters as long as 1) is custom to your needs, 2) simple enough for a quick learning curve, 3) everyone using it and 4) connected to the projects (eg: code repos) and processes (eg: deployments). Don’t think just because you have a tool you no longer need face-to-face moments, especially in small teams with tough goals. The tool is a mean to an end.

6. Choose between timeline-rigid or scope-rigid

Even if you need to cater to top-down requests or feature decisions, you need to make clear that it’s either scope-rigid ?? (this is what we need to deliver with little flexibility on what can be cut) but the timeline to deliver needs to be flexible, OR the target deadline is rigid ? but you’re free to cut the scope to guarantee that date.

7. Involve backend early as early as possible 

To prevent falling into scopes driven by product or design, or even getting frontend developing too soon, enforce moments where backend is exposed to the whole scope and helps define the boundaries. Schedule this “kickoff” as soon as you have clear requirements, but before starting any design/development. Get the whole team in this meeting, make it clear whether the product is timeline or scope-rigid to align expectations. Even if backend is in the middle of something else, disrupting them for a little bit can be net positive in the end, as their insight can guide priorities, dependencies and what goes into being built.

8. Evangelise “lean scoping” 

The importance of “shipping fast-learning sooner” should be greater than feeling your product is complete or beautiful. But this mindset of “MVP” or cutting a scope in order to deliver faster should not be a burden of the product team alone. No PM is proud to hack their products into barebones, so make this easier by having everyone pitch in. “Can you do less code?” “Can you design less?” “Is it really necessary to do X, Y or Z for this launch?”. Share the burden across the team.

Have you put in place other tactics that made your product team stronger, happier and more successful?

If you enjoyed bring on those 50 ?? to make more product teams see there’s a way to get to a better place.