The reality is that the industry is talking about AI, much more than it’s building AI. This is because it’s complicated, it’s moving really fast, and let’s be honest pushing a model to production takes a ton of trust … afterall, what if this thing goes completely rogue on you?

Being able to lean on a vendor like OpenAI, that has a seemingly infinite budget for AI talent, is a move that ensures you can sleep at night (when your AI support bot isn’t).

This is good for simple tasks, like the one I mentioned above … connecting your documentation and support data to a GPT for a 24/7 support chat bot. This all changes when you start talking about data that can’t be found by a determined googler on a support forum. The type of data that if your competitor found could cause irreparable damage, or data that if exposed violates regulations and leads to massive fines (think HIPAA). Do you really want to push that over to OpenAI or any other SaaS vendor?

The answer is NO–and this is where on-prem comes into play.

Shifting from Impressing to Impacting

When AI came onto the scene, everyone jumped on it. That AI support bot I mentioned above was viewed as proof that your company was ahead of the AI-native learning curve … a real leader. It was impressive, but outside of customer support efficiency gains (which I just googled and found are really hard to actually prove), it’s not really that impactful.

The real impact of AI is going to emerge when it has access to proprietary business data at scale, and for this it needs to go on-prem.

Security, Security, Security

If Steve Ballmer was still dancing around at Microsoft he almost certainly would evolve his iconic chant from “Developers!, Developers!, Developers!” to “Security!, Security!, Security!” … besides with Cursor, you only need a few of them right?

This is where open source comes back into view. For on-prem to be a valid move, you need a model that can be deployed on-prem. In the past these models were built internally, largely by research and investment firms, who had a real business need for AI.

Now, everyone has a real business need for AI (at least that’s what the board wants to hear), and talent is hard to come by. And open source makes this accessible to all (more on the relationship between open source and enterprise growth).

Great, I Have a Model, Now What?

“If you build it, they will struggle to deploy it” –Kubernetes

The model is only one part of the equation. To this point, most teams are either trying to shove it through their existing pipeline or building an AI specific pipeline to run in parallel. The problem with this is that existing pipelines lack the orchestration and governance capabilities that are required by AI/ML. They’re also not friendly to your peers on the data science side of the house, who have a completely different set of tools. On the other hand, building an AI specific pipeline means moving away from the best practices and workflows that you’ve put in place for your app code.

Making On-Prem, Open Source ML Attainable

This is where solutions like Jozu come in. Jozu originated out of our own struggles with ML development and deployment (read more about this journey). The same struggles that were faced by developers pre-Docker. AI/ML is unique and needs use case specific tools, however, we don’t need to reinvent the wheel, we just need a different type of wheel.

Containers solved the “it works on my machine” problem, and though you can use a tool like Docker (and many do) to package up your ML project, it’s not optimized for the ML use case.

Sticking with our wheel analogy, you could think of the Open Container Initiative (OCI) as a rubber circle. It’s the foundation of what we call a tire. Docker would be your typical Goodyear all weather tire that should be on 90% of all road vehicles, because it just works. ML on the other hand, is not a road vehicle, it’s a F1 car. Your Goodyears will allow it to roll forward, but you’re not getting anywhere near the performance you should be getting.

This is why we built (and open sourced) KitOps ModelKits. ModelKits are the container type that are purpose built for AI/ML (learn about our journey from initial traction to product-market fit). The key thing here is that they are still a container type based on the same standard that Docker and Kubernetes are. This should dispel the misconception that we’re trying to create a whole new ecosystem/standard. In fact, because ModelKits are in the OCI family, they are compatible with your existing pipelines … anywhere you can put a Docker container, you can put a ModelKit.

But, that’s not where it ends. ModelKits make it easy to package up and deploy your open source models, but how do you govern them on-prem?

This is where Jozu comes in. At the very basic level, Jozu can be looked at as an on-prem Hugging Face. It’s where your open source model lives and is versioned. It gives your team the tools they need to work with ModelKits very efficiently, surfacing version diffs, allowing rollbacks, packaging inference, signing, audit logging, and much more.

Maybe more importantly, it adds the governance layer into your workflow that provides you and your team with the confidence you need to deploy models at scale. And, best of all, it lives on-prem. Jozu was built to enable the next wave of AI innovation, the one that will take place securely behind your firewall and lead to the massive business impact we’ve all been expecting.

