Search Results

The challenge In the constantly changing landscape of cloud computing, Akamai wanted to better understand developers' thoughts around distributed cloud computing. Their goal was to have a better grasp of developers’ level of awareness, current intentions towards it, and where they imagine the greatest utility lies with this technology.  The approach SlashData designed a developer-focused survey to capture insights into distributed cloud computing. By identifying the right developer audience and asking targeted questions about technology usage, challenges, motivations, and thoughts about the future of cloud computing, the survey revealed insights into what developers think about the future of distributed cloud computing. The data was thoroughly cleaned and analysed to build a strong understanding of the current perceptions. The result SlashData delivered a report based on a comprehensive analysis of survey results, uncovering developers’ growing interest in distributed cloud computing and highlighting areas where they feel the industry falls short. The report provided actionable insights into the key improvements developers seek before adopting distributed cloud services. These include clear cost savings, improved security, and better tools for managing distributed environments. Developers also emphasised the need for stronger data security standards and interoperable open cloud solutions.  Following the report’s release, SlashData was invited to TFiR to discuss the findings in detail and expand deeper on the content of the report.  Why SlashData SlashData’s expertise in questionnaire design, ensuring legitimate responses, and analytical capabilities allowed us to address Akamai’s questions in a timely manner. SlashData was able to convert the analysis into a strong narrative and actionable insights that allowed Akamai and the wider cloud service provider community to understand how developers were preparing for a distributed cloud computing future. If you’re looking to uncover developer insights and transform data into actionable strategies for your business, contact us today! Related services Quantitative research Developer research

The challenge One of the major silicon vendor companies engaged SlashData to gain insights and recommendations for targeted improvements to their developer program. Their goal was to enhance developer satisfaction and engagement with their resources. Additionally, they sought to identify competing developer programs to benchmark their satisfaction and engagement levels against those of other competitors and industry leaders. The approach SlashData leveraged existing data from its 2024 Q1 Developer Nation survey, which reached over 3,500 professional developers across Western Europe, Eastern Europe, North America, South Asia, and the Greater China area. These developers shared insights into their experiences with various developer programs. Respondents were recruited through SlashData’s developer community and verified third-party survey panels, ensuring a robust and representative sample. In addition to using existing quantitative data to answer the client’s questions, we conducted desk research. This was done in order to provide a deeper dive into the user experience with the client’s developer documentation and sample code. Through this analysis, the client was able to receive first-hand feedback and recommendations on how to improve their developer support. The result The data gathered from SlashData’s survey helped the client understand the drivers of engagement and satisfaction amongst professional developers. The analysis answered the client’s core questions, including: Which types of developers are the most engaged with the client’s developer program? Which developer program resources are most important to highly engaged developers? Which types of technologies are associated with high engagement? Which developer profiles does the client attract, and how well does the client engage these developers compared to other vendors? Which of the client’s technology resources are associated with the highest engagement and satisfaction? Which types of developers should the client focus on to raise engagement and satisfaction? What are best-in-class examples of vendors with high engagement and satisfaction scores? These insights helped the client gain a deeper understanding of developer engagement patterns and program needs. In turn, this enables them to tailor their offerings to align with developer profiles and preferences, enhance satisfaction, and drive engagement with key resources and technologies across targeted developer segments. Why SlashData For the client, SlashData’s robust methodology and established global community of developers provided a unique advantage. Leveraging a deep understanding of the developer landscape, SlashData tapped into its extensive developer community and a curated network of third-party providers to reach precisely the right audience for our client's research objectives. Our proprietary survey platform hosted the survey, ensuring robust data integrity through advanced metadata analysis and sophisticated dynamic question logic, so the client received accurate, reliable insights on developer engagement and satisfaction with its technology resources. Do you have a developer program you would like to offer more support to your developer audience? Let’s see together what they need. Contact us. Related services Developer Program Benchmarking Quantitative research

In today’s fast-paced digital economy, long-term success is not a given. It demands constant innovation, agility, and a willingness to adapt. For product managers, every decision matters and cannot be left to chance alone – great products are created using data-backed decisions. In this article, we will discuss why using data is essential for decision-making and how market research data, in particular, can help you find success. Why data is essential for decision-making While intuition can go a long way for a successful product manager, using a data-driven strategy can help provide clarity on what truly works and what does not. By conducting market research to analyse trends and understand the needs of your customers, you can remove the guesswork from the equation. Let us consider a scenario where your internal stakeholders want to change a staple feature of your product. Rolling out such a change without validating it with your customers may lead to detrimental results for your product. However, if you test this update with a small subset of your customers and monitor the impact of this change, you can minimise unnecessary risk and make informed decisions. Before committing to a new feature for your product, it is a good idea to first gather evidence that demonstrates its potential value. Depending on the situation, this may be done through a small survey of your target audience, asking your current customers about their thoughts, or even testing out this feature with a small subset of your current users. However, using data to make informed decisions goes beyond that. It involves analysing broader market trends, benchmarking your product against its competitors, and so much more. Remove the guesswork by validating product changes through small-scale testing. In general, whether you are about to launch a new product or looking to improve your current one, using the right market research data can maximise your chances of success. With this in mind, let us now have a look at some of the challenges you may face as a product manager and the different types of market research data you can use to make informed decisions. Understanding your customers through market research  As a product manager, ensuring that your products meet the real needs of your users  is one of the most critical aspects of your role. Overlooking the critical pain points of your customers or focusing on features that do not resonate with them can lead to poorly received products. A great product is one that addresses the real needs of its customers, not assumptions. By sending surveys  to your customers and asking the right questions, you can generate quantitative insights about their likes and dislikes, identify missing features, and pinpoint where you can improve. Alternatively, you may wish to take a qualitative approach by conducting interviews  and focus groups . These methods help you dive deeper into your customers’ motivations, behaviours, and preferences, providing rich insights that go beyond numbers. We can help you understand your customers and their needs. Find out more about our services. Prioritising features Building a successful product requires significant resource allocation, meaning that prioritising the wrong features can be very costly. On top of this, dealing with competing demands from stakeholders can make it difficult to know which features to prioritise. Luckily, market research offers plenty of solutions that solve a large variety of problems. One such solution is A/B testing , which uses randomised controlled experiments to compare two versions of something like a product feature or a marketing strategy to figure out which one is better than the other. For example, you may hypothesise that sending out notifications to the users of your application twice as often will boost engagement. However, this may not be the right choice for your application. This is where A/B testing  comes in handy. You can roll out this feature to a randomly selected group of users and test its effects on your engagement metrics of choice. A/B testing turns hypotheses into actionable insights, reducing the risks of costly missteps. In more complex scenarios, methods like MaxDiff  and conjoint analysis  can also provide detailed insights. MaxDiff  can help you figure out which features to prioritise by asking your customers to identify the most and the least important features in a series of questions. On the other hand, conjoint analysis  can be used to determine which feature combinations appeal most to your customers. This can be done by simulating a series of real-world choices and asking your customers which ones they prefer. Advanced methods like MaxDiff and conjoint analysis reveal what users value most, enabling smarter prioritisation. Price optimisation Another challenge product managers face is figuring out how much to charge customers in a way that maximises revenue. While conjoint analysis  can be helpful in performing price optimisation alongside feature sets, more specialised techniques may be more useful when your product's features are already decided. For example, Van Westendorp’s price sensitivity meter  can be used to identify a price range for your product by asking your target audience at which prices your product would feel too cheap, provide good value, or be too expensive. On the other hand, the Gabor-Granger method  directly asks customers whether they would purchase your product at certain price points. This approach pinpoints the price that maximises revenue by assessing actual purchase intent at different price levels. Effective pricing strategies balance perceived value and purchase intent. Van Westendorp reveals the optimal price range, while Gabor-Granger pinpoints the price that maximises revenue. Identifying market opportunities Approaching product management without first understanding market trends can lead to roadmaps that do not align with what the market needs. In turn, this can result in wasted efforts in pursuing stagnant or declining opportunities. One way to combat this is by performing a competitive market analysis , which can help you better understand the space and discover where to focus your efforts. Analysing market trends  can extend this a step further by monitoring shifts in the behaviour patterns of your customers and identifying things such as emerging technologies. In addition to this, it can be highly beneficial to perform market sizing research . With this, you can assess the size of your addressable market and, if an opportunity is worth pursuing, how much to invest in it. Monitoring post-launch performance While launching a product can be challenging in itself, it is only the first step on a long journey towards long-term success. To achieve this, you must monitor how well your product performs and address user feedback throughout its lifetime. However, failing to do so can lead to severe consequences, including customer churn and a damaged reputation for your company. By leveraging existing industry reports  or commissioning custom surveys , you can gather valuable insights to ensure that your product remains relevant and meets the expectations of your customers. For instance, fielding a survey with a representative sample of your target audience can help you understand your product’s standing in awareness and adoption. To identify what works well for your customers and what needs to be improved, you can also measure how satisfied they are with your product, including its specific attributes. Similarly, asking users of your product about how likely they are to recommend it to others can help you measure customer loyalty. For this, well-established metrics such as customer satisfaction (CSAT) and the net promoter score (NPS)  can provide valuable insights. Beyond this, you may also wish to explore things like user engagement rates or supplement your research with some qualitative interviews to build a comprehensive picture of how well your product is performing. Success does not stop upon launching a product. It is sustained by continually listening to your customers and evolving your product to meet their needs. How we can help As a product manager, you will face a wide array of challenges, ranging from understanding what your customers need, to finding ways to stay ahead of your competitors. Market research provides the tools and insights you need to make smarter decisions, reduce risk, and deliver products that resonate with users and drive business success. At SlashData, we specialise in delivering tailored research solutions for product leaders like you. Whether you are exploring a new market, refining your product roadmap, optimising pricing strategies, or assessing which features to prioritise, our expertise ensures you have the insights you need to succeed. Contact us today to discuss how our custom research solutions can empower your team and fuel your product’s success! About the author Nikita Solodkov, Senior Market Research Analyst Nikita is a multidisciplinary researcher with a particular interest in using data-driven insights to solve real-world problems. He holds a PhD in Physics and has over five years of experience in data analytics and research design.

