Confluent 2024 Strategy

🧠 Free Recall ❓ Quiz 🔍 Cues 🔮 Simulation 🥷 ShadowBox 📐 Encode Cards

Our first priority is to execute each quarter to grow the business, increase our efficiency, and deliver our services to our customers. We’re building towards a large multi billion-dollar business, growing a sizable team, and operating at scale and with increasing efficiency as a mission critical system for thousands of customers. This execution gives us license to continue on our current path of innovation and growth. This means hitting the targets we’ve laid out in our long range plan including specific goals around cloud consumption, revenue, CP bookings, pipeline, hiring, customer support, operations, and numerous other areas. This document will lay out what we must do and  highlight key focus areas to drive growth, efficiency, and improved execution for the coming years.

The Road Ahead

We will drive focus across the organization on the key measures that will deliver long-term value for our company, our people, and our customers. We have translated our long-term strategy into measurable objectives that span financials, operational metrics, and employee engagement.   Our investments are guided by the “growth and profitability” framework which sets a “mid-term” and “long-term” target for managing top line growth and profitability . Our “mid-term” target is to deliver >5% of operating and free cash flow margin at revenue growth of ~30%. Our FY24 Long Range Plan (“LRP”) has us continuing strong topline growth while delivering on our commitment to be Non-GAAP operating margin and free cash flow margin profitable for the full year. Additionally, we have also set ourselves with one year and three year goals for share burn and dilution that we need to execute on.

Key Efficiency Drivers

Achieving our efficiency targets will require a dedicated focus on operational efficiency to be a core part of the company’s DNA. Here are the most critical company-wide efficiency drivers:  
Build a world-class team at scale as a remote-first company: We have over 2,700 employees in 24 countries. Remote-first will be a top employee value proposition for teammates and a competitive advantage for attracting future teammates. We will continue to enable our teammates to do their best work by optimizing all aspects of how we communicate, onboard, learn, and develop as professionals in a remote-first environment. Our remote-first value proposition will allow us to attract the best talent and optimize for scale based on our location strategy objectives.
Optimize our operational maturity: In order for us to scale efficiently, we will have a relentless focus on optimizing operational maturity across all processes and functions. This includes reducing prior years “tech debt” and maintaining a long-term focus to scale processes that adapt to our high growth and dynamic business needs. The direct result of not optimizing for operational maturity results in inefficient allocation of capital and reliance on incremental headcount that does not scale with our growth. The most impactful ways to optimize our operational maturity include 1) creating a self-serve data culture in which we can lead meetings with data dashboards not powerpoints 2) automating more processes 3) exploring and implementing Gen AI use cases.
Powering our innovation engine with high velocity execution and a visionary product roadmap: We believe the best way to power our innovation engine is to couple vision with ruthless execution. Our vision to penetrate our large and growing total addressable market is outlined in the Win at Kafka and DSP strategy documents. Our ability to execute with high engineering velocity while maintaining the highest quality standards is critical for us to deliver our product roadmap commitments to our customers. We will continually improve the product roadmap process (prioritization, resource allocation, go-to-market planning) to efficiently maximize incremental top-line contribution.
Efficient scaling in our go-to-market: Sales and marketing costs are the most meaningful areas of leverage on our journey to profitability. With over 4,000+ customers and $770M+ expected revenue in FY23, we have natural leverage based on lower costs of maintaining and expanding with existing customers. We are also intentional about our resource allocation to fuel topline growth (PG, PLG, sales capacity) and the highest ROI areas that help accelerate our consumption transformation journey. We believe the most critical aspects to meet our sales and marketing efficiency targets will be the 1) intentional prioritization and focus (countries, territories, segments) and 2) productivity improvements (PPH) improvements from scaling sales enablement programs and greater topline contribution from the partner ecosystem. The customer GTM strategy doc further outlines GTM initiatives. 
Reduce operational, legal, and security risk: Our customer’s trust in the resiliency of our services is of our utmost importance in order to retain and grow our customer footprint. In particular, as we look to expand our TAM to highly regulated industries (e.g. FinServ), having sufficient controls in place to reduce risk are required.The Cloud Architecture & Reliability team is leading a cross-functional engineering effort to reduce the time to recover data and services in the event of disasters.
Relentless focus on ROI across all teams: We developed a FY24 plan that calls for another year of Non-GAAP operating margin improvement of 10+ points and full year profitability as defined by Non-GAAP operating and Free Cash Flow Margin. At the heart of delivering returns to our shareholders including employees, the amount of free cash generation of a company is critical. Increasing our topline growth is the most efficient way to deliver improving free cash flow margin. However, there are also operational maturity practices (contractual, payment terms with customers) and spend management levers to optimize free cash flow margin further.

Enough isn't done to force Change
Remote work style, writing
leadership principles
Self serve data
ROI across all teams

Objective 2 Win at Kafka

