We’ve all read them; they’ve been around for decades: Books on management, product development, and team-building practices are in plentiful supply. However, applying those well-known ideas and achieving the desired outcomes doesn’t always work out quite as smoothly as the literature might suggest.
In a recent project that we worked on together with our client ShareNow, it felt different. Everything magically came together - we built a great high-performing team and had a very successful product rollout. Below, we will share some of the methods that we believe were crucial for our success as a team and consequently the awesomeness of the product we built.
______
1. Collaborating on product discovery
The project kicked off not in a meeting room or on a whiteboard, but on-site with the users. A core team including the product owner, a business analyst, and a developer went to investigate who the target audience was, how they do their daily work, and which of their problems with the existing solution could be solved by our product.
Throughout the project, we used all sorts of maps to visualize the information we gathered. This helped product and engineering collaborate on understanding the problem space in a more scalable and sustainable way.
2. Getting buy-in from everyone
After our initial research, we needed to shape the project and identify the best options to pursue. Senior leadership shared their priorities with us in a workshop. Over the course of 2.5 days, we gradually aligned on the scope of the project, discarded some potential approaches, and collaboratively identified the most valuable one for the business.
3. Setting up a cross-functional team
Most developer teams have a strong focus on solving technical problems. In addition to developers and a product owner, our team was also joined by two UX-designers and a business analyst. That meant we had enough capacity to do both the development work and the required ongoing research to deeply explore the user problems.
4. Discussing ways of working
The team decided collaboratively what kinds of meetings we should have, how much we wanted to work remotely vs. in the office, and which framework we wanted to use. The most useful exercise here was to discuss our roles and responsibilities. We shared what core skills and secondary skills everyone brought to the team, and what our expectations were of one another’s roles. Immediately, this created a collaborative spirit.
5. Building user feedback loops (Lean User Research)
We stayed in touch with the future users of our product in numerous ways, remote and in-person. We enabled analytics and metrics for our application from day one. Releasing a beta version of the app allowed us to get immediate feedback and to identify functionalities that needed improvement.
6. De-risking the user journeys
As we moved from the old system to our new solution, re-thinking a lot of user journeys and changing the architectural approach involved a lot of risks. To mitigate that, we identified the most frequent user journeys and covered those in the new tool first. We created a transition strategy that kept the number of construction sites low.
7. Visualizing ‘shaping’ work
We extended the developers’ Kanban board to the product team and called it the "Experiment Board". Our UX people, business analyst, and product owner used it to collect ideas, validate them and eventually move them to an analysis and design stage before they were transferred to the production backlog. Visualizing this work proved beneficial in many ways, allowing us to discuss ideas early with developers while also providing transparency and clarity for stakeholders and management.
8. Pairing with everyone
Besides pair programming with developers, we also paired across roles to solve certain tasks. This helped us appreciate different perspectives, share knowledge, and quickly find the most feasible solutions instead of being blocked due to long back-and-forth discussions.
9. Overcoming workplace silos
With the pairing approach, the roles and responsibilities discussions, and the team composition, we were able to create a trusting environment where people felt free to try something new. We actively tried to work on things that were outside our core skills. Everybody felt responsible for the overall outcome and not just their individual contribution.
10. Creating a social network
We got to know each other. We talked to each other. We put our egos aside. And that way we created a social network. This built the empathy, approachability, and trust that allowed us to support each other in not only work and but also in non-work matters when the pandemic hit and we transitioned to being fully remote.
______
Our product received awesome reviews from users and stakeholders, and we have no doubt that its success is closely related to how well we worked as a team. As we refine the recipe to reliably replicate this every time, using ideas from the Design as a Team guidebook, we hope that these 10 best practices will serve as an inspiration for other teams. When it works, it’s almost magical and a lot of fun!
If you’d like to learn more about this topic, watch our on-demand session from YConf.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
