Transitioning to Full-stack Product teams (and what did we learn along the way)

Useful practices to get the best from Specialized teams applied to Full-stack Product teams

NOTE: This article is not intended to give a detailed description of how a Product Team should be structured, but to share some positive practices that helped boosting quality and productivity in a multi-disciplinary and fast-changing team ecosystem.

Nearly 3 years ago I joined a Product team with a very peculiar setup. For a little while, we were a team of 7 Product Owners working with 3 back-end development teams and 1 UX team.

Each development team was dedicated to a different part of the organisation’s B2B domain, and the UX team was supporting all of them. Respectively, each PO was focusing on a different product (more or less related to business goals, not not necessarily front-end bounded) within the B2B side, meaning that there was no dedicated group of people with different expertise focusing on the same thing.

It’s easy to figure out some of the issues we faced: back-end / UX misalignment, back-end overlapping, emergence of tech silos, lack of shared vision,… and all of this payed off in the form of demotivation and limited productivity.

Transitioning to multidisciplinary teams was probably an easy decision to make. It just made sense having dedicated groups of people autonomously (resource-wise) “working on the same thing”. Although the new format had few other challenges (some of which I analyzed in this separate post), I would like to focus now on the positive things of having specialized teams, and how to leverage them moving to a multidisciplinary setup.

• Product Owners needed to sync-up. It’s not that we wanted to, it was our normal status. We were a team of 7 Product Owners sitting together having to literally fight for resources. It was actually hard to miss what your colleagues were doing and what was the status of your satellite products.
• Prioritization was tough (and that’s good). Having limited and shared resources led to some tough discussions (constructive friendly-fire most of the times). This made you think twice about the business value of your stories. Brainstorms were thriving and nobody took anything for granted. Although agility was often arguable, this period raised my work’s quality standards and helped me shaping a thorough product thinking.
• Easier to align with the business. 1 single and united team of Product Owners meant 1 point of contact. Alignment with other parts of the business was also the standard. This union also gave the team quite some lobbying and influential power.
• Efficient back-end development. High quality standards. That is, within each independent dev team (as mentioned before, there was some overlapping between teams). Working with a bunch of peers, all experts in the same area and language (call it Ruby, Perl, PHP, …), creates a natural environment to encourage good coding practices and pursue high quality. Some trade-offs on velocity…but let’s take the discussion of Velocity vs Quality vs Meeting business needs into a separate post.
• UX was consistent along all the Products. As with back-end, having all UX expertise concentrated in a unique group of professionals helped being consistent and pushing for quality. Main trade off here was the lack of alignment with back-end (some ideas to tackle that here), and sometimes with business requirements too.

The challenge then becomes how to facilitate those positive outcomes in a scenario where the expertise is scattered within independent Full-stack teams. Let’s start by not calling them independent, but self-sustainable. There are many dependencies with other teams, but if other teams would not exist, they will still be self-sustainable.

After a couple of pitfalls we noticed the obvious issues. Just try to put a “No” on each of the points listed above and you will get the direction into which things were turning. Here is a list of 7 simple practices that helped us keeping the best of specialized teams:

1. Build Specialists’s Communities. In a similar fashion to Spotify’s Squads we made sure that each specialized area (UX, back-end, front-end, analytics,…) of the Product Teams built community within their expertise. Some examples of ways used to keep the communities closer: chat-rooms (e.g. UX, infrastructure, iOS, etc), regular update meetings, showcase of progress, ..
2. Organize Tech talks. While these are very common to present specific technologies or products that the company is adopting, we often used them to deep-dive into parts of the stack that was prone to overlaps or dependencies. The talks often helped creating awareness about ownership or focus areas, preventing duplication of efforts and facilitating cooperation.
3. Encourage Project catch-ups. It is common to have multiple teams working towards the same or similar goals (usually quarterly and company-wide). It is also frequent to have dependencies on other teams (especially on e-commerces). To give a practical example, one of our most complex projects consisted of a communication platform between supply, demand and the organisation itself. The platform touched at least 5 Product teams (B2B, end customer, operations, security,..), we heavily depended on each other and we had to progress in parallel in order to release successfully and effectively our products to all the different sides of the business. What started as an informal weekly chat ended up being the place to go for discussing progress and roadblocks, sometimes saving all of us uncountable hours of emailing each other. The meeting consisted mainly of Product Owner and sometimes senior stakeholders, who then cascaded any relevant updates to their respective teams.
4. Write / give Regular updates (reports). We Product Owners / Managers tend to have a love-hate relation with these. It usually starts with the later, but turns into the former when it’s brief, becomes more or less standardized, it has a consistent periodicity and it encourages healthy discussion. There is a very thin line between brief, useful reports and overkill “everythingwehavedone” writings, closer to religious holy books. While these regular updates tend to be requested and encouraged by Management level, they are also a great resource to share progress and initiatives at and within the different layers of the product.
5. Organize Showcase / Show & Tell sessions. These are frequent at UX level, however they can become more resounding and help opening up to different perspectives when having a wider spread of roles represented in the audience.
6. Run Bug bashes. I’ve heard people saying that a bug bash is a waste of time, when in reality they were not running bug bashes. Having some members of a team testing their own product is not a bug bash. A properly run session will not only help ensuring the quality of the product being tested, but will also help creating awareness of the product within external participants. To certain extend, and without forgetting its main objective, it could turn into a useful showcase. There are many articles describing best practices for a bug bash. While I work on mine, here are some good tips from Netguru.
7. Organize prioritization meetings with guests. Sometimes we become so focused on our roadmap that we end up working inside a bubble. Having an external guest in prioritization meetings will make us question certain things, help us bringing a fresh perspective and prevent us taking things for granted. I have experienced situations that made me re-think the status-quo of the team and even the need of its existence. This can be especially helpful spotting assumptions.

At the end it all comes to good, effective communication. Any structural change will always improve the communication in certain direction, at the price of its detriment in another. The key is to identify any existing silos or alignment gaps that may appear during transitions, and to detect what works better on each scenario. I hope this article will be useful and encourage readers to spot those gaps within their organizations, and that the ideas shared will help getting the best of connected, self-sustainable Product Teams.

Thanks for your time, and as always, feel free to share thoughts, ideas or more best practices if you have experienced similar situations.

Please like, share and comment if you enjoyed it!

For further reading on this topic:

Spotify engineering culture. The model into which we transitioned happens to be pretty similar to Spotify’s Squad / Tribe / Chapter / Guild model. This great presentation has been shared more than 5k times by the time of writing this article, and it may sound familiar to product readers.

Hudl Product structure. A similar example, heavily inspired in Spotify.

Buffer’s case. The evolution of a company’s Product structure through 4 different models.

SVPG Good Product Team, Bad Product Team. A nice nod into The Hard Thing about Hard Things’ “Good Product Manager vs Bad Product Manager” chapter (great book, by the way) by Marty Cagan.