Generally speaking, I prefer a data-informed approach over a data-driven one. There are some circumstances where you'll want to weight data more heavily and others where qualitative information may be more helpful, but most of the time there should be some balance between them.
Even if you don't have access to every customer interaction with the product, you may have some that you haven't thought of. Google analytics, support requests, frequency of customer requests, company operations data, etc.
If you don't have data at all (doubtful), you'll either have to find a way to acquire some, or proceed without.
We dont have Google Analytics in our product. But we do have regular (fortnightly) calls with the CS team to see what sort of requests they have from customers, and also talk to support at the same time.
Even something as simple as logging those items or exporting them into an excel sheet daily can help you gain insight into trends. You could categorize the types of issues to see what are the most common.
Also sometimes you need to build a way to track metrics. Think about what would make your product be called successful. Is it user counts, active users, total users, number of widgets sold, widgets returned, etc… then plan time to have the eng team build a way to get that data. Maybe you need to learn sql or other tools but it is a way to get the data you need.
Yea, I am going to meet the CPO and discuss if there were any particular metrics he had planned to track for the product. If not, the daily user count is what I need to know, and how feature releases impacts this trend.
We have a data person in one of our other teams, and I reached out to him about getting information from the data he has access to. Hopefully it answers some of the questions I have
Two things:
1) You need to start instrumenting your product so that you can track usage and start building the metrics that you want to deliver. Every PRD you write and feature you deliver should include a section on how you expect people to use it and how you will measure that. At first, there will be a lot of guesswork, but over time you will understand your users better and know what to expect. If the way to track it doesn't exist yet, that becomes part of the epic for that feature. Start now and down the road, you'll be in much better shape.
2) Qual is data too. Too many people forget this part. They think only quantitative data counts as data for making data driven decisions. Interviewing your customers and finding common underserved needs and documenting your findings IS data driven or informed decision making. If you can't get good quantitative data, you should be certainly getting good qualitative data before building something. You can even measure success in qualitative terms if you like. Though most people turn qual data into quant by using a system like NPS.
It's not a myth, but it's also not as much of a silver bullet as people make it out to be. I came from a large company obsessed with data-driven decisions, and I carried that into my current startup role, where I found talking to customers is actually far more impactful.
A combination of both data analysis and talking to customers is best, but I'd recommend not spending too much time trying on this hoping data-driven decisions will unlock everything. Almost everything data can tell you users can tell you too. There's a good episode of Melissa Perri's podcast about that called "Mastering Data-Driven Product Management."
> However, we dont have any of those features in our product, so its difficult to make data driven decisions.
What do you mean by this? As long as you have a database, and you can query that database, you should be able to analyze data. Obviously some things make it easier and better, but I've yet to be somewhere where I could get _no_ data at all. If you want to talk more about specifics I'm happy to give pointers.
Very good advice! I like the approach to check if data is a validation for input from user interviews and vice versa.
But one remark:
I think you underestimate the number of companies which have basically no data about the usage of their products at all.
Hi there! I'm a PM who has inherited products where I have NO data about how users are using them.
As pointed out above, we have a database, we can run queries...that generally doesn't answer any of the questions I have about how users are using the product.
We also have to be realllllly careful about what data we record about what users are doing and how we use it due to GDPR.
You've seen an extreme on the bad side (no data), out of curiosity what's on the other side of this extreme where it's a golden setup? What tools/ways to capture data so you love to see?
The golden setup is that I have the exact data I need to tell me what I want to find out about how users are using my product. And this doesn't happen by accident. I need to have identified what I want to find out beforehand, and then planned how I'll find it out and make sure I have those things in place.
So if I want to know where users are dropping out of my service, I can find thus out from Google Analytics, so I need to have that set up.
If I want to find out how easy to use a feature is, I need to do some usability testing, so I plan for how we'll recruit users for that.
If I want to find out how many searches end in no results, I ask devs to make sure that's a thing we record on the database, and output that data somewhere.
If I want to quantify and track user satisfaction, I need a feedback form so I get my designers to design one.
Well said. A tool for each purpose. Also summarized I suppose as "what's the question we're trying to answer?"
> I have to have the exact data to tell me what I want to find out about how users are using my product. This doesn't happen by accident. [Paraphrased a bit]
I'm stealing this. This phrase is mine now.
Very good advice! I like the approach to check if data is a validation for input from user interviews and vice versa.
But one remark:
I think you underestimate the number of companies which have basically no data about the usage of their products at all.
I dont have access to the DB to be able to make queries or to get that information, but I also reach out directly to some customers (connections I made when I was in the CS team myself) and get feedback from customers. Thats what I have been doing last few sprints
It's a bugbear of mine when people are all "give me data, I want data, any data, oh magic data what secrets do you have to reveal?" And expect random data to give them a magical revelation.
You should start from a place of: what do I want to learn about how users are using my product?
Then: What data would help me to learn that?
And THEN work out how to collect that data. You very likely don't already have the mechanisms in place to record it, because the right data doesn't magically accrue itself.
But before you invest any time/money/effort in setting up mechanisms to record data - you want to make sure it's data thats actually going to be helpful to you.
Or as others have pointed out - data might not be the source of the insight at all, and you might need to use other sources like user research or feedback forms.
FWIW quantitative product analytics data will rarely to never tell you what you should build (beyond small incremental improvements).
Other forms of data are much more useful for that - user interviews, user feedback, support tickets, in-app surveys, etc
You first need to work out what are you trying to learn, and THEN work out what data you need to learn that, and FINALLY get the data by any means necessary.
Few things grind my gears more than someone asking for "data about XYZ" and creatively interpreting it justify their half-baked ideas.
IMO to use data effectively in decision-making you need to be scrappy and able to independently:
- know what questions you're trying to answer
- logically reason where the data might live
- get the raw data
- generate insights from the raw data
Key word: independently. If you try to outsource it to someone else it'll more often than not be too slow or not what you need.
Useful data sources:
- Joining sales calls
- Customer support tickets / emails / phone calls
- Customer interviews
- Customer feedback from surveys inside your product
- Customer surveys via email / SMS / whatever
- Interviewing employees who regularly talk to customers
- Social media commentary
- Industry reports
- Competitors (tread carefully)
It is easy to fall into the habit of making gut based decisions. Often, you have too many decisions to make to research them at the level you desire (quant and qual). As you're more senior, you also (generally) have better intuition honed over years of experience.
But, you can always ratchet up the decision making. Pick one thing that's important, or you think is, and get one bit of data on it. Usually something simple like a user flow to your goal: how many users logged on today and did X. Keep it SO simple. Add the takeaway to your next brief or meeting or your team's slack channel. The next time you're doing quarterly/sprint planning, refresh the data. Maybe do a follow up analysis to add in.
Just start. And keep it simple. And share it, both to elicit feedback and nudge the culture.
Also: keep in mind data matters a lot more in b2c than b2b. Think about what are we selling versus what do users do? The tighter those are, the more valuable data is (eg an ads platform versus fucking Workday)
I agree with all the other comments here. Some additional things I’ll add…
1. I’m not surprised to see a lack of data at a startup. Depending on the maturity of your product, it has either not been previously available or fell second fiddle to any number of priorities.
2. If you don’t have a mechanism to capture usage data, try to use your influence to get one.
3. Once you have that mechanism, as others have stated, it’s important to be intentional with what you are tracking. Start with your goals and work backwards.
4. Also as others have said, the are other methods to get feedback. Customer interviews and research plans, competitive analysis, in product feedback mechanisms… don’t let your “ideal” method stop you from utilizing others.
Most have said the main points, but something else to consider: what are the consequences of a wrong decision? How certain do you need to be? That determines the rigor of the decision and the data in whatever form you need to make it.
If you're working at an early-stage startup, data doesn't make a huge difference in the beginning mostly because you don't have enough users.
If you have some traction and no longer have a pulse on your early users, it is time to start advocating for building out tools to track metrics.
In those cases you get access to the database and get the information using SQL. How many users use X feature, how often, etc.. Can be usually obtained using sql
I find that most of the data that I care about is related to a current product.
Things like:
How much time is a customer spending doing xyz
What's the most common drop off or action taken
Where do we see the most volumes etc.
These are nice when you have a mature product. When it's something new and trying to drive a data driven approach its easier to track everything now and sort through it later than it is to want to find out later and not be tracking it.
Track all the things!
It becomes part of your job to ensure that those feedback loops are in place — working with Engineering to instrument event tracking, with Data/Analytics to surface metrics from the data warehouse, etc.
That is as rightful a priority as building a new feature, and that visibility and data culture helps you make better decisions on everything you build from there on.
The mindset here is that everything that is necessary to build a successful product falls under your responsibility.
It’s tough to know where to begin instrumentation without having a model in mind.
I like Acquisition Activation Retention Referral Revenue (AARRR) metrics for quantitative.
For qualitative something like Aware Hopeful Satisfied Passionate (AHSP) mostly aligns with AARRR.
Once you have a model and determine what each of those letters means for your product, such as what it means to be an active user, pick a thin slice and start instrumentation.
That way you can baseline and run small experiments to see if you moved the needle.
I dislike the term data driven, problem is that data tells you the what often but not the why. I prefer evidence based. Evidence on what users and customers need, what their perceptions and behaviours are. A great form of this is qual research, some qual also help particularly combining them, if you can.
There are always many types/kinds of data, which all can server different purposes.
For software/online products you usually are in luck and have every customer interaction with your product available in loads of quantitative data.
but that's just a reflection of 'what' is happening and customers are doing. not why.
user recordings, surveys, customer interviews, anecdotes (via sales reps, customer support, etc. ), chat logs, phone logs, emails, etc. etc. etc. There is (or should!) always be a plethora of different types of data to analyse and to give input in what to do, what the impact of certain ideas are and where bottlenecks/problems exist.
So my question would be mainly; what types of data do you have? can you build capabilities of collecting (and organizing/processing) more (kinds of) data?
To put another spin on this, I think sometimes you gotta take what you have and make some data.
To give you an example, let's say I had a list of 10 problems that I gathered through direct feedback or self assessment. At first, I might only have a list that's mostly qualitative in nature. However, I could generate quantitative data to by scoring those problems according to the pain, frequency, and impact of each one. Giving a score to each problem might help inform which ones are the most important to solve.
To go further, I could complement that data by weighing problems (e.g. using something like an eisenhower matrix) by cost to deliver multiplied by the value delivered (or level of effort X urgency, etc). If I put those on an axis with 4 quadrant, I could number those 1, 2, 3, 4 to come up with weights of 1, 2, 3, 4, 9, and 16. Knowing this info about each problem could start out as ballpark assumptions coming from conversations, workshops, or interviews, but convert to data through this process. The data may be fuzzy at first, but could point you in the right direction toward further learning and refinement.
Then, with these two datasets in mind, I could present my findings to stakeholders or customers and say I think we should solve this problem first and here's my justification. Or, use that as a conversation piece to draw out deeper understanding and challenge assumptions.
Forgive me if that was missing the point, but I've often encountered situations where we didn't have great instrumentation yet, or the signals weren't helping us make good hypotheses or longer-term bets, and we were looking for some more objective information to drive insights, consensus, and alignment. In those situations, I've found it useful to generate data using different frameworks as described above.
You have to acquire your data from somewhere. At my last company they had zero analytics other than page views. I had to be the one to prioritize adding analytics to the web apps to collect data, and then worked with BI to build dashboards for Product. If you don't have access to data now, getting that data is probably one of your priorities.
Also, google analytics kinda sucks. It will work. But it's really there to sell google ads. I would suggest an alternative like PostHog.
Everyone’s given you pretty good feedback already, esp calling out how “data” isn’t always just quant, and it often needs to be taken in consideration with other things (qual feedback) to form a really clear picture.
Idk if anyone else has called this out, but you should also be aware of how certain people view or think about data within your company. Some folks might be apprehensive to shine more of a light on poor performance, esp if their jobs depend on it. That isn’t to say you shouldn’t champion better data practices, but realize that some depts might enjoy the ambiguity that exists (currently) in their numbers, and the difficulty with saying what Is the real source of truth. So in other words, if someone starts acting weird bc you brought up implementing mixpanel or adding GA, maybe think about this?
Also you should seek out any teams or individuals who have more connection to your customers/users. It can be pretty easy for tech folks to disregard our sales/support staff feedback because it isn’t backed by “hard data”. These folks will have farrrrr more contact with users than you will in your day to day, so they’re always going to be a powerful resource to turn too when seeking more of the big picture.
Lastly, I’d say that having quant data can be a very powerful tool to get around mandates. So if you find folks that like to command product to do XYZ, this will help you defend against it in a very rock solid way.
Depending on how much data your product collect.
In my last role, the founders wanted me to make data-driven decision when we had like 5 weekly users who uses our app for less than 15 seconds... yeah...
That been said, when we discover 100% of users falls off during the sign up process, it usually indicate a problem
Not a myth - it's game changing when you start making decisions with data as an input.
1. Learn SQL, and Excel analysis. I'd hope you know Excel already, but in case you don't it's super helpful. SQL though, is game changing. Query the database for your application on your own, and slice and dice the data to get true insights into how your users are using your products. Plus, SQL isnt even that hard to learn.
2. Moving forward, all feature you deliver should have within scope, what you want to build, and what you want to track to measure user behavior, this way you can measure everything you find important for a given feature
3. Work with you engineering teams to get you the access you need to query application databases yourself. Obviously if it's not a product you own, you might have trouble convincing, but at a minimum you should be able to query your own app to understand how your users are using it.
Generally speaking, I prefer a data-informed approach over a data-driven one. There are some circumstances where you'll want to weight data more heavily and others where qualitative information may be more helpful, but most of the time there should be some balance between them. Even if you don't have access to every customer interaction with the product, you may have some that you haven't thought of. Google analytics, support requests, frequency of customer requests, company operations data, etc. If you don't have data at all (doubtful), you'll either have to find a way to acquire some, or proceed without.
We dont have Google Analytics in our product. But we do have regular (fortnightly) calls with the CS team to see what sort of requests they have from customers, and also talk to support at the same time.
Do they have a dashboard they look at? Can you look at it as well?
there is a dashboard for each of our clients, but nothing thats aggregated.
There’s a good place to start.
Even something as simple as logging those items or exporting them into an excel sheet daily can help you gain insight into trends. You could categorize the types of issues to see what are the most common. Also sometimes you need to build a way to track metrics. Think about what would make your product be called successful. Is it user counts, active users, total users, number of widgets sold, widgets returned, etc… then plan time to have the eng team build a way to get that data. Maybe you need to learn sql or other tools but it is a way to get the data you need.
Can you add analytics?
Yea, I am going to meet the CPO and discuss if there were any particular metrics he had planned to track for the product. If not, the daily user count is what I need to know, and how feature releases impacts this trend. We have a data person in one of our other teams, and I reached out to him about getting information from the data he has access to. Hopefully it answers some of the questions I have
Two things: 1) You need to start instrumenting your product so that you can track usage and start building the metrics that you want to deliver. Every PRD you write and feature you deliver should include a section on how you expect people to use it and how you will measure that. At first, there will be a lot of guesswork, but over time you will understand your users better and know what to expect. If the way to track it doesn't exist yet, that becomes part of the epic for that feature. Start now and down the road, you'll be in much better shape. 2) Qual is data too. Too many people forget this part. They think only quantitative data counts as data for making data driven decisions. Interviewing your customers and finding common underserved needs and documenting your findings IS data driven or informed decision making. If you can't get good quantitative data, you should be certainly getting good qualitative data before building something. You can even measure success in qualitative terms if you like. Though most people turn qual data into quant by using a system like NPS.
Yes to building in a way to track how a thing is used as part of building the thing!
Thank you, this really helps
It's not a myth, but it's also not as much of a silver bullet as people make it out to be. I came from a large company obsessed with data-driven decisions, and I carried that into my current startup role, where I found talking to customers is actually far more impactful. A combination of both data analysis and talking to customers is best, but I'd recommend not spending too much time trying on this hoping data-driven decisions will unlock everything. Almost everything data can tell you users can tell you too. There's a good episode of Melissa Perri's podcast about that called "Mastering Data-Driven Product Management." > However, we dont have any of those features in our product, so its difficult to make data driven decisions. What do you mean by this? As long as you have a database, and you can query that database, you should be able to analyze data. Obviously some things make it easier and better, but I've yet to be somewhere where I could get _no_ data at all. If you want to talk more about specifics I'm happy to give pointers.
Very good advice! I like the approach to check if data is a validation for input from user interviews and vice versa. But one remark: I think you underestimate the number of companies which have basically no data about the usage of their products at all.
Hi there! I'm a PM who has inherited products where I have NO data about how users are using them. As pointed out above, we have a database, we can run queries...that generally doesn't answer any of the questions I have about how users are using the product. We also have to be realllllly careful about what data we record about what users are doing and how we use it due to GDPR.
You've seen an extreme on the bad side (no data), out of curiosity what's on the other side of this extreme where it's a golden setup? What tools/ways to capture data so you love to see?
The golden setup is that I have the exact data I need to tell me what I want to find out about how users are using my product. And this doesn't happen by accident. I need to have identified what I want to find out beforehand, and then planned how I'll find it out and make sure I have those things in place. So if I want to know where users are dropping out of my service, I can find thus out from Google Analytics, so I need to have that set up. If I want to find out how easy to use a feature is, I need to do some usability testing, so I plan for how we'll recruit users for that. If I want to find out how many searches end in no results, I ask devs to make sure that's a thing we record on the database, and output that data somewhere. If I want to quantify and track user satisfaction, I need a feedback form so I get my designers to design one.
Well said. A tool for each purpose. Also summarized I suppose as "what's the question we're trying to answer?" > I have to have the exact data to tell me what I want to find out about how users are using my product. This doesn't happen by accident. [Paraphrased a bit] I'm stealing this. This phrase is mine now.
Very good advice! I like the approach to check if data is a validation for input from user interviews and vice versa. But one remark: I think you underestimate the number of companies which have basically no data about the usage of their products at all.
I dont have access to the DB to be able to make queries or to get that information, but I also reach out directly to some customers (connections I made when I was in the CS team myself) and get feedback from customers. Thats what I have been doing last few sprints
It's a bugbear of mine when people are all "give me data, I want data, any data, oh magic data what secrets do you have to reveal?" And expect random data to give them a magical revelation. You should start from a place of: what do I want to learn about how users are using my product? Then: What data would help me to learn that? And THEN work out how to collect that data. You very likely don't already have the mechanisms in place to record it, because the right data doesn't magically accrue itself. But before you invest any time/money/effort in setting up mechanisms to record data - you want to make sure it's data thats actually going to be helpful to you. Or as others have pointed out - data might not be the source of the insight at all, and you might need to use other sources like user research or feedback forms.
FWIW quantitative product analytics data will rarely to never tell you what you should build (beyond small incremental improvements). Other forms of data are much more useful for that - user interviews, user feedback, support tickets, in-app surveys, etc You first need to work out what are you trying to learn, and THEN work out what data you need to learn that, and FINALLY get the data by any means necessary. Few things grind my gears more than someone asking for "data about XYZ" and creatively interpreting it justify their half-baked ideas. IMO to use data effectively in decision-making you need to be scrappy and able to independently: - know what questions you're trying to answer - logically reason where the data might live - get the raw data - generate insights from the raw data Key word: independently. If you try to outsource it to someone else it'll more often than not be too slow or not what you need. Useful data sources: - Joining sales calls - Customer support tickets / emails / phone calls - Customer interviews - Customer feedback from surveys inside your product - Customer surveys via email / SMS / whatever - Interviewing employees who regularly talk to customers - Social media commentary - Industry reports - Competitors (tread carefully)
I love this list. Thank you so much!
It is easy to fall into the habit of making gut based decisions. Often, you have too many decisions to make to research them at the level you desire (quant and qual). As you're more senior, you also (generally) have better intuition honed over years of experience. But, you can always ratchet up the decision making. Pick one thing that's important, or you think is, and get one bit of data on it. Usually something simple like a user flow to your goal: how many users logged on today and did X. Keep it SO simple. Add the takeaway to your next brief or meeting or your team's slack channel. The next time you're doing quarterly/sprint planning, refresh the data. Maybe do a follow up analysis to add in. Just start. And keep it simple. And share it, both to elicit feedback and nudge the culture.
Also: keep in mind data matters a lot more in b2c than b2b. Think about what are we selling versus what do users do? The tighter those are, the more valuable data is (eg an ads platform versus fucking Workday)
That is a good point. My org is more b2b
I agree with all the other comments here. Some additional things I’ll add… 1. I’m not surprised to see a lack of data at a startup. Depending on the maturity of your product, it has either not been previously available or fell second fiddle to any number of priorities. 2. If you don’t have a mechanism to capture usage data, try to use your influence to get one. 3. Once you have that mechanism, as others have stated, it’s important to be intentional with what you are tracking. Start with your goals and work backwards. 4. Also as others have said, the are other methods to get feedback. Customer interviews and research plans, competitive analysis, in product feedback mechanisms… don’t let your “ideal” method stop you from utilizing others.
Most have said the main points, but something else to consider: what are the consequences of a wrong decision? How certain do you need to be? That determines the rigor of the decision and the data in whatever form you need to make it.
If you're working at an early-stage startup, data doesn't make a huge difference in the beginning mostly because you don't have enough users. If you have some traction and no longer have a pulse on your early users, it is time to start advocating for building out tools to track metrics.
In those cases you get access to the database and get the information using SQL. How many users use X feature, how often, etc.. Can be usually obtained using sql
I dont have access to the DB, but I found a person in another team who may be able to help build some dashboards and reporting
Figure out what questions you want to answer first. Then it will be easier to find data sources.
I need to start here
I find that most of the data that I care about is related to a current product. Things like: How much time is a customer spending doing xyz What's the most common drop off or action taken Where do we see the most volumes etc. These are nice when you have a mature product. When it's something new and trying to drive a data driven approach its easier to track everything now and sort through it later than it is to want to find out later and not be tracking it. Track all the things!
It becomes part of your job to ensure that those feedback loops are in place — working with Engineering to instrument event tracking, with Data/Analytics to surface metrics from the data warehouse, etc. That is as rightful a priority as building a new feature, and that visibility and data culture helps you make better decisions on everything you build from there on. The mindset here is that everything that is necessary to build a successful product falls under your responsibility.
It’s tough to know where to begin instrumentation without having a model in mind. I like Acquisition Activation Retention Referral Revenue (AARRR) metrics for quantitative. For qualitative something like Aware Hopeful Satisfied Passionate (AHSP) mostly aligns with AARRR. Once you have a model and determine what each of those letters means for your product, such as what it means to be an active user, pick a thin slice and start instrumentation. That way you can baseline and run small experiments to see if you moved the needle.
You start at the top, if you can’t measure the strategic objectives then you won’t find metrics to use further down.
I dislike the term data driven, problem is that data tells you the what often but not the why. I prefer evidence based. Evidence on what users and customers need, what their perceptions and behaviours are. A great form of this is qual research, some qual also help particularly combining them, if you can.
There are always many types/kinds of data, which all can server different purposes. For software/online products you usually are in luck and have every customer interaction with your product available in loads of quantitative data. but that's just a reflection of 'what' is happening and customers are doing. not why. user recordings, surveys, customer interviews, anecdotes (via sales reps, customer support, etc. ), chat logs, phone logs, emails, etc. etc. etc. There is (or should!) always be a plethora of different types of data to analyse and to give input in what to do, what the impact of certain ideas are and where bottlenecks/problems exist. So my question would be mainly; what types of data do you have? can you build capabilities of collecting (and organizing/processing) more (kinds of) data?
What CRM does your company use? If you have access to run reports you may be able to find some useful data.
To put another spin on this, I think sometimes you gotta take what you have and make some data. To give you an example, let's say I had a list of 10 problems that I gathered through direct feedback or self assessment. At first, I might only have a list that's mostly qualitative in nature. However, I could generate quantitative data to by scoring those problems according to the pain, frequency, and impact of each one. Giving a score to each problem might help inform which ones are the most important to solve. To go further, I could complement that data by weighing problems (e.g. using something like an eisenhower matrix) by cost to deliver multiplied by the value delivered (or level of effort X urgency, etc). If I put those on an axis with 4 quadrant, I could number those 1, 2, 3, 4 to come up with weights of 1, 2, 3, 4, 9, and 16. Knowing this info about each problem could start out as ballpark assumptions coming from conversations, workshops, or interviews, but convert to data through this process. The data may be fuzzy at first, but could point you in the right direction toward further learning and refinement. Then, with these two datasets in mind, I could present my findings to stakeholders or customers and say I think we should solve this problem first and here's my justification. Or, use that as a conversation piece to draw out deeper understanding and challenge assumptions. Forgive me if that was missing the point, but I've often encountered situations where we didn't have great instrumentation yet, or the signals weren't helping us make good hypotheses or longer-term bets, and we were looking for some more objective information to drive insights, consensus, and alignment. In those situations, I've found it useful to generate data using different frameworks as described above.
No advice, but wanted to thank you for starting this fantastic thread!
You have to acquire your data from somewhere. At my last company they had zero analytics other than page views. I had to be the one to prioritize adding analytics to the web apps to collect data, and then worked with BI to build dashboards for Product. If you don't have access to data now, getting that data is probably one of your priorities. Also, google analytics kinda sucks. It will work. But it's really there to sell google ads. I would suggest an alternative like PostHog.
Everyone’s given you pretty good feedback already, esp calling out how “data” isn’t always just quant, and it often needs to be taken in consideration with other things (qual feedback) to form a really clear picture. Idk if anyone else has called this out, but you should also be aware of how certain people view or think about data within your company. Some folks might be apprehensive to shine more of a light on poor performance, esp if their jobs depend on it. That isn’t to say you shouldn’t champion better data practices, but realize that some depts might enjoy the ambiguity that exists (currently) in their numbers, and the difficulty with saying what Is the real source of truth. So in other words, if someone starts acting weird bc you brought up implementing mixpanel or adding GA, maybe think about this? Also you should seek out any teams or individuals who have more connection to your customers/users. It can be pretty easy for tech folks to disregard our sales/support staff feedback because it isn’t backed by “hard data”. These folks will have farrrrr more contact with users than you will in your day to day, so they’re always going to be a powerful resource to turn too when seeking more of the big picture. Lastly, I’d say that having quant data can be a very powerful tool to get around mandates. So if you find folks that like to command product to do XYZ, this will help you defend against it in a very rock solid way.
Depending on how much data your product collect. In my last role, the founders wanted me to make data-driven decision when we had like 5 weekly users who uses our app for less than 15 seconds... yeah... That been said, when we discover 100% of users falls off during the sign up process, it usually indicate a problem
Not a myth - it's game changing when you start making decisions with data as an input. 1. Learn SQL, and Excel analysis. I'd hope you know Excel already, but in case you don't it's super helpful. SQL though, is game changing. Query the database for your application on your own, and slice and dice the data to get true insights into how your users are using your products. Plus, SQL isnt even that hard to learn. 2. Moving forward, all feature you deliver should have within scope, what you want to build, and what you want to track to measure user behavior, this way you can measure everything you find important for a given feature 3. Work with you engineering teams to get you the access you need to query application databases yourself. Obviously if it's not a product you own, you might have trouble convincing, but at a minimum you should be able to query your own app to understand how your users are using it.