In 24 months, the reliability, performance, cost advantages, and global nature of Confluent Cloud will be mentioned in the same breath as S3, Dynamo, Spanner, and the other great cloud native systems. 
However, until then, the promise of a relatively stable and cost effective Kafka dial tone will increasingly become a commodity as existing and emerging players undercut Confluent to gain market share.
Confluent is seen as the premium player in the market and we are being undercut left and right. This is a race to the bottom, but it’s a race we must compete in and win.
We are competing on price performance, admin overhead, and mission critical reliability. We must be best-in-class in all three.  Kora was a massive step in the right direction, but the job isn’t done. In 2024 we will need to debut K2 
K2 Product Requirements and Exploration and migrate customers away from single tenant pkcs in 2025. We will not win this race if we don’t.
Whoever wins Kafka is going to take the whole dang DSP market. Kafka is the foundation of the data streaming platform. If we don’t win Kafka, we can’t win the data streaming market. But we won’t win every workload right away, and it’s important that we call out the customer segments and workloads that we can’t win with our current product while evolving our product to be faster and less expensive.
Our Confluent Platform business is most vulnerable to this race to the bottom, especially where customers are just paying for a supported, high capacity Kafka, that is easily substituted. Ultimately, these customers will move to managed services. But in the meantime we need to protect our CP revenue base, and build cloud connected CP features that ensure these customers migrate to Confluent Cloud and not one of our competitors.
Lastly, we need to continue fueling the top of the funnel, Apache Kafka, by exciting and uniting the Apache Kafka community. We will be investing in application developer focused features that make Kafka more relevant for more use cases and make the day to day work of an application developer easier.

When will we know we have won?

There is no clear finish line here, but we will know we have won once:
Aiven and Redpanda employees start leaving
The superior price performance of Kora will allow us to beat MSK on price.
Confluent Cloud Kafka can handle Super Bowl size events without any additional on-call
More than 80% of customers running Confluent Platform are running in “cloud connected mode”
Our cloud Kafka product achieves a best-in-class, 85% contribution margin
Even the largest Digital Native customers are abandoning self managing Kafka and moving to Confluent Cloud’s fully managed SaaS offering
Confluent Cloud represents 51% of all Kafka usage.
Have we been Winning at Kafka?

In 2021, we outlined our strategy for Confluent Cloud to become the de facto data streaming platform in the Cloud. The strategy was rooted in:
Kafka adoption starting with Confluent Cloud: making Confluent Cloud the first step to learning and using Kafka
Change found below: The acceleration of Redpanda and the deceleration of our Cloud led PLG motion required us to revisit this strategy.
Being 10x Better: we needed the market to understand that Confluent Cloud is different than what you get with Apache Kafka
Adjustment: It was challenging to explain why Confluent Cloud was more Cloud Native and 10x better than Apache Kafka. Kora is now our one word answer.
Winning in Tech: we need to win revered Tech companies that would sing our praises and add legitimacy to our platform offering.
Adjustment: we know we have to win the hearts and minds of the tech ecosystem but this doesn’t mean we need, or even should, go after all tech workloads right away. This is a must-win segment but we need make sure we are winning the right workloads, with the right customers, at the right time given the capabilities of our current product. We need to take a more precise and targeted approach with Apex workloads.
We need to focus this effort on gaining referenceable, credentialing logos, not just in tech but in finserv as well.
Building a Cloud Brand: we need the market to know that we were a Cloud company first and that we had the best implementation of Kafka in the Cloud.
Done: Confluent is now known for having a fantastic Cloud service. Mission Accomplished.
Where are we going?

Accelerating success of new entrants in the market (Redpanda), learnings from our Cloud Native, Everywhere, and Complete marketing campaign, and new revenue opportunities within our platform business have required us to evolve the pillars of our strategy.
 To win we will need to focus the following:
Ensure Apache Kafka dominates streaming
Connect CP into our global Cloud-based CNS
Make Kora the global, cloud-native implementation of Kafka
Evolve our pricing and packaging for a more competitive world
Win in the most strategic segments
Updated Strategic Pillars

1/ Ensure Apache Kafka dominates streaming

To address the Redpanda threat and the newness of our product-led growth motion, we must invest more in Apache Kafka, specifically in new developer-focused features. 86% of new logo opportunities and 95% of new logo wins start with open source Apache Kafka. We must continue to innovate in the open source to maintain our position at the top of the funnel. We can’t let Redpanda take the top of the funnel. Instead, we will relegate Redpanda to nothing more than an over-extended science project gone wrong.

We need to add useful and exciting features to the open source that are geared more towards developers than operators. While KRaft and Tiered Storage were the right investments at the time, we should now focus more on the Kafka API. 
In the long term, Apache Kafka will be known as the de facto reference implementation of the Kafka API. Apache Kafka will be to Postgres what Confluent Cloud is to Aurora. Apache Kafka will have a rich set of application developer features, including queues, easy-to-use produce and consumer APIs, debugging tools, transactions, two-phase commit, hierarchical topics, and consumer groups.
These developer centric features will excite the community, but we also need to get more involved, including the likes of RedHat, AWS, Instaclustr, Cloudera, Uber, and Aiven, as well as, partners like Azul, Aklivity, and Gravitee. United the Apache Community will beat Redpanda with the size and pace of innovation of a truly open source project.
This is the year that Kora and Apache Kafka completely diverge. We will have a dedicated team focused on the success of Apache Kafka, it’s ecosystem of clients, and the longevity of the Kafka protocol. 
Critical Apache Kafka Projects

