For a highly technical product offering, how much messaging emphasis should be placed on technical value versus overall business value that your solution provides?

If by technical value, you mean “what does this thing actually do?” - a lot. Most technical categories are super crowded (and if they’re not crowded, they’re nascent and not well-understood), so being precise on “we’re different in that we solve these problems in these ways” is super important so that those details aren’t left entirely for SE’s in a discovery meeting with a prospect. If you have a highly technical product offering chances are you also have highly technical users/decision makers that you're trying to reach - treat their time and intelligence with respect by getting to the "there there" of what your offering does and how it helps. Business value is of course important - like good old “reduce MTTR” which is a mainstay in my space - but the HOW is often the differentiated part, make that clear without getting into the weeds of feeds and speeds and you’re golden.

[Insert “Why not both?” meme] :)

The best thing you can do is bring these stories together – when technical value solves business value, you have yourself a winner. (I don’t think I’ve ever encountered the inverse of that, now that I think about it)

This manifests itself in a number of ways, but you almost always needs an explicitly budgeted project to attach to. Thinking top down – execs who mandate certain initiatives send managers out looking for technical solutions. When a practitioner tries a product out and gives it the thumbs up, that works its way up the chain. Thinking bottom up – when a practitioner finds a product that solves one or more of their responsibilities, they’ll make the case to their managers who get an exec to drop it into one of the project budgets.

That’s an oversimplified view, it’s never that straightforward a path, but the main point here is that business value and technical value should be two sides of the same coin. Smart buyers know that – you don’t hear, “nobody got fired for buying IBM” anymore, companies do their diligence. As a PMM, it’s about identifying the motions – first, what are the compelling events that lead to budgeted projects? Then you want to land messaging that speaks to the value for the business owner responsible for the results of the initiative, and land messaging that speaks to the value for the technical practitioner responsible for the implementation. Easy, right?! :)

I wrote about this topic in more depth here (https://www.workinproduct.com/blog/elements-of-a-positioning-system-compelling-budgets) – the next post was supposed to be about value drivers, but I had to put a pause on the series. Now I’m motivated to wrap it up, thanks!

If you get to know who you're talking to, it's a lot easier to know what to say. That's a core tenet of messaging and being a good conversationalist in general.

Your first step with a question like this is to establish buyer personas. Who's involved in the buying committee? Are they the key decision maker or an influencer? What do they need to know? If you don't know, start by doing win/loss in partnership with your revenue teams. Try to get a handle on who was involved in recent purchase decisions, what their process looked like behind the scenes, what motivated their decision, and where they had questions.

You may confirm you have highly-technical buyers driving the bus. Or, you may find that the key decision maker and budget holder is typically a business owner who brings in an IT partner to evaluate the technical feasibility of your product. Do the dilligence to find out and you'll learn when and where the technical emphasis is most critical.

The answer is you need both, but targeted to the right audience: business value for the economic buyer and technical value for the user / implementer. In some cases, the buyer AND the user are technical personas (e.g. Github). In other cases, the roles are split.

For example, for mParticle, the buyer/champion is the Director / Head of Marketing Technology, but the data engineer is the implementer. In this case, the message to the data engineer is: We make your life simpler. We take care of data collection and integration, so you don't have to instrument tracking code every time your marketing team makes a data request or adds a new tool. But it's the business value that drives the purchasing decision. How is this data going to help your marketing teams deliver more personalized messages / build better customer segmentation?

In these split scenarios, the technical persona won't be the champion of the deal, but they can sure kill it because of lack of technical functionality / poor developer experience.

This is all dependent on the personas you're trying to target. In my opinion, your positioning should not change, but you should have messaging specific to your buyer and/or user personas, or those who will be influencing the purchase in a B2B context. For example, when we're talking about the breadth of offerings we have in Morningstar Direct for financial professionals, we need to ensure that we're addressing the overall business value to those execs who are making the decision to purchase our solutions for their entire enterprise, but we also need to ensure that we have more technical messaging for the IT and/or technology teams who may be integrating what we offer into their existing tech stack. This gets a little more tricky if you're marketing APIs for developers or others who could be more skeptical of marketing messaging without much detail. My recommendation would be to develop a messaging map that starts with your overall value proposition and then write variants on that for each of the different audiences who will be evaluating your products/solutions and then go test that messaging. As I mentioned before, I'm not much for jargon, but there may be certain aspects that you need to cover with a more technical audience - SOAP APIs? REST APIs? - and once you've convinced those audiences and they can report back to their exec teams that you know what you're talking about, that's a win. I see this need also showing up quite frequently in responding to RFPs. My recommendation here would be to gather up your last 10-20 RFPs, determine the similarities and develop your own sample RFPs to ensure you're covering off on the more technical messaging needs at scale (if indeed your audience's buying processes and needs are consistent).