For many development teams, tools are more than just software - they’re the engine driving every project, sprint, and release. Yet, our data shows that the decision to purchase new tools often lies not with the developers but with the leadership team, whose insights and strategies shape the tech stack. So, how exactly are CEOs, CTOs, and other technology leaders involved in deciding on the tools that will power their teams? In this blog post, we’ll dive into the involvement of technology leaders in tool selection, comparing their influence to other technology professionals within their organisations. We’ll also explore how factors like software development experience and company revenue affect their role in decision-making. With revenue often linked to organisational complexity and resources, understanding these dynamics provides a clearer picture of how management shapes the tools that teams use. This blog post is based on data collected in the 27th edition of SlashData’s Developer Nation survey, which reached more than 9,000 respondents from 130+ countries worldwide. In this blog post, we look at over 6,500 technology professionals working for organisations with two or more employees, more than 1,500 of whom identify themselves with management roles. The role of tech leaders vs other tech professionals in tool buying decisions When we break down involvement across four main roles within organisations - technical, non-technical, management, and IT operations - there are some notable differences. The technical professionals are the least involved in overall selection or purchase decisions, with 14% reporting no involvement at all. Meanwhile, managers are more involved, especially when it comes to approval of the overall team budget (28%), approval of expenses on tools and components (32%), and final selection decisions (50%).  IT operations professionals are more likely to be responsible for final tool selection than their technical peers The management group includes tech/engineering team leads, CIO/CTO/IT managers, and CEOs. Of these, CIO/CTO/IT roles are the most influential in making the final tool selection, approving expenses, and determining the budget for developer tools. For instance, 67% of CIO/CTO/IT managers make the final decision on tool selection for their teams, compared to 59% of CEOs and only 36% of tech leads. 67% of CIO/CTO/IT managers make the final selection decision for team/company tools This pattern highlights that managers drive final decisions, balancing functionality with budget and strategic goals. Recognising this influence, SlashData has now expanded its market research efforts  to focus more on CEOs, CTOs, and other C-level executives, providing insights tailored to these decision-makers and their unique priorities in shaping technology strategy. How experience in software development shapes tech leaders’ involvement in tool selection Involvement in tool selection and budget decisions isn’t solely determined by role - it’s also shaped by experience. Managers' involvement in tool selection decisions increases with experience in software development, especially for key decision-making activities.  Leaders with over five years of experience are the most actively involved, particularly in making recommendations (54%) and final selection decisions (52%) for team or company tools. This suggests that seasoned leaders leverage their expertise to guide important tool choices, balancing strategic needs with practical insights from years in the field.  This trend also extends to budget-related decisions. Executives with extensive experience are more likely to set the overall team budget for developer tools (30%) than beginners in the field (19%). The proportion of involvement in approving expenses and overall budget climbs steadily with experience, highlighting a likely correlation between tenure and budgetary authority. This pattern paints a clear picture of how experience shapes managers’ role in building a company’s tech stack. How company revenue shapes tech leaders’ involvement in developer tool buying decisions Understanding how revenue impacts tech leaders’ involvement in tool selection is essential, as financial resources often dictate the complexity of decision-making processes. Our data shows that tech leaders’ level of involvement in tool selection and budget decisions generally increases as company revenue grows. In smaller companies (monthly revenue up to $5,000), tech leaders’ involvement in tool selection is limited, which is true for other role categories as well, potentially suggesting limited resources.  However, as revenue increases, tech leaders become more actively involved, particularly in making recommendations and making final decisions. This suggests that companies with higher revenue likely have more complex needs, requiring executive input to ensure tool choices align with strategic goals.  For instance, around 46% of tech leaders in companies generating over $50,000 monthly are involved in approving expenses on tools and components, compared to only 23% in companies with a monthly revenue of up to $5,000. Similarly, around 62% of tech leaders in companies with over $50,000 in monthly revenue make final selection decisions for company tools, compared to 45% of those with a monthly revenue of up to $5,000. 62% of tech leaders in companies earning at least $50,000 monthly are involved in making final tool selection decisions Are you targeting tech leaders who make tool purchase decisions? Contact us to gain insights into their preferences. About the author Bleona Bicaj, Senior Market Research Analyst Bleona Bicaj is a behavioral specialist, enthusiastic about data and behavioral science. She holds a Master's degree from Leiden University in Economic and Consumer Psychology. She has more than 6 years of professional experience as an analyst in the data analysis and market research industry.