KIP-405: Kafka Tiered Storage - Apache Kafka - Apache Software Foundation 
KIP-500: Replace ZooKeeper with a Self-Managed Metadata Quorum - Apache Kafka - Apache Software Foundation 
KIP-714: Client metrics and observability - Apache Kafka - Apache Software Foundation
KIP-848: The Next Generation of the Consumer Rebalance Protocol - Apache Kafka - Apache Software Foundation 
KIP-932: Queues for Kafka - Apache Kafka - Apache Software Foundation 
KIP-939: Support Participation in 2PC - Apache Kafka - Apache Software Foundation 
Other critical projects that need to make progress:

hierarchical topics
first-class schema support in Apache Kafka
protocol simplification and auto-generated clients
It’s all well and good to increase the top of the funnel but to realize a return from our OSS investments we need to eventually turn these AK users into paying customers. How can we increase our odds converting an Apache Kafka user into a Confluent Cloud customer?
This is counter intuitive, but step 1 is making Apache Kafka users successful at scale. Small AK workloads are less likely to feel pain and therefore not move to a managed service. Developer education and the right mix of AK features will help here.
We will debut a free-forever “Confluent Developer Console” that will drive client sign ups and help us get metrics about prospective Kafka workloads in the broader market. See below for more detail.
Our Kora message will drive interest in our Cloud to gain performance and cost efficiencies. We need to continue driving home that we are faster and less expensive than Apache Kafka.
Advocacy

We need to continue to get our message our there, especially to on the ground developers who are looking to get started with streaming.
Continue to invest in Confluent Developer: Your Apache Kafka® Journey begins here 
Collaborate with the above competitors and partners on Apache Kafka advocacy
Leverage university partnerships to teach classes on streaming data that promote Apache Kafka and Confluent Cloud. 
Continue investing in the startup program and get venture to promote our message.
Increase our presence at developer conferences and meetups
We need to strike the right balance between Apache Kafka and Confluent messaging. We cannot loose sight of promoting Apache Kafka. We need to enable a new group who is focused only on Apache Kafka's success (see below) to promote Apache Kafka directly. We don’t want this to be Confluent on behalf of Apache Kafka vs. Redpanda.  We need this to be the entire Apache Kafka community vs. Redpanda.
2/ Connect CP into our global Cloud-based CNS

Confluent Platform is a massive money maker for Confluent and an emerging competitor now has $100M in fresh capital and a banner ad that says, “cut your Confluent bill by 50%.” Make no mistake, selling Confluent Cloud and Confluent Platform will be more challenging next year. In addition to the TCO & price performance improvements Kora will bring, we need to increase the value per dollar of Confluent Platform. We will accomplish this by adding Cloud connected features, bundling CP features, and making some CP components free.
Why is CP important? Adrian Colyer of Accel estimates that if the CSPs moved as quickly as possible to build capacity, it will still take another 15 years to have enough datacenter capacity to run all existing on-prem workloads. He adds, with “[a]ll that said, here’s something I strongly believe: the enterprise will always remain heterogeneous.” There is still a lot of on-prem hardware out there with a lot of applications running and a lot of data to deal with. We have the distinct advantage of being able to build a DSP that is everywhere.
We need to be where our customers have applications and data, but more importantly, we need a product that bridges and encourages the migration from on-prem to the cloud. By reaching our control plane into on-prem Confluent deployments, we will unite the Cloud and on-prem and start to convert our CP install base into Cloud revenue. 
Hybrid Topic Management

First, we will rebrand Health+, focusing our efforts on Cloud connectivity, deprecating C3 for a Cloud Connected only version. For air-gapped environments, we will form partnerships with Kadeck, Factor house, and Conduktor for management and monitoring solutions.

We will also find ways to decrease duplicative development costs by consolidating our two control planes (C3 and CC Control Plane), as well as, provide developers with easily available tooling both locally and via our Cloud Connected management capabilities to accomplish their daily tasks.

Local Developer Console

Confluent Developer Console
Secondly, we will debut a Confluent Developer Console to fence off Redpanda and drive PLG. The Confluent Developer Console will displace tools like Redpanda Console for simple local development workloads, drive PLG into our cloud, and help us get more data on how Apache Kafka is being used more broadly in the market.  
Remove free CP nodes with Cloud Deals

End Free CP: CCloud Customers pay for CP Licenses 
More immediately, we will stop giving away CP nodes when signing CC deals. We are giving away more than $18M in free CP today. This was the right move at the time, but we need to make a change to increase revenue and allow us to take on more margin dilutive, but credentialing, Cloud deals. 
3/ Make Kora the global, cloud-native implementation of Kafka

Distributed Cloud 3 Year Product Strategy 
In 2023, we branded our Cloud Native version of Apache Kafka. It’s a lot easier to answer the question, “why are you more cloud native” now that we can just say Kora. We also have an award-winning VLDB paper that goes into all the details and is the perfect technical leave behind.
Better, Faster, Cheaper: Build Kora 2.0

