What Does It Mean to Be a Tool Agnostic Product Manager?

Editor’s note: this month we’re talking about the Products for Product Managers, and how to use them to build great digital products! Keep an eye out for blogs, events, podcasts, and more!

Tool agnostic. It’s a phrase people throw around with little thought, perhaps without fully considering the opportunities and challenges that come with it. If we break down the phrase “tool agnostic,” a tool is any device used to carry out a particular function (in this instance, the digital products that Product Managers use to do their work); and agnostic means noncommittal or unable to take a stance. 

Yikes. Unopinionated isn’t usually on the list of desired PM traits—the last thing we want is a wishy-washy PM. But being tool agnostic doesn’t mean being incapable of taking a stance. Rather, it means taking a stance on other priorities that are more important than whatever particular technology is in use to complete a job. 

Tool agnostic Product Managers are noncommittal towards tools because they prioritize their product and team needs first. They’ll abandon a tool they’ve been using in a heartbeat if it opens the opportunity to work with another product that’s even better suited to help them accomplish their product, team, and business goals. In other words, they are tool agnostic but needs devoted.

This is a strength because it means no loyalty or partiality towards a particular technology will keep them tied up, unable to find the ideal solution to a problem. 

The Process is Not the Tool

At this point, you might be thinking…what’s the big deal? Surely it can’t be that bad to find a tool you love and stick with it through thick and thin. Well, you’re right. It’s not that bad, but it’s also not that good. 

You can build your entire product tech stack in this way, working with tools that are comfortable and get the job done, but that don’t do the best job possible. Because business is a game of margins, this matters. Oiling hinges and smoothing out wrinkles can make the difference between success and failure.

Especially in the product world where teamwork and customer experience are so critical, it’s useful to keep an eye on your tech stack and continually reassess if it’s fully serving your needs.

iron smoothing out wrinkles

Another problem with being devoted to a particular product is that tools are not neutral; they can push us into certain workflows or processes because the way they function is more or less fixed. We as humans are much more malleable, so it’s easier to shape ourselves and our business processes to the tool rather than the other way around. 

If someone has been using the same roadmapping product for years, they’ve probably shaped their roadmapping process to fit that product. To them, the process of creating a roadmap is synonymous with the process of using the tool. If it’s a little finicky, they’ve found a work-around. If it doesn’t have a certain feature, they do without.

If your process is tied up with your tool, you’re viewing your process through the lens of that technology instead of looking for technologies that best support that process. It’s easy to conflate technology and process, but it’s more useful to see the two as separate. That way, it’s easier to streamline the processes that help you reach your goals, which sometimes means changing out the technology you just so happen to be using to support them.

Benefits of being tool agnostic

The most impactful aspect of tool agnosticism is that it gives you full bandwidth to prioritize your needs. Remember: be tools agnostic, needs devoted. 

Whether addressing team, product, customer, or business needs, tools agnostic Product Managers have the freedom to focus on the future. Sometimes it’s necessary to switch tools to move in the direction of the future of the company or the industry. With emerging technologies and shifting markets, staying on top of your tech stack helps counteract the ongoing change and ambiguity that Product Managers inevitably deal with. 

In short, it makes you and your team more agile and encourages big picture thinking!

man sitting at laptop writing on a notepad, smiling, and thinking

So how do you become tool agnostic? 

Step 1: Identify your needs

Step 2: Research which product and technologies will help you fulfill those needs

Step 3:  Revisit on an ongoing basis to uncover potential misalignments in tool capabilities vs needs

Step 4: Repeat!

This can be a big time investment up front, and it might be a financial investment as well if you land on a paid product. But in the long term, customizing your tech solutions to your needs will save you time and money. More importantly, proper tech stack/needs fit will give you the functionality and flexibility to make incredible products that will drive user adoption and revenue.

And finally, being tool agnostic can help you have a better relationship with your team. By talking with your team to understand their needs, you’ll automatically be showing you care about supporting them in their various roles. 