Citizen developers (sometimes referred to as “power users”) play a crucial role in bridging the gap between business requirements and IT capabilities. Despite lacking formal training in software development, these individuals drive innovation by building or customising solutions for themselves and their teams, streamlining repetitive processes, and enabling faster business transformations. Citizen developers are professionals who utilise no-code or low-code tools to address business needs without being formally employed as software developers or having a computer science degree. SlashData’s latest (Q3 2024) global survey reached nearly 10,000 respondents involved in technology projects*, either as professionals, hobbyists, or students. Of those, more than 7,000 were working as professionals, meaning that they earned their living working professionally in one or more of the areas defined in the footnote below. About 10% of these technology professionals met our criteria of being a citizen developer.     In this blog post, we explore what sets citizen developers apart from other technology professionals and the implications for the broader tech community. By understanding who they are and what motivates citizen developers, organisations can better leverage the strengths of this critical community to foster a culture of open collaboration in their organisations. Defining citizen developers To identify citizen developers through our survey, we excluded all technology professionals formally employed as software developers and those holding a university degree in computer science. We then filtered respondents who use at least some no-code/low-code tools in their workflow.  While improvements in AI and its coding assistance capabilities have empowered many non-developers to use programming languages and their respective tools, no-code/low-code tools remain the defining benchmark for citizen developers. Most technology professionals (51%) do not use no-code or low-code tools, but of the 49% that do, we compare them to citizen developers below. The distributions of the two groups are very similar, suggesting that no-code or low-code tools are not disproportionately valued or utilised in citizen developers' workflow vs other technology professionals.  Citizen developers’ experience in software development In the early career stages (less than 5 years of experience), citizen developers are disproportionally represented compared to traditional technology professionals. This suggests that non-software development professionals who are newer to the tech industry may gain interest early in their careers and may start getting involved with technologies to become power users. Conversely, at advanced experience levels (16+ years), citizen developers are less represented, indicating that they may transition into other roles or lack the lengthy career paths common among traditional tech professionals. Citizen developers are, on average, half a year earlier in their technology careers compared to other technology professionals. Citizen developers have an average of 3.5 years of experience, slightly less than the 4 years reported by other technology professionals. This raises the question: Do citizen developers aim to evolve into more technical roles?  Looking at their motivations for contributing to software development provides valuable insight into this question. Prevalence within startups Citizen developers are more common in startups, largely due to necessity. In lean organisations where resources are tight, such as startups, tasks requiring automation or technical solutions often fall to power users within the business.  We know from previous research that startups attract developers earlier in their careers . While, as noted above, this is due in part to necessity, it is also likely that citizen developers gravitate towards organisations where flexibility, experimentation, and rapid product iteration are the norm. These settings allow these professionals to transition into more advanced technical or leadership positions over time. In these dynamic environments, they may gain visibility and influence, leveraging their unique blend of domain expertise and technological aptitude to drive innovation. As we will see below, this mixed bag of skills can come in very handy when making technology purchasing decisions.  Citizen developers and tool purchasing decisions Citizen developers are notably active in influencing or making purchasing decisions for developer tools, often at a higher rate than their counterparts. A fifth of citizen developers (21%) approve expenses compared to just 14% of their colleagues. Likewise, 30% of citizen developers are responsible for specifications, compared to 24% of other technology professionals. However, when it comes to purchasing for individual use, citizen developers trail their counterparts.  Citizen developers are more likely to be involved in purchasing decisions than other technology professionals. The high degree of involvement by citizen developers in company-level purchasing decisions may seem counterintuitive, given their slightly earlier career stages. However, their involvement reflects their hands-on, practical approach to addressing workflow needs and their understanding of business needs. These power users understand the business side and are involved with the technical side to a degree that allows them to serve as a bridge between technical and business stakeholders.  Are citizen developers part of your target audience? Let’s dive into their preferences together. Contact us.  About the author Brayton Noll is a behavioral scientist with a background in climate change and environmental research. He holds a PhD from TU Delft in computational social science, with his thesis focusing on human behavioral dynamics and climate adaptation. He has five years of experience working with data analytics. * By “technology projects” in this report, we mean any of the following types of software development projects: Web apps / Software as a Service, mobile apps , desktop apps , backend services,   augmented reality (incl. mixed reality) ,  virtual reality, games, data science, machine learning / AI, industrial IoT, consumer electronics devices / consumer IoT,   apps/extensions for third-party platforms and ecosystems, or embedded software.

In a world that’s changing faster than ever, businesses face an increasingly complex environment. Emerging technologies, such as artificial intelligence, are transforming industries. At the same time, shifting consumer behaviours, political changes, and economic disruptions create additional challenges and opportunities for businesses. Amid this complexity, market research becomes an essential tool for building successful business strategies, offering the insights needed to adapt, innovate, and thrive. In this blog post, we'll explore the top five reasons why market research should be a cornerstone of your business planning for 2025, helping you make data-driven decisions that address future challenges and opportunities. Understand the market and identify trends To succeed in today’s rapidly changing market, businesses must keep up with market dynamics and emerging trends. Market research plays a pivotal role by helping companies identify critical success factors and anticipate shifts, enabling strategic and informed decision-making. By closely monitoring elements such as industry trends, innovations, regulatory changes, and consumer behaviours, businesses can adapt proactively and maintain their competitive edge. Market research can also help uncover untapped growth opportunities, enabling businesses to expand strategically. By identifying prospects such as geographic expansion, targeting underserved niches, or innovating with new products and services, businesses can make informed investment decisions that drive growth. An essential process for identifying and evaluating these opportunities is Total Addressable Market (TAM) sizing, which evaluates the number of potential customers/users and potential revenues. Understanding the TAM allows businesses to determine the viability of pursuing specific markets and guides the level of investment required to capitalise on these opportunities. Leveraging them not only opens new revenue streams but could also enhance a company's competitive position. Competitive intelligence equips organisations to stand out, differentiate, and strategically position themselves for long-term success. Additionally, market research provides a comprehensive understanding of the competitive landscape. By analysing competitors’ strengths and weaknesses, businesses can identify areas to focus on, such as enhancing customer experience, refining product offerings, or optimising marketing strategies. This competitive intelligence equips organisations to stand out, differentiate, and strategically position themselves for long-term success. Know your customers The better you know your customers, the less you need to guess. Understanding your audience is key to serving their needs. Market research allows you to uncover not only the explicit needs of your customers but also their unmet needs and pain points. By diving deep into consumer insights, businesses can tailor their offerings to provide more value. For example, a software company may discover that its target users seek better integration with specific tools. By prioritising seamless integrations and actively promoting these features, the company can enhance customer satisfaction and retention while also attracting new customers who value these capabilities. Additionally, differentiating customer personas allows businesses to design targeted plans that cater to the unique characteristics of each segment. Market research can aid in identifying distinct personas based on behavioural, attitudinal, demographic, and psychographic data, guiding how to reach and engage them effectively. For instance, from our extensive research experience, we commonly see how regional differences are crucial in shaping customer behaviour and preferences. Understanding these regional distinctions helps businesses develop localised strategies , ensuring products, marketing, and services resonate with specific audiences. Identify and mitigate risks Every business decision carries inherent risks that, if ignored, can result in significant setbacks. Market research is essential for identifying these risks early, enabling businesses to plan effective mitigation strategies and adapt proactively rather than reactively, which can often be too late. Know the risks, plan for them, and sleep better at night. A prime example of market research’s value is its ability to minimise the risk of launching an unsuccessful product. Through concept testing, surveys, focus groups, and user testing, businesses can gauge consumer reactions and refine their offerings before committing substantial resources. This approach ensures the final product meets customer needs while significantly reducing the chance of failure. For example, early-stage concept testing allows businesses to understand customer preferences and refine their offerings accordingly. By employing techniques such as MaxDiff surveys, conjoint analysis, and monadic testing, companies can compare various concepts and pinpoint the attributes that truly resonate with their target audience. With these insights in hand, organisations can iteratively develop solutions that align with market demands, increasing the likelihood of a successful product launch and accelerating the path to product-market fit. Improve products and services Analyse, optimise, repeat. Good products are never truly finished. Market research can also be a powerful tool for refining and optimising products and services , informing product roadmaps to better align with market demands. By collecting insights from customers (or even competitors’ customers), businesses can identify areas for improvement, such as enhancing technical support, adding new features, or addressing existing pain points. An essential part of this process involves using quantitative methods like MaxDiff and conjoint analysis to determine the most appealing combination of features, understand the relative importance of product attributes, and optimise the feature and price mix for new products. Making this an iterative process ensures that products and services evolve alongside customer needs and industry trends, boosting customer satisfaction, increasing retention rates, and expanding market share. A critical aspect of product optimisation is crafting an effective pricing strategy. A well-designed pricing approach not only generates revenue but also ensures positive cash flow, which is essential for funding strategic initiatives and growth. This is particularly important in industries like tech, where companies often face challenges converting free users into paying customers. Market research sheds light on the motivations, pain points, and preferred pricing models that influence customers’ decisions to upgrade.  Moreover, techniques such as the Van Westendorp price sensitivity meter and the Gabor-Granger method can be employed to understand consumer price sensitivity more effectively. With these insights, businesses can simplify the transition from free to paid , maximising conversions while enhancing the customer experience. But pricing optimisation doesn’t stop there. Market research also helps businesses understand consumer price sensitivity and competitor pricing strategies. This enables companies to establish optimal price points and create tiered offerings that not only attract and retain paying customers but also deliver exceptional value. Strengthen brand strategy A strong brand is the foundation of a successful business, and market research plays a pivotal role in crafting branding strategies. By measuring and tracking the strength of your brand  and your main competitors, you can understand how your brand is perceived in the market. This includes key metrics such as awareness, loyalty, perception, and positioning, which are critical for assessing the health of your brand. You can’t improve what you don’t measure. By doing market research, companies can inform their brand strategy plans, allowing them to adjust their messaging and positioning in response to shifts in consumer sentiment. Understanding how your audience feels about your company or offerings enables you to make strategic decisions that enhance brand perception and deepen customer loyalty. This could mean pivoting your messaging, highlighting different brand values, or finding ways to differentiate more effectively. Additionally, market research can uncover areas of opportunity to strengthen the brand's connection with the audience. Whether refining the brand’s story, tapping into new channels to reach customers, or adjusting the visual identity to stay relevant, these insights ensure that brands evolve in line with consumer expectations and remain resilient against competitors. At SlashData, we specialise in delivering actionable, data-driven insights tailored to your unique business challenges. Whether you’re exploring new markets, refining your brand strategy, prioritising product features, or honing your product roadmap, our expert guidance will help you elevate your strategic planning. Contact us today ! About the author Álvaro is a market research analyst with a background in strategy and operations consulting. He holds a Master’s in Business Management and believes in the power of data-driven decision-making. Álvaro is passionate about helping businesses tackle complex strategic business challenges and make strategic decisions that are backed by thorough research and analysis.

