Successful balance: gracefully and tactfully raising a dev tool price

Cover for Successful balance: gracefully and tactfully raising a dev tool price

Topics

Share this post on


Translations

If you’re interested in translating or adapting this post, please contact us first.

Is it ever a good idea to raise a dev tool’s price? What justifies doing so? And if you have to do it, how do you do it with grace?

Let’s say you’ve had a somewhat popular dev tool that’s only used one monetization strategy for years, and everything is humming along just fine. But the market is constantly changing, and like it or not, if your tool is useful, competitors begin to pop up. You can lose users to them, and the users who stick around will start to request features that your competitors are offering. Something has to be done.

Naturally, your team decides to implement changes to boost your product’s value and the benefits that users get from it. If this is done properly, your tool becomes even more attractive. But according to new financial demands, the cost of the tool will also probably have to be increased. However, this isn’t so simple.

Raising prices for a dev tool product can be a really sensitive task that requires careful navigation. You need a deep understanding of your customer base, and their needs, feelings, and expectations. This can present a huge challenege, but this challenge can be transformed into a growth opportunity!

We’ve assembled a list of steps you can take to prepare for an effective pricing shift and a new product focus. This list is based on our own practical experience, and in particular, from work with one of our clients, Coveralls. Designers and managers from Evil Martians worked with the core team of this dev tool step by step on this delicate journey.

First, how this can go really, really wrong

Before we even think about moving forward, let’s step back a bit and begin by evaluating the risks that may pop up when designing a new pricing policy.

  • Risk of alienating existing users: Developers are often sensitive to regular changes in the tools they use. Price hikes can lead to dissatisfaction and cause users to seek alternatives.
  • Reduced competitiveness: If your product’s price increases, it may become less competitive—especially if similar tools are available at lower prices.
  • Decrease in perceived value: If an increase isn’t justified with added features or services, users might perceive that they’re getting less value for their money.
  • Communication fails: the news of the increase is delivered can impact user reactions; poor communication can lead to misunderstandings, dissatisfaction, and churn.

Dev tools target a very specific audience of engineers and this audience has several notable differences from ecommerce or FashionTech consumers.

Engineers are a tough crowd (we know because we’re engineers).

First of all, developers rely on your tool for their everyday work. So, any changes—including price hikes—can disrupt expectations and budgets. Remember, these users have invested time and resources learning and integrating your tool into their workflow, so sudden price changes could be seen as unfair or exploitative.

Next, reputation is a powerful force in the developer community. Abrupt or significant price changes can harm relationships and damage your reputation.

Third: the dev tool market is highly competitive. Many products offer similar features, so a significant price increase could push current users and potential customers towards more cost-effective alternatives.

Stability and impact vs. effort

So, let’s say you’ve already accumulated a list of user feature requests and, perhaps, unfortunately, complaints (it takes too long to complete requests, it’s tough to find information, the service is unstable).

At this point, you need to sort the tasks and divide them into several streams: those to increase the service stability and new features.

Stability comes first. An unstable product can lead to a loss of trust and a decrease in user satisfaction, which may ultimately lead to attrition. Consider the complaints about long completion times and the difficulty of finding necessary information as your first tasks. Fixing these issues can also indirectly introduce new features as your users can now use the product as intended and more efficiently. If your app has significant stability issues, you might allocate 70% of resources to that and 30% to new features. As stability improves, you can adjust the balance.

Create an Impact/Effort matrix. For each request or complaint, estimate the impact of addressing it (how many users will it benefit, and how significant will that benefit be?) against the effort required for implementation (how many resources, including time, will it take?) Use this data to create a priority matrix. High-impact and low-effort tasks should be your priority (considering the proportion mentioned above).

Remember, the goal is not to satisfy every single request or to eradicate every single complaint. Instead, it’s about improving the overall user experience and building a product that caters to the needs of your users in the most efficient way possible.

Some more necessary preparations

Make sure your analytics make sense. Your product must have fine-tuned analytics to get detailed information and insights. They should provide a full range of data on critical performance indicators: load, fault tolerance, speed, etc. If you don’t have proper analytics, it’s time to build or enhance them and collect historical data—this helps form hypotheses and make changes faster. You can try something more innovative with robust analytics, like Growth Hacking.

Increase fault tolerance, prepare for heavy loads, identify and fix the most critical bugs. You’ll need a prioritized backlog based on data from analytics. You can use additional metrics for prioritization (for instance, explore requests from an enterprise customer who pays for a subscription or an active user). If you see a decrease in the number of support requests and the total number of complaints—you’ve reached your goal!

Add new competitive features. Carefully analyze competitors (or run benchmarks on key product indicators) and user requests to shape a new roadmap. The sprint approach works excellently here: right after implementation, you immediately start beta testing (when the task is complex and requires user feedback). This will help you launch new features and get feedback faster.

