It's not just about the tool

The tech stack, the toolbox, the vibrant market of solutions trying to drive more efficient product management and development…if you are in product operations it is part of your job to be familiar with it all, and to discern which solution would work best for your organisation. This is, in my experience, also one of the hardest parts of being in product ops.

How a solution can become the problem

A lot of the solutions on the market want to be the solution product managers spend the most time in. I get it, we work with the same metrics for our product, to ensure it is sticky and engages our users. This means there is fierce competition among these tool offerings to be the end-all-be-all solution, and every employee seems to have a favourite tool to spend the majority of their time in.

These tools are invaluable for teams to better communicate, organize their work, understand each other’s progress and challenges, and track and resolve issues as they come up. Usually what I’ve observed is when someone (usually a product leader) discovers a tool that makes all these things easier, they feel like their team should have had it yesterday, and what is most important for that champion of the tool is that their team specifically can have it as soon as possible, so they can meet their goals.

The challenge I face in product ops is to ensure that the incentive to improve how we work, and how new tools can leverage that, gets spread consistently across the entire company, in the most efficient yet sustainable way possible.

Too many organisations, especially when they are rapidly growing, can develop tool anarchy without clear operational thinking. Every team member will fall back on their preferred tool and argue with each other for that tool’s dominance. Or they will adopt the same tool, but use it in drastically different ways.

Without someone thinking and observing how and why we develop certain behaviours around tools on an organisational level, these tools actually contribute to the problems they are built to solve: inefficiency, communication issues, confusion.

The key to an effective tool roll-out

I have now rolled out the tool Productboard at two different companies, of two different sizes and in very different industries. The roll-out of that tool, even though the tool itself was not different in what it offered, looked entirely different depending on the company contexts and needs, as well as the internal champions for it. It reinforced an idea that I already had in the back of my mind as a student of anthropology, that tools are only as good as the behaviours and habits we establish around them.

In both companies, I feel like product leadership (and the IT department) underestimated the effort required to roll out one of these tools in a consistent and effective manner across a growing product team. Introducing a new tool is not just about granting access and providing technical training. It is even more so about matching the solution to the problems that need to be solved, and changing behaviour in order for it to truly reap the intended benefits.

I recently undertook a course in change management and it is striking how valuable that learning has been when applying it to rolling out a new tool. Change management principles speak to the importance of not just paying attention to the operational and tactical needs of a project, but also the people side.

I was able to more effectively roll out a tool like Productboard, and get buy-in from leadership, when I first asked and listened to my colleagues about their greatest struggles. I learned what aspects of this tool will be useful, and could solve particular pain points that were broadly felt, and other aspects we would want to put aside.

As a result, instead of the pushback I expected from Product Managers in adding one more tool to their already bulging tech stack, they were enthusiastic about the particular problems this specific solution could solve. It also allowed me to shape a tailored roll-out plan that suited our company context and was responsive to other internal changes within the company.

Be conscious of your context

Something we learn in anthropology (and even to some extent in change management) is that everything is interconnected. We need to appreciate the wider context of behaviours and relationships in which we introduce our tools, as well as the wider tool ecosystem and what problems each of these tools have been introduced to solve. Only then can this quickly growing market of solutions that product ops helps shepherd into our growing startups realize their true potential.

It is critical for us as product operations professionals to treat new tools as a behaviour change exercise. If we are to be successful in making our companies better so that we can produce better products and services for our communities, we need to start by focusing on the problem to solve, and maintain integrity in choosing the solution that is right for our unique context.

Originally shared in Hugo Froes' newsletter Thoughts Unravelled on 27 Jul 2022.