In the expansive universe of software developer tools, where both free and paid choices abound, vendors strive to carve out a niche and capture the attention of developers. This blog post provides a glimpse into our recently published Pricing Strategies for Developer Tools report , which explores what motivates developers to adopt new tools, the factors they consider when they evaluate them, and the pricing models that best align with their needs. Here, we provide a practical guide that can help you tailor your offering to capture the attention of developers and gain a competitive edge in the market. Inside the developers’ mind: Understanding tool adoption and evaluation factors To set the stage, it’s crucial to understand the primary motivation driving developers to adopt tools. Our research found that the majority (56%) of developers prioritise increasing productivity, with improvements in code quality (13%) and performance (7%) trailing far behind as secondary priorities. All other goals are prioritised by 5% or fewer developers. Therefore, tailoring your offering and communication to emphasise how your service enhances productivity can effectively capture developers’ attention. When delving into the factors developers weigh when assessing a new offering, feature availability takes the lead, influencing the decisions of 31% of developers, closely followed by the importance of high-quality documentation (25%). Additionally, 23% and 18% of developers emphasise the value of free plans and free trials, respectively. Therefore, providing a free plan or trial becomes paramount for developers to test and determine whether a tool aligns with their requirements. Without this option, your service may be easily overlooked, prompting developers to explore competing offerings. Moreover, over one in five developers (21%) considers transparent pricing an important factor during tool evaluation. Hence, hiding pricing structures behind contact forms or sales calls poses the risk of losing potential users. Pricing should be straightforward, ensuring expense predictability and avoiding hidden costs or fees. However, it should be noted that the importance of transparent pricing drops to 14% among developers in large organisations (1,000+ employees), as enterprise plans often require direct engagement with sales for tailored quotes. Navigating the fine line: Ensuring competitiveness without overextending free offerings Offering a free plan or trial for developer tools is essential, but simply onboarding developers to these free offerings may not be enough. Developers often abandon free plans and trials due to limitations in features, functionality, and usage limits. Approximately one-third of developers who abandoned a free plan or trial in the past year cited these reasons. On the flip side, the primary motivations for developers to upgrade from a free to a paid plan include gaining access to advanced features and having higher or no usage limits. 44% of developers upgraded to get access to advanced features, and 31% to increase usage limits. Hence, when designing your free offerings, it is crucial to achieve a delicate balance. Avoid making your free plan uncompetitive, yet be cautious not to offer excessive functionality for free. Feature availability, as emphasised in the previous section, is the most important consideration for developers when exploring new platforms. A non-competitive free plan might lead developers to abandon your product, seeking alternatives or overlooking your tool altogether. Conversely, providing too much functionality for free may attract numerous developers to your free plan, but converting these free users into paying customers becomes challenging if they already have access to all the necessary functionality without upgrading. Therefore, finding the right equilibrium is key to a successful pricing strategy. To achieve this balance, it’s essential to first map out the offerings of your main competitors and strategically design your pricing strategy in light of this information. For any assistance during this research phase, please feel free to reach out. Pricing perspectives: How do developers prefer to pay for tools? When asking developers about the key pricing  factors influencing their choice to upgrade to a paid version of a developer tool, one factor emerges as the clear frontrunner: the pricing model / fee structure, considered by nearly half of developers when upgrading (49%). Other important considerations include the vendor’s reputation and trustworthiness, the total cost of ownership, and suitable pricing tiers, each considered by approximately a third of developers. Taking a closer look at the most important pricing factor (the pricing model), we found that subscription-based pricing holds a substantial lead as the preferred option for developers, with 53% expressing a preference for it. In contrast, one-time purchases (39%), usage-based pricing (34%), per-seat licensing (21%), and pay-per-feature (13%) models lag behind. However, preferences in pricing models can vary depending on the type of tool. For example, 53% of developers favour usage-based models for cloud services, while 44% prefer a one-time purchase for integrated development environments (IDEs) or text editors. Hence, aligning your pricing model with developers’ preferences for your offering type is crucial. Digging deeper into subscription-based models, specifically into billing preferences, monthly and annual billing cycles emerge as the top choices. Monthly billing is favoured by 43% of developers, compared to 35% who prefer annual billing. To cater to the majority of developers, it is essential to offer both options. Interestingly, we found in our analysis that business size influences billing preferences. For instance, developers in small businesses (2 - 50 employees) show a higher inclination towards annual billing (43%) compared to those in larger companies (around 33%). This inclination is likely driven by the cost savings associated with annual plans, aligning with the financial constraints often faced by smaller companies. On the other hand, enterprise developers show a greater preference for quarterly plans (14%) than their counterparts in smaller companies (5%). This could be attributed to the intricacies of budgeting and financial planning processes in larger enterprises, typically structured on a quarterly basis. If targeting enterprises, incorporating quarterly billing alongside monthly and annual options can set your offering apart. Moreover, this flexibility could help overcome potential obstacles tied to departmental approvals, particularly in finance - a recurring challenge identified in the upgrade process to enterprise plans, as we cover in the full pricing strategies report. While this blog post offers a sneak peek into the intricate world of developer tool pricing, our journey into the minds of developers is far from over. For a more thorough understanding, we invite you to explore our Pricing Strategies for Developer Tools report . Uncover a wealth of additional data that delves beyond the surface, empowering you to refine your pricing strategy with precision. This report includes detailed analyses, full distributions of factors, breakdowns by variables such as company size, roles, and decision-making power, and other information that surpasses the scope of this blog post. Are you helping developers with your offering? Get in touch and we can look together at developers' needs.

