Field Notes · Elle Anderson · andersonco.ukField note · Tools of the Trade
Product Tools Without a Reason
I have used almost every tool in the modern product stack, from Productboard and Aha! to Amplitude, Heap, Mixpanel and Pendo. In most of the organisations I have joined, those tools were bought before anyone agreed on their purpose. This note is the conversation I wish had happened first: what each tool is genuinely good at, the gotchas that catch teams out and how to bring one into a product function so that it earns its licence.
The Pattern I See Everywhere
A new head of product arrives with a favourite tool from their last role. A vendor demonstration lands well with an executive. A team, tired of spreadsheets, buys the most popular option on a review site. Six months later the tool is half populated, three teams use it in three different ways and nobody quite trusts what it says.
The software is rarely the problem. What is missing is a reason: a clear job for the tool, a person who owns it, a shared way of using it and a simple measure of whether it is working.
The Problem Is the Product
I say the same thing about every tool, whether it is a business tool your teams use internally or the product you are building for customers. The tool is only ever a solution. The product is the problem you are solving.
If you nail that problem down first, the tool matters far less. When it stops solving the problem, you can pivot to something better without losing your way, because you always knew what it was there to do.
Start With the Job, Not the Logo
Before you buy or renew anything, write down five things on a single page.
- The job. The decision this tool will help someone make better or faster.
- The owner. One named person who is accountable for how it is set up and kept healthy.
- The model. How work, insight or events will be named and structured, agreed before anyone starts typing.
- The ritual. The meeting or habit in which the tool is genuinely used. A tool that nobody opens in a meeting is a tool that nobody trusts.
- The exit. What you would lose if you switched it off tomorrow, and how you would take your data with you.
If you cannot fill in that page, the honest answer is that you do not need the tool yet.
The Tools, Honestly
Here is how I would describe each of the tools I meet most often, based on using them in real product teams. Features change quickly, so treat this as a guide to how each tool is best used rather than a list of what it can do today.
| THE TOOL | ITS REAL PURPOSE | THE GOTCHA | HOW TO DO IT WELL |
|---|---|---|---|
| Productboard Product management and roadmapping | Connecting customer insight to features and the roadmap, so you can show why something is prioritised. | The insights inbox fills faster than anyone triages it, and roadmaps get built from the loudest notes rather than the strongest evidence. Teams also recreate their whole backlog here and in Jira, then spend their time keeping two systems in step. | Decide what lives in Productboard (problems, insight and the roadmap story) and what lives in your delivery tool (the build). Give triage an owner and a weekly slot, and link every roadmap item to the insight behind it. |
| Aha! Strategy and roadmapping | Large, multi-team organisations that need strategy, goals and roadmaps joined up and reportable to leadership. | It can do almost anything, so teams configure it into a bureaucracy. Hours go into fields and workflows that serve reporting rather than decisions. | Start with the minimum: goals, initiatives and a roadmap view. Add a field only when someone can name the decision it will inform. |
| Jira Product Discovery Discovery inside the Atlassian world | Teams already working in Jira that want ideas, evidence and prioritisation close to delivery. | Because it sits next to delivery, discovery quietly turns into a pre-backlog, and ideas are scored and shipped without ever being tested. | Make evidence a required step before an idea moves into delivery, and review the discovery board in its own forum rather than at sprint planning. |
| Amplitude Product analytics | Understanding behaviour over time: funnels, retention, cohorts and the impact of experiments. | Without an agreed tracking plan, event names multiply until nobody knows which “sign up” is the real one. Dashboards then become decoration that nobody believes. | Write a tracking plan before you instrument anything, name an owner for the event taxonomy and begin with the five questions leadership actually asks. |
| Mixpanel Product analytics | Fast, self-serve answers about what users do, popular with product-led and mobile teams. | The same taxonomy trap as any event-based tool, plus a tendency for every team to build private reports, so the organisation ends up with twelve versions of the truth. | Curate a small set of shared, trusted reports and retire the rest each quarter. Treat definitions such as “active user” as product decisions, and write them down. |
| Heap Product analytics with automatic capture, now part of Contentsquare | Capturing interactions automatically, so you can ask questions about the past without having planned the tracking. | Capturing everything feels like insight until you try to define events consistently. Without curation the data is broad but shallow, and interface changes can silently break your definitions. | Use automatic capture as a safety net rather than a strategy. Still define and verify your core events, and audit them whenever the interface changes. |
| Pendo In-app guidance, feedback and analytics | Onboarding users, announcing changes and collecting feedback inside the product, especially in business software. | Guides are so easy to launch that users drown in pop-ups, tooltips and surveys, and soon ignore all of them. | Put one person in charge of the in-app calendar, cap how many guides anyone sees in a week and measure each guide against the behaviour it was meant to change. |
| Dovetail Research repository | Storing, tagging and finding customer research, so insight outlives the project that created it. | It becomes a beautifully organised graveyard: research goes in, but decisions never come out. | Agree a small, shared tagging scheme and close the loop by linking each insight to the decision or roadmap item it shaped. |
How to Bring a Tool Into Your Product Function
The implementations I have seen succeed all follow the same five steps, and the ones that struggle tend to skip at least two of them.
- Define the job and the decisions it will support, and agree them with the leaders who will rely on what it produces.
- Name an owner and give them time. A tool without a gardener becomes a jungle within a quarter.
- Agree the model first: the naming, the structure and the definitions, written down and short enough to remember.
- Pilot with one team for six to eight weeks, then fix what hurt before you roll it out more widely.
- Build it into a ritual, such as a weekly review, a quarterly planning session or a leadership dashboard that people genuinely use.
Then, once a year, look at every tool in the stack and ask a simple question: if we switched this off tomorrow, would anyone notice? If the honest answer is no, you have found your saving.
Choosing Between Them
Most organisations need one tool for each job, not one of everything: one place for discovery and the roadmap story, one source of truth for behaviour, one home for research and one way to speak with users inside the product. Overlap is where the cost hides, and it is also where the arguments about whose number is right begin.
Product names are used descriptively, and no trade marks are claimed. This is the first in a short series; deeper notes on individual tools will follow.