Positioning for Users vs Positioning for Buyers

You might never have thought about how your API endpoint security solution resembles a sugary breakfast cereal or a toy car, but if you are selling a software engineering tool (or, indeed, business software of most types), you are probably asking yourself if you should position for the users or for the buyers.

Before I get back to talking about sugary breakfast cereal, I wanted to let you know I’m hosting a webinar on this topic this Thursday, April 29th at 9am Pacific. Sign up here.

Users and Buyers

In the consumer world, the biggest example of a user vs buyer problem is products aimed at children. Children are the ones who play with the toys and eat the sugary cereal, but they have no economic power to go to the store and purchase those items themselves. They can, however, influence the economic buyers.

In a engineering team, there’s often a similar dynamic at play: individual contributors might not have control over which tools are used in the company, or at least which tools are officially supported and licensed. In an engineering team it can get even more complex, too, because sometimes — often — there are multiple users, each using the tool in some way. The economic buyers might be users, too, as well as the security team and the platform team and application developers. This web of users makes it even more challenging to decide who to position for.

So who do you position for?

Like any good consultant, I’m going to say “it depends.” Because it often does, though there are some common themes.

First of all, if you’re positioning an open source project position for users. There are no buyers.

Second, if you’re positioning a paid product, it depends on whether you have a top-down adoption strategy or a bottom-up adoption strategy. A top-down adoption strategy requires positioning for buyers. A bottom-up strategy means you should position for users.

Third, if you have multiple users, deciding who to position for is a core part of determining your positioning. A Kubernetes tool that security teams also use is fundamentally different positioning from a security tool that integrates with Kubernetes.

Don’t lose sight of value

Regardless, if your users aren’t buyers and vice versa, you need to understand and be able to articulate the value you provide to both groups. Parents care about the vitamins and minerals in the sugary cereal, kids care that it turns the milk green and is sweet. (Ok, in this example the parents are probably deluding themselves about nutritional characteristics.)

The bottom line: Be able to articulate the value that you provide to both users and buyers. Directors of engineering and individual contributors care about different things, but most tools have something for both of them. Make sure you’re able to articulate that clearly.

Do you have more questions about positioning when your users and buyers have different things keeping them up at night? Join the webinar! Here’s the signup link again.