K2 Product Requirements and Exploration 
Increasingly, Kora is delivering better price performance, elasticity, lower admin overhead, and reliability for our customers all thanks to a more cloud-native, multi-tenant first design. We have met our competitors on 10x latency, and now we need to turn our attention to year over year CKU improvements. The promise of a CKU has always been that it gets better over time: more connections, more throughput, better latency. We have a roadmap for these improvements and we need to bake those improvements into our LRP so we can remain price performance competitive with MSK, Redpanda, and Aiven who continue to undercut on price.
Problem is, Confluent is seen as the premium player in the market, and in a lot of ways, we are. We have the best implementation of Kafka in the cloud, run by the folks who know Kafka best, supported by the best Kafka customer success team on the planet. However, we don’t want to be Ferrari, we want to be Toyota with a complete line up of offerings. A Toyota Corolla to the Lexus LS500. And customers should be able to move from one model to the next seamlessly thanks to Kora’s cloud-native architecture.
Kora is a massive achievement that took over $1B of R&D investment and 5M person hours to make. But we can’t stop innovating. Kora needs to get even better if we want to be the Toyota for data streaming. We aren’t done. We have another mountain to climb: K2 (Kora 2). We need to take Kora a step further and fully embrace multi-tenancy. In 18 months, we will have our first production cluster running on the next evolution of Kora.
How will K2 be different?
Confluent CloudOS- First, K2 will leverage the new capabilities of Confluent’s Cloud Platform that will simplify networking, scaling, and reduce costs. 
Aeneid - Future Confluent Cloud Architecture / Platform 
Effectively no limits - our limits get in the way of sales and consumption. CKUs will move from a unit of scale to a unit of billing. The eCKU (elastic CKU) billing model found in Enterprise will move to all SKUs. Rather than dedicated clusters, customers will be able to reserve CKUs to ensure capacity is available when they need it (think reserved EC2 instances).
Flat networking - everything can talk to everything with the right user permissions to create a Global streaming data fabric for our customers. Every topic can be easily mirrored globally without the need for network or cluster linking. Every topic is available for Flink to query. Every topic will have a URI that can resolve anywhere in the world.

uri: confluent.cloud/<org>/<region>/<namespace>/<topic>/<offset>
Latency slider - customers will be able easily choose between cost and latency, as well as, latency and availability on a per topic basis. good, better, best latency.
Start small, scale globally - customers will be able to start with basic clusters and scale all the way through standard, enterprise, and even “dedicated” without migrating. Dedicated clusters will be renamed to reflect the logical rather than physical isolation: Confluent Private Regions.
Remarkable Cost Efficiency - our ability to shape workloads, densely pack workloads, and innovations at the storage and replication layers will allow us to offer an unparalleled cost profile to our customers.

Customers will be seamlessly migrated to this new experience.
Global CNS: K2 will move us from Clusters to Topics

The above investments in AK and K2 will allow us to deliver a topic centric experience where the idea of clusters fades away and topics filled with structured, business object data moves into focus. Our eCKU model will allow us to bill for the hourly capacity required to power a given set of topics.
Topics can now be more easily grouped into hierarchical namespaces and even span regions. As we adopt this new topic centric paradigm, we will need to revisit our cluster centric abstractions. For example:
cluster links - they will have to remain for dedicated and hybrid setups, but multi-region deployments will need to take on a different form in a K2 cluster.
we will need to rethink of basic, standard, and enterprise skus look like if they aren’t associated with a cluster.
The relationships among connect, SR, networks, organizations, and Kafka will need to be revisited.
Build K2 Iteratively staring with cheaper topics and a headless Iceberg Interface

[WIP] Project Kirkland

Iceflow: Topics as Iceberg Tables in Confluent Cloud (name TBD) 
We can’t win at Kafka without seeing the benefits of K2 in 2024 and this is why we will be taking an iterative approach to its development. 
The first feature we need to add to K2 is a new feature that allows customers to trade off between latency and cost. Consider these our “glacier topics” that will allow us to win event/logging/metrics aggregation use cases where latency isn’t as much of an issue.  
We can’t give up these high throughput workloads. Two reasons:
They will remain on Apache Kafka where they will continue to feed into S3 and then drive Spark workloads. If we don’t get the data we can’t work with customers to shift left and drive workloads into Flink.
These workloads are easy pickups for Redpanda (soon WarpStream). It’s an easy undercut. These workloads are often found at large scale tech companies that gather clickstream metrics. So to Win in Tech we need these less expensive topics.
Our less expensive, higher latency topics will help us combat MSK, Redpanda, and WarpStream, but today we are leaving money on the table by driving data an S3 bucket without providing much more value than acting as a big expensive byte buffer. Rather than egress the data to S3 and give Snowflake and Databricks all the unstructured data to go make money on, let’s help out our customers and put the data into a structured, queryable format. Iceberg has won that market and we have all the puzzle pieces to deliver accurate, well structure Iceberg Tables to our customers using our Kora storage engine. 
4/ Evolve our pricing and packaging for a more competitive world

