One of the core jobs of product managers is to speak with users to better understand their needs, pain points and the context in which they operate and use our products. But not all user calls are the same.
There are 3 prominent types of user calls:
- Discovery or problem validation calls
- Roadmap discussions
- Solution validation calls
Here's an in-depth look at how we approach the three types of user calls at GitLab.
Discovery calls
Discovery or problem validation calls are product managers' most crucial conversations with users. Discovery calls are typically set up to learn about our users in a targeted way. These calls help build a better understanding of users' pain points.
For discovery, we need a recipe for repeatable, comparable user calls. For this reason, we should create an interview script and follow that script on all the user calls. This does not mean these calls are robotic and devoid of improvisation, not at all! The script should provide the backbone of the discussions. We can adjust it either during the call or in advance based on prior knowledge about the user. Good discovery calls typically take the form of a deep-dive conversation: we know the script by heart and can run back and forth around it, always asking the questions that fit the conversation.
Finding the right users is one of the most challenging parts of discovery calls. Thankfully, with GitLab, this is relatively easy. We can always reach out to the most active users on issues and invite them to a call. Another technique I employ is to find users in the Cloud Native Computing Foundation and Kubernetes communities' Slack channels and articles on Medium. This way, I can also find non-GitLab users, a set of people likely more valuable to interview than existing users. Finally, we can recruit users with the support of the account managers. They are always helpful in connecting PMs with users. Asking the users about their needs shows them that we genuinely care about them.
There are at least two distinct discovery calls: PM-led or UX-led. UX research typically works on projects with a strict scope. For PM-driven calls, a great framework is "Continuous discovery" calls by Teresa Torres. With continuous discovery, we build a deep understanding of our users and get well-understood opportunities. The technique allows us to get a broad view and to dive deep into specific aspects of our problem space when needed.
Roadmap discussions
Roadmap discussion calls are typically initiated by sales or account management teams. Product managers are asked to join the prospect/customer call to strengthen our positions and show how much we care for the customer.
To prepare for roadmap discussions, PMs should have an effective way to present the roadmap. This typically happens in the form of slides. A diligent PM might even prepare something specifically for the client.
During these calls, the user/customer/prospect will typically ask the questions, and the PMs respond. Our role in these calls is to represent the truth. We might be tempted to paint a rosier picture about the current or expected state of the product than is actually true, and we should avoid making time-bound promises.
What are the expected outcomes of roadmap discussions? They can help strengthen our position with the user. Remember that these calls primarily cater to our customers/users and customer-facing teams. As such, they are unlikely to provide deep learning about our users.
If we approach these calls with the intention to prove that our roadmap is correct, we will likely fall victim to both response and confirmation biases. There are techniques to validate a roadmap, but they are more aligned with problem validation than roadmap discussion calls. For example, UX researchers should be able to help validate a roadmap as a UX research project.
Solution validation calls
Last but not least, we have solution validation calls. These calls serve our learning but are way more focused than discovery calls. Solution validation calls require some form of a prototype for a specific problem we want to test and get feedback on from our users.
At GitLab, the prototypes are typically built by product design or engineering. The product manager might miss some of these calls in an empowered and autonomous team. But, as these calls are great learning experiences, we should aim to be there to support and learn if we can.
A solution validation call might be started with a concise roadmap discussion. Unlike in sales calls, our aim is not to influence the user but to set the scene for solution validation. The central part of the call should be around the proposed solution. We should provide the least amount of guidance to our users since there are no humans available to direct our users when they are working with the actual product. If much guidance is required, that is a sign that we might want to rethink our UX approach.
Finding suitable interview candidates for a solution validation call might be tricky. For GitLab, we often use the shortcut of inviting users based on their activity on relevant issues. Sometimes, when our issues provide enough context, we might get some solution validation asynchronously as users give their feedback directly in the issue.
How many calls?
How often does a good PM have all these calls? For discovery calls, I aim to have 3 calls per week. Above this, I don’t mind taking 1 sales call. While I prefer the product designer to run solution validation calls, I try to participate there too. Not every solution requires dedicated validation, so having a target number for solution validation calls is unrealistic. The better the discovery calls are, the fewer solution validation calls you might need. Still, even the best discovery cannot and should not answer all the questions of a solution validation. Often there are different (and totally valid) approaches to the same problem, and we need to pick the one that is the easiest for users to understand.
I think we need to speak to our users every day. Working at GitLab, sometimes this might take the form of issue comments, but face-to-face calls are a must. In any case, during these discussions we should aim to learn from our users, not just answer their questions. A handy question in issues is to ask for more context from our users. The response might highlight unknown use cases or edge cases we missed previously.
Take the calls
It is helpful to remember all the user call types we practice as PMs. As mentioned, I think the most crucial user calls for PMs are the discovery calls. If we don’t make discovery calls, nobody will; also, PMs might not be needed in the other calls. That said, a product manager's job is to also help the business be viable. So we should be able to support sales and always have a deck ready for roadmap calls. Lastly, we should work continuously with our team on solution validation so that everyone is confident in our solution.