SlashData recently published a ground-breaking white paper addressing the Holy Grail of questions among Developer Relations, community managers, Developer Program Managers and more. The Developer Engagement Value framework calculates the added value every onboarded developer brings in real dollars. This is the total value that a developer is expected to bring over a period of time either by using a vendor’s technologies themselves (direct value) or by inducing/supporting others to do so (indirect value). In this blog post, we are diving deeper into the practical use of the framework by showcasing a real-data example of a cloud vendor and how we calculated the value of their developer community across all their products and services for four different segments. Hop on directly to the full white paper. The use case of a cloud vendor We considered a – hypothetical – scenario where the cloud vendor wants to estimate the value of their developer community across all their products and services and is interested in doing so for four journey-related segments: students, junior developers, specialists / senior developers (specialists for short), and managers. Using real data , we demonstrated how you can use the Developer Engagement Value framework to: understand developer segment transitions, prioritise audiences for outreach, select the value-maximising initiatives for these segments, and understand how to optimise your offerings. Here are some of our key findings: 68% of student developers onboarded by the cloud vendor will be professionals with some tooling decision-making influence within their organisation within a year . This implies that any investments the cloud vendor makes in students will begin to bear (more) fruit in – up to – a year later in 68% of the cases. Senior developers and specialists are the most valuable segment out of the four we considered (students, junior developers, specialists / senior developers, and managers), each developer in this group bringing $15, that is 2.3 times more than the dummy ARPU we assumed. This speaks volumes as to why ARPU is not sufficient to capture the full value that a developer brings , and why you should therefore be adopting a full-view lifetime value instead. In particular, specialists bring slightly more value than the managers , and that stems from higher Support and Skill-Builder value ($4.22 vs $3.73) and higher Developer Feedback Value ($8.53 vs $8.00). Different DevRel activities are expected to boost value of different types for any given segment . More specifically, we found that among the cloud vendor’s junior developers, those who value training courses and hands-on labs are 17% more likely than those who don’t to bring usage-inducing value. These initiatives, however, seem to have only a small effect on the product-enhancing value of junior developers. Therefore, focusing on these will mostly have an impact on the usage-inducing value.  On the contrary, those among junior developers who consider documentation and sample code to be important bring 15% more product-enhancing value than those who don’t , whilst, the effect of good documentation on usage-inducing value is only 2% higher for those who consider it important vs those who don’t. Therefore, If the focus is to increase junior developer contribution and feedback, focusing on good documentation is a good strategy, as it will attract junior developers who are more valuable that way. There is more to this story and you can read it all in the full white paper .  #developerdollarvalue #developervalue #cloud #dev #developervaluemodel #developervalueframework

Yes. You read the title right. An answer to the worst nightmare of industry professionals in developer-facing roles. This includes people in Developer Relations, community managers, Developer Program Managers and more! It’s not just us saying it; it’s the people in these roles who have expressed how challenging it is to prove the value an onboarded developer brings, and they have done so in podcasts , panels and 1 to 1 discussions we had. That’s why at SlashData, we developed the framework that calculates the added value every onboarded developer brings in real dollars. In our thought leadership report, we show you how to calculate this dollar value by introducing the concept of Developer Engagement Value . The total value that a developer is expected to bring over a period of time either by using a vendor’s technologies themselves (direct value) or by inducing/supporting others to do so (indirect value). It is a forward-looking metric that takes into account the variable nature of developer behaviour and introduces a framework to calculate developer value in real dollars. You can access the full framework here . Or read on for more information.  Why do you need to know the value an onboarded developer brings? Developers are more than mere product or service users. Developers are unarguably partners and co-creators who add value that extends well beyond the direct revenue stemming from technology usage. Many Developer Relations (DevRel) and developer marketing practitioners struggle to prove just how valuable an onboarded developer is, and, consequently, to justify their budget investments in DevRel. Even if they do get their budgets approved, they are faced with the problem of how to optimally allocate this budget to the different activities. But are DevRel budgets the only reason why you would need to estimate the value that a developer brings? How about when launching a new developer product? Won’t you need a way to predict how many developers this new product will attract and how much value these new developers will bring? For decades, Customer Lifetime Value (CLV or LTV) has been used to predict the value a client will bring throughout their ‘lifetime’ (length of relationship) with a company. Model setup and estimation was fairly straightforward at the time when all we had to worry about was direct revenue and transactional data. But in the developer ecosystem and in the era of network effects, indirect revenue, influencers, open source, and developer communities of all shapes and sizes… how do you capture value? This is what we are after with the Developer Engagement Value . 4 key questions to answer first Estimating the value that a developer brings is a daunting task, given the indirect value contributions and network effects intrinsic to the developer ecosystem. Challenges, however, begin a lot earlier in the problem definition process than the indirect value estimation stage. Considering these four key questions will help us to define the boundaries of the problem better: Whose value should you estimate? As discussed earlier, it’s not just those using your products. We posed this question also to our community of DevRel practitioners, and we got back a broad spectrum of answers. See the full report for a selected set of their responses. Can you observe the developer journey? Time is a continuum and observing a developer’s journey uninterrupted in this continuum is one of the most challenging endeavours. Telemetry alone will not get you there. How should you define ‘lifetime’? What is the time horizon for your predictions? How far into the future should you try to see and estimate value for? Do you really need a dollar value estimate per onboarded developer? It depends on what your end goal is. For example, if what you’re trying to achieve is optimal prioritisation of DevRel initiatives, then a relative, rather than an absolute, value will suffice. If, however, you need a number for your ROI and budget calculations, then you do need a dollar value estimated. The DEV framework As we mentioned earlier, the concept of Customer Engagement Value (CEV) has been around for more than a decade. We built on the model proposed by Kumar et al. (2010), adjusting and extending it to capture all the forms of engagement that are typical to developers. In a nutshell: Our framework proposes a method of estimating the total value that a developer is expected to bring over a period of time, either by using your technologies themselves (direct value) or by inducing/supporting others to do so (indirect value). We call this the Developer Engagement Value (DEV) , and it is a forward-looking metric that takes into account the variable nature of developer behaviour. To arrive at the Developer Engagement Value, SlashData identifies seven key areas from where developer value stems – seven value categories: Developer Direct Value (DDV) Supporter and Skill-builder Value (SSB) Peer Influencer Value (PIV) Decision-maker Influencer Value (DmIV) Developer Referral Value (DRV) Developer Feedback Value (DFV) Developer Contributor Value (DCV) Then, factoring in data from its global developer surveys, SlashData can map all the evolution paths that the developer segments of interest can theoretically take in the course of a selected forecasting period. The next step is to  build models to find the link between developer value and specific initiatives (DevRel, developer marketing, pricing strategy, or product feature design) and finally provide scenarios which show you how each initiative is expected to change the value of each segment.  The framework is fully flexible as it can be applied to a single product, to a group of products or across your whole business. It is also sensitive enough to pick up nuances between similar initiatives and, as such, can provide you with granular insight on specific activities. What can the Developer Engagement Value framework do for you? How are you planning to use it? Dive in the full version and here’s to a brighter future. Download the framework . #developercommunity #developerdollarvalue #developervalue #roi