Learn more about KitOps and Jozu to see how they can help your organization deploy AI/ML models securely on-premises.

The Search for Product-Market Fit in a Sea of Possibilities

Up to this point, our focus has been on building KitOps and creating the platform to manage ModelKits—the open source ML artifacts our team pioneered. But here’s the thing: having great technology and knowing exactly what to do with it are two very different challenges.

When you start with open source, especially in the rapidly evolving ML space, the possibilities feel endless. Every day brings new problems that need solving, and it’s tempting to try to address them all. The danger? You end up with a product that halfway solves a bunch of problems, but none well enough that anyone would actually pay for it.

This is the reality of searching for product-market fit. In a perfect world, there’s a single, obvious problem with a clear solution for a well-defined audience. In reality, PMF usually looks like stumbling around in a dark room trying to find a light switch—except you don’t know which wall it’s on.

But here’s what makes it even trickier: PMF is relative. Thousands of developer tools achieve what many would consider market fit for specific problems and specific groups of developers. The catch? The market is often too small or unwilling to pay, making the business unviable despite the technical success.

With KitOps ModelKits, we faced this exact crossroads. We could lean into the developer space where tools like Docker and Hugging Face are playing, or target the operations/infrastructure/platform space where the market is less defined but certainly being eyed by major vendors.

100K Installs: The Power of Focused Iteration

When we first started, we were 100% focused on KitOps. We knew the core idea was solid, but we had no idea who would use it or what specific features would matter most. We got just enough right to drive a modest number of downloads, then used each iteration to focus ourselves a bit more.

The result? In just over a year, we’ve broken 100,000 installs.

Jozu tells a different story. Our product is less than a quarter old, and until recently, we’ve been addressing two key areas: speed to production and security. We knew both were enterprise pain points, but we were still figuring out which one deserved our full attention.

The Tradeshow Test: When Reality Meets Strategy

In April, we took our speed messaging to KubeCon EU. If I’m being honest, the results were less than exciting. It’s hard to pinpoint exactly why some messages don’t land—maybe it was EU regulations, maybe we were too deep in the open source space, or maybe it was simply a message-audience misalignment.

But here’s why I love tradeshows: they offer quick feedback loops, exposure to different personas and industries, and the ability to rapidly test different messages. Which is exactly what we did next.

A few weeks later at Red Hat Summit, we had our second chance. This time, we leaned into our security messaging—and the response was night and day. By the end of the week, we had just enough data points to be dangerous: a clear target persona, specific industries we could easily reach, and a handful of really strong leads.

Finding the Courage to Commit

At some point, every startup faces a critical decision: you have to commit to going deep and establish yourself as the solution for the problem. Without this focus, you’ll struggle to command premium pricing and find it nearly impossible to scale your go-to-market activities.

For us, this means going all in on the security side of DevOps for ML.

It’s scary to narrow your focus when you know your technology could solve multiple problems. But that’s exactly what product-market fit requires—the courage to say no to good opportunities so you can say yes to the great one.

The 100,000 installs of KitOps proved we could build something people want. Now, with Jozu, we’re proving we can build something enterprises will pay for. And sometimes, that’s the difference between a successful open source project and a sustainable business.

Get Started

Ready to explore ModelKits for your own AI/ML projects? Check out our getting started guide or try Jozu Hub for a ModelKit-first registry experience. Join our community on Discord to connect with other developers building the future of MLOps.

The journey from open source project to product-market fit isn’t linear, but every stumble teaches you something valuable about your customers, your market, and yourself. The key is listening closely enough to hear what the market is telling you—even when it’s not what you expected to hear.

Early in my tech career I read a post from a founder that had managed to build a highly-engaged community. This was back in the Seth Godin days, so I’m sure we called it a niche … anyway, in the post they pointed out that there is a tipping point in community engagement, which happened when you reached 100-fans. To be clear, a fan is not a community member. A fan is someone who loves your product so much that they give you free promotion. Today we call these champions, and they aren’t only important for community growth, but key to selling your product.

KitOps is currently being used in product by multiple enterprises. The KitOps value is clear.

