Just curious about the qualities you guys need in an excellent product analyst, such as tools, expertise, etc. Is there anything that product analysts should be doing that you don’t see them doing?
I don’t always see the value in hiring a lot of product analysts because I think product managers can often conduct a lot of the analysis themselves very quickly using amplitude and other tools. What do you think?
Hello @SamanthaYuan,
I could do it myself, of course. However, there are numerous more tasks that only I, the product manager, am able to complete, such as product definition, dealing with design, organizing user research, etc. The PM is a generalist by definition, but that doesn’t mean I should do things just because I can; instead, I should focus on what would help the team and my product achieve its full potential.
I seek for three things in analysts:
Technical expertise To be an excellent analyst, this is required yet insufficient. You must be familiar with SQL, statistics, A/B testing techniques, possibly some R/Python, etc. basic competencies for everyone working with data. (Should you possess ETL expertise? Well, in my opinion, that depends on the business; in large businesses, a data engineering team is able to handle that; in smaller businesses, perhaps the analyst must occasionally take the lead.
A business setting. This, in my opinion, is what sets average analysts (and data scientists) apart from truly outstanding analysts. I won’t believe anything you suggest to me or the analysis you produce if you don’t take the time to understand how the product actually operates and what can affect the metrics because it won’t accurately reflect reality. When product analytics was centralized at the firm where I used to work, you effectively got a different analyst every time who knew nothing about your product and had to produce some complicated analysis in a week. Senior leadership, you know what? The analysis was consistently faulty and superficial.
Interaction. A sophisticated analysis is challenging to explain. And to make matters worse, the analyst sometimes needs to “telescope” up and create a simpler version to present to senior management or business stakeholders who are unfamiliar with the product in addition to explaining it to me and my team. Inexperienced analysts (and DSes, too) may be tempted to use a highly complex KPI indicator that may be extremely sound but confuses the living daylights out of external stakeholders. Thus, it is crucial to be able to communicate, tell a story, and demonstrate (for instance, through charts).
I completely concur with point one. I think analysts can get away with having superb SQL but terrible soft skills or business experience, which makes them worse analysts than they would be if they only had basic SQL and a sound business mind.
I divided the PA’s duties generally into three categories:
Get insights from the data that is already available by looking at the data we presently have and identifying trends. They should develop theories (or borrow them from others) and then support or refute them. They are essentially maximizing the knowledge gathered from the available data.
Increasing the amount of data available, whether by adding additional sources, converting it to a data warehouse (making it aesthetically pleasing and easily accessible), or performing transformations (i.e. calculations on existing data).
New data insights are essentially experiments and launches that ensure you are aware of what actually transpired. ensuring that your groups are stratified (about equal), and that you are aware of the statistical importance of what you are doing.
This leads me to the conclusion that, regardless of who is on the team, it is the PM’s obligation to ensure that the aforementioned occurs.
If no one is present, they must make this happen. It will most likely be simple and non-technical.
If the technical need makes it unfeasible, they will ensure that effort to make it available is prioritised by an engineer or personal assistant.
They will advocate for an engineer or PA to join the team if neither is available.
If there is a PA on the team, they will ensure that they are focusing on the research and experimentation opportunities that have the greatest potential.
I hope that was helpful, and I’d be happy to answer any other inquiries.
@NaomiNwosu, This seems to be quite accurate in general. My team’s PA has three primary areas of accountability (these may change as we are also bringing in Amplitude but for now we use Google)
1- Analyzing, auditing, and designing our tagging strategy for online and app properties
2- Identifying and collaborating with data engineers to include additional data sets into data studio for improved reporting.
Create important metrics and insights from recently released products and features.
These may all be PM responsibilities but doing so frees us up to concentrate on strategy and development rather than spending time gathering and preparing data.
I agree on all those points, for me the lines just get a bit blurry between some of the PM and PAs responsibilities, but maybe that’s just because of my recent employment.
Hello everyone. @NaomiNwosu, you are correct. There could be a lot of overlap in approaches and skill sets. When a product analyst is hired by a generalist PM, I would attempt to avoid doing that. Therefore, someone with a background that emphasises “analysis” rather than “product.”
Conducts analyses that have already been scoped flawlessly (deep-dive into AB tests and how it changed user behavior, checking if a surface area has broken windows by looking at drop-off rate)
Suggests novel approaches to analysis that can help the product roadmap
Ensures, in collaboration with engineers, that event tracking and tables are operational as required to support any analysis we choose to perform.
A great PA:
Proposes updated or new measurements that more accurately reflect the business objective
Turns into the go-to authority in the subject they cover
Based on their in-depth knowledge of the product’s utilization from a data perspective, finds new potential for the product.
I believe that product analysts should find market gaps as soon as possible. Knowing the audience’s demands, the market’s tendencies, and its future developments
The final product should be useful information that the PM can use to make decisions. It might even identify hazards or opportunities for the firm or product.
@HeatherKurtz, Agree with this. I think the Product Analyst is just a title that is more palatable for BAs going from waterfall to agile environments. Like Product Owners or Product Managers, a PA would need to wear several hats as well.
The most common duty of a Product Analyst is to utilize data analysis software to research market trends. Their main contribution to a company is to correctly project the costs of developing and marketing a product, as well as potential sales and profit.
Before putting a product on the market, or to determine what upgrades can help increase sales of an already-developed offering, Product Analysts interview existing customers and/or potential users to get their feedback. This can be done via conducting focus groups, individual interviews and usability tests as well as anonymous surveys.
In this role, individuals must liaise with numerous parties from different departments. Product Analysts work with marketing departments to explore entering into new market sectors; advise salespeople on a competitive pricing strategy; project the costs of development and launch for the finance department; as well as suggest improvements to the development team.
I genuinely disagree that performing market research is a product analyst’s “common duty.” Although they should always keep an eye on the competition, I believe that knowing their own product inside and out and being able to suggest changes should come first.
The most effective people I’ve worked with see opportunities inside recently announced features based on the new measures, while developing data sets and KPIs always with an eye toward enhancing the bottom line.