In the blog post, Take your Data to Dinner , we discussed the importance of clean online survey data: not all survey responses are suitable for analysis – in fact, negative and often fraudulent actors abound. That blog explained how to screen data in order to establish its reliability and cleanliness. In this post, the focus is more technical. Looking strategically at what modern, industry-leading data collection methodology should look like, we unpack the nuts and bolts of the kind of information a market research firm should be collecting from their survey respondents so as to be informed about their quality of the data they provide. What counts as a fraudulent response to our surveys First and foremost, who are the negative actors that we’re talking about here? Before jumping in, it should be noted that these groups are not the only creators of dirty data. At SlashData, we have observed three categories of fraudulent respondents, broadly speaking:  Complete response bots. These bots circumnavigate a survey tool and deliver their answers as a complete set directly to the end point of an API. Think of it as a fully packaged response delivered without even a click needed on the survey tool. Their responses feel forced, clumsy, and lack the human signature. Bot responses from web automation tools. It is always sad to see sophisticated web debug tools such as Selenium harnessed in this manner. These web automation tools work by taking control of the browser according to a programmed routine designed by a developer. It may not be wholly surprising that for a market research firm in the tech space (with a proud pedigree amongst the developer audience) we have seen a goodly few iterations of this sort of bot. Responses like these have hidden systematic patterns which can lead to their detection. Humans working as click farms. This is an individual or a group utilising one or more physically or even virtually different devices in order to register multiple responses to a survey. These responses provide human-like responses but often reek of disinterest and are usually filled with contradiction. Their answers exude artificial resonance.  I’ll explain how we tackle each of these groups. As a prerequisite, I’ll explain the information SlashData gathers so as to do this. Thereafter the overall mechanism, a trust index, which integrates the multiple information sources. Equipped with this, I’ll return to each of these negative actor groups explaining each trip themselves into negative trust territory. A decision is only as good as the information up which it is made. Judging data quality on a number of unique information pieces Before making any decision, it is obviously prudent to gather information. The nightmare situation of any court judge (or market research firm) is the presentation of new evidence mid-trial: not only does it prompt re-evaluating all that has gone before but, in some instances, it casts doubt on the information already provided. For some market research firms, the threat that new ‘mid-trial’ information poses is so concerning that it acts as a deterrent from even seeking such information in the first place. This is a research bias! It is a bias that helps explain why market research firms say that they already have enough information to decide the quality of a respondent and are not hungry for more or to be challenged.  To avoid dismissing information with an important impact on our understanding of the cleanliness of our data, we do not accept this position at SlashData. Instead, we have focused on acquiring several unique pieces of information in order to generate an overall mechanism – a trust index – which integrates the information we are able to gather about our respondents into a single score against which we are able to evaluate their credibility as a bona fide respondent. It is obviously only worth designing a trust index if you have multiple sources of information such as click position monitoring, reCaptcha validation, IP and proxy detection methods; and this is just to name a few. Some of the key pieces of data that are core to SlashData’s approach in data collection standards are the viewpoint data (telling us exactly how much of the question the respondent engaged with), per-question timing, and third-party validation mechanisms such as GitHub verification for developer profiles. Constructing a trust index for our data Just having information does not give an answer. That is why constructing a trust index is such a sophisticated (and yet essential) process.  Here, The Trust Index designed at SlashData, is the key to a coherent system of quality control which works by tracking actions that build and diminish trust. To give an example, a response that does not use privacy persevering tools and is of the same geolocation and reported location builds trust. Similarly, a response that uses privacy preserving tools is trust neutral – it could be either a good or bad actor and based on this information alone, there is no sufficient evidence to determine either way. But couple privacy preserving tools with a signature that suggests it is the same device, close starting times and known incentives to defraud — a picture of overall trust diminishment occurs.  Deploy and Detect Let us return to the three groups of negative actors we identified above to demonstrate how we are able to detect each by deploying our industry-leading data collection methodology. Complete response bots. This type of bot scores very negatively on the Trust Index by bypassing many of our other data collection mechanisms – for instance, they would not have a sensibly defined viewpoint (because their responses did not come through a survey tool). This is a quick and reliable red flag to their credibility which means that we can be completely sure that this type of bot has been completely removed from our clean data at SlashData. Bot responses from web automation tools. This is a more sophisticated type of bot fraud. Because the bot interacts with the survey tool, it is able to create responses that contain basic viewpoint information and other artefacts that our other mechanisms of data collection are on the lookout for. There are some dead give-aways, though: the bots’ response times between questions are either fixed (taking precisely 2 seconds for instance) or follow some type of probability distribution, such as being normally or uniformly distributed. A real human response would take more or less time per question depending on the length of the question, the sophistication of the question (grid or list) and if the question is multi- or single-choice. Too much uniformity in this area signals a response of low trust value. Web automation tools also fail to pass reCaptcha tests. A failure of a reCaptcha test in any instance is an extremely trust diminishing action .  Humans working as click farms. This type of fraud requires screening through multiple different data sources in order to be detected since it is a broad group within which are several levels of professionalism. The least sophisticated examples answer questions carelessly, almost randomly and thereby fail multiple trust tests for consistency; those that are slightly more sophisticated may attempt to change devices or use privacy preserving tools, but subtle pointers  give them away and they are inevitably detected. The most sophisticated require the analysis of multiple patterns/combinations involving unlikely userAgent device signatures, privacy information and responses.  You cannot prevent, fight or detect fraud if you do not have the data.  Do not let cancerous data consume your research. The importance of partnering with a market research firm which is constantly committed to the improvement of data collection methodologies for online surveys is one way you can avoid publishing noise and instead focus on making a noise about your research! We can get the clean data you need to optimise your strategy. How? Let’s talk . About the author Jed Stephens, Senior Data Scientist Jed has several years of research experience in the academic and industry sectors, mainly focusing on applied statistical research and computational implementations of new statistical methods. He holds an MSc in Statistics. His interest is in turning data into informed, actionable decisions.

