I love it when people ask “what is the best tool for x..” – mostly because the answer will forever be my favorite product management answer ever: it depends.
While social validation and proof are two gamification pillars that have proven over and over again to give results, when it comes to choosing the right product stack for your team, it takes a little bit more than just relying on what everybody else is using.
At the end of the day… What works for one might not actually work for another.
I thought I’d break down how to actually go about selecting the right product stack for your team and what questions to ask before selecting a tool.
TLDR
In case you’re in a rush, here’s the quick TLDR:
- Make sure you understand what problem introducing a new tool solves for your team.
- Process first, tool later!
- Write out your requirements.
- Consider your budget!
- Start a trial with the core team and extend it out to other stakeholders.
WHY DO YOU NEED A NEW TOOL?
Have you stopped and asked yourself – why is it that we actually need a new tool?
What problem are we actually trying to solve?
We all suffer from shiny object syndrome, so be sure that you ask the right questions before you decide to get involved with trials (and possible tribulations!)
Be sure to outline all the problems you are having first. As product sits in the intersection of other teams, gather that feedback from stakeholders involved as well.
This isn’t about features though, this is about outcomes, so be sure to ask what they hope to achieve and what is stopping them from doing so with the current stack.
PROCESS > TOOL
The number one reason teams tool hop is because they tried to force the product to fit their process. It’s almost like forcing a square peg into a round hole.
Start by defining your process first, and once you have that in place, see which tools can help you implement it.
There will probably be a few trade-offs to be made, so make sure you understand how far you are willing to go – and what you are willing to let go of.
WHAT DOES A PRODUCT STACK INVOLVE?
Sorry to throw this at you guys again, but “it depends.”
The first thing you’ll need to look at is what your current product team looks like, and potentially what you would want it to look like in a future. This may prevent you from tool hopping!
Generally, a product team might have the following team members:
- Product manager
- Product owner or business analyst
- Product designer
- Product marketing
With that in mind, you should be looking at what jobs need to be done to help those team members in their day to day.
I like to divide my product tools based on activities.
Communication and Collaboration
A good product team constantly stays in touch. Communication and transparency is the key to your success!
My favorite communication tools are:
My favorite collaboration tools are:
Product Process
A product team does a lot more than just ‘roadmapping’ – so a product tool that touches on your product process is key. This includes roadmaps, ideation, prioritization, discovery and a view into the delivery process.
The tool that checks all the boxes for me is airfocus (ok, slightly biased opinion I suppose!)
It’s the first modular product management tool, which means I can add, remove and adjust different pieces to the puzzle that is product development as needed.
Design
Let’s not forget your design team here! I actually divide these into two categories – actual design tools (mockups, prototyping, etc.) and tools that help with research and discovery.
My favorite design tools are:
My favorite discovery tools are:
External Comms
A product marketer’s job requires a lot of external comms with customers and potential leads.
A few of my favorite are:
- CloudApp – for quick gifs and screenshots
- Descript – to create videos
- Appcues – for release announcements and in-app guidance
GATHER REQUIREMENTS
Once you have your process down and you know what problems you are trying to solve, it’s time to start gathering requirements.
I like to approach this by asking stakeholders the following questions:
- What are your must-haves?
- What are your nice-to-haves?
- What are you willing to let go of?
It’s important to ask these questions to make sure you’re not potentially choosing the tool that has the shiny objects you’ll never use.
It also gets everyone to start thinking about negotiation and trade-offs for themselves.
There is no perfect tool.
Say that a few times now.
There is no perfect tool that will absolutely satisfy everyone, but there may be one that satisfies most things and fits nicely with your workflow, your process, and may even enhance and introduce solutions for problems you weren’t aware of before.
LOOK AT YOUR BUDGET
Money is never a fun topic, but it is one to be had.
Make sure you understand what the budget at hand is and how flexible you are willing to be.
Most importantly, address whether the tool is giving you the perceived value and whether that fits with the budget at hand. In other words – are you just potentially paying for shiny objects, or are you paying for something that will give you and your team value.
START YOUR TRIAL PERIOD
If you’re wondering why I’ve only just introduced the idea of a trial, it’s because it’s imperative for you to understand what problem you are solving before checking out the tool.
If you start a trial without purpose, how do you know if the tool will actually help?
Now that you actually *know* what you are looking for, your initial testing can be done a lot faster than expected. Those tools that do not fit your process can very quickly be identified and removed from the list.
I generally recommend having the initial trial period with the core team, that is, the team that will be affected the most by the introduction of this tool.
If all checks are in place, invite the extended stakeholders and go through what the tool does and does not do, how it fits their must-haves and nice-to-haves, and how delighters are also introduced.
If there are any technical aspects to the introduction of this new tool, involve your development team and make sure you check with them what is possible and not possible.
Again, you may need to do some negotiation and trade-offs here!
WHAT HAPPENS NEXT?
It may seem obvious to say ‘ok, now buy it!’ but I generally recommend holding off a bit and running a testing period.
A trial is for you to understand whether the tool fits, a testing period is for you to understand whether your assumption is actually correct. This allows you to double check any possible kinks and address potential blockers (and prepare you for how you might deal with them later on, if that is even an option.)
Some vendors might have special pricing for a short period of time, so don’t be shy and ask what that might look like.
Good luck!