Cost Roadmap

In 2024, we need to continue to market Kora. The broader market, our prospects, and our customers need to know that we have a fundamentally better engine behind our Kafka cloud product that gives our customers the most reliable, cost effective, and performant streaming experience on the market.
By the end of 2023, we will have public benchmarks in market along with the VLDB paper, but on the cost side we need lower public pricing. The Enterprise SKU will help immensely with the public perception of our cloud product being outrageously expensive, but we also need public tiered pricing so prospects don’t run off to a competitor before we can even have a conversation.
2024

2025

[WIP] Project Kirkland 
Public Tiered Pricing
CP and CC Pricing decreases
Applying our K2 cost improvements to our existing  and future, performance express topics.
Zone aligned producers
 
Move away large scale dedicated clusters

We can’t win all the Kafka workloads with our current product but K2 will unlock more workloads in 2024 and 2025.

CP Repackaging

5/  Win in the most strategic segments

Tech

Time and time again, we have seen trend-setting tech companies decide who wins in a winner take all platform market. These highly respected houses of engineering talent create virtuous marketing cycles in a follow the leader sort of way.
We need to win some of the most respected companies in tech who will sing our praises and credential our cloud platform. Here’s the problem: winning Apex tech customers is demanding and margin dilutive. Using current MSK prices + a 30% premium, we will max out at a 40% CM for most Apex deals. This is a good outcome but it needs to be factored into our LRP. 
 TODO recalculate number using updated S3 info and producer alignment.
It will take us some time to build out the next evolution of Kora so we need to be careful about the type of workloads that we go after. We should not go after Apex opportunities like we are today. They require a different approach. Our time and attention needs to be on building out a new architecture that allows us to go after any Kafka workload in relatively the same way. 
Rather than view the Digital Native Apex segment as a massive revenue opportunity, we will measure success in this segment by the number of reference customers. With this in mind, we will no longer rank opportunities in the digital native segment in terms of the size of their workload, but by how credentialing their logo is in the market. We should not spend time chasing these opportunities unless the logo is particularly credentialing. Marketing will determine the list of these credentialing customers and sales will staff dedicated teams to go after these opportunities
We can find profitable and easier to onboard Kafka workloads at some of the most respected Tech companies. We do not need to win all the Apex deals. We should focus on only a handful of Apex workloads to really go after in 2024 and 2025. We can use existing GTM tactics on Pacesetter and Commercial opportunities and improve our odds of winning be leading with ESKU.
  TODO Revenue targets

Thinking in terms of customer segments isn’t granular enough to figure out who is a good fit for Confluent and who isn't. We need to be thinking at the workload level.
Workloads we can win in 2024

Workloads that will be challenging to win in 2024

Mission critical streaming workloads that require high availability.
With our 10x performance improvements rolling out in November 2023, we can go after more latency sensitive applications except those that are currently running on bare metal (e.g. trading use case where CP is more appropriate)
We will continue to win the high throughput, high retention workloads thanks to the robustness of our tiered storage offering.
Workloads where the customer’s discounts don’t exceed ours
Workloads that don’t require ultra low (sub 50ms p99) latency
Fast and high throughput uses cases where we will remain cost prohibitive until we evolve our architecture further in 2025. We will not win high throughput, low latency workloads on cost. We should not spend cycles going after the DIY crowd of customers. We should rely on our funnel.
High throughput, real time ML model (i.e. TikTok or Youtube Shorts)
Real-time metrics and aggregation decision platforms (i.e. Amplitude, Mixpanel, Social Networks)
In general these workloads are found at large consumer social network and large scale metrics/analytics platform companies.
Super cost sensitive workloads where all of the following are true
built into the cogs of the customer’s product
the prospect has been running Apache Kafka at scale for years
the prospect doesn’t value the benefits of a SaaS solution
the prospect has a high volume use case (10+ GBps) and their cloud provider discounts are on par with Confluent.
Finserv / G-SIBs

Globally systemically important banks (G-SIB) can be just as credentialing as a Stripe, Uber, or Airbnb. Going after Finserv logos is now part of our Win at Kafka strategy. To win over these large banking customers in the Cloud, we will need to improve our TTR across the control plane and all satellites to sub 6 hours, as well as, add optional Confluent Staff access transparency and approval and location requirements. This is captured in 
Project Truffle Overview.
Market Segmentation

While we are too expensive for in the Tech market, we are underpriced for the Finserv market. We will need to segment our product to better serve these two markets at two very different price points. However, just like tech, we need to think critically about the workloads we take on in 2024. We should not take on ultra low latency finserv workloads in our cloud in 2024 (e.g low-latency trading platforms, credit card authorization workloads. settlement > auth). We can’t go after bare metal performance workloads in the Cloud. Pivot to CP.
FedRAMP

Our FedRAMP efforts are setting up our future dedicated offering (Confluent Cloud Private Region) which will serve the most sensitive workloads. These FedRAMP dedicated clusters will help us win in tech, who serve federal customers, as well as, win large regulated banks and government institutions.

FedRAMP Overview and Onboarding 
  TODO Revenue targets

High Level Roadmap

2024
2025
2026
Tagline
Build K2, sell what we have
Migrate to K2
Win with K2
Product
Kora 2.0 development. Sell what we have: 10x performance, ESKU, SaaS Reliability, and Scale.
Introduce low “glacier topics” at KSL (project kirkland)
Public pricing changes, including public volume discounts.
Give customers a no admin, global kafka experience that is obviously different from our competitors.
Migrate customers to the new stack seamlessly
 
Cost optimizations on our stack through optimized placement of data.
Sub 10ms latency improvements to further the latency slider
Debut the new security centric SKU aimed certain workloads
Unlocked workloads
All sub 1GBps workloads thanks to ESKU, Kora, and VPC v2.
Ultra high throughput logging and metrics aggregation use cases.
 
K2’s eCKUs and revamped replication model will allow us to win on cost across the board.
We will have the best SaaS Kafka by miles.
Locked workloads
Price and latency sensitive workloads > 10GBps
Sub 10ms tail latency workloads
Sub 10ms tail latency workloads
BYOA

KPIs

Pillar
AK Dominance
Kora
Credentialing Logos
Connect CP to our Cloud
Summary
We need to keep the AK top of funnel healthy
We have and will continue to innovate our Cloud Native implementation of Kafka called Kora
We need the most respected Tech and Finserv companies singing Confluent Cloud’s praises
We need our Cloud to run everywhere, including on-prem, and we need to recognize it as cloud revenue
Northstar KPIs
Apache Kafka 
Engagement Metrics (Downloads, Dev List, Slack, Meetup attendance, etc.)
 
 
MSK/Redpanda win rates
LKC to PKC ratio
 
Weekly p99 latency by SKU
 
Weekly fleet availability by SKU
 
Max CKU dimensions
Number of Tech and G-Sib reference customers
Number of Confluent Platform deployments connected to Confluent Cloud
Key Deliverables
Queues for Kafka
 
Client Metrics
 
ZK Removal
 
2 Phase Commit
 
Dev Image
All Project Sonic reliability and latency milestones
 
Kora 2.0 (instant elasticity, lower costs to customers, topic uris, topic based billing)
 
Incentives to get customer references
 
5 Pacesetter or G-SIB reference customers
CP bundling and pricing changes
One-click Cloud Connected telemetry and management setup
 
Online licenses and node registration
 
Consumption based CP pricing

Cross Functional Asks

Sales
Refocus our Apex sales efforts. Pick 4 accounts where we have the highest chance of winning, build teams that act as consultants, and use a combination of CP and CC to slowly win increasingly more mission critical and complex workloads. 
Finance
Align on a rebundling of CP in our LRP that allows for a net CP price decrease to remain price competitive.
Marketing
Build a pipeline of referenceable tech customers from existing customer base
Build a campaign around Apache Kafka innovation and dominance
Customer Success
Build incentives to win public customer references
People
Go after Redpanda and Aiven talent

Objective 3

Today Confluent is thought of as “The Kafka Company”; however, we believe that Kafka is just the first layer in a larger, more strategic platform, the DSP. This will allow customers a full suite of capabilities letting them stream, connect, process, govern, and share data streams throughout their organization.
Our Data Streaming Platform (DSP) which today consists of Connect, Stream Processing and Stream Governance will deliver $300M ARR within 3 years and will be adopted by 100% of our Confluent Cloud customers.
But that’s not where we are today. We know that today 53% of Cloud Environments representing 51% of total throughput in Confluent Cloud don’t even have schemas and therefore are mostly ‘dumb pipes’. Connect has 25% adoption and is significantly held back by networking, pricing and lack of breadth. Governance is attached to over 75% of PAO’s but we need to drive deeper usage especially by our largest customers. Flink is starting from zero and will be building on 12% adoption of KSQL.
We also know that it matters. When customers adopt our IP, they retain. When they adopt multiple pieces of our IP they expand. It was true with Confluent Platform and now it’s true with Confluent Cloud:

2024: Product market fit

In 2024 we will primarily be selling our DSP as an upsell from a la carte Kafka to Kafka pre-buyers. To ensure this is successful and to set ourselves up for 2025, we must do the following:
Take Flink to GA across SQL and programmatic features (@Michael Agnich , @Eugene Koblov, @James Rowland-Jones  )

In 2024 we will round out our Flink offering and make good on our promise of delivering a simple, serverless, and cloud-native stream processing service. 
Confluent has made a massive strategic investment, placing Flink at the center of our streaming compute platform and product strategy. In 2024, Flink will drive roughly $8M in cloud consumption as it’s being completed and by end of FY 2026 Flink will approach $100M ARR. However, to achieve this goal we will need to double down in 2024, building on the foundation we've laid in 2023, so the growth continues to compound. To do this we must ensure that we round our our Flink API support adding Java and Python support to our offering with UDF and Table API. We also must ensure all customers and users are unblocked from using Flink. 
Milestone 1: By Kafka Summit London Flink SQL is:

General availability of Flink SQL on public networks in all three public clouds (AWS, Azure, GCP)
Detailed Scope:Flink SQL on Public Networking - General Availability Scope
Early Access of UDF 
Detailed Scope: 
Flink UDF Product Requirements  
Early Access of Table API 
Detailed Scope: 
2024-03-19 Table API on Confluent Cloud - EA Scope 
Generally available via Private Networks with ESKU support in AWS (stretch goal)
Milestone 2: By Current 2024 Flink will be:

Generally available on private networks across all APIs in all public clouds (AWS & Azure with GCP to follow within 6 months)
Generally available with v1 of Table API support in all three clouds with Java and Python support  
Generally available with v1 of SQL UDF support in all three clouds with Java and Python support 
Plug key gaps in networking, feature availability, and usability (@Michael Agnich , @Jon Fancey , @Sunil Patil , @Rohit Bakhshi )

In 2023, DSP will account for roughly 10% of Cloud consumption and by 2026 this will grow to 30% even while Kafka itself sees strong growth. Our focus in 2024 will be closing those gaps especially with our most mature offering, Connect.
Milestone 1: By Kafka Summit London Close Critical Connect Gaps

Private Networking for Connect (AWS and Azure)INIT-540: Solve Private Networking for Fully Managed ConnectRESOURCED
 
Launch a SLA for fully managed connectorsINIT-3503: Fully-Managed Connect SLADONE
 
End commercial loopholes
End Free CP: CCloud Customers pay for CP Licenses 
Make migration of connectors easier (target Q2)  INIT-3894: Custom Offset for Confluent Cloud Connectors DUPLICATE
 
Milestone 2: By Current 2024 Hub will address:

Anonymous user access sign-ins to allow tracking, notifications, IP protection and custom connector pathways to CC
Address telemetry gaps in Confluent Hub 
Confluent Hub 2.0 - 2024 plan 
Milestone 3: By End of 2024

Complete Custom Connector offering across all clouds
Completely refreshed Confluent Hub to capture new users and drive consumption of DSP components
Complete CSFLE INIT-177: Client-side field level EncryptionIN DEVELOPMENT
 
Complete Data Portal Phase 2 INIT-2354: Data portal - phase 2PARTIALLY RESOURCED
 
Complete Stream Lineage Phase 2 INIT-1917: Stream Lineage Phase 2RESOURCED
 
Complete Data Profiling INIT-1394: Data profiling RESOURCED
 
Achieve 100% year-over-year growth driven by our consumption focus (@Michael Agnich , @Kevin Chao )

DSP Forecast and Mix
We’re aligned across product, marketing and the field on our DSP targets over the next few years and the DSP will be the biggest growth driver for our cloud business.
In order to make that happen, we need to make changes in how we go-to-market and compensate our sales teams. Given these are Confluent Cloud targets, these revenue goals are only achievable through true consumption by the customer. Therefore, there are a number of GTM activities we need to support in FY24 to hit our DSP consumption goals (non-comprehensive):
Launch the GA of our Flink service and introduce a corresponding marketing campaign and sales motion to translate product awareness into not only PG, but actual Flink attach and consumption
Enable and certify the Field on the “relaunch” of Connect and introduce a Connect “Level Up” program to migrate self-managed Connect users to fully managed
Refine the Stream Governance adoption motion to drive greater usage of features beyond Schema Registry and increase Advanced package attach rate
Figure out how these pieces fit together in a potentially broader “Stream-Connect-Govern-Process” framework to drive more holistic adoption of the non-Kafka components of our platform
Revamp our “Complete” always-on motion around Connectors + Stream Processing + Stream Governance into a broader product-upsell campaign
Given the increased reliance on these features to hit our revenue targets, we also need to supplement these GTM activities by activating and incentivizing the Field to focus on driving non-Kafka consumption:
Not only move the sales teams to consumption-oriented compensation, but create non-Kafka product consumption targets at the theater and/or region level to align incentives across Product, Marketing, and the Field for DSP-specific attach + consumption
Need to add visibility and review processes for account teams in C/T360 dashboards on product attach & consumption
Introduce horizontal SE (or other overlay) specialists goaled on product attach rate and revenue to ensure focus (with Flink as priority given the required specialized expertise) – this overlay cannot just be “evangelists” who are not tied to adoption/consumption goals
Roll out mandatory certification programs to ensure the Field and Partners are enabled to sell and drive adoption on each product area

Begin to establish the DSP as a category

As we evolve our strategy on data products, we will also need to evolve our brand marketing to build an identity for Confluent that’s more than just Kafka. We need to build market category for data streaming that’s as big as the data warehouse category.
In FY24, we will prioritize and invest in efforts to build a Confluent brand identity for Data Streaming. We will lean into telling a visionary DSP narrative for the Technical Executive that will highlight our unique POV on the category and platform differentiators. We will lean into Data Products and how our 5 core DSP capabilities help bring this to reality. We will get more provocative and consistent with our messaging, highlighting our message in unique ways across multiple different channels. We will do this by: 
Establishing a singular company narrative for the tech exec persona
Deploying a media strategy that regularly features our key leaders in compelling stories that shine a light on our unique POV and the category 
Participating in comparative assessments with market leading industry analysts such as Gartner, Forrester and IDC
Using the voice of our customers and industry influencers to tell our story
Executing a multi-wave digital brand campaign 
Milestone 1: Build messaging on Data Products by Jan 2024 (@Priya Balakrishnan )
Build Confluent’s unique POV on Data Products with a pitch deck and message brief 
Milestone 2: Launch a marketing campaign on Data Products in June 2024 (@Priya Balakrishnan ) 
Build downstream assets including .io and SEO pages, book/whitepaper (technical paper for the enterprise architect), ebook (for the Tech Exec), customer stories and appropriate enablement content  to kick off the campaign, with a focus on the pre-believer Tech Exec.

Prototype a use-case-based selling mechanism that skips the Kafka-up-sell (@Priya Balakrishnan )

While selling into a pre-believer account (and pre-believer persona) bypassing Kafka entirely is a less efficient GTM motion as it stands today, to own a brand in our own right, and not just acquire a fraction of the Kafka user base, we need to determine how to go to market with this motion. This requires us to simultaneously build a brand for Confluent while educating our customers around specific use cases. This will be a paradigm but necessary shift to sustain long-term company growth and help us move up the stack. 
To pilot this motion, in 2024, we will focus on one specific Streaming Data Pipeline use case where we can have an authoritative and compelling point of view on how and why they should use the various DSP capabilities to deliver business outcomes. The use case we recommend is Data Warehouse and Data Lake Ingestion. This use case will focus on our take on the current way the Medallion Architecture is implemented and highlight how Data Streaming is the best place to turn data into gold for better efficiency and greater cost savings. 
Milestone 1: Launch in May and run it through Sept
Kick off a pilot on the use case with a select group of existing and greenfield accounts. At the end of this period, we should be able to refresh and fine-tune the messaging for our target personas, baseline what it takes to sell into a greenfield account (directly “selling” to the target persona) and compare its efficacy to how we sell into an existing account (thru our champion). 
Dependencies:
Product: Flink GA (need to discuss if there are other product deliverables required to kick off this effort)
Sales: Identify target accounts (~15 greenfield accounts and ~15 existing accounts) and focused commitment 
Product Marketing: Messaging refresh for the specific target persona
Ask: Build a focused cross-functional group across PM, PMM and Sales to pilot this motion 
Drive key partnerships in the tech ecosystem and SIs that help customers realize a DSP in their organization (@Paul (Pmac) Mac Farland , @Rodrigo Sanchez Bredee )

ISV (and selected CSP Managed services) Ecosystem 2024 initiatives for Connect, DG and Flink

The nature of Confluent’s ISV partner ecosystem will also need to evolve beyond Kafka in order to enable additional adoption and growth of the Data Streaming Platform. 
Confluent's ISV partner ecosystem also needs to evolve beyond Kafka to drive adoption and growth of the Data Streaming Platform. In 2024, the Connect with Confluent program will expand beyond the Kafka API to include partner-built custom connectors and to leverage the upcoming http and OpenAPI-based connectors. This initiative requires expanding custom connector coverage, updating Confluent Hub, publishing best-practices guides, an SDK, and a testing framework for plug-ins, and implementing SSO with selected partners to reduce friction.
From a process and organization perspective, we will establish a Partner Council composed of PM, Eng, PIE and PMM to drive high agreement regarding which partners to prioritize, as well as to establish which connectors/integrations we will build vs. partners vs. the community.
We will also begin to build out and nurture the partner ecosystem for Stream Governance, both with companies in the Data Catalog (Collibra, Azure Purview, Alation, etc.) space as well as in data protection & data security (securiti.ai, Protegrity, etc.). Working with data governance partners will enable us to include CC in our customers' enterprise-wide Data Governance initiatives, which will drive adoption of DSP into more use cases. It will also provide a beachhead for us to eventually make a claim for the source-of-record position for Data Governance, given that we are “first to the data”. 
In 2024 we will pilot integrations with selected, high-value/high-data-gravity partners such as SAP to develop joint customer journeys that leverage both the data as well as the metadata layer in both products (e.g. leverage SAP’s upcoming business-semantics object catalog to enrich the metadata on the CC data portal, and create a mechanism for DSP users to subscribe to that data leveraging SAP’s Kafka client, from CC), which will provide a highly differentiated offering. 
While initially Flink will be a “closed loop” service offering within DSP (only Kafka-to-Kafka use cases), once we enable Flink Table Storage, UDF’s and external connections, we will work with selected partners to develop solutions and accelerators (e.g. for GenAI). 
SI Partners

The DSP provides an opportunity to engage with SI’s and convert their existing Apache Kafka operations outsourcing practices into one that focuses on strategic transformation, focused on business outcomes and best practices (e.g. implementing data contracts & data mesh in both the business as well as in the technical domains). Done correctly, this will allow them to move up the chain to more strategic engagements, as well as help DSP adoption by providing the thought leadership and selling into personas (“the business”) that are currently out of reach for Confluent.

Unstarred

Dunk (exclude from study)

Confluent 2024 Strategy

Review Questions

Todos

Sensemaker