Chris TozziGuest Author

If you’re a software company, describing what your tool does in a technical sense is one thing. Explaining its functionality in a way that makes it appeal to the market is quite another.

Too often, software companies make the mistake of positioning their tool in a way that makes perfect technical sense but doesn’t align clearly with buyers’ expectations. Or, to cater to the market, they describe their product using mumbo-jumbo and buzzwords that might sound impressive in the C-suite but mean little to the developers who play a critical role in choosing tools for their companies to use.

Thus, effective software product marketing is a bit like navigating the straits between Scylla and Charybdis (a six-headed monster and an enormous whirlpool in Greek mythology). Conversely, you should position your product in a way that communicates its value for a business, rather than focusing too narrowly on what it does. But at the same time, you must avoid being overly broad, or chasing buzzwords that will turn technical buyers off in a flash.

Keep reading for tips on how best to position a developer tool in the marketplace.

Broad vs. narrow tech marketing

First, let’s define in more detail the problem that software companies face when trying to position a new product.

One common mistake is to focus too intensively on the technical functionality of your product, and consequently failing to convey its full value. If you say that your product is a “scanner for containers,” for example, you define yourself very narrowly. The only technical buyers who will find your product are the ones who are looking specifically for a container scanner. Buyers searching more broadly for “security tools” are unlikely to find you within the sea of other software vendors that sell security tools.

The other common mistake is positioning a tool too broadly. For instance, if you say that your product is a “CI/CD tool,” you do a poor job of conveying to developers what the tool does. CI/CD is a broad and generic term, and there are more than a dozen different kinds of tools that fit within the category.

Likewise, it’s not uncommon to see vendors describe their tools using terms like “Kube-native digital transformation platform for containers.” (OK, that example might be a bit of an exaggeration, but it illustrates the point; and yes, “Kube-native” is now a thing, although I’ve yet to see anyone define what it means explicitly.) Would you have any idea what a tool with a description like that does? I wouldn’t, beyond hazarding a guess that it has something to do with containers or Kubernetes. And if I were a technical buyer, I wouldn’t give the tool a second thought.

Finding the right place in the software market

How can you position and market your tool in a way that doesn’t fixate too narrowly on its specific functionality, while also avoiding a broad, generic positioning that fails to communicate the tool’s technical value?

Part of the answer is to make sure to describe the tool in terms that make sense to developers. A healthy approach is to look at the language that your most successful competitors use to describe their software and assess how technical buyers would respond to their positioning. Even if you disagree with your competitors’ technology approach to the market, which you probably do, evaluating how they position themselves can give you perspective on your strategy.

Joining a complementary ecosystem

Also critical is to determine which ecosystem your tool is a part of, and adjust your positioning accordingly. Few software platforms succeed on the market as general-purpose solutions for all types of infrastructures, development strategies, and use cases. And even if you think your tool has the potential to be useful to every developer out there, you’re probably not going to succeed in marketing it that way unless you are Google or Microsoft.

Instead, you need to define your tool as being part of an ecosystem or catering to a specific (but not too specific) set of needs.

For example, if you develop a security solution for containers, you would fit in the Kubernetes and Docker ecosystem. Your product messaging should emphasize the idea that your tool should be part and parcel of any Kubernetes- or Docker-based software delivery pipeline.

Or, consider the example of an APM tool vendor. Most APM tools available today support most types of infrastructure. However, if you look around the APM marketplace right now, you’ll notice that most of the best-known vendors currently have messaging that centers on delivering APM for microservices, containers, and dynamic environments. That doesn’t mean they don’t support monolithic, non-containerized, and static environments, too (most still do). It’s an example of how they have adjusted their messaging to fit within a particular ecosystem – centered on microservices, containers, and DevOps. Even though their tools could work in other ecosystems, they adopt a more focused marketing approach by pursuing an ecosystem with active buyers. Since containers and microservices are still new, teams that use these technologies are less likely to have an APM solution already in place compared to those working with legacy infrastructure).

If you can market or sell your tool through a portal or buying path that caters to the ecosystem you’ve chosen to pursue, that’s even better. One way to do this is to make sure your product appears within marketplaces that cater to that ecosystem. For example, if you sell a tool that helps monitor AWS environments, you’d better make sure that that tool is part of the AWS Marketplace because buyers are at least as likely to look for it there as they are to search for it on Google.

Similarly, if your tool complements or expands upon another, make sure that your product is available in the same portals. For example, a technical buyer who enters a marketplace to find a performance-monitoring tool for Kubernetes environments, may well also be searching for a security monitoring tool for Kubernetes. If you sell either of these tools, you want to make sure yours is in that same marketplace, so that buyers can find them together.

Although the language you use to describe and define your tool is part of the battle, making your tool visible within the ecosystem you cater to, is equally important. After all, most technical buyers don’t know how you think about your product or its place in the market; they only know how they see the market and what they are seeking. To maximize the chances of your target market finding and liking your product, you need to make sure it is easily accessible as part of the ecosystem of tools those prospective buyers need to do their jobs.


Sell API-first products to millions of developers with Manifold


Stratus Background
StratusUpdate

Sign up for the Stratus Update newsletter

With our monthly newsletter, we’ll keep you up to date with a curated selection of the latest cloud services, projects and best practices.
Click here to read the latest issue.