Analyze and improve the user experience. Analyze UX in key product areas: billing and payment flow, onboarding, and what needs to be changed in the interface due to price updates. User feedback and analytics data are also precious here. For example, you can see the correlation between the number of requests to your tech support service and low user activity after registration—this can mean that users don’t have enough information at their onboarding stage. So you can fix it.

Also, review all the critical user scenarios: registration, onboarding, trial, payments, and searching for information in your documentation. Drill more profound into the billing scenario because convenience, simplicity, and transparency are critical. For example, in one of the customer projects, we found that one non-working field in the payment form could fail the whole subscription payment process (that’s when your user immediately leaves you for a competitor.) Also, users may not understand the conditions or how to complete custom fields.

Understandable and accessible patterns always work well here. An excellent option for early-stage startups could be integration with a service known for its simplicity (like Stripe). The paying user and the financial team that receives the payment can work in a straightforward interface.

End on a high note. Offboarding has the same importance as onboarding. When users are dissatisfied or want to change a service, you need to give them a clear and accessible opportunity to leave, explain their reasons, and show options to change their minds. This data can also be helpful for the current pricing policy analysis and further hypotheses for your product development.

Changing a price with grace

After you’ve completed the above analysis and preparation, you can begin to change the pricing policy. Here are some strategies.

  • Value addition: Before you increase the price, consider adding new features or improving existing features. This way, users will see they’re getting more value for the increased cost.
  • Grandfathering: Allow existing users to keep their current pricing for a certain period, ensuring their loyalty is valued. This can help ease the transition to the new pricing structure.
  • Tiered pricing: Offer different pricing tiers, each with various features. This allows users to choose the price point that best suits their needs and budget. If the higher-priced tiers offer significantly more value, users may be more willing to pay a higher price.
  • Gradual increase: Instead of a sudden substantial price increase, consider implementing smaller increments over time. This is less likely to shock customers and allow them time to adjust their budgets accordingly.

Showing your users that it’s really worth it

The most complex and critical part of the strategy is informing your users about the price updates and getting their understanding and support (and, the ideal but possible case is when you even increase the number of users.)

Therefore, a communication strategy matters here: you must explain why a pricing change is necessary and how it will improve your product in the long run.

Here are some valuable practices to demonstrate how an increased price correlates to increased value for the user:

  • Demonstrate increased value: Ensure users understand what they’re getting in return for the increased price. Highlight improvements, new features, and other benefits with a higher price.
  • Open and honest communication: Be transparent about why the price increase is necessary. It could be to maintain the product’s quality, fund future developments, or cope with increased operational costs. When users understand the reasons behind the increase, they’re more likely to accept it.
  • Reiterate the Unique Selling Proposition (USP): Emphasize what makes your product stand out. If you remind users of your product’s unique value, they’re more likely to accept the price increase.
  • Customer success stories: Share stories from users who’ve derived great value from your product. Success stories can be powerful persuaders, demonstrating the real-world benefits and results that your tool can deliver.
  • Engage and listen: Invite feedback from your users about the price increase. This can make them feel valued and heard, and it can provide you with valuable insights to help manage the transition effectively.

There are some essential considerations when communicating about changing the pricing policy.

First, the tone of voice shouldn’t be guilty (no “Sorry,” “Unfortunately,” and “We had to”)—on the contrary, explain the new value of the service.

Regular measurement of audience engagement also matters: you need to understand whether your users read newsletters and news and how many unsubscribe—so you can further adjust the communication strategy (and even the pricing one.)

Finally, there should be a gradual process of informing users:

  1. Speak about news and milestones, plans and roadmaps, and form a positive agenda: ”We are enhancing our product now.”
  2. Announce plans to raise prices and explain why the company made this decision. Provide links to additional materials.
  3. Give time and the opportunity for users to ask questions and discuss with managers and tech support how the price will change for their specific cases.

You can use social networks, blogs, corporate news on the core website, and newsletters as communication channels—you can also share positive vibes and maybe some problems that the company faces in the market (but that’s up to you.)

You shouldn’t be limited by announcements of new feature releases only: inform your audience about important milestones like a beta test of a new feature, the first 100 customers, the results of a month, six months, a year, and plans.

In general, your announcement should lay out step by step how the company is investing the raised revenue into the dev tool’s future evolution.

You can also use the format of the corporate quarterly/annual reports (this can become a newsworthy event itself) and design a separate landing page for each of them (like we did for the Coveralls project.)

You will need platforms where your community can discuss your tool and share their thoughts and ideas in a quick and convenient format (and discuss prices openly). These could be channels in Slack or Discord, Gitter, StackOverflow, or proprietary portals for documentation and communication, as many projects have. These are the source of the most valuable insights and an additional opportunity to give the word to your users to promote your service on their own.