What do developers expect from tech leaders in their developer program offerings? How do the leading developer programs compare? If you are looking for answers to these questions, then the Developer Program Benchmarking is for you.  What is the Developer Programs Benchmarking? It is SlashData's semi-annual market analysis on engagement and developer satisfaction, of industry-leading developer programs. Working with developers is challenging and modern developer programs consist of myriad activities including: Documentation Providing sample code Developer education Tooling In-person events Online communication among others.  It is hard to be great at everything, and it is hard to allocate effort and money effectively for maximum impact. So, we benchmark the developer programs against each other and in doing so, we provide a clear path to improving your own developer program.  What can the Developer Programs Benchmarking help you improve? There are two main areas in this benchmarking study that can help you improve.  First, measure what developers value in various resources and activities, in all their diversity, across several segments of the developer population.  Second, we highlight the best-practice leaders and what makes them stand out. There is no single leader across all 22 activities we measure —everyone can improve somewhere.  To understand the success of the various developer programs included in our research, we use three key metrics:  Adoption —the percentage of developers in our survey that use each program. Engagement —how frequently the users of each program consume its resources. Satisfaction —how developers score each attribute of the programs they use, equal to the proportion of five-star reviews minus the proportion of one-and two-star reviews What new insights are there from the leading developer programs in Q3 2023? The main highlight? Many smaller vendors eclipse the established market leaders' satisfaction scores Developers' answers in public forums In each new edition, we have a special "Deep Dive" where, on top of the main insights on Developer Programs, we focus and shed light on a more specific area of Developer programs. For this edition, we added a Deep Dive on Answers in public forums. Here are the questions we answer. Which types of developers value answers in public forums the most? How often do developers ask questions, answer questions, or otherwise utilise public forums? What are the most important characteristics of a useful answer in a public forum, and how does this change by developers’ experience levels? How satisfied are developers with the quality, frequency, and speed of vendors’ responses to questions in public forums? You can find more details about developers’ preferences for developer programs at the dedicated Developer Program Benchmarking page . If you are looking to benchmark your developer program against the leaders, please get in touch .

Clean data is difficult to define. Simply, clean data is data that is analysis ready, but the term ‘analysis ready’ has baked into it much more than initially meets the eye. Perhaps then, the easiest way to get clear on what clean data is, is to understand what clean data is not. After all, as Tolstoy put it, “ All happy families are alike; each unhappy family is unhappy in its own way .”  Dealing with dirty data Dirty data is, by definition, data that is not analysis-ready - it is fraudulent, corrupted, or distorted in one or several of a number of ways, depending on how the data is provided. In surveys, for example, questions can be hurriedly answered, answered by selecting at random, answered systematically randomly, such as by always selecting the third option, answered in pretence, answered boastingly, and so on and so on. And this is just to name a few.  Suddenly, the data is corrupted, and what we are left with is not fit for clean, reliable analysis. Let alone decision-making.  What this means in practice is that it is only the data from respondents who are genuine and also consciously engaged (with a survey) that should be considered “clean”. Clearly a market research firm needs to be able to provide the process of screening for the various forms of dirty data. Clean data are necessary for real-world, tangible decisions A simple equivalent might be something like this. Imagine that you’re a user on an online dating platform. You’re looking to find your match, but out there online, it’s tricky - how do you know the people you meet are who they say they are? What if they’re only funny over text? What if, in reality, they don’t look like their profile picture? What if their online persona is only just that? Meeting someone in person gives you an immediate sense of whether that person is genuine or not — but online, we become reliant on cues: does my match eat the same types of food as me, watch the same shows, or support the same causes? These are all proxies for that first meeting when your instinct takes over and screens your match. That first meeting is the dirty data detection mechanism of dating. In an online survey, we almost never meet our participants in person. Getting to clean data, therefore requires building mechanisms to screen your ‘matches’ in the same way as you might in the online dating world. Without the proper infrastructure, one is liable to allow in those who are non-genuine.  At this point, you’ve scrolled through your potential matches online, and now it’s time to get serious. You want to begin a conversation, get to know them better, and check that when you actually talk to them, they are who they say they are. Being a researcher myself, I would suggest something scientifically proven to achieve results, such as Arthur Aron’s 36 questions which lead to love . This is also why all our clients benefit from survey questions written by our experienced market research analysts. Without a well-written question, the answer will always appear as if it was dirty data. Surveying and producing data beyond the ‘what’, looking at the ‘how’ We all know that on a date, the ‘how’ the question is answered is as important as the ‘what’ was answered. Enter SlashData’s bespoke survey tool. Whilst the survey is asking questions written by our experienced market research analysts, the survey tool gathers information about how respondents are answering the questions in order to screen for potentially non-genuine ‘matches’. It is this “how” that is critical to our advanced integrated cleansing system. Clean data example 1 Here is a concrete example: when speaking to other researchers, they are often shocked to know that at SlashData, we know exactly how long it took a respondent to answer any given question. The industry standard screen is ‘total time in the survey,’ but this is easily exploitable by respondents. How genuine do you think your date would be, for example, if they spent ten minutes answering your first question about the other dates they had met online but only 10 seconds answering all your other questions about likes, dislikes, family, work, hobbies, hopes and dreams? Their total survey time might be 10 minutes and 30 seconds, yielding a respectable 2min, 37 seconds per question average (over four questions), which, by industry standards, would yield an acceptable ‘total survey time’. Industry standards would tell you your match is ‘clean’, but you’d be right in feeling more than a little dubious.  At SlashData, we would be looking far closer at the time taken to answer each question because, when you’re looking for ‘the one’, it matters. This innovation would not be possible without our survey tool. Clean data example 2 Another example: as your date progresses and you start to learn more it is only human nature to complete a consistency check. Think of it as checking your respondent’s life story. “You’ve made a React app? But you told me you didn’t know JavaScript”. A red flag. A little later, you realise your first date is actually a UI designer. Consistency rules are critical to detecting if the picture the respondent paints stacks up as a whole. For every three questions SlashData typically implements a consistency rule - a large survey may consist of sixty plus validations. These rules allow us to check whether the data we’re getting is reliable. While these rules can be implemented regardless of the survey tool, you should be enquiring if your market research firm takes care to consider and implement these.  Data consistency is key A flip side to consistency is advanced pattern detection. Is your date taking the same to consider each of your questions or are they disinterestedly answering via the easy way out? At SlashData, we’ve seen respondents who have been recruited from top panel providers who nevertheless always choose the third option on the list. Depending on the survey tool your market research company used this may be impossible to detect if the options are randomised - how do you know whether your respondent has scrolled down enough on the screen to grasp the full question, or whether they’re simply picking from options that they can immediately see? These characteristics are critical to know when deciding how trustworthy a respondent is.  After all this, imagine the worst case scenario. Imagine after effort - all that swiping and small talk and screening out the dodgy ones -  you turn up to find that your date is…just here for the food. You’ve been let down and probably feel used. This is an instance where the incentives (a nice meal or cash amount for answering the survey) yield problematic results. In an online environment, it requires industry-leading adaptations to detect repeat responding and bot responses. An advanced cleansing methodology should take into account the device used to answer the survey, whether any proxy, VPN, or IP masking was used — all while not penalising legitimate use of these privacy tools. This requires the complex consideration of response patterns and respondent metadata. Bot and repeat responders are a real problem for clean data — both artificially inflate the number of survey responses as well as add considerable noise to the results. Consistency checks also form an important aspect of checking for this type of response data. Love is a serious matter. Clean data is crucial. Finding a genuine match takes effort. All are as true for screening online data as they are for online dates. To find that the data is ‘analysis ready’ requires a number of mechanisms to sift out a myriad of dodgy dates or dirty data that shouldn’t be underestimated in their importance. Per question speed tests, click pattern detection, consistency checks, AI bot detection, repeat responder detection are just some of the technical achievements of SlashData’s cleansing methodology. SlashData’s bespoke in-house survey tool is best in class in providing these inputs to any cleansing process. Is your data clean? It is critical to ask your market research partner if they have the information to actually ensure this is achieved. If you want to better understand our process or explore a specific topic together, let’s talk . About the author Jed Stephens, Senior Data Scientist Jed has several years of research experience in the academic and industry sectors, mainly focusing on applied statistical research and computational implementations of new statistical methods. He holds an MSc in Statistics. His interest is in turning data into informed, actionable decisions.