When we were at KubeCon EU last month we observed that if you aren’t using KitOps, you’re not really versioning your ML project. When you say this aloud, it feels like a massive stretch. In fact, most of the developers I spoke to argued the point, insisting that their current stack has versioning, and to that point they are correct. BUT, there’s a big problem, all of these tools version independently. The data is versioned in DvC or S3, the code in GitHub, the model in Jupyter, the tuning in MLFlow, etc. These tools are excellent at what they do, but when I asked how they kept track of all these different versions, the answer was …. A SPREADSHEET!

For me, it’s music to my ears. After all, the best startups build software that replaces a spreadsheet right?!

But that’s not all, replacing spreadsheets is only one reason ML teams love KitOps. The second is eliminating vendor lock-in.

Vendor lock-in is an interesting problem to focus on. I’ve worked at Red Hat and AWS, so I’ve argued both sides of the vendor lock-in conversation. I’ll be honest here, when it comes to how to run your cloud-workloads, going all in on a single vendor is a better choice for 90% of companies, and the other one is really just selling FUD. The idea that a cloud-vendor is going to randomly hike prices way above the market is unrealistic, compute cost is a race to the bottom.

However, when it comes to AI workloads the race is happening incredibly fast … like cut your costs in half overnight fast. This is where the vendor lock-in conversation comes back into view, but from a different angle. Enterprises want the ability to quickly migrate to the cloud provider that can give them the cheapest compute cost for their ML workloads–something that changes on a weekly basis.

We pioneered ML project adoption of the OCI (Open Container Initiative)

When we created ModelKits, we chose the OCI because reinventing the wheel is a waste of time. OCI artifacts seem to have been (unintentionally?) built to perfectly suit ML projects. Initially, our goal was just to eliminate the pain of re-packaging our ML projects from one vendor specific package type to the other … not fun. As we engaged with other teams, we realized that others were thinking about this same thing, which led to contributing KitOps to the CNCF and leading the creation of the ModelPack spec, the Cloud Native Artificial Intelligence Model Format Specification, which establishes open standards for packaging, distributing and running AI artifacts in the cloud-native environment. We’re currently going through the voting process, so fingers crossed the ModelPack spec becomes the defacto standard.

Keep in mind, open source software doesn't pay the bills

As a founder building an open source software, it’s easy to become disillusioned. At the end of the day 85K open source installs means nothing for our bottomline. This is where Jozu comes in. How do you take something that in its organic form is valuable and create a product that amplifies that value 100x?

I live in a small town in rural Virginia, that is about 50-miles outside of Washington DC. On Main St. we have a little bakery that is known for its amazing apple pie. The walls are covered with pictures of important people and foodie magazine articles featuring their pastries. When Thanksgiving comes around, an apple pie will cost you around $40, but only if you get your order in few months early. You can think of open source in the same way. Apples are valuable by themselves, but when you put that apple inside of the right wrapper (in this case a pastry from The Red Truck Bakery), the value increases exponentially.

I like to think about ModelKits like apples and Jozu like the fully baked apple pie. You could take your ModelKit and host it in any OCI compatible registry, that’s the beauty of open source. But when you use Jozu Hub, you can extract the full potential of that ModelKit.

What exactly does Jozu add?

Let’s start with versioning (since I mentioned it already). ModelKits are immutable and therefore versionable, but versioning in itself needs to take place somewhere. Additionally, ModelKits are signable, which also needs to take place somewhere, and let’s not forget the ModelKit’s rich meta data. You could push your ModelKit to Docker Hub or Artifactory, but since they weren’t created for ML projects, they don’t display the information that ML teams require to speed up their development process (by over 45% to be exact!)

We also add things like Hugging Face (HF) import, which allows you to easily curate a catalogue of HF models for your team, model scanning, to ensure that the model you pulled from HF is safe to use, an audit log which automated the tracking of all actions taken against the project, and inference to get your project to production quickly.

These are things that are easy to say, but hard to do. For example, when we talk to customers, audit logging typically takes a team of 2 developers, one week per quarter to complete … you heard that right 8-weeks of developer time annually!

Then there’s inference. If you think Kubernetes is hard, try going from a Jupyter Notebook to a Kubernetes production environment, I bet you couldn’t even say that 10x over without confusing yourself, much less actually do it.

If we could only get one ...

This brings me to the current focus on my founder journey. Enterprise sales.

