Tooling for your product team is a necessity. It often gets overlooked or tools are quickly chosen because we are so focused on the challenges in our own products. But, getting tooling right helps get better results faster.
This post lays out the different categories of tools your product team needs in the stack and provides some example tools in each category.
Rather than try to be comprehensive lists of the tools in each category, this post aims to help you consider the categories and types of tools that can help your product team.
The categories are:
- Product Roadmaps
- Project Management
- Product Analytics
- User Research
- Experience and Feature Design
- User Communication
- A/B testing and rollout
Let’s dig into each of these categories.
Creating roadmaps is probably the first activity that comes to mind when people think about what they need for product management. It’s probably the more glamourous part as well. It makes sense, you need to be able to visualise where you are headed.
Product Roadmap tools let you easily list out your features then prioritise and sequence them so that you end up with a solid plan for what you need to deliver.
The better tools can be configured to automatically apply your preferred product prioritisation framework to the features you enter.
The requirements you need to look for here are:
- Quickly enter product features
- Prioritise the features
- Sequence the features in a timeline
- Easily rearrange prioritisation and sequencing
Some extras that are worth bonus points and consideration are:
- Applies your product prioritisation framework.
- Tracks request by customer
- Links features through to initiatives and themes.
- Integrates with your project management tool
A word about integration. Often product teams also want integration with their project management system. Experience has shown that the effort involved here doesn’t usually pay off. Many of the tools on the market advertise that they can do it but when it comes down to the mapping required and the edge cases that usually throw the entire system out, it just isn’t worth the time. If it works out of the box, great. Otherwise insist on integration at your own risk.
You need a project management tool to make sure your product initiatives are coming together. You might fit with your engineering teams preferred tooling or you may run your project management separately. Either way, you need something.
Covering what you might look for in Project Management tools is almost an entire 378 page essay so I won’t do that here. Instead I want to simplify the choice.
Most teams fit into one of two extremes: Simple or Disciplined.
Simple is about ease of collaboration with a basic level of tracking. Usually it is about some level of accountability but there aren’t any factors that make it a necessity.
Disciplined is where teams want or need extra rigour for whatever reason (larger team size, higher risk, personal preference).
Figure out which you lean harder towards and then choose a tool.
You need tools to understand how your users are using your product(s). A pilot wouldn’t fly without instruments, so how can you expect to drive your product without analytics?
Just to hammer the point, I’ve learnt the lesson that observing actual behaviour is the only form of data that matters. So this is an essential part of your stack. You need to be in this tool daily, choose wisely.
You want to think about the type of product you have when choosing a tool in this part of the product tool stack. Some analytics tools work better for mobile, or web or B2C or B2B. The more specialist the more likely they’ll provide easier ways to understand your specific users.
The main consideration for a product analytics tool is:
- What journeys and actions do I need to track in my product? Does the tool support that easily? Better yet, does it specialise in it?
Everything else is secondary.
Luckily, if you use something like segment.io then you can use multiple analytics tools and switch them in and out as needed.
Once you’re beyond an out of the box setup you will need or want to go further and create your own data warehouse that combines multiple data sources in order to better understand your users. Don’t jump here until you’ve maxed out your current tools though.
Finally, I still find that we end up pulling data out of our various analytics tools and combining them into a spreadsheet for ease of reference each week or extra analysis. Trusty spreadsheets are another tool you need here.
This category of tools helps you further understand how your users are behaving, their thoughts and their feedback.
Often I’ll use or see product teams using multiple tools in this part of the stack. So you can almost think of multiple subcategories here. These are roughly:
- Visualise user journeys: e.g. Hotjar
- Conduct surveys: e.g. Typeform, Survey Monkey, Qualtrics
- User satisfaction: e.g. Delighted (NPS)
- Other tools: Airtable (create forms, custom databases), Mode Analytics (really dig into your users)
Each of these subcategories gives you different insights and angles to understand your users from. We find we are often switching these on and off as they are needed at different times.
Feature & Experience Design
You need a tool in your stack to help you design features and interfaces.
This category shares a lot of overlap with what your UX team is likely using. You probably want them to drive the choice here but it doesn’t hurt for you to have your own kit bag in order to better explain your ideas. A picture or example speaks a thousand words.
The tool you use can depend on your product. For example, when we are working on slack chatbots we will use slack’s message builder combined with sketch or PowerPoints to design a conversation journey. There are also tools available for designing voice interaction, like Adobe’s Say Spring.
It helps to be able to prototype without the engineering team. If image speaks a thousand words then an interactive prototype speaks a million. Or something like that anyway.
You can use these to sell your ideas internally or gain real feedback from users and prospects.
The best teams even go a step further and use the tools in this category to deploy features into production without code, that their users can begin using. I think of this as Features Without Code.
On the prototyping end of the spectrum you want something that someone without a design or programming background can use to easily put together an interactive series of screens and forms.
For Features Without Code you can use the example tools above. I’ve also seen success with Amazon’s mechanical turk (“wow AI!”) or up workers doing background processing.
You will probably want or need a way to communicate with your users. Whether you do it infrequently or you automate it to help users onboard, activate and stick.
What you want to consider in this category of the tool stack is:
- Do we want to have real time discussions?
- Do we want automation to help users through their journey with the product?
- How closely linked does it need to be with the events? (Some of them don’t easily pickup analytics events you fire from your back-end systems).
You can also use a communications tool to experiment with ways to improve the conversion or success rate with some journeys.
Be careful with real time. It can set your conversations up for failure. If you have a real-time chat tool to chat with your users then make sure you set your offline settings correctly.
A/B Testing and Rollout
Depending on your product this category might be essential early on or something you can hold off on.
You need volume to take advantage of A/B testing. You don’t need volume to take advantage of feature flagging and rollout.
A/B testing tools let you test your ideas quickly and your alternatives. Instead of arguing in a meeting room over two ways a page can be designed just launch both. See what your users say. These are best applied in high volume usage products because you need statistically significant numbers, like 50-100 people through each variation of your test.
Feature flagging and rollout tools can be used to do a/b testing. They can also be used to progressively roll features out or provide different configurations to different customers.
An example of this is LaunchDarkly.