Also, you can quickly transform the feedback from these channels into your “to-do” list—compared to searching for such comments on Twitter or Reddit.

Beyond theory: our collaborative journey with Coveralls

Let’s now step into real-world practice by examining our recent collaboration with Coveralls, a dev tool to monitor test coverage by revealing which parts of your code aren’t covered by your test suite. In this project, we got a perfect opportunity to test and apply the strategies we’ve outlined above—and with consolidated efforts of the Coveralls team and Evil Martian’s designers, we carefully prepared every step.

Again, stability comes first!

What is important for a developer using any monitoring and analysis system? Stability, speed and accuracy. Remember, stability comes first (link to the corresponding paragraph).

In the case with Coveralls, we started by optimizing the service to achieve stable and predictable performance under increased loads. This involved modifying the infrastructure, working with legacy code, and accelerating the core features of the application.

The first thing we did was to increase transparency and controllability by implementing a monitoring system (of course, based on Martian open-source software, Yabeda).

Next, based on the obtained metrics, we started a comprehensive set of work on optimization, acceleration, increasing stability and resilience-this is the main development track that is still ongoing. It included updating Ruby, Rails, and all related components, refactoring, infrastructure optimization, and a lot of different things-but this became possible only because performance metrics and dashboards appeared, showing how the application feels.

Segmentation and personalization

Our journey began with a deep dive into Coveralls’ customer data. We divided the user base into distinct segments based on their usage patterns, average spending, and their Lifetime Value (LTV)—an estimation of the net profit attributed to the entire future relationship with a customer.

For example, enterprise clients who consistently utilized higher-tier features and had a track record of high LTV formed one segment, while infrequent users made up another.

Once we had this segmentation, we tailored our communication strategy to each group. We took a more personal approach for enterprise clients and long-standing customers, reaching out directly to discuss the impending changes. On the other hand, for the larger audience, we crafted emails and in-app messages that were transparent and sincere.

We clearly stated that the last price change occurred a decade ago, explaining that a price increase was essential to continue providing a robust and valuable service.

Effective channel utilization

Next, we focused on ensuring our message reached every customer. Drawing on the knowledge gained from audience segmentation, we leveraged various communication channels—email for direct, personalized communication; social media for broader announcements and reminders; and in-app notifications for active users.

For instance, for our enterprise clients, we used direct emails and even phone calls, while for regular users, in-app notifications and social media posts served to get the message across.

Technical preparedness

An often-overlooked aspect of price restructuring is the technical readiness of your payment systems. Our collaboration with Coveralls highlighted this necessity when we encountered unexpected technical roadblocks.

We dealt with an outdated payment API that made transactions difficult, deprecated features in our billing portal that impeded user experience, and auto-migration issues due to the limitations of our existing tools. These technical glitches led to higher churn rates and customer dissatisfaction as payments weren’t processed correctly.

We helped the team to migrate to stable, supported versions and released the support team from resolving payment-related problems and reprocessing payments manually every single time.

Contingency measures

No matter how comprehensive your communication strategy is, there will always be customers who miss the notifications or disregard them until they see the revised charges.

We created contingency plans to address this, such as extending payment deadlines or offering limited-time discounts. This approach helped to appease those who were initially taken by surprise by the price increase.

The outcome

By successfully navigating these challenges and implementing these strategies, we managed to double Coveralls’ revenue. The growth rate has remained stable in the months following the price adjustment, indicating that the transition was effective and accepted by the user base.

Remember, though, changing prices isn’t quick or easy. In our case, it took almost 5 months of planning and preparation. This timeline can change based on different situations. This experience reminds us just how important it is to start preparing early when you decide to raise prices.

Your turn

Our collaborative experience with Coveralls provides a robust roadmap if you’re contemplating a similar transition. Understand your audience deeply, adopt a multi-faceted communication strategy, ensure your payment systems are updated, and prepare for eventualities.

Price increases can be tricky, but with the right strategy and clear, transparent communication, it is possible to implement them in a way that minimizes user churn and maintains a strong value proposition for your product. And, of course, metrics should be the focal point: they will allow us to understand what users think to fine-tune a strategy.

Remember, at Evil Martians, we’re experienced guides and ready to assist those who decide to undertake this pricing strategy.

At Evil Martians, we transform growth-stage startups into unicorns, build developer tools, and create open source products. If you’re ready to engage warp drive, give us a shout!

Join our email newsletter

Get all the new posts delivered directly to your inbox. Unsubscribe anytime.

In the same orbit

How can we help you?

Martians at a glance
17
years in business

We transform growth-stage startups into unicorns, build developer tools, and create open source products.

If you prefer email, write to us at surrender@evilmartians.com