Messaging and Positioning Considerations for Introducing an Open Source Product
If your open source product vanished overnight and all the code disappeared, how would people respond? The community’s reaction, whether it ranges from not being a big deal to complete, utter despair, will reveal the true worthiness of your product.
At the All Things Open conference, Emily Omier, a seasoned positioning consultant, sat down with Avi Press (Founder and CEO, Scarf) and Matt Yonkovit (The HOSS, Scarf) to discuss how to message, position, and validate your open source product on The Hacking Open Source Business Podcast. You can watch the full episode below or continue reading for a recap.
Because measuring adoption and usage of open source products is a major challenge, sometimes the hyper emphasis on quantitative metrics (e.g, the ratio of documentation views to downloads or churn rate at each phase of the user funnel) can overshadow the often overlooked yet equally important qualitative dimensions. Understanding perceptions greatly matters too and provides a wealth of insights to glean from. In order to obtain this data, you need to get feedback.
The following section is especially applicable to product teams, organizations supporting business owners (OSBOs), and marketing and sales teams looking to gather qualitative data that can inform the direction of a product. You can source user interviews by speaking with existing users, reaching out to potential users in your target audience, or hosting a listening tour. User interviews serve as one of the most prevalent methods for sourcing qualitative feedback, but it takes a certain mindset to get them done right.
When starting a company, it is natural to derive your vision and mission from a very particular use case. Over time, the tendency can be to zero in on that use case and build your product entirely around it. This perspective, however, can limit your product potential and even cause you to ask the wrong questions during the learning process. Perhaps your users indeed use the product in the way that you have in mind, but this may not always be the case. Sometimes they might use it for a slightly different purpose and oftentimes for wildly different ones. By making too many assumptions about your users, you can project conclusions that you’re seeking to hear instead of allowing users to transparently communicate their needs.
For example, one company that Emily consulted had created an open source project aimed at reducing cloud costs—at least this was their original intention. On the other hand, users did not view it as a cost control product. Therefore, when the company asked users why they needed to get their cloud costs under control, the question appeared irrelevant and failed to elicit any valuable information about actual usage. A carefulness to avoid assumptions would have led to greater revelation.
As a general rule, most of your time during a user interview should be spent listening. Pockets of silence will likely arise that make you feel pressured to fill the space in an effort to keep the conversation moving forward, but the best way to maximize silence is to embrace it. You want to use that silence to, in a way, nudge the participant to go off script and share thoughts that might not otherwise have surfaced. Silence during conversation affords participants enough time to ponder a response without overthinking the answer. This is a large part of why live conversation is so valuable and preferable over asking questions over email or another asynchronous medium. With the latter, participants may extensively wonder what the person asking wants to hear or feels impressed by when what you really want is honest feedback.
Moreover, be mindful of your body language. Even the subtle aspects of how you’re sitting or expressing emotion on your face can guide participants toward a certain answer and bias the results. The same principles that research methods generally rely on apply here too.
Asking about a specific feature can almost feel like a leading question because it assumes that the participant cares. A better question to ask would be, “Why did you start to use XYZ feature?” In fact, asking why users sought out the product in the first place is a great way to begin user interviews. The order should commence with questions that zoom out before zooming in. If you can discover what caused users to actively search for a solution that exists somewhere in the world to address their problem at hand, then you’ll start with a fundamental understanding of your user base to build off of that will allow you to more comprehensively and systematically piece together learnings as you go.
Open source maintainers and business owners notably struggle in this area because of how invested they are. It takes a lot to launch and sustain a company, and you can become used to putting on blinders. To neutralize this where it matters, it helps to go from one extreme to another: Actively try to get negative feedback instead of dreading it. You may be surprised by how critical feedback can actually highlight the unique and special qualities of your product.
One of the companies that Emily consulted did not match their competition in terms of feature offerings. They directed more of their energy toward ensuring security, so it would take three to four times as long to launch a feature. Their users appreciated the peace of mind that came with knowing that a feature was secure, fueling their loyalty to the company despite their product being less feature rich. The motivation for using the feature differentiated the company’s product rather than the feature in it of itself. As you can see in this example, the right questions (not only “the how” or “the what” but also “the why”) draw out the most valuable insights, and spending the time to craft those questions will not return empty.
Up until this point, we’ve presumed an extant following from which you can derive user interviews, but what about if you’re launching a brand new open source project that no one knows anything about? How do you position it in the market? The default tends to take two forms: Present the project as either the open source version or a more secure version of another familiar technology. Both routes use the competition as a point of reference, but the first positions yours as the cheaper, free version, while the second positions yours as the better, implicitly more expensive version.
Primarily emphasizing that your product is open source certainly provides developer appeal that may boost adoption at the outset, but it won’t make the biggest difference in the end. People care more that their systems in production run smoothly, and they will pay to ensure that if needed.
Companies like Medusa (technically open source Shopify) understand this well. Instead of leaning on the buzz that a product positioned as open source might generate, Medusa targets mid-market customers that need Shopify’s features but aren’t large enough for a major custom development. Medusa positions their offering as more comprehensive than Shopify but less pricey than a custom-developed product rather than merely labeling themselves as open source Shopify. Another example is Mattermost. Rather than position the collaboration platform as open source Slack at a big event, such as a conference headed by the Department of Defense, Mattermost leads with security-first messaging. They keep in mind the customers whom they serve and their foremost concerns.
Tempting as it may be to insert “open source” for the sake of a shiny buzzword, it’s important to align all messaging with the value proposition that most resonates with your target audience for long-term appeal.
In the open source world, maximal conversion occurs when you can influence adoption from the top down and bottom up. When it comes to a single property such as a website, the question then becomes how you can cater to multiple audiences, who respond very differently to various messaging. Some companies don’t have a go-to-market strategy, just copy the messaging of a close competitor, and simply say that they’re better and run with it, whereas others ride the developer hype train by leveraging highly technical messaging and a deluge of code examples.
For starters, it’s difficult to get buy-in by only copying competitors or stating that your product is better. You will disappoint customers because chances are that gaps exist between you and your competition. Plus, you may position yourself as a step behind if you’re constantly following other vendors as opposed to demonstrating that you’re the leader that other companies look to.
On the contrary, if you highlight the unique value proposition and differentiators of your product, you distinctly set yourself apart from the competition. This may or may not mean accentuating the open source nature of your product depending on the competitive landscape and to what extent open source matters to your buyers.
In addition, focus on the outcome. Not every public-facing property needs to delve into the nuts and bolts of how to achieve the outcome technically speaking. You will have opportunities to direct developers to the docs to learn more, but a shared goal between developers and those with purchasing power usually lies in the outcome that they seek to achieve.
Given this, it might seem like all companies would harp on improving developer productivity or accelerating innovation so that everyone’s messaging starts sounding like a broken record. This doesn’t have to be the case as long as you can establish the specific outcome that plays into that overarching goal and how your company will help developers uniquely achieve it. It requires some granularity as well as an awareness of how competitors are positioning their products so that you don’t end up coming across just like everyone else.
In the case of a company with a hugely successful open source product but a commercial offering without any momentum, the priority should be to better position the commercial offering. When the converse occurs, in which a company generates revenue but the open source product appears to underperform, investing resources in better positioning the open source product makes sense. All in all, each offering in your product line, whether it’s on premises or in the cloud, needs its own positioning and messaging to be clearly outlined so that you can make adjustments appropriately as your business ebbs and flows.
Messaging and positioning are dynamic activities that would behoove you to revisit based on continuous learning and feedback. Messaging and positioning both sway and are swayed by public perception, and therefore we should be wary of underestimating or neglecting its importance.
Technology may provide the backbone to your company’s success, but launching a successful open source company extends beyond the internals. Messaging and positioning can make or break how you relate to a potential user base, because they determine first impressions before users even get their hands on your product.
When introducing your open source product into the market, consider keeping these four key points in mind:
If you’d like to explore what Scarf can offer, you can get started today. If you enjoyed the read, be sure to check out the The Hacking Open Source Business Podcast as well. We’ve got new and exciting episodes coming your way!
Published
December 9, 2022
This article was originally posted on
Hackernoon
If your open source product vanished overnight and all the code disappeared, how would people respond? The community’s reaction, whether it ranges from not being a big deal to complete, utter despair, will reveal the true worthiness of your product.
At the All Things Open conference, Emily Omier, a seasoned positioning consultant, sat down with Avi Press (Founder and CEO, Scarf) and Matt Yonkovit (The HOSS, Scarf) to discuss how to message, position, and validate your open source product on The Hacking Open Source Business Podcast. You can watch the full episode below or continue reading for a recap.
Because measuring adoption and usage of open source products is a major challenge, sometimes the hyper emphasis on quantitative metrics (e.g, the ratio of documentation views to downloads or churn rate at each phase of the user funnel) can overshadow the often overlooked yet equally important qualitative dimensions. Understanding perceptions greatly matters too and provides a wealth of insights to glean from. In order to obtain this data, you need to get feedback.
The following section is especially applicable to product teams, organizations supporting business owners (OSBOs), and marketing and sales teams looking to gather qualitative data that can inform the direction of a product. You can source user interviews by speaking with existing users, reaching out to potential users in your target audience, or hosting a listening tour. User interviews serve as one of the most prevalent methods for sourcing qualitative feedback, but it takes a certain mindset to get them done right.
When starting a company, it is natural to derive your vision and mission from a very particular use case. Over time, the tendency can be to zero in on that use case and build your product entirely around it. This perspective, however, can limit your product potential and even cause you to ask the wrong questions during the learning process. Perhaps your users indeed use the product in the way that you have in mind, but this may not always be the case. Sometimes they might use it for a slightly different purpose and oftentimes for wildly different ones. By making too many assumptions about your users, you can project conclusions that you’re seeking to hear instead of allowing users to transparently communicate their needs.
For example, one company that Emily consulted had created an open source project aimed at reducing cloud costs—at least this was their original intention. On the other hand, users did not view it as a cost control product. Therefore, when the company asked users why they needed to get their cloud costs under control, the question appeared irrelevant and failed to elicit any valuable information about actual usage. A carefulness to avoid assumptions would have led to greater revelation.
As a general rule, most of your time during a user interview should be spent listening. Pockets of silence will likely arise that make you feel pressured to fill the space in an effort to keep the conversation moving forward, but the best way to maximize silence is to embrace it. You want to use that silence to, in a way, nudge the participant to go off script and share thoughts that might not otherwise have surfaced. Silence during conversation affords participants enough time to ponder a response without overthinking the answer. This is a large part of why live conversation is so valuable and preferable over asking questions over email or another asynchronous medium. With the latter, participants may extensively wonder what the person asking wants to hear or feels impressed by when what you really want is honest feedback.
Moreover, be mindful of your body language. Even the subtle aspects of how you’re sitting or expressing emotion on your face can guide participants toward a certain answer and bias the results. The same principles that research methods generally rely on apply here too.
Asking about a specific feature can almost feel like a leading question because it assumes that the participant cares. A better question to ask would be, “Why did you start to use XYZ feature?” In fact, asking why users sought out the product in the first place is a great way to begin user interviews. The order should commence with questions that zoom out before zooming in. If you can discover what caused users to actively search for a solution that exists somewhere in the world to address their problem at hand, then you’ll start with a fundamental understanding of your user base to build off of that will allow you to more comprehensively and systematically piece together learnings as you go.
Open source maintainers and business owners notably struggle in this area because of how invested they are. It takes a lot to launch and sustain a company, and you can become used to putting on blinders. To neutralize this where it matters, it helps to go from one extreme to another: Actively try to get negative feedback instead of dreading it. You may be surprised by how critical feedback can actually highlight the unique and special qualities of your product.
One of the companies that Emily consulted did not match their competition in terms of feature offerings. They directed more of their energy toward ensuring security, so it would take three to four times as long to launch a feature. Their users appreciated the peace of mind that came with knowing that a feature was secure, fueling their loyalty to the company despite their product being less feature rich. The motivation for using the feature differentiated the company’s product rather than the feature in it of itself. As you can see in this example, the right questions (not only “the how” or “the what” but also “the why”) draw out the most valuable insights, and spending the time to craft those questions will not return empty.
Up until this point, we’ve presumed an extant following from which you can derive user interviews, but what about if you’re launching a brand new open source project that no one knows anything about? How do you position it in the market? The default tends to take two forms: Present the project as either the open source version or a more secure version of another familiar technology. Both routes use the competition as a point of reference, but the first positions yours as the cheaper, free version, while the second positions yours as the better, implicitly more expensive version.
Primarily emphasizing that your product is open source certainly provides developer appeal that may boost adoption at the outset, but it won’t make the biggest difference in the end. People care more that their systems in production run smoothly, and they will pay to ensure that if needed.
Companies like Medusa (technically open source Shopify) understand this well. Instead of leaning on the buzz that a product positioned as open source might generate, Medusa targets mid-market customers that need Shopify’s features but aren’t large enough for a major custom development. Medusa positions their offering as more comprehensive than Shopify but less pricey than a custom-developed product rather than merely labeling themselves as open source Shopify. Another example is Mattermost. Rather than position the collaboration platform as open source Slack at a big event, such as a conference headed by the Department of Defense, Mattermost leads with security-first messaging. They keep in mind the customers whom they serve and their foremost concerns.
Tempting as it may be to insert “open source” for the sake of a shiny buzzword, it’s important to align all messaging with the value proposition that most resonates with your target audience for long-term appeal.
In the open source world, maximal conversion occurs when you can influence adoption from the top down and bottom up. When it comes to a single property such as a website, the question then becomes how you can cater to multiple audiences, who respond very differently to various messaging. Some companies don’t have a go-to-market strategy, just copy the messaging of a close competitor, and simply say that they’re better and run with it, whereas others ride the developer hype train by leveraging highly technical messaging and a deluge of code examples.
For starters, it’s difficult to get buy-in by only copying competitors or stating that your product is better. You will disappoint customers because chances are that gaps exist between you and your competition. Plus, you may position yourself as a step behind if you’re constantly following other vendors as opposed to demonstrating that you’re the leader that other companies look to.
On the contrary, if you highlight the unique value proposition and differentiators of your product, you distinctly set yourself apart from the competition. This may or may not mean accentuating the open source nature of your product depending on the competitive landscape and to what extent open source matters to your buyers.
In addition, focus on the outcome. Not every public-facing property needs to delve into the nuts and bolts of how to achieve the outcome technically speaking. You will have opportunities to direct developers to the docs to learn more, but a shared goal between developers and those with purchasing power usually lies in the outcome that they seek to achieve.
Given this, it might seem like all companies would harp on improving developer productivity or accelerating innovation so that everyone’s messaging starts sounding like a broken record. This doesn’t have to be the case as long as you can establish the specific outcome that plays into that overarching goal and how your company will help developers uniquely achieve it. It requires some granularity as well as an awareness of how competitors are positioning their products so that you don’t end up coming across just like everyone else.
In the case of a company with a hugely successful open source product but a commercial offering without any momentum, the priority should be to better position the commercial offering. When the converse occurs, in which a company generates revenue but the open source product appears to underperform, investing resources in better positioning the open source product makes sense. All in all, each offering in your product line, whether it’s on premises or in the cloud, needs its own positioning and messaging to be clearly outlined so that you can make adjustments appropriately as your business ebbs and flows.
Messaging and positioning are dynamic activities that would behoove you to revisit based on continuous learning and feedback. Messaging and positioning both sway and are swayed by public perception, and therefore we should be wary of underestimating or neglecting its importance.
Technology may provide the backbone to your company’s success, but launching a successful open source company extends beyond the internals. Messaging and positioning can make or break how you relate to a potential user base, because they determine first impressions before users even get their hands on your product.
When introducing your open source product into the market, consider keeping these four key points in mind:
If you’d like to explore what Scarf can offer, you can get started today. If you enjoyed the read, be sure to check out the The Hacking Open Source Business Podcast as well. We’ve got new and exciting episodes coming your way!
Tools and strategies modern teams need to help their companies grow.
.png)
.png)
.png)
.svg)
.svg)
.svg)
.svg)
If your open source product vanished overnight and all the code disappeared, how would people respond? The community’s reaction, whether it ranges from not being a big deal to complete, utter despair, will reveal the true worthiness of your product.
At the All Things Open conference, Emily Omier, a seasoned positioning consultant, sat down with Avi Press (Founder and CEO, Scarf) and Matt Yonkovit (The HOSS, Scarf) to discuss how to message, position, and validate your open source product on The Hacking Open Source Business Podcast. You can watch the full episode below or continue reading for a recap.
Because measuring adoption and usage of open source products is a major challenge, sometimes the hyper emphasis on quantitative metrics (e.g, the ratio of documentation views to downloads or churn rate at each phase of the user funnel) can overshadow the often overlooked yet equally important qualitative dimensions. Understanding perceptions greatly matters too and provides a wealth of insights to glean from. In order to obtain this data, you need to get feedback.
The following section is especially applicable to product teams, organizations supporting business owners (OSBOs), and marketing and sales teams looking to gather qualitative data that can inform the direction of a product. You can source user interviews by speaking with existing users, reaching out to potential users in your target audience, or hosting a listening tour. User interviews serve as one of the most prevalent methods for sourcing qualitative feedback, but it takes a certain mindset to get them done right.
When starting a company, it is natural to derive your vision and mission from a very particular use case. Over time, the tendency can be to zero in on that use case and build your product entirely around it. This perspective, however, can limit your product potential and even cause you to ask the wrong questions during the learning process. Perhaps your users indeed use the product in the way that you have in mind, but this may not always be the case. Sometimes they might use it for a slightly different purpose and oftentimes for wildly different ones. By making too many assumptions about your users, you can project conclusions that you’re seeking to hear instead of allowing users to transparently communicate their needs.
For example, one company that Emily consulted had created an open source project aimed at reducing cloud costs—at least this was their original intention. On the other hand, users did not view it as a cost control product. Therefore, when the company asked users why they needed to get their cloud costs under control, the question appeared irrelevant and failed to elicit any valuable information about actual usage. A carefulness to avoid assumptions would have led to greater revelation.
As a general rule, most of your time during a user interview should be spent listening. Pockets of silence will likely arise that make you feel pressured to fill the space in an effort to keep the conversation moving forward, but the best way to maximize silence is to embrace it. You want to use that silence to, in a way, nudge the participant to go off script and share thoughts that might not otherwise have surfaced. Silence during conversation affords participants enough time to ponder a response without overthinking the answer. This is a large part of why live conversation is so valuable and preferable over asking questions over email or another asynchronous medium. With the latter, participants may extensively wonder what the person asking wants to hear or feels impressed by when what you really want is honest feedback.
Moreover, be mindful of your body language. Even the subtle aspects of how you’re sitting or expressing emotion on your face can guide participants toward a certain answer and bias the results. The same principles that research methods generally rely on apply here too.
Asking about a specific feature can almost feel like a leading question because it assumes that the participant cares. A better question to ask would be, “Why did you start to use XYZ feature?” In fact, asking why users sought out the product in the first place is a great way to begin user interviews. The order should commence with questions that zoom out before zooming in. If you can discover what caused users to actively search for a solution that exists somewhere in the world to address their problem at hand, then you’ll start with a fundamental understanding of your user base to build off of that will allow you to more comprehensively and systematically piece together learnings as you go.
Open source maintainers and business owners notably struggle in this area because of how invested they are. It takes a lot to launch and sustain a company, and you can become used to putting on blinders. To neutralize this where it matters, it helps to go from one extreme to another: Actively try to get negative feedback instead of dreading it. You may be surprised by how critical feedback can actually highlight the unique and special qualities of your product.
One of the companies that Emily consulted did not match their competition in terms of feature offerings. They directed more of their energy toward ensuring security, so it would take three to four times as long to launch a feature. Their users appreciated the peace of mind that came with knowing that a feature was secure, fueling their loyalty to the company despite their product being less feature rich. The motivation for using the feature differentiated the company’s product rather than the feature in it of itself. As you can see in this example, the right questions (not only “the how” or “the what” but also “the why”) draw out the most valuable insights, and spending the time to craft those questions will not return empty.
Up until this point, we’ve presumed an extant following from which you can derive user interviews, but what about if you’re launching a brand new open source project that no one knows anything about? How do you position it in the market? The default tends to take two forms: Present the project as either the open source version or a more secure version of another familiar technology. Both routes use the competition as a point of reference, but the first positions yours as the cheaper, free version, while the second positions yours as the better, implicitly more expensive version.
Primarily emphasizing that your product is open source certainly provides developer appeal that may boost adoption at the outset, but it won’t make the biggest difference in the end. People care more that their systems in production run smoothly, and they will pay to ensure that if needed.
Companies like Medusa (technically open source Shopify) understand this well. Instead of leaning on the buzz that a product positioned as open source might generate, Medusa targets mid-market customers that need Shopify’s features but aren’t large enough for a major custom development. Medusa positions their offering as more comprehensive than Shopify but less pricey than a custom-developed product rather than merely labeling themselves as open source Shopify. Another example is Mattermost. Rather than position the collaboration platform as open source Slack at a big event, such as a conference headed by the Department of Defense, Mattermost leads with security-first messaging. They keep in mind the customers whom they serve and their foremost concerns.
Tempting as it may be to insert “open source” for the sake of a shiny buzzword, it’s important to align all messaging with the value proposition that most resonates with your target audience for long-term appeal.
In the open source world, maximal conversion occurs when you can influence adoption from the top down and bottom up. When it comes to a single property such as a website, the question then becomes how you can cater to multiple audiences, who respond very differently to various messaging. Some companies don’t have a go-to-market strategy, just copy the messaging of a close competitor, and simply say that they’re better and run with it, whereas others ride the developer hype train by leveraging highly technical messaging and a deluge of code examples.
For starters, it’s difficult to get buy-in by only copying competitors or stating that your product is better. You will disappoint customers because chances are that gaps exist between you and your competition. Plus, you may position yourself as a step behind if you’re constantly following other vendors as opposed to demonstrating that you’re the leader that other companies look to.
On the contrary, if you highlight the unique value proposition and differentiators of your product, you distinctly set yourself apart from the competition. This may or may not mean accentuating the open source nature of your product depending on the competitive landscape and to what extent open source matters to your buyers.
In addition, focus on the outcome. Not every public-facing property needs to delve into the nuts and bolts of how to achieve the outcome technically speaking. You will have opportunities to direct developers to the docs to learn more, but a shared goal between developers and those with purchasing power usually lies in the outcome that they seek to achieve.
Given this, it might seem like all companies would harp on improving developer productivity or accelerating innovation so that everyone’s messaging starts sounding like a broken record. This doesn’t have to be the case as long as you can establish the specific outcome that plays into that overarching goal and how your company will help developers uniquely achieve it. It requires some granularity as well as an awareness of how competitors are positioning their products so that you don’t end up coming across just like everyone else.
In the case of a company with a hugely successful open source product but a commercial offering without any momentum, the priority should be to better position the commercial offering. When the converse occurs, in which a company generates revenue but the open source product appears to underperform, investing resources in better positioning the open source product makes sense. All in all, each offering in your product line, whether it’s on premises or in the cloud, needs its own positioning and messaging to be clearly outlined so that you can make adjustments appropriately as your business ebbs and flows.
Messaging and positioning are dynamic activities that would behoove you to revisit based on continuous learning and feedback. Messaging and positioning both sway and are swayed by public perception, and therefore we should be wary of underestimating or neglecting its importance.
Technology may provide the backbone to your company’s success, but launching a successful open source company extends beyond the internals. Messaging and positioning can make or break how you relate to a potential user base, because they determine first impressions before users even get their hands on your product.
When introducing your open source product into the market, consider keeping these four key points in mind:
If you’d like to explore what Scarf can offer, you can get started today. If you enjoyed the read, be sure to check out the The Hacking Open Source Business Podcast as well. We’ve got new and exciting episodes coming your way!
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)
.png)