I’ve spent a lot of time in the tech world, but I’ve never been in sales. Like all things we’re approaching it from a trial and error standpoint, while gathering as much advice from smart people as possible. I find that the biggest challenge is getting in front of the right person. Developers love KitOps and Jozu, but developers aren’t buyers. And, the path from an individual developer to a C-level decision maker is incredibly long, and if I’m honest a bit wishful.

This is the challenge that I’m working on solving right now. How do we create a replicable process for finding CXOs with an initiative that aligns to the benefits that Jozu Hub offers? I’ll let you know when we figure it out.

As always onwards and upwards!

/jw

This comes down to the simple fact that everyone wants to move quickly. We look for week-over-week gains, and when those gains plateau it can be increadibly discouraging. Ironcially, you quikcly come to realize that the entire game we play is comprised of making incremental gains, reaching a plateau, then figuring out another strategy to make more incremental gains. If you can repeat this process for a few years, you’re likely to reach some sort of exit or growth flywheel.

For the sake of simplicity let’s call this repetition (incremental gain, plateau, more incremental gains) the founding cycle. In my experience the most difficult part of the founding cycle (assuming that you have built the personal discipline to stick with someting for a LONG period of time) is manufacturing the transition from plateau back to incremental gains … and, the more times you repeat this cycle the harder it becomes.

Why? Think about it like this. When you start a project, your first few months can be spent on doing things that are considered tablestakes. You’re creating a website, social profiles, blog posts, google ads, warm outreach, etc. If done right, these things will allow you to see months of incremental growth.

The issues begin when the returns of your activities begin diminishing. Remember our goal is to see incremenal growth week-over-week, so the impact of something like a post on X will be lower as time progresses. Eventually, you’ll discover that each platform has a tipping point where your activities get throttled or your audience tunes you out. When this happens, you’ve reached your first iteration of the founder cycle. Congratulations, you’ve plateaued!

Nailing the transition

If you’re anything like me, this plateau means a few sleepless nights and a few over caffinated days of ideation. Moving forward means you’ll need to solve three problems,

1. How do you automate the activities you’re already doing?
2. How do you make room for trying out new activities?
3. What are the new activities you are going to try?

Automating the activities you’re already doing–This is one of the most important steps. If you get this wrong, you lose all of the momentum and impact you’ve worked so hard to create. Your goal here should be to layer activites on top of the existing activities. You can do this in a few ways, first, you can figure out ways to automate the activity. An example of this is automatically posting on social channels when you publish a blog. Another way to do this is to had the task off to a contractor who can do it for a fraction of the cost and time. For venture backed founders, this is generally the best path to pursue. It requires (over) documenting the exact processs, finding competent talent, and communicating the desired outcomes.

Make room for new activities–As you progress through your founder cycle, you will try a lot of things. Some of those activities will have larger impact than others … it’s the classic 80/20 rule. When you hit your plateau it’s time to evaluate your activities, identify the ones that have the biggest impact, and squash the ones that aren’t generating impact (or as much impact). This will make room for you to try new things.

Find new activities to test–This is by far the hardest part. To start, you can simply look at other players in your category or companies targeting the same audience and try out things they are doing, though you’ll eventually run out of things to steal. When you do, you have to get creative. I’ve found that the best way to do this is to work backwards from a very specific outcome. But, be careful, if you get too ‘high-level’ you’ll run out of ideas quickly. I like to start by breaking down the steps in a converion path. The first step might be to get visitors to your website … more specifically visitors from organic search. This is where you can start getting creative. For this example, you might begin investing in Reddit, since Reddit threads are now ranking highly on Google SERPS.

How you navigate the founder cycle is up to you, but one thing I can say is that establishing a repetable way to approach it is key.

I hope you find this helpful,

/jw

Most of the time, when I talk with other founders, they just assume that the key was some really good demand gen strategies, or if you’re old enough to remember the trend, ‘growth hacks.’ To be transparent, yes, demand gen strategies played a role, but (and this is a big but) demand gen is not the driving factor behind these successes. Instead, it’s something that is usually overlooked by early-stage founders: messaging.

When I compare these three companies and the activities that led to usage and adoption, messaging was the catalyst that got the adoption ball rolling.

