Why do customers value your open-source project? How to monetize open-source projects [Pt. III]
This is part three of a five-part guide on how to monetize open-source projects. This week we are working through a framework on how to interview customers to get actionable insights.
This is part three of a five-part guide on how to monetize open-source projects.
Part I, Introduction. We start with common monetization mistakes and frameworks like Business > Product > Technology, reasons why monetizing open-source projects is hard, and finally, different types of open-source projects.
Part II – Economics of open source. This piece discusses the economics of open-source projects. We also talk about how to determine what value your specific open-source project delivers to your intended customers.
Part III – Today we’ll cover a detailed plan on how to get feedback from customers.
Part IV (May 1) - We will use the information that you filled in the worksheet to decide monetization scheme and actual pricing.
Part V (May 8) - We’ll cover creating long-term value and building a sustainable business.
Part VI (May 15) - Finally, as a bonus, we’ll cover Artificial Intelligence and Open Source.
Skip intro….
Feel free to skip this part if you remember everything from the last two parts. Otherwise, here is a quick recap.
- Common monetization mistakes
- Business > Product > Technology
- Why monetization is tough (you’ll be surprised)
- Different types of open-source projects (standards, libraries, frameworks, and applications)
- Why use tools from economics to understand open-source?
- The coordination problem in economics
- Two ways of solving the coordination problem – markets and firms
- Open source is organized differently – commons-based peer production
- Incentives for individuals and companies to participate in open source
- Another tool to analyze open source – Value Chain Analysis
- Value chain for standards, libraries, frameworks, and applications
- Value creation-Value Capture framework
In today’s post, we will cover an actionable framework to get feedback from your customers. We'll discuss how to conduct customer interviews especially to determine what next steps you need to take.
From technology to product
The conversation we have with customers needs to help us decide on two important, and interrelated questions,
- What steps do we have to take to make the open-source project into a business?
- What do we have to do to make the project into a product?
If you are wondering why we are differentiating between a business, product, and technology, read this. In all likelihood, the open-source project that you are going to monetize is a core technology and not a product, leave alone a business. Yet.
Use case map
We need a framework to collate the raw information that we’ll be collecting during, and after talking to customers. This will help us analyze all the information while trying to reduce bias as much as possible. To do that we’ll put the information that we have collected in a use case map along two dimensions
The problem we are solving, and
Who we are solving the problem for
What problems do customers solve with your project?
Key Pain Points: We need to determine the key problem or pain point that the open-source project addresses. Customers often use generic terms when discussing their pain points, such as "faster" or "better." That is not actionable and does not help us think through monetization. It is crucial to dig deeper to uncover the core issues they are facing. Users might be grappling with budget constraints or facing performance pressure from their superiors, and your project could help them achieve results more quickly or cost-effectively.
Frequency: Next, consider the frequency with which users encounter the problem. Some issues may arise only occasionally, like the annual tax-filing process addressed by TurboTax. In contrast, others may be more frequent, such as the instant communication needs met by platforms like Slack or Discord. Understanding the frequency of the problem will help you gauge the value and relevance of your solution.
Alternatives: Next, we need to examine the alternatives available to users when seeking solutions to their problems. Alternatives may include other software projects or entirely different approaches. For instance, Slack faces competition from Discord and Microsoft Teams, which offer similar functionalities.
Additionally, the "do-nothing" option should be considered; if this is a viable choice for users, it may indicate that the pain points your open-source project addresses is not significant enough.
What differentiates your solution: Identify the factors that differentiate your solution from the alternatives. We need to get to the heart of what makes this project better for this customer. What prompted them to pull the trigger and also, why do they keep using it? Is your project easier to use, or does it yield faster results? Perhaps the support provided by your community or the quality of your documentation sets you apart.
The next set of things we need to decode is about the people who are using the product.
Understanding the users
Understanding the users of your software product is crucial for its ongoing success and development. We want to recognize who is using your software, their job titles, and their emotional investment in your product.
Demographics: Job titles can provide valuable context for how users interact with your software. For example, a marketing manager may use your product to analyze campaign performance, while a software developer might utilize it for project management and collaboration. By recognizing these distinctions, you can ensure that your product caters to the unique requirements of each user group and provides features and functionalities that address their specific needs.
Emotional attachment and motivation: Once you have a clear understanding of who is using your software, it's important to gauge their emotional attachment to your product. One way to measure this is by asking users how sad they would be if your software were to suddenly become unavailable. Their responses can shed light on the extent to which they rely on your product and the value it brings to their lives.
Caveats in interviewing
It's essential to approach these interviews with caution and mindfulness, being aware of certain caveats that can hinder the effectiveness of the process.
Not a journey map: The goal of these interviews is not to create a journey map. A customer journey map is a visual representation of the customer's experience with a product or service, outlining the different touchpoints, interactions, and emotions they encounter.
Focus on the problem not the solution: Customer interviews should focus on the problem space rather than the solution space. The problem space refers to the set of issues, challenges, and needs faced by customers, while the solution space encompasses the potential products, services, or features that can address these concerns. Founders and technical people often start thinking of architecture, database relationships, and GitHub repos while the customer is describing their problem. Avoid this temptation. This can lead to biased results and missed opportunities for uncovering valuable insights.
Which customers should you talk to?
Since you already have a thriving open-source project your first instinct will be to call your existing customers. That is a good start but it is not enough.
Talking to existing customers can help confirm or deny your mental hypothesis of the core value that your open-source project is providing. They can also help you fine-tune your customer interview style. But they are not going to help you learn anything new. We need to talk to potential customers who could be using your open-source project.
To work through these examples, we need to find people that are not using your project right now. The best way to do that is to ask your existing customers for referrals. In our experience, if you frame this correctly as a learning exercise and not a selling exercise then you will get a lot of referrals.
Talking to people that are not using your project right now, but could, helps you uncover new use cases and insights.
Tips on the actual interview
Avoid leading questions
To avoid asking leading questions in customer interviews, it's crucial to pay close attention to the phrasing and structure of your inquiries. Start by using open-ended questions that encourage the interviewee to share their thoughts and experiences without any preconceived notions or assumptions.
Bad questions
Do you enjoy working with [xyz] repo?
Was the installation easy?
Did you like the documentation?
Good questions
How did [xyz] repo make your development process easier?
How did it take you to install [xyz]? Did you expect it to take lesser time? Where did you get stuck?
How many times did you have to refer to the documentation? At what point? Did you search Google for documentation or did you navigate inside the documentation site?
We are trying to insights by structuring the question around how what and why.
Bias in language
Additionally, actively monitor your language and tone to ensure that you do not convey any personal bias or preference. When framing questions, avoid using words that imply positive or negative connotations, as they can influence the customer's response. For example, instead of asking, "How satisfied were you with our product?" opt for "How would you describe your experience with our product?" This neutral phrasing helps eliminate any implied expectations and enables the customer to provide a more authentic response.
Customers will tell you what they think you want to hear
Most people tend to avoid confrontation when they can. During customer interviews, it is not uncommon for customers to say what they believe the interviewer wants to hear, either consciously or unconsciously. This phenomenon is known as social desirability bias.
Here are some tools to help avoid social desirability bias.
Unaided Questions: When asking questions that aim to uncover the biggest problems or challenges in a particular area, it's essential to use open-ended phrasing to encourage respondents to share their genuine thoughts and experiences.
Examples of questions that follow this format include:
1. What are the biggest challenges you face when using our software?
2. What are the most significant obstacles you encounter when trying to complete your tasks using our platform?
3. What are the primary difficulties you experience when navigating our website?
4. What are the most pressing issues you face in managing your team's workflow with our project management tool?
5. What are the top concerns you have when trying to integrate our solution with your existing systems?
Aided questions: Asking questions that help jog customers' memory can be an effective way to elicit more accurate and detailed responses. By providing context or presenting a scenario, you can help the interviewee recall relevant information that might not have been top of mind. However, be cautious not to lead them towards a specific answer, as this can result in biased responses.
Examples of questions that can help jog customers' memory include:
1. We've heard that some users have experienced difficulties with our mobile app's navigation. Can you think of a time when you encountered a similar issue?
3. We have received feedback that the onboarding process for our service can be overwhelming for new users. Can you recall your experience when you first started using our service and if you faced any challenges during that time?
4. A few customers have reported that our customer support response times could be improved. Have you ever needed assistance from our support team and felt that the response time was not satisfactory?
Stack ranking priorities: Forcing customers to prioritize their choices by stack ranking is an effective method to better understand their preferences and needs. Stack ranking requires the customer to order a list of options, features, or issues based on their importance or preference. This approach allows you to gain insights into what matters most to your customers, helping you make informed decisions about where to focus your efforts and resources.
You can ask customers something like, "You have suggested five improvements. Which ones of these are the most important?" Our favorite phrasing is, "If you can get one feature next month, which one should it be?"
We are mixing stack ranking with forced choice, but the key idea is the same.
Budget allocation: Another method is the "budget allocation" technique, where customers are given a hypothetical budget and asked to allocate funds to various features, improvements, or issues. The allocation of funds will reflect their priorities, with more budget being allocated to the items they deem most important.
Each of these methods offers a unique way to gather prioritized feedback from customers, helping you better understand their needs and preferences, and ultimately improving your product or service offerings.
Summarizing feedback
Categorize the takeaways into two groups: first-order and second-order findings.
First-order findings: These are the direct observations, comments, and feedback provided by the customer during the interview. These findings include specific product or service-related issues, preferences, likes, and dislikes. They often represent the most immediate and tangible aspects of the customer's experience. Examples of first-order findings might include a
If the customer describes a particular feature as difficult to use
Dissatisfaction with response times from customer support,
Mentioning a specific need that your open-source project fulfills.
Second-order findings: These are the underlying patterns, trends, or insights that emerge when analyzing and interpreting first-order findings. They often reveal deeper customer motivations, unmet needs, or broader challenges faced by users. Examples of second-order findings might include
Identifying a common pain point among customers that could indicate an opportunity for product improvement
Discovering a gap in the market that your product could fill
Recognizing an emerging trend that could impact your business.
Some other things to keep in mind
We are focused on monetization, not building
This whole guide is about monetizing an existing open-source project. We will be focusing on just that and not on building a product.
In standard product management practice, there would be a lot of work done to discover the problem and validate if it is worth building the product or not. What we are doing here is different. We have a product (in the OSS project). We are trying to discover and articulate why people use this problem.
If you are interested in learning about how to find what to build by talking to customers there is a lot of content for that out there already. We can recommend Lenny’s Newsletter for that.
Don’t skip this part
You’ll be tempted to skip this step since you think you know the problem that people are trying to solve. DO NOT skip this step. You might have a good intuition on what the users of your open source project are using the project for you but you likely don’t have an idea of how they value your work. Monetization is about finding value.
Don’t outsource this to product managers
Another difference is that a lot of product management is designed to collect information and inform and convince. In this case, you are doing the work yourself. As I have said before, don’t outsource this.
Here is a sample customer interview script that you can use as a jumping-off point for your interview calls.
Customer interview script
Introduction
1. Thank you for taking the time to speak with me today. My name is [Your Name], and I am the creator or maintainer of [open-source project]. We're continuously working to improve our product, and your insights as a customer are incredibly valuable to us.
2. This interview should take about 45 to 60 minutes, and we'll be discussing your experiences with our product, the problems you're solving, and any alternatives you may have considered. Your feedback will help us refine our pricing and monetization strategies to better serve you and other customers.
3. Please remember that there are no right or wrong answers; we're simply interested in learning about your honest opinions and experiences. Feel free to be as open and candid as possible.
4. With your permission, I'd like to record this interview so that I can review it later for a more accurate understanding. Is that okay with you?
Problem identification
5. Can you describe the main problem or challenge that you were facing before you started using the project/library/framework?
6. Can you tell me about a specific situation when you encountered this problem? What was the impact on you or your business?
7. How frequently do you face this issue?
8. What other problems are you solving with our product? If you could rank these problems in terms of their importance, what would that ranking look like?
Customer Persona
9. Can you please tell me about your role within your company or organization?
10. What are the main responsibilities in your role, and how does our product help you fulfill those responsibilities?
11. Who else in your company or organization benefits from using our product? Can you describe their roles and how the product helps them?
12. How does our product fit into your overall workflow or daily activities?
Alternatives
13. Before using our product, did you try any other solutions or approaches to address the problem? Can you please describe them?
14. What factors led you to choose our product over these alternatives?
15. Are there any other products or services you're aware of that could potentially solve the same problem?
Product Differentiators
16. What were your initial motivations to try our product? What attracted you to it?
17. Can you describe any unique features or aspects of our product that stood out to you?
18. How has using our product impacted your work or life? What are some specific examples of the benefits you've experienced?
Memory Joggers and Open-Ended Questions
19. We've heard from other customers that they've struggled with [a specific problem]. Have you experienced this as well? Can you tell me more about that?
20. Can you describe any challenges or obstacles you've faced in trying to achieve your goals with our product?
21. Is there anything else you would like to share about your experience using our product, or any additional feedback you think might be helpful?
Closing
22. Thank you so much for taking the time to share your thoughts and experiences with me. Your feedback is invaluable as we continue to improve our product and pricing. If you have any further questions or comments, please don't hesitate to reach out to us.
23. With your permission, we may reach out to you in the future to follow up on any points from this conversation or to gather additional feedback. Would that be okay with you?
24. Thank you once again, and have a great day!
Next week
We will use the information that you filled in the worksheet to decide monetization scheme and actual pricing.