Minimally Viable Self-Service Product Analytics

If tomorrow I left Amplitude and joined another company, I would make access to a product analytics tool (Amplitude, or similar) a part of my job offer.

It is that important. It’s that critical to a team’s success.

Once you’ve seen a true self-service product analytics product in action, there is no going back. You can’t un-see it. And I say this not just as a product manager, but also from the perspective of analysts and analytics leaders. Once you’ve seen how you can up-level the work of product teams, you can’t go back.

How do I define a minimally viable self-service product analytics product?

Here’s a quick attempt:

1. Product team members can answer the majority (~80%) of questions—both existing questions and exploring and posing new questions—without needing the help of an analyst (but being able to collaborate if necessary, see #6 below).
2. Product team members can answer questions without using SQL (or similar). While extremely valuable, SQL should not be a blocker for collaboration and decision making. Many “standard” product questions (like retention with the added complexity of identity resolution) require advanced, fault-prone SQL writing.
3. It’s possible to zero in on individual, unique users and their behavior across their different devices (while respecting privacy concerns, of course). User-level resolution is critical.
4. Analysts can spend a majority of their time (~80%) on high leverage, more strategic work—not answering repetitive, low complexity, ad-hoc questions.
5. Speed of analysis matches the speed of question asking and exploration (the speed of curiosity). While “real time” is not necessary in many cases, it is extremely helpful when exploring data, framing questions, and quality checking insights/answers. No one should wait minutes/hours/days for an answer.
6. Analysts can pair/collaborate with product team members, and team members can “take home” and extend the work. Effective analyst-to-team collaboration is hugely important. It needs to be fast, effective, and collaborative, with minimal hoops. Also, product team members can collaborate among themselves (share, fork, adapt, comment, add commentary, etc.) on insights using a browser.
7. Developers can, with minimal time investment, add tracking using a usable and well documented SDK.
8. Product team members can collaborate on event definition outside of spreadsheets (and wikis), with the benefit of version control, type safety, auto-complete, and CI/unit testing integration. The team can use human understandable event and property naming (nouns, verbs, adjectives, and adverbs).
9. Rich context. Events should support additional context (properties) to enable a suitable depth of analysis and insights. For example, purchases include ‘amount’, and selecting items from a list include ‘position’ or ‘row’. Instrumentation is resilient, and not subject to changes in CSS.
10. Most (90%) questions and use-cases should not require data engineering, changing pipelines, adjusting underlying tables, etc.
11. Options for notifications, anomaly detection, and alerts. Product team members are not beholden to obsessively view dashboards to make sure nothing is going wrong.
12. Ideally, you can let anyone in the company use the product without jumping through contractual hoops and/or setting up any kind of environment.

Where is your team at today? Can Amplitude help? Whatever you do…make this happen.

Try our demo today.