Nowadays, developers have an abundance of options to choose from when it comes to finding information about software development and staying up-to-date. Nevertheless, their needs and preferences vary  depending on where they stand on their developer journey and based on a few key characteristics. If you would like to understand what those are and how they affect developer information choices, then keep reading! In this blog post, we draw data and insights from SlashData's 27th Developer Nation survey, which was fielded in Q3 2024 and reached 9k+ developers worldwide. Open source communities and social media are the leading resources where developers go to find information Open source communities (43%) and social media (41%) are the leading resources for developers globally to gather information  and stay up-to-date about software development, according to our data. In comparison, only 3% of developers rely on vendor-organised events, while other resources, such as meetups and hackathons, also see limited (c. 14%) interest among developers. Vendor-driven resources including official websites, newsletters and/or events, are used by ~40% of developers. Experience is a key factor affecting information resources preferences Experience in software development stands out as one of the main factors influencing resource decisions. Indeed, experienced developers  (those with at least 10 years of experience) utilise a more diverse set of resources to get information and stay up-to-date  about software development compared to developers that are just starting out and have less than 2 years of experience (utilising 3.5 resources on average vs 4.3 among experienced). However, it is not only the breadth of resources that varies with the level of experience, but also the channel preferences. For example, experienced developers lean heavily (52% vs 32%) towards vendor-driven resources  to stay up-to-date, whereas nearly half of developers with up to 2 years of experience rely on social media  for their information (vs 31% of more experienced developers).  Experienced developers prefer vendor-driven resources to stay up-to-date. The relatively high use of vendor-driven resources could reflect the fact that experienced developers have more responsibilities than their early-career peers. To explain, the pressure to ensure proper implementation and functionality can lead to a preference for official vendor materials - such as documentation, blogs, and newsletters - since these resources tend to be of higher quality and more reliable. Another reason that official resources are not so favoured among developers with limited experience could be that this kind of resources might demand better understanding of the subject matter and in some cases a deeper level of expertise, something that is also gained through experience. On the other hand, the prevalence of social media among early-career developers, in conjunction with their limited use of a number of fairly established information channels, could be due to a lack of awareness of those resources. For example, Q&A sites and conferences/events which are generally known among developers. Developers with little experience are also more likely to be utilising conversational AI services / chatbots than their more experienced peers (30% vs 22%). For many developers making use of conversational AI services, the combination of real-time interaction, breadth of knowledge and a “safe environment” (as you can ask basic, or even ignorant, questions without fear of judgement) are possibly compelling adoption points. These features, however, don’t seem to be particularly appealing to highly experienced developers. Amongst the rest of information resources, the use of open source communities and Q&A sites, as well as listening to distinguished peers, are top of mind among experienced developers. Information source preferences vary by region Another important separating factor is the region developers are based in. There are certain regions, where reliance on information resources is limited compared with others. For instance, countries in Asia (including China and Japan) exhibit a small degree of resource utilisations, compared with other areas (3.2 on average vs 4.2 excl. Asia). At the same time, developers within each region seem to have varying preferences in terms of which exact types of resources to use. For instance, Western European developers are significantly more likely to attend conferences or events than the rest of their peers (38% vs 25%) , whereas Latin American developers show a much stronger preference for social media and following respected peers than average (59% vs 40%). Similarly, CEMA-based developers are more likely to be using official vendor resources than developers based in other regions (47% vs 40%). In the US, official resources are used by 41% of developers, with community-driven resources (community websites, forums and groups) a close second. Importantly, maybe in light of the ongoing turbulence in the US labour market, a third of US developers prioritise education through attending seminars or pursuing training courses and workshops . Other characteristics affecting information resource selection for software developers   In addition to experience and location, the types of projects that developers work on is another factor affecting the preferences for information resources. More specifically, involvement in different project types might require developers to use different frameworks, technologies and/or programming languages. Thus, depending on the maturity, reliability and accessibility of each tool or service they use, developers may seek to retrieve information from different channels that best match each topic of interest, in order to optimise their level of understanding. For example, our data shows that web and backend developers, as well as those building apps/extensions for 3rd-party ecosystems, behave similarly  not only in terms of their information sources preferences but also towards the number of resources that they use (around 4.2 vs 3.5), when compared with developers in other sectors. Specifically, they stay up to date using a diversified portfolio of resources following both official/vendor-based (such as docs or forums) and non-official/community-based resources (such as Q&A sites or open source communities). So, any effective outreach strategy would likely need to extend beyond official documentation and require at least some level of presence on community-based channels  for these developers.  Another interesting finding is that more than one in three developers involved in ML/AI, embedded software development, or industrial IoT, are attempting to sharpen their skills through seminars, training courses or workshops , compared with just about 20% of AR/VR developers. AR/VR developers used to be more eager for training resources  (~33% of AR/VR developers in Q3 2023), broadly highlighting the current bifurcated state of the ML/AI and AR/VR sectors, as the former continues to see additional investments from companies because of the remarkable progress of generative AI models, and the latter being put somewhat on the backburner. For the vast majority of areas discussed earlier (excl. Latin America), results remain consistent across regions, meaning that these findings cannot be attributed to geographical location effects. More data, more insights! If you’d like to receive more data and insights about where developers go to find information, as well as what types of content they prefer, reach out to us  or explore all our research at the SlashData Research Space . About the author Lazaros Ioannidis Data Analytics Manager Lazaros has extensive experience in data analysis and research, with a background in financial markets. He holds a Master’s in Finance and is a CFA® charterholder. At SlashData he helps clients find data-driven insights to questions they must ask about their business.

Developer Marketing & Relations: The Essential Guide just published its 3rd edition Quick history: In 2018 SlashData decided to publish a book titled “Developer Marketing: The Essential Guide”, seeing the lack of education in developer marketing and relations roles and activities. In that book, industry leaders from the world’s largest companies shared their “things to do and things not to do” experiences. Each chapter had its own author, focusing on the topic they knew best. Fast-forward to today. Thousands of books have already been sold. The industry evolves fast. Not all ground has been covered. Therefore, an updated edition was much needed. This is why the “Developer Marketing & Relations: The Essential Guide – 3rd Edition” has been launched. The 3rd Edition features 9 new chapters and 1 revised chapter since the first 2018 edition. It is a much more complete read and covers most of the topics that dev marketing and DevRel professionals will come across in their professional life. The book can be read cover to cover or readers can pick the topics they are interested in. Each chapter addresses a specific topic written by an author from a major company. Some of the topics are community (+ how to make it inclusive), building personas, building developer programs, developer events, connecting with developers and many more from 24 authors and 17 Industry-Leading companies. The book’s aim is to educate and help professionals push their careers forward. All profits from book sales are donated to worthy organisations: Code.org, Girls Who Code, Black Girls Code and CoderDojo. So far we have donated more than £7,000. To support the dev marketing and DevRel community at challenging times, the book price is reduced by 50% to make it accessible to everyone: $9.99 for the paperback and $4.99 for the digital edition. The book is available through Amazon in Paperback and Kindle  and through the book website in ePub . For more details, see the book website. If you are a journalist and want to spread the word and/or write a review of the book, you can claim a free copy . Companies the book authors work in: Amazon Web Services, apidays, ARM, Atlassian, Facebook, Google, Microsoft, Nutanix, Oracle, Qualcomm, Salesforce, Samsung, SAP, TomTom, Unity, VISA, VMWare #book #developermarketingresources #devrel #developermarketing #resources #devrelresources