As an engineer my focus for most of my career has been building scalable, performant, well architectured and secure software. While those are definitely required ingredients for your product to succeed I’ve started being more and more aware those are just part of the whole recipe.
Eighteen months ago I became fascinated by lean product development and Design thinking so I decided to get out of my comfort zone and start a new career as a Product Lead. I started that journey working on a project for a global company. The product today has a tremendous impact on its users and it’s one of the main enablers of our client business strategy. The development has recently paused and I’ve found myself reflecting on the journey and what made it successful. While many different factors contributed to the success of the product I’d like to share with you my experience with processes and team dynamics.
Before we get to the nitty gritty it’s important to note that Potato is a product development agency and we work with brands and businesses across the world, from startups to big corporations. We don’t generally own the products we develop and it’s therefore a priority for us to collaborate with our clients to find the right approach and processes to succeed together.
Since processes, expectations and governance can vary from company to company this can sometimes be something of a challenge. Fortunately, at Potato, we like a challenge.
In this article I’ll look both at how we changed the relationship and approach with our client and how we’ve reshaped our processes and ways of working to equip the team for success in any environment.
Reshaping agency/client relationship
When I joined the project our client was expecting a pretty rigid waterfall approach. They felt they could just hand over a product specification and expect the team to deliver it. Collaboration between the team, stakeholders and product owner was expected to be minimal.
While we knew from the beginning this wasn’t an ideal set up, we were aware we couldn’t turn processes around from day one.
We had to prove our approach would work better and allow us to deliver faster and higher quality results for our client.
I won’t lie, the beginning of the project was messy and, as we were expecting, the big gap separating the development team and product owner proved to seriously impact the progress straight away. It was hard to align on goals and purpose, client and agency struggled to understand the direction the product had to take and that was preventing us from moving fast and building the right solutions. At the same time, the client was having difficulty creating focus around the right problems to solve, many voices from different departments involved in the development were being lost and it was hard for the product owner to understand how the different pieces of the puzzle would fit together.
This gave us the opportunity to suggest different methodologies and prove how effective we could be working as an agile team, where the product owner and development team join forces to innovate and deliver together.
We started using Scrum and leveraged sprint planning sessions with the client to define actionable goals to create focus around the problems the product had to solve. We also began collaborating with the product owner and senior stakeholders to identify how the product could deliver against business goals and user needs/problems to create an effective product roadmap. This really helped the team to keep the right focus, understand the challenges ahead and finally be able to effectively build the right product.
We started working as one team, there was no separation between client and agency and that proved to be powerful. It was now clear we were all pushing in the same direction and everyone was exposed to the right context. The team had visibility on the strategic goals and product outcomes while the product owner could keep a closer eye on progress and understand the impact of his choices. The team could design and build features understanding what outcomes were required from them and the product owner could trust the team to take those decisions.
The impact of these changes was great but I wouldn't be fully honest with you saying it was an easy and sharp transition. Finding the right way to work with our client and improving team processes and approach took time and effort. But I can say today it was a really rewarding experience that was worth every minute. The quality and speed of work dramatically improved as did the team health and client satisfaction.
Find the process that works for your team
The first lesson we had to learn in this journey is that there’s no one solution to fit them all. I learned that first hand, when I started reshaping the processes. We’ve worked with the agile coach in our team to define the perfect process, to have well-defined roles and responsibilities, to have our ceremonies be consistent and effective, to have our Gitlab board structured in the best way possible.
I was expecting everything to be perfect from day one, but that’s just not the reality, it really isn’t. Every product, every team and every organisation is different and there’s no perfect way to run your project. The key is to work with your team to find the ideal approach, the one that works for you.
That’s what enabled us to improve and become more effective and organised through time while always being conscious that perfection is not to be reached. Rather strived for and the key being continuously adapting to change.
But how do you do that? I can tell you what worked for us and hope it’s a good source of inspiration.
Don’t strive for something perfect from day one, be experimental, try, learn, iterate and adapt your processes to your needs. Doing a retrospective every sprint is a good way to do that: learn from your mistakes, take what worked well and iterate.
Make sure your team understands the process and is involved in shaping it. The words Agile and Scrum are widely misunderstood and/or misused across the industry. On top of that differences in Scrum approaches and process are intrinsic in its nature. That’s why it’s crucial everyone understands the concepts, owns the processes and believes in them. It wasn’t the case for us and that caused some issues at the beginning of the project.
On top of that, at Potato we work in cross functional and autonomous teams and, while that’s key to delivering good digital products, it also introduces a few challenges.
The team needs to work as a cohesive unit while, at the same time, different members need to apply different lenses to the product. As a Product Lead you likely want to focus on the long term strategic view of the product, think about the big themes and their impact on users and business. As a Product Designer you need a good setup to run Product Discovery, run User and Stakeholder Interviews, carry on discovery work and effectively organise product insights. As a UI designer and Engineer you need a good framework and processes to effectively collaborate on User Stories. This applies to all different roles of your multi-functional team.
That’s why it’s fundamental everyone is actively involved in defining processes and shaping the framework and methodologies to run itself.
Empower your team
If your engineers are just writing code and your designers creating UI components you’re leveraging 25% of the capabilities of your team.
When it comes to defining and designing solutions, it’s still pretty common practice to have product managers or even senior stakeholders and executives decide what features go into the roadmap and how they are scoped out. The team's only focus is to implement what is funnelled down.
While changing such a structural behavior is incredibly hard, we did work closely with our client to break some of those patterns and prove the benefits of having an empowered team.
While it's the product manager’s (and management) responsibility to provide the product vision, lead the long term strategy, create focus and refine the value proposition, it’s the team responsibility to solve those big challenges. They own the actual expertise, they understand the technical constraints and they better understand the users.
Be reassured that this way your team will thrive: they’ll be more inspired and driven, they will understand if/when some trade offs are required (instead of being frustrated by another “silly” request from management).
Having your engineers, designers, uxers really understand the product and the problems it is trying to solve has been one of the most important means to success.