So far, we've talked about your role as product manager, and we've also talked about the designers, engineers, and product marketing managers you'll be working with very closely every day.
But there are other people in supporting roles you'll also work with. These people will probably not be dedicated solely to your team, as they are typically assigned to a small number of other product teams.
Now, you might not have any of the people I'm about to describe available to you. It really depends on the size and type of organization you work at. If you're at a small startup, you very probably will have none of these roles, and you will need to cover these activities yourself. But if you're at a company that has some or all of these roles, I want you to know why they exist and, most important, how to make the best use of these people.
As you'll soon see when we talk about how we do product discovery, we are continuously doing two kinds of rapid learning and experimentation. One kind of learning is qualitative, and the other is quantitative.
Especially with the qualitative learning, some of our research is generative, which is understanding the problems we need to solve; and some of our research is evaluative, which is assessing how well our solutions solve the problem.
User researchers are trained in this range of qualitative techniques (and some of them are also trained on the quantitative techniques as well). They can help you find the right type of users, craft the right types of tests, and learn the most from each user or customer interaction.
The key to tapping into the real value that these user researchers can provide is to keep in mind that the learning must be shared learning. You need to witness the insights first hand. More on this when we talk about the principles of product discovery, but while I want you to appreciate what user research can help you with, I don't want you to think you can delegate to them to do the learning and then send you a report.
If your company does not have user researchers, then your product designer will typically pick up these responsibilities for your team.
Similarly, for quantitative learning, data analysts help teams collect the right sort of analytics, manage data privacy constraints, analyze the data, plan live‐data tests, and understand and interpret the results.
Sometimes, data analysts go by the name business intelligence (BI) analysts, and they're experts in the types of data that your business collects and reports. It is well worth making friends with your data analyst. So much of product work today is data driven, and these people can be real gold mines for you and your organization.
In some companies, especially those with a lot of data—such as larger consumer companies—this may be a full‐time role dedicated to a specific product team. In this case, the data analyst would be sitting and working alongside the product manager and product designer.
Data analysts help teams collect the right sort of analytics, manage data privacy constraints, analyze the data, plan live‐data tests, and understand and interpret the results.
If your company does not have any data analysts, then responsibility for this typically falls on the product manager. If this is the case, you'll probably need to plan to spend significant time diving deep into the data to understand your situation and make good decisions.
Test automation engineers write automated tests for your product. They have largely replaced the old‐style manual quality assurance (QA) people.
Now, it's very possible that your engineers are responsible both for writing software and for writing these automated tests. If that's the case, then you probably won't have many test automation engineers. But most companies have a blended approach in which the engineers write some of the automated tests (e.g., the unit level tests), and the test automation engineers write the higher‐level automated tests.
Whichever model your company has is typically up to the engineering leadership, which is fine. However, what's not okay is if your company doesn't have test engineers, and your engineers don't do the testing either, and they are looking to you as product manager to do the quality testing.
While it's true as product manager you want to make sure things are generally as you expect before things go live (acceptance testing), that's a far cry from being able to release with confidence. The level of test automation necessary to release with confidence is significant and a big job. It's not unusual in complex products to have multiple test engineers dedicated to each product team.