Tune in for an in-depth chat about how companies can improve their revenue through fully understanding their open source project and software. Emily speaks truthful sense. This is a tough message for the overly optimistic among you. As Richard so rightly points out – knowing the right thing to do vs doing it are two different things!
Emily outlines the many, many ways a company can leverage open source in their offerings and is beautifully frank about source available vs open source… So where does DevRel come in to this? Well – unless a company has clearly identified its positioning, then how can DevRel communicate the benefits your project, service or product deliver?
You need the template – visit Emily’s website (link below) – to clearly define your company’s positioning.
Now with clear positioning, the first thing you should do is raise your prices…what? Crazy! But no. It’s a real and possible strategy.
Emily shares her background with us, and issues a warning about choosing journalism as a career…a good way to get comfortable with not having any money. Do not ask Emily to write a Kubernetes 101. She’s had quite enough of that, thank you very much. But the repeated requests did wake her up to the opportunity to help companies to take their messaging and positioning seriously.
Reach out to Emily Omier: https://www.linkedin.com/in/emilyomier/
Interview Intro
Richard Rodger: [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started.
Today I am speaking to Emily Omier, who helps startups get their open-source positioning right. It's a complex topic and something that is close to the heart of many people in developer relations. Because without the right positioning, without the right understanding of what your company is about, getting out there and speaking to your community in the right way, with the right message, is pretty much impossible. What Emily does, absolutely essential to the success of many companies, and especially those who base their business on open source. Alrighty, let's get stuck into an in-depth discussion. [0:00:55]
Main Interview
Emily Omier
Richard Rodger: [0:00:56] Emily, welcome. It is great to have you here today on the Voxgig podcast. You are an open-source consultant. What is that? [0:01:04]
Emily Omier: [0:01:05] Well, interestingly enough, when you put it like that, there's a couple different things it could mean. So, I'll start with what I do, which is, I help open-source startups, sometimes larger open-source companies, which I would define as any company that is very closely tied to an open-source project, i.e. their company wouldn’t exist without the open-source project.
I help them define their positioning, connect their positioning to their revenue model, improve their revenue streams or stream. Sometimes there's more than one; sometimes there's several. And make sure that they're connecting their open-source project to their commercial goals. So, that's what I do. Three's – but there's a lot of different kinds of open-source consultants out there. I would say I'm a positioning and revenue strategy consultant for open-source companies. [0:02:00]
Richard Rodger: [0:02:03] Can you explain the idea of positioning? It was something that I didn't even have a concept of until a few years ago, when I read – this author April Dunford wrote a really good book on it. What does it mean? [0:02:14]
Emily Omier: [0:02:14] Yes. She's the guru. [0:02:16]
Richard Rodger: [0:02:16] Yeah, totally.
Emily Omier: [0:02:17] Positioning, it's about controlling the assumptions that people are going to make about whatever it is that you're selling. And you can even think of positioning like – when you think of this on commercial terms. Where in the supermarket do you find an item, like if you're looking for baking soda? Baking soda is a project that you can use for a lot of different things. You can use it as a cleaning material; you can use it to scrub your sinks and stuff. You can use it as a deodorant; people shove it in their fridge to make it smell better. And then you can also use it as an ingredient to make cookies.
So, do you find baking soda in the cleaning aisle at the grocery store or do you find it in the baking aisle at the grocery store? That's a positioning decision. What assumption do you want people to be making about what they're supposed to use your product for and what's good or bad about it? You're going to make a lot of different assumptions. If you see baking soda, a box, sitting in the cleaning aisle, versus if you see it sitting in the baking aisle.
And then when it comes to software, it's the same. Any software that you have out there – well, maybe not any software, but most software – you could use in different ways. And often, what companies find is that the way that people actually use it out in the wild is not exactly how they intended it to be used. And sometimes, there's a use for this software that's actually way better and way more differentiated than what was originally intended. You want to capture that.
And the goal with getting your positioning right is that you're getting people to immediately understand what's your unique about your product or your project, if we're talking about an open-source context. How it's different from other options, why people should care, also who should care about it. And we talk about having tight positioning; that means that you're really specific about what this software is useful for.
And that's really important, because a lot of startups, they have this very grandiose vision about how they're going to change the world, and every single developer in the world is going to use this software. And the reality, first of all, is probably no software is going to be quite that ubiquitous. But also, you're a startup; you have $2 million in funding. And that seems like a lot of money until you start paying people salaries, and then you're like, "Shit, I better get some customers."
And the thing that's a little bit ironic is that when you say – the – if the message that you send out to the world is, I am appropriate for everyone, that's the same as saying, "I am awesome for no-one." But instead, if you send the message out that I am perfect – I'm the ideal solution for people who meet these very specific criteria."
Maybe there are only 1,000 of those people in the world, but that 1,000 people, for whom you meet exactly their specific needs, they're going to want to buy your product, or use your open-source project. But that's if we're talking commercial sense. If you meet their needs so well and nobody else is out there that's meeting their needs and you are speaking directly to these people, they will fork over money for your project or your product. [0:06:11]
Richard Rodger: [0:06:11] It's such a powerful idea; I was really taken with it. But it's so hard to put it into practice. Just knowing it is different from acting on it. I have a question around the customer focus of a company. Would you recommend a different strategy if the company – let's say they've bought into open source and they're using open source or their system is open source in some way.
But is there a difference between companies that focus on non-developer clients – it's a service, but it's not particularly used by developers – and those that are focused on developers. And do you see much open source in the first category or is it mostly confined to the developer focused companies? [0:07:00]
Emily Omier: [0:07:02] That is a really question. The companies that I work with, that I call open-source startups, they have an open-source project that's like – I like to think of it as the foundation of their company, as this open-source project. And their exact relationship and why this open-source project matter varies dramatically from company to company. But anyway, think of it as, they have this foundation of an open-source project.
And then they might have services that are on top of that open-source project; that might be how they generate revenue. They might have an enterprise distribution of this open-source project. They might have a cloud assisted – they might have a cloud-hosted SaaS of this open-source project, and that – those are the common revenue models.
There are open-source startups that have a developer market. Usually, people talk about those types of startups most, but there are also open-source startups that have a non-developer market; they both exist. I fundamentally think that when we're talking positioning in terms of what do they need to be worried about, the important thing is that they're an open-source startup, not whether or not they serve a developer market.
And the reason that I say that is because there's always going to be – even among developers, there's always going to be some developers who are interested in contributing to the open-source project and then others who aren't. Also, developers is a very broad category; you're still going to want to narrow it down dramatically to different types of developers.
And the – it's the fact that they're open source that adds the complexity, because you will always want to have the positioning for the open-source project and a positioning for the commercial offering that are different. You will always – even if the market for both is developers, there will always be a difference between who the market for the commercial offering and who the market for the open-source project is. [0:09:15]
Richard Rodger: [0:09:15] Different brands almost, right? [0:09:16]
Emily Omier: [0:09:18] I don't personally recommend different brands. There are some companies that do have a different brand name, an entirely different brand. I don't think you need a different brand; I don't think it's a good idea. But you have to be aware that the target market is different. The reason I don't recommend a different brand is because you still need an umbrella positioning for your company that holds everything together.
You still need to tell a coherent story about what your company does. Your company is going to have a point of view that's going to be pulling everything together. Ultimately, you're solving one problem, the same problem, and the open-source project is one way; it's one path that you can take to get to that solution. The cloud hosted or the commercial offerings are just other paths ultimately to solve the same problem. [0:10:14]
Richard Rodger: [0:10:16] How do you solve the challenge of credibility. Because let's say the open-source project and the product is something like a user interface framework. So, things like VIEWDIFY or Material UI come to mind, where you have – it's open source, but then you can buy training or you can buy extended components or whatever.
But at least for me, in the project, I'm still downloading the code. I still control everything, versus a scenario where the framework might be open source, but then there's a platform, a SaaS. And if you're buying into that open-source framework, you have to go with the commercial – the commercial hosted platform is the main way that things run. And I'm thinking things like Next.js and Vercel, maybe something like that. Isn't there an inherent tension there? How do you resolve that? [0:11:32]
Emily Omier: [0:11:35] There is an inherent tension in some way. The point is though that some people are going to want to use the open-source. They're going to want to use and be capable of using the pure open source. If that's not possible, you're not an open-source company.
It needs to be possible to – for somebody to solve their problem with the pure open source, totally anonymously, without giving you any information about themselves, without interaction with a salesperson or whatever, or without paying you any money. Those conditions have to be met; otherwise, you're not an open-source company. But at the same time… go ahead, sorry? [0:12:26]
Richard Rodger: [0:12:27] What do they call it? Source available, isn't it? That's another- [0:12:30]
Emily Omier: [0:12:30] Source available is not the same as open source. Source available is bullshit open source. [0:12:38]
Richard Rodger: [0:12:40] Exactly. So, how do you help the developer relations people in the companies that you work with? [0:12:48]
Emily Omier: [0:12:49] I consider developer relations as almost downstream of what I do. The developer relations people need to know what they're supposed to say. [0:12:58]
Richard Rodger: [0:12:59] The positioning.
Emily Omier: [0:13:00] That is what the positioning determines. Yeah. Positioning is everything from determining what the identity of your company, so the – at its core positioning, as when you say what is your – what is project X, how do you answer? You answer, "Project X is blah, blah, blah." Blah, blah, blah is your market category.
In the baking soda example, baking soda is a soda that you pour over your sink and use it to scrub off your dirty sink, versus baking soda is a leavening agent for your cookies. Two different positionings, and that's – I think of it – it's a now. That's – it's your market category that's the core of your marketing positioning.
There's other things that are circling around your position that are also really critical, that are also things that your developer relations people would need to be saying. There are things like, what is your company's point of view? Every company has a point of view. In an open-source context, oftentimes that point of view can include some technical things. This is another distinction, non-open-source companies versus open-source companies.
If you have a SaaS product and it's being sold to HR departments of companies, enterprises, those HR professionals, they do not give a damn about technical decisions you made. If you have an open-source company, regardless of who the target market is, people will care about your technical decisions and they will pick it apart. And you need to – part of your point of view, part of your story, needs to include: we think X, Y, Z programming language was the appropriate choice for this particular product, for example.
But there's other things that can go into point of view. So, we have a point of view about the market, about where the marketplace is heading, about tradeoffs that are or are not acceptable, about how humans actually behave. So, you need to have your point of view. You need to understand what pain points you solve; you need to understand what the competitive alternatives are, so not just competitive technology.
But for example, if you have a product and it's a compliance product, it allows you to comply with some laws. That the competitive alternative to using that software is often paying a fine. So, you have to be aware of that and talk about it. And if your pricing is such that it's dramatically more expensive than paying the fine, you don't have a business; people will just pay the fines. [0:16:05]
Richard Rodger: [0:16:06] One of the challenges people have working in developer relations is, often the company has not defined the positioning, and people are often thrown into the role and told, "Go organize a meetup. Write some blog posts, whatever. Get X many eyeballs." People find that very – people do find that very challenging. Do you think that's most companies? If I'm applying for a developer advocate role, should I be – should the question that I ask my interviewer be, "what is our positioning?" And if they cannot answer that, should I be thinking twice? [0:16:45]
Emily Omier: [0:16:47] It depends. Do you want to help them define their positioning? I was also going to say, yeah, if they haven't defined their positioning, you should tell their boss to hire me. [0:16:57]
Richard Rodger: [0:16:59] I have a really good friend, Emily; she told me- [0:17:01]
Emily Omier: [0:17:00] Exactly. But I do think it is a lot of companies. And another thing that can often happen is, the founder has a really clear idea in his or her head, but it only exists inside of their head. And- [0:17:20]
Richard Rodger: [0:17:20] Sounds familiar.
Emily Omier: [0:17:21] Yeah, exactly. This is a huge problem. And if that is the situation, the leadership needs to take some time and define the positioning and write it down. So, in my opinion, if you do not have a document that records your positioning, you do not have your positioning defined. You do not need to work with someone like me in order to get your positioning defined. Some people do find it very useful, but what you do need to have is positioning that's written down.
If there's somebody in a developer relations role who's listening to this and they're like, Yeah", my company is – they have no defined positioning whatsoever," the actionable thing that they can do is work with their leadership to get something written down. On my website, I have a sample positioning template, positioning canvas template that you can download.
And download that template; work with your leadership. Now I will say one caveat; this has to be CEO level. It's pretty core to companies' identity, so you do have to get access to the leadership of the company. But work with those people to fill out that positioning canvas and try and be as specific as possible.
The other thing is, we're talking about – as if there's just one developer relations person. What happens in practice is that there's five developer relations people and if those five people are going out and saying different things about your product, that's a problem. And then you have the CEO going on a podcast and telling – spreading a different message. And you're just confusing people in the market, and that's really frustrating; it's really frustrating and demoralizing for people inside the company. But it's also very confusing and it' a form of sabotage that companies don't even quite realize that they're doing to themselves. [0:19:35]
Richard Rodger: [0:19:38] It really is one of those almost secret weapons for a company to get very powerfully aligned on what the actual positioning is. You mentioned you have a template which is a worksheet, which is really cool. But when you go into a company – let's say they're realized – the CEO has realized that they're making a mess of it, or at least that they're not sharp enough, just walk us through your process. How do you sit down? How long does it take? What do you do? [0:20:09]
Emily Omier: [0:20:11] When we're working just on positioning versus when we're working on – I do just positioning and then I also a deep dive on revenue that's connecting the positioning to different revenue streams, adjusting how we think about those revenue streams so that we can hopefully make the – either make the company more profitable or, I should say, get it closer to profitability.
But when we're working just on positioning, then we do an eight-hour workshop that is spread over four days. I have a series of prompts that we work through with the leadership team of a company. And the kind of things we're thinking about is almost like a brainstorm of what are competitive alternatives. We'll start out with what is the positioning now? What are the competitive alternatives? What are the pain points?
So, thinking through all those things that exist are really important to define but exist on the periphery of the core positioning, which is that market category. And then at the very end of the process, we take into consideration everything that we've defined and try out a number of different market categories together, to see which one is causing us to make the right assumptions.
I would say it's part science, part art. But at the end, we get to something that's much more specific than what people came to me with, much more differentiated, which is the – that's the – those are the two things that I look for, something that's very specific and something that's absolutely differentiated; no-one else in the marketplace is doing it.
And then this one should be obvious but it's not always; it has to be accurate. So, that is a pitfall that I definitely see companies falling into when their positioning is misleading. Sometimes it can happen by accident, which is bad enough, but there are also times when it's not by accident, which is bad. [0:22:29]
Richard Rodger: [0:22:30] So, then is when – it's a little bit vaporware maybe or something like that, right? [0:22:33]
Emily Omier: [0:22:34] Sometimes it's not even that bad. It's – you want to make sure that the thing you are saying you're the best at, you are actually the best at. [0:22:43]
Richard Rodger: [0:22:43] Okay, gotcha. So, the actionable items out of your engagement are – so, the actual positioning statement; choosing the market category. And then the other one which I'm interested in is revenue. Because people – it's a huge subject of debate. How do you make money as an open-source company? Just walk us through that piece. How do you – how does the positioning connect to the revenue? [0:23:12]
Emily Omier: [0:23:14] That's a really good question. The first thing is, if you get your positioning right, you should almost certainly raise your prices. One of the biggest mistakes that I see a lot of open-source companies making is, open source is free. And there's this foundation in any open-source company that you have this open-source project that you're devoting a lot of resources to, which is free.
And a lot of open-source companies somehow get it into their mind that being inexpensive is one of the things that's really important. But if your positioning is good, the fact that you're – that there's this open-source project out there that's free to use should be completely irrelevant to your pricing. So, that's the first step.
And the second thing that your commercial offering should be priced in a way that reflects that it's the best at whatever it is it's the best at. And oftentimes, open-source companies are really hesitant to do that and possibly be the most expensive of the competitive alternatives. So, if your positioning is good, you have a solid differentiated value proposition, no reason that your prices can't be the most expensive in the marketplace. So, that's number one.
Second thing is getting really confident in how your market is. Let me rephrase that. Getting really specific in your different target markets and what they need, what's important to them. And what that allows you to do is understand what features you should be putting in your open-source project, what features you should be putting in your commercial offerings, but then also what features you should not be dedicating a lot of resources to.
So, if you have X, Y and Z features in your commercial offering, you do this positioning exercise; you determine that the values provided by features X and Y is super important to your customers. And that is – it's very valuable. But feature Z, nah, people don't really care about it. That means that you can deprioritize or perhaps even take out feature Z. That doesn't add to your revenue, but it can dramatically decrease costs.
And it can also mean that you're able to focus on those values that do matter to your target audience. And by doubling down on that, you become that much more valuable, which helps you get more customers, helps you become more entrenched in the customers that you do have. And that can definitely lead to increased revenue. [0:26:19]
Richard Rodger: [0:26:20] Okay. Yeah. There are a lot of – there's a lot of moving parts. I – yeah, I'd love to be a fly on the wall and see it in action. How on earth did you end up doing this? [0:26:34]
Emily Omier: [0:26:36] That is a good question. I never know how far back in the history of my life I should go back, because I'm almost 40. Which I still think of myself as young, but I guess I'm not that young anymore. I did a lot of random stuff when I was in my 20s; then I went to graduate school in journalism. And then I gradually discovered that that is a terrible way to make a living; I do not recommend it to anybody. I am, however, very skilled at making do with not very much money as a result.
Anyway, at a certain point, I decided that I sucked at making a living with journalism and do something else. And this is how I started writing for tech companies, doing marketing content. And that was really fun; I was really good at it. But I have – the problem we're talking about with the dev rel people was that often, I would find the companies I worked with had no idea what they wanted to say.
And this was very frustrating to me, because I was supposed to be saying something for them, and they couldn't give me any guidance about what it was. Or they would say – so, I ended up working for a lot of companies in the cloud native and Kubernetes ecosystem. And after I was – the third time someone asked me to write a Kubernetes 101 piece, I was like, "Forget it. This is ridiculous." I never wanted to write another Kubernetes 101. [0:28:17]
But I did start gradually moving up the food chain, shall we say, because it was like, well, clearly, you need more help than just somebody to pound out some marketing content. You need to figure out what you want to say first. And that led to working on messaging, and then positioning is one level up from messaging.
If you think of messaging as primarily affecting the marketing department, but positioning, as I was just outlining, it's not just marketing; it's your project roadmap. It's your – what your sales motion looks like. It's including, are we doing a bottoms-up strategy; are we doing a top-down strategy? What's our outline look like etc.? So, it's – completely impacts your sales strategy completely impacts your marketing, and also your – all these business fundamentals like your revenue strategy etc.
And so, that's how I got to doing where I am now. I came into working with open-source startups through the Kubernetes ecosystem. First, I had been doing marketing for Kubernetes companies, and there's a lot of open source in the cloud native ecosystem. And then I started working on the messaging and positioning.
And I realized that as I started working on positioning, the key difference in what the process looked like and what the complexities looked like wasn't that they were in the open – or it wasn't that they were in cloud native companies; it was whether or not they were open source. And so, that's what I started to focus on.
Now I work with any open-source company, including those that, like I mentioned are – have products and projects that are not actually for a developer audience at all. But I think that the complexities of positioning and the complexities of building a revenue model are unique to open-source, rather than being unique to say, a product for Kubernetes engineers. [0:30:32]
Richard Rodger: [0:30:33] Emily, that's a fascinating life journey into this stuff. We're almost out of time. I've one final question, and maybe you have some insight into this, given that you're probably talking to a lot of companies. Why now? Why is it becoming such a thing, so many software companies are choosing this open-source path now? [0:31:00]
Emily Omier: [0:31:03] This is a good question. Why are they? There's some people out there who say open source is eating the world, but I'm going to say that there's two reasons why companies choose to be open-source companies. So, reason number one is a bad reason and that' s because they see everyone else doing it and they think everyone else is doing this and so I should do this too.
Reason number two is a good reason, which is that they see concrete business rationale for being an open-source company. So, obviously, like I said, I do not think "Everyone else is doing it so I should too" is a good reason. That's definitely up there; I've definitely seen that. But let's talk about that second one.
As a generalization, there's a couple of business values that being open source can bring to your company and it depends. Every open-source company does not get these same values. One of them is around transparency; this is not talked about enough. There are some markets where transparency is super-important.
And if you're able to say, "Look, I know that privacy is really important to you, Mr and Mrs Customer. I know that you don't want to just trust us; you want to be able to verify. Here's our source code- you can verify for yourself that we meet your privacy requirements. We're not" –And if we're talking about privacy – if somebody puts – if you have black box codes, you can't know for sure. Maybe there's a call home function in it or something; you don't know for sure. But if you can inspect that code yourself, you can say, "I'm really confident that this is not doing anything that it's not supposed to."
So, that is incredibly important for a lot of markets. I think that that's not talked about enough in the open-source business world, because it's almost like the open source – in that scenario, open-source is in a growth engine. It's something that helps you reassure your customers, but can still – that can be really powerful. That's – just having that transparency means deals close a lot faster. You've eliminated a really common and really strong objection to people buying your software. So, transparency is one, again generalizable for a lot of open-source companies.
Another thing is that open source could be their go-to market motion. You have to tread a little bit lightly with this, because treating your open-source community like a bunch of leads is a very bad idea. But certainly, especially if your play is, we want to become the number one most used default for – of ex-technology, the way that you do that is by being open-source and getting every developer who has to do whatever it is that you do to use your software, to use your project.
Now you do have to make sure in that case that you have a business model. There are examples of companies that have been successful in having their technology used absolutely worldwide, and have still struggled to build a commercial model, to build revenue. But that's certainly another reason; they see the open source as a growth engine for building the company.
I would, even if you don't intend your project to be the absolute market leader in whatever it is that you do, there's a lot of companies that see open source as an awareness play, part of their – of a bottoms-up go to market strategy. So, I think those are really two of them. [0:35:27]
Richard Rodger: [0:35:29] Lot of – there's a lot of stuff to think about from this one. Thank you so much. This has been very interesting. It affects us personally because we do a bit of open-source, but I can certainly see parallels to other situations I've been in, customers that we work with. Lots to think about. Thank you so much. Super interesting. [0:35:51]
Emily Omier: [0:35:52] Thank you for having me on the podcast. [0:35:53]
Richard Rodger: [0:35:54] Wonderful. Okay. Take care. [0:35:55]
Emily Omier: [0:35:56] Yes, you too.
Endnote
Richard Rodger: [0:35:57] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:36:24]