Especially if you’re coming into a new company, you might be overwhelmed by all of the unfamiliar products the team uses. Your knee-jerk reaction to this situation might be to try and convert back to the familiar by imposing the tools you like onto your team members. Being open to understanding why these tools work for them and being willing to adopt them will help you get off on the right foot. You can change tech tools later down the line if needed, but this change will be coming from a place of underlying process need rather than personal preference.

Reasons we get stuck on a tool

It’s easy to talk about tool agnosticism in theory, but in practice it can be tricky. Finding the right tech stack for your needs requires effort! And there are lots of deterrents and distractions along the way.

Familiarity and Ease

Our brains like familiarity. That’s why it’s easier to keep using the tech tools we’ve already been using, even if we know there might be another one more suitable for us. And when it does come time to switch tools, we can be influenced by trends, word of mouth, or pretty UI. Good tools become a trap in this way, in that popular tools with great capabilities can become our default. 

It’s the product version of the music Top 40. All of our friends tell us about it, so even if it’s new to us we’re willing to give it a listen. It’s ubiquitous, so it’s familiar. You find yourself humming it in the grocery store without meaning to. And it’s probably high quality—great production, good for dancing. Top 40 is popular precisely because it works for lots of people. But indie, techno, or neo-soul might be what really lights you up! If you never explore past the Top 40, you’ll never find that out. 

person with headphones in walking down a sunny streen

It’s simpler to accept the obvious technology that’s right in front of you, or the industry standards. But it’s worth it to do your due diligence and examine if the familiar tech solution is the right fit.

Fear of Failure

Adopting a new tech solution is no joke. Even if a new product is perfect for you, the transition will likely be bumpy. The effort it takes to adopt a new tool can fill you with doubt.

What if the new solution doesn’t work? What if it turns out to be an expensive mistake? Well, it might be. But continuing using a product you know for a fact isn’t delivering the capabilities you need certainly is. 

You’ll never know until you try, and prior research should help mitigate this risk. 

Even if everything does go sideways, you’ll at least learn something new about your process and get more information about what kind of alternatives will actually help.

Lack of Buy-In

Product Managers don’t always have full control of their tech stack. You may have gotten past the roadblocks of familiarity and fear, but you still won’t make any headway if your higher-ups won’t fund the new tools and your team hates the idea of change. 

Stakeholder management and alignment are valuable skills you can use to get buy-in here. So if you go back to your needs and demonstrate 1) the why behind the change, and 2) how the new tool will help, you have a higher chance of getting others on board. 

Change is harder than stasis, which is why it’s intrinsically less desirable. But you’re Product Managers! You can handle it. 

Check out next: Product Management Skills: Stakeholder Management

When NOT to change tools

We’ve spoken at length about the pros of changing tools, because willingness to change is the more challenging part of being a tool agnostic Product Manager. But the other side of the tool agnostic coin is knowing when not to change. Tool agnosticism isn’t about changing tools willy nilly; it’s about identifying the best tools for your needs and sticking with those tools until an even better solution comes along. 

As we just discussed, it’s a lot of work to change tools. It isn’t a decision to be made lightly. That’s why it’s so important to identify the right tech solutions for you sooner rather than later: if you land the best fit the first time around, then that’s it. You won’t have to go through the disruptive integration/adoption process until you find a really great reason to switch to another solution.

We talked about the necessity of switching tech tools when your current solution is falling short; but it’s also possible that an imperfect solution is the best current solution. That’s why we need a balance between looking for news tools and using them. 

puzzle missing a piece

Developing a tools agnostic mindset is useful at any stage of building your product tech stack. You might not be able to meet 100% of needs 100% of the time, but it’s worthwhile to strive for. Even if you don’t have the resources for the best-possible data-stack now, you can still move towards that goal. And as you improve your business processes and your tools, your business will iteratively improve as well. Good luck!

Want to learn more about building a great product tech stack? Check out our new Micro-Certification!

Adopt a tool agnostic approach to build a successful product tech stack.

Enjoyed the article? You may like this too: