Evaluate product analytics tool
1. Interview stakeholders such as Marketing Analysts to determine the main problems they are facing when trying to use behavioral data and formulate the Problem Statement using the Pain Points.
Force stakeholders to assess which pain points are most critical and which are less important. For example, “reports not in real-time” is not as important as “subscription reporting not 100% accurate.”
2. Outline the possible tool-stack scenarios based on stakeholder requirements in a spreadsheet (scenario A, B).
One scenario could be: you only want to run and maintain solutions you can host yourself (your business is highly secretive and sensitive). For each scenario, list the positive and negative sides. For example, in scenario A, you have to maintain 2 tools instead of 1.
3. Create a list of all the features you need, regardless of importance-in the same spreadsheet, as rows.
Rank all of them based on some importance scale. For example, MoSCoW.
4. Find the tools that fit one or more scenarios and put them in the list, as different columns under each scenario.
A tool can easily fit into multiple scenarios, but may be evaluated differently or have a different “role”, so list the tool in all columns if necessary.
5. For each tool in each scenario, make a rank of how well they fulfil the requirement (in each cell).
For example, 0 = not at all, 1 = somewhat, 2 = fully.
6. Fill in all the pricing and additional information about each tool- contract durations, unexpected charges- into the spreadsheet.
This “peripheral” information should not be the core decision factor in your matrix, but if you have a specific budget (which is most likely) then this will allow you to keep tabs on this.
7. Set a meeting and align with your stakeholders on which scenario and tool setup best fits all criteria.
Your desired outcome of the meeting should be deciding on which scenario and tools you will then “test drive.”
8. Run a simple proof-of-concept with the tool-stack you selected on a smaller subset of your business/product.
If possible, go beyond a limited 7/14-day trial and get at least one month of hands-on experience The test drive should involve as many of your stakeholders as possible, but MUST include the users who will be working with these tools daily (not just C-level).
9. Repeat the alignment meeting and Proof-of concept if the tool doesn't meet expectations -otherwise, purchase and implement your selected tool-stack.
Some possible reasons for “bust” could be: The required budget will be higher; Client support was not good; the tool interface was poor; Feature X didn’t fulfill the functionality as you intended