For example, when we launched YouCaring, there were a handful of platforms in our space. There was Kickstarter for business ideas, GoFundMe for personal expenses, and a bunch of little players that I can’t even remember. All of them positioned themselves in their own way. Kickstarter was “funding and following creativity,” and GoFundMe was “raising money online” and had just started using the term “crowdfunding.” By mid-2013, everyone was a crowdfunding platform, and no one outside of the industry knew what that actually was. Most of our fundraisers were for medical expenses and funeral expenses, things that just don’t happen very often, meaning our user was almost always a first-time user.

Instead of going in the same direction as everyone else (crowdfunding for xyz), we simplified it and just called it “free online fundraising,” and as it turns out, that’s exactly what average Joes and Janes were googling.

Codenvy, on the other hand, was a bit different. Codenvy was way earlier and way more technical than YouCaring and only had a few competitors. Codenvy’s challenge was that no one knew what it was, understood the underlying technology, or was actively looking for a solution to the problem. It started as “an industrial cloud IDE,” but we hit our stride when we simplified to “on-demand developer workspaces,” and really found traction when we used “Cloud workspaces for dev teams.”

What was the trick?

Messaging to the masses

I don’t know about you, but sophistication feels sexy. Big words make you feel smart. Creating categories has the appeal of innovation.

The problem is that sophistication is confusing to the average user, big words aren’t usually used in a simple Google search, and it takes years for a made-up category to become common knowledge. When you create messaging like this, you take your already small ICP and cut it down by 80% or more.

When most founders or early marketing hires create messaging, they target a subsegment of users called early adopters. Early adopters are unique: they are aware and educated about the problem you’re solving or solution you’ve created, they are actively looking, and most of all, they care deeply. Because they are the ones finding you, there’s a temptation to create messaging targeted at this persona.

This is a big mistake. Growth comes from messaging to the masses.

A few tips for pulling this off

First, when you’re creating messaging, focus on an audience that is not aware or educated. This means that they might group you into a category of tools that you don’t really fit into. At this stage, your goal isn’t to reeducate them; instead, your goal is to figure out what they are searching for and communicate your ability to solve their problems.

Second, oversimplify your messaging. Oftentimes I’ll hear a founder describe their product and then say, “it’s basically just x for y.” If you have to draw that comparison, your messaging is too complex (and you should just use that comparison!). Early adopters might use more specific terminology, but keep in mind that they understand your solution well enough that simplified messaging will work on them as well.

Finally, stay away from industry-specific terminology. Don’t use an acronym if it’s not well adopted, don’t use a category if it’s not established, and stay away from stringing lines together that no one else is. Keep your messaging honest; if you’re just starting off, you probably aren’t “the fastest browser on iOS,” “the last revenue SaaS you’ll ever need,” or “the most trusted way to secure your data.”

I hope you find this helpful,

/jw

All that to say, I’m long over due for an update here, not to mention a face lift for this site, which I hope you like :)

I climbed the ladder and I cannonballed off

The past few years have been full of ups and downs, a sign that I’m still alive?

I weathered the chaios of the pandemic and tech’s great resignation at AWS, which was an absolute joy. AWS is a machine, it exposed me to some of the smartest people I’ve ever worked with, pushed me to raise the bar with my own deffinition of excellence, and gave me the opportunitiy to contribute to and lead a few really big projects. Some of the highlights include working on repositioning AWS in the DevOps category alongside Emily Freeman and now MongoDB CMO, Peder Ulander, leading the messaging for GitOps and IaC at AWS, and bringing Kubernetes and containers into the Serverless EDA messaging and positioning, which ended up being a focal point for Werner Vogel’s 2022 reInvent keynote.

Success at a company like AWS opens a lot of doors, for me that was a VP role at Docker. Docker is one of the most loved and used developer tools. When I was getting started in tech it seemed like every week there was a Tech Crunch article covering their innovation, partnerships, heck even their jungle like offices in SF. Unfortunately that version of Docker (focused on Docker Enterprise) didn’t pan out and a small team rebuilt the company around Docker Desktop.

There are a lot of questions around the company, how they participated in open source, how they price, etc. But what you can’t question is the value they bring to developers. When I joined Docker they had secured a $102M investment at a $2.1B valuation. They were a little over $50M in ARR on a crazy trajectory to $100M, and by the time I left had surpassed that number by quite a bit.

I saw the role at Docker as a opportunity to roll my sleves up at a company that had everythign going for it, or so I thought. The thing about companies is that they are a lot like people, you have to do life with them to really know who they are and what they are about. It didn’t take long to discover we weren’t a match and thought I had built a killer team that was just hitting their stride, we decided to part ways.

When one door closes ... you know the rest

My roots are in the startup space. When I think back on my most enjoyable work memories they are with early stage companies. Companies where I was playing a pivotal role on a small and dedicated team who was determined to change one little part of the world. It’s not for everyone, but something about risking it all for the chance of a big win puts a smile on my face and some pep in my step.

Before leaving Docker I had begun playing with the idea of templatizing my method for creating product messaging and positioning. Leaving Docker gave me the time I needed to put pen to paper and what resulted was what I call the Stori Messaging and Positioning Framework. I worked with my now co-founder to pitch it to a few companies and what do you know, people wanted to buy it. Even more exciting was that it led to some really great results in a very short amount of time. This led to the birth of https://gostori.com which now works with PE and VC firms to help their portcos communicate value and differentiate from the competition. We take on a limited number of projects and work with founding teams who are highly invested in developing messaging (and who we actually like.)

The cherry on top for this season was a serindipitous co-founding of a software startup called Jozu, which is built on open source KitOps.

It all started the CEO of Jozu (someone who I’ve spent most of my career working with and for) reached out to see if I wanted to help lead marketing and operations for his incubation funded project. At the time the project (maybe more of an idea in progress) was a marketing analytics tool for APIs and machine to machine interactions. Having spent some time in the very crowded and competitive GTM software space I knew exactly what I was getting myself into and was a bit concerned.

Eventually my concerns were brought up by other members of the team and we ultimately decided to pivot. This led to the creation of KitOps our open source MLOps tool. We built KitOps to solve a problem that we were feeling internally at Jozu, which was how to handoff models from a data scientist to a software development team and then to a DevOps/SRE team, more on that here. Then turn Jozu into a Hub for KitOps ModelKits, our OCI-compliant package for AI/ML projects.

Long story short, I’m now the co-founder of two companies, one in the services space and one in the software space. I spend a lot of time on the software side of things which is very much a passion project for me. When I’m not doing that I enjoy working with other founders to uncover the value of their products, communicate their product vision, and build a more differentiated message for their GTM efforts.

Is it a lot, sure. But I’ve always been someone who’s had a side project, heck for most of my career I’ve flipped houses in my spare time. Ultimately, when you work on things you love with peolpe you guenuinly like and care about the day just seems to fly past.

A recent podcast with Dr. Benjamin Hardy mentioned a study on stress. The study showed that how you view a stressful situation will determine if the stress of that situation has a positive or negative impact on your physical and mental well being.

There are many reasons why we feel stress in a business context. Most of the time it’s because there is a problem we are facing.

Or is it? The thing about problems, is that they are really just situations. I’m reminded of the saying, “The problem, is what you make it.”

Maybe it’s better to say “The problem is how you define problems?”

For me, problems are rare. This is because I define problems as a situation that has no possibility of reaching a positive outcome.

If you think about it, there are very few of these situations, in which case, what you are facing is simply a challenge.

Challenges are good. They force us to rise to the occasion, to overcome, to innovate, and to win.

The challenge is what makes business a game worth playing, something you love to do, something you’re proud of.

The trick … disassociate your job or career with life and death. I know what you’re thinking “LIFE and DEATH!? Who associates their job with that!”

Anyone who’s afraid to lose their job because they need a paycheck to buy food and pay rent/mortgages.

Needing a paycheck isn’t a bad thing, we go to work to provide for our families. An inherently noble act.

An act that most of us need to perform over the duration of a +40-year career. That’s an incredibly long time if all you do is struggle with fake problems.

Balancing output and outcome is one of the biggest challenges I’ve faced as a leader. There is a tension between the two and trying to balance which one you prioritize for often leads to achieving neither.

A few years ago, Elon Musk became famous for sleeping on the production line floor. He had a clear reason, Tesla needed to improve its output. Tesla’s biggest risk wasn’t how well their cars performed, instead the risk was that they didn’t have the ability to produce enough cars to perform.

Knowing when to sleep on the production line floor, is all about knowing when to build and when to optimize. There are seasons where you and your team need to deliver, and in those seasons output is the priority. There will also be seasons where your team needs to improve outcomes–a season that almost always follows a season of output.

The key to successfully navigating these seasons comes down to three things: 1/ Know when you should sleep on the production line floor. As a leader you can’t live there, it’s not practical and is a massive disruption to your team, chose wisely. 2/ Know how/where to sleep on the production line floor. Most of us don’t have an actual production line, meaning we are interjecting ourselves into a virtual process. How you do that will determine the ability to achieve your outcome. Find a place where you can observe everything without it actually being known. Then take the time to inject small optimizations and solve small problems. 3/ Know the goal, and when it’s accomplished, go home.

It’s been a few months since I last published a post on developer marketing. I’ve been busy with the holidays, a new role at AWS, not to mention life beginning to slowly return to normal (kids going back to school, people working vs doom scrolling all day, trying to burn that quarantine fifteen … you get it). I’ve also been mentally wrestling with a few changes that I’ve observed taking place in the developer tools space. We’ve heard it said many times that COVID accelerated key business trends like cloud adoption, remote working, and online learning. When the dust settles, I think that we’re going to realize that a lot more has changed, in fact it’s hard to believe that anything was completely un-impacted. Developer marketing, open source community building, and technical product marketing for dev tools is no exception. I think an argument could easily be made that our space was one of the more impacted areas and that the transitions we’ve seen from COVID are going to increase the scope of our space. In this post, I want to share a trend that I’m seeing develop between open source and the enterprise.

Last year I wrote a lot about the open source business model and developer marketing strategies, but what I didn’t hit on was the somewhat (maybe extremely?) symbiotic relationship between the two of them. For context, this post was inspired by two recent conversations with founders bringing products to market with an open source strategy. Our conversations center around how to maintain a balanced focus on both and ensure that both the project and the product are jointly successful. I find that this is always a point of tension, but it doesn’t need to be that way. Open source feels complex, but in reality, it’s not. Companies have been doing this successfully for decades now, but never at the level that we see it today. Open source projects have become dependent on the enterprise to fund their existence and the enterprise has become dependent on open source to champion industry standards and lower the barriers and cost of building new software. When we look at the growth of these joint strategies, the relationship is nothing less than jointly exhaustive. I can’t emphasize this enough, open source marketing/community building is demand gen for the enterprise, and demand gen for the enterprise is open source marketing/community building.

Open source has been skyrocketing in popularity lately, which amplifies the trend above due to competition and crowding in the space. Just a few years ago it wasn’t normal for a startup to open source their codebase, now it’s hard to find one in our space that hasn’t. Why? I think that there are a few reasons for this. Some are completely legitimate and others I can’t see as anything more than a corporate virtue signal. Let’s start by looking at why companies are open sourcing in regards to growth.

I’ve found that there are three main reasons, 1) awareness with developers (a.k.a. the end user). This is generally well intentioned, open source foundations are trusted by developers and developers flock to open source communities to find innovation and learn. By open sourcing your product you gain access to all of those developers who if interested might even help you advance your project. This is the open source world at its best. 2) Pursuing an industry standard. If your goal is to build an ecosystem around your project or you can benefit from the industry as a whole adopting your project, open source is the way to go. This strategy allows you to easily partner with other companies and tie your growth to their growth. This is the win:win open source utopia that companies often envision when exploring open source as a strategy … that is until someone bases a competitive solution on the project you pioneered. This is both the best and in a few cases the worst of the open source world. 3) Nothing but optics. Every now and then I talk to someone who open sourced a product for all the wrong reasons. They wanted to attract and retain employees, they wanted to be associated with a popular foundation, or they wanted to land a big deal that had open source in the criteria. This almost never works and is one of the reasons that there are so many dead projects out there. Open source is about the community and optics don’t build community … it’s not authentic.

If your reasoning is based on point 1 or 2, there is a very good chance that open sourcing will positively benefit the growth of your company. But, you can’t just open source and walk away. Remember the statement that I made above, open source marketing/community building is demand gen for the enterprise and demand gen for the enterprise is open source marketing/community building. The strategy only works when it has a healthy open source community to build upon. This is where the enterprise becomes really important. The enterprise has resources and open source projects need resources (developers, audiences, customers, MONEY). If you look at any of the top open source projects, the main contributors are developers who are employed by the enterprise for the purpose of contributing to these projects (if you’re curious about how they stack up, here’s the rankings). This gives the project a healthy baseline, meaning that it’s not growing stagnant. These enterprises then advocate for the project, which attracts individual contributors, forming a community. The enterprise also sponsor the foundation where the project lives which funds the things we never talk about but make a big difference, like project branding, an advisory board, community events, and foundation management.

Healthy projects have thriving communities and communities create awareness. Awareness of the upstream project creates awareness of the downstream product. And, vice versa product growth puts attention on the project, the more customers your product has the more invested they will be in the health of the upstream project.

Few topics raise tensions in a marketing org like bringing up the developer database. Sales teams need leads to follow up on and marketing needs to hit numbers to satisfy the sales team’s quota. For developer marketing teams, that often times means living outside of the good graces of the broader revenue org. In this post I’m going to talk about a few ways to build an internal understanding of the importance of a dedicated developer database and why protecting the developer database is key.

Before we dive into it, if you don’t understand the developer buying journey, I would encourage you to check out the three-part series that I wrote on the developer buying journey last year. The series covers the developer buying journey, the role of open source and developer communities, and finally developers and BANT/the sales process. If you are new to dev marketing, it’s a great place to start.

Why building a developer database is important

It’s important to understand that enterprise sales is comprised of two main personas, decision makers and end users. When you look at how decision makers interact with a technical sales cycle, they tend to assume a cyclical relationship. They identify a need, they evaluate solutions, they make a purchasing decision, and after a predetermined amount of time they either renew that agreement or reevaluate their options. Developers on the other hand develop a more linear relationship with a product. As they use the product, their knowledge of the product increases, as does their knowledge of how that product or solution integrates with other solutions. For a developer, switching products can cost much more than the price of the product, it means losing major learnings that took time to build.

This is why the role of developer marketing can have such an incredible impact on customer retention and expansion, and why developer marketing teams focus so heavily on establishing programmatic elements vs marketing campaigns. For developer marketers, building a database that is engaged and healthy is the main way to ensure that the end users of your products are continually increasing their knowledge and affinity for your solution. This is in contrast to demand gen, growth, and field marketing objectives where the goal is to push contacts into a buying process. If the contact has already bought your product, they are no longer valuable unless you have another product to sell. To developers, most of the time this type of interaction is not appreciated. Developers evaluate products based on challenges and needs, if they don’t have a need for the product or are facing a challenge that the product can solve, pushing these solutions does more damage than good. Timing this process is almost impossible, that’s why developer marketing programs are so valuable. I find that it’s in the best interest for most companies to view developer marketing as a customer success function and not a demand gen function.

Creating organizational alignment

Developer marketing teams tend to be viewed as an enigma in most companies. They aren’t developers but they are technical and the good ones can code, they aren’t advocates but they behave like them, and they aren’t marketers but they use all of the marketing team’s tools. To make things even more complicated, some of the most successful dev marketing teams report through product teams and in some cases even have products that they manage. These differences are a fast track to organizational misalignments and misunderstanding. Though I’ve never achieved 100% internal alignment, I have found several ways to build a common understanding and appreciation.

The most important thing is to creating alignment, is defining who developers are. This includes job titles, levels, and technologies used. All too often companies group all technical roles into a ‘developer’ segment. The issue with this is that though all developers are technical, not all technical roles are developers. There are technical roles that can meet sales qualification criteria and who actively participate in the buying cycle. You see this a lot with IT roles, which is why tensions can build quickly. Generally, speaking your developer database should not contain contacts that would qualify as a lead in a sales funnel. If it does, it means that your targeting is either too broad or your developer titles might be too senior. The other thing that creates tension is if the targeting criteria is too narrow and developer contacts are being sent to sales and marketing as a qualified lead. Finding the perfect balance takes time, but the effort is well worth the wait. It’s important to meet regularly with sales and marketing to refine your process, and keep an eye on the contacts who are being passed off as a lead. Unsubscribe and click-through-rates are a valuable early indicator of how your segmentation is working.

The second way to create alignment is to educate and advocate internally about the impact that developers play in the buying process. Most people understand that developers don’t have budget to spend or the authority to make a purchasing decision, but they don’t understand the influence that developers have on a sale. It’s important to build an understanding of the impact that poorly targeted or overly aggressive marketing and sales campaigns can have a developer’s affinity towards your company. With so many options on the market, developers can be picky about which solutions they use, and believe me, they are …