How to: launch new products
Note: I am part of Cloudflare’s new product go-to-market team. We focus on the Enterprise sales business; self-service strategy is vastly different. Opinions are my own.
Part 1: Innovation 101
Many successful companies have an “innovation department”, or some variation thereof. For tech companies this is especially important, as disruption and disruptive innovation takes place at a much greater pace than it does in more traditional industries. And as Clayton Christensen famously argues in the Innovators’ Dilemma, and later the Innovator’s Solution, the best way to avoid being disrupted by challengers is to become the disruptive innovator yourself.
At Cloudflare this disruptive department is called Product Strategy. It effectively exists in a vacuum, in parallel to the core organisation. The downside of this setup is that there will by definition be a lot of duplication, as the team is just doing “its own thing”, ignoring the processes and structures put in place by the core org. The upside however is that this smaller team is much more nimble and can release and iterate on new products faster, without needing to deal with the bureaucracy that is the inevitable result of becoming a large and established business. In short, it’s a startup within a (former) startup.
Importantly, this type of idea factory is designed not to operate at scale and most of its creations are typically not something a company should go all in on. The department’s intrinsic value lies in churning out an idea, briefly validating it, and moving on to the next one. This is illustrated perfectly by Google X, which describes itself as a “moonshot factory” and openly acknowledges that most of its projects will fail and blow up on the (hopefully) proverbial launchpad. They are the idea factory of Alphabet, one of the most valuable companies on the planet, but despite Alphabet’s seemingly infinite resources it is still too risky for them to bet all their chips on one ‘moonshot idea’, no matter how promising it might seem.
Cloudflare’s core org, in contrast to Product Strategy, is designed to operate at scale. However for a company to remain successful, figuring out how to innovate is not enough — it must be able to scale that innovation the way a disruptor would eventually do it. Consequently the main options boil down to either transforming the idea factory into a second, large and rigid organisation and spinning it off, or figuring out how to transfer a product from Product Strategy to the core org.
If we follow the analogy of Product Strategy being like a startup, the two aforementioned paths re-emerge: once an idea is validated, the startup’s team can either keep working on it and attempt to scale it up on their own, or they can be acquired by a larger company to be integrated into the acquirer’s pre-existing infrastructure. However while acquisition allows ideas or products to scale much faster than organic growth can, the inevitable integration process with the acquirer is everything but trivial. And the same applies to handing over a product from an internal idea factory to the core org. Taking a prototype, as good and validated as it may be, and trying to scale it by plugging it into a pre-existing, finely tuned and calibrated machine, is hard. Solving this problem and guiding this transition is why our team was created.
Creating an entirely new role, or joining a team in its infancy, is risky. The opportunity costs are potentially high — the company might waste resources, the individual might impair their career prospects — and worse, one may end up exacerbating the prevalence of bullshit jobs. However when considering the dilemma outlined above it became clear to Cloudflare’s leadership that there was a missing link. Somehow products needed to move from one silo to another and, in hindsight somewhat unsurprisingly, it turned out that “plugging new ideas into the machine” wouldn’t just happen by itself. The solution was to create that link. Initially it wasn’t clear what exactly that meant, but the objective was clear: make sure that the things coming out of the idea factory become successful. Thus the New Product Go-To-Market (NPGTM) team was born.
Part 2: Product-market-sales fit
The purpose of our team is to help find “product-market-sales fit”, as Jyoti Bansal called it. This means leveraging sales strategy to influence a specific product, and vice versa. At different organisations those dynamics will have different implications. In the case of Cloudflare the product team is very technical and tends to prioritise solving hard engineering challenges over helping with the creation or execution of a go-to-market plan. Meanwhile neither Sales nor Marketing are focused on experimenting with, and iterating strategies for, experimental products that are not already significant revenue drivers. The resulting gap may not exist at other companies, or may be filled differently, but at Cloudflare the New Product Go-To-Market team serves as that stopgap.
As outlined above, while it is not the easiest approach, integrating an idea into an established organization is the fastest way to scale it. Thus, to rapidly scale the go-to-market efforts for ideas coming out of Product Strategy, our team’s challenge is to work out how these products can be plugged into the main Sales org. Consequently, despite our team’s ideological proximity to Product Strategy, it is hierarchically situated within the core org’s Sales department. This vantage point lends credibility with both the regional sales pods we support, as well as the various product teams we collaborate with.
Naturally we work closely with all of Sales and effectively fulfil every role involved in the sales cycle. From sourcing the first leads and reaching out directly to prospects, performing both technical and business level discovery, pitching and building value, objection handling, solution design, compiling pricing, negotiating offers and structuring contracts, to assisting with subsequent technical implementation and support. Each of those steps would normally be done by a specialist of the respective domain. Yet due to the inherent novelty of the products we deal with, none of them have a ‘playbook’ they can follow, no proven approach that works. Through trial and error we write this sales playbook as we go. Consequently, part of our responsibility includes enablement, or communicating the lessons of our playbook to other teams. Additionally, given our role in facilitating the first deals for a new product from start to finish, we inevitably become very involved in defining marketing strategies, revenue forecasting, contract language, as well as working on an appropriate pricing model.
Similar to most of the Sales team, but unlike the Product and the Product Strategy team, our team is directly incentivized to maximise the commercial success of the products we work with; despite not closing deals ourselves we carry a quota. Our team focuses on ensuring that the vision behind our products translates to revenue in the short-term to medium-term. It is precisely this orientation that constitutes part of the value we bring to helping with the go-to-market approach of Product Strategy’s innovations. After all, the Product Strategy team’s mandate specifically is to look much further ahead into the future than any other part of the organisation. That long-term perspective however does not align very well with Sales, who revolve around results in the short-term. Adopting this different perspective puts us in a position to work closely with Product Strategy, while acting entirely differently.
Moreover, the same logic through which we bring value to Product Strategy also applies to the core Product org. Despite not looking ahead multiple years, they still generally plan for the long-term. Consequently many of the tactics we employed with Product Strategy can also be applied with new products released by the core Product team and eventually we started to actively support them as well. But what do these tactics look like in practice?
Part 3: Practice
The first lesson we learned was the importance of localisation. Unlike product teams, which are often centralised in one place to facilitate an easier exchange of ideas, our team needed to be globally distributed and focus on individual regions. Go-to-market strategy is, or rather should be, inextricably linked to the market to which it is applied, and simply claiming that a market is ‘global’ is not good enough. Uber’s failed attempt to displace the Chinese market’s incumbent Didi is a memorable example of a failure to accept the reality that local differences are enormously important. We can’t simply copy-paste the same approach we used in North America to the rest of the world. Thus, despite being a team of generalists, we shifted from a global to a regional view.
Scenario 0
While the company places bets on more than just one new area, we learned that we had to be more careful in choosing where to focus our efforts and which products to support. Two main factors play into that decision: the delta between a new products status quo and attaining both sales and technical readiness for it, as well as the product’s potential total addressable market.
The trajectory of moving from weak to strong sales and technical readiness respectively, exemplifies the pace at which a product attains product-market-sales fit, as described by Jyoti Bansal. Variables that inform the trajectory include market size, technical complexity and disparity to the rest of the product portfolio. Products we focus on tend to have a substantial future market size and the potential to be major revenue drivers, but are still in their infancy on almost all aspects. Once we’ve decided on a product, we guide its development until it reaches its potential, or until we are confident about the product’s trajectory.
Scenario 1
Friction can occur both with regards to “sales readiness”, as well as “technical readiness”. Ideally, the product’s journey will proceed linearly, making equal progress on both dimensions. In reality however, there is a lot of friction on both sides, and one of the areas typically ends up falling behind, meaning the other side has to work extra hard to help the product course-correct. Depending on the order in which friction is reduced in a specific area, the overall strategy might need to adapt. It follows that our team’s job is to manage the reduction of friction on both dimensions and to shift strategy accordingly.
Scenario 2
Scenario two is the most common scenario, partially because it tends to occur when following the “move fast and break things” approach that Facebook famously used to advocate for. In this scenario the product is straightforward for the Sales team, but lags behind in terms of technical readiness. Typically it will be a product out of the core product org, meaning that it is not a “moonshot project” and that it has a target market similar to that of an existing product category. While it’s possible that the engineering challenge was simply underestimated and now lags behind the roadmap by accident, the product was likely intentionally released before being ready. This allows the product team to get early customer feedback ‘outside of the lab’. However it also puts a higher burden on the sales teams.
The challenge from a go-to-market perspective lies in adjusting velocity accordingly, for example by intentionally stalling customers. That might feel uncomfortable and counterintuitive, but that discomfort is greatly outweighed by the struggle of dealing with a multitude of churning customers, who are rightly dissatisfied with an unfinished product. Not only does selling too aggressively at the start put the sales teams in an uncomfortable situation, but it also ends up putting the product teams under unnecessary pressure as triaging customer escalations delays the product roadmap. Despite the discomfort caused, this approach — when managed appropriately — allows the respective product teams to iterate and experiment much faster, as they can see what works and what does not.
Scenario 3
The third scenario is the inverse of scenario two, meaning that while progress is being made on the technical axis, the go-to-market strategy is a lot less clear, or outright neglected. As Ben Thompson remarked in reference to Alphabet’s aforementioned decision to not put all their chips on one of their moonshot factory ideas, and instead deciding to raise outside funding: “One of the big problems with being a science project for a monopoly is the absence of an incentive to get to market sooner-rather-than-later [leading to] an endless pursuit of the perfect instead of the good enough”.
Operating in a vacuum, and not engaging with customers, or failing to think about a go-to-market strategy from the very beginning, will slow things down in the long term. Instead of waiting for the ‘perfect product’ (which does not exist) it’s essential to work with Sales to engage early customers. Given our team’s unique position to synthesise input from those customers, it’s not uncommon for us to strongly advocate for changes in the roadmap based on our interactions. More importantly, the Sales motion associated with this type of new product, including the target buyer and messaging, is likely different from anything else in the product portfolio. Consequently both Sales and Marketing will be struggling to fit the product into known paradigms and rely on our team’s experience to bridge that gap. Overall, adding sales to the product-market-sales fit equation early on serves to add clearer targets, expectations, and a much clearer time frame, avoiding the type of detour outlined above.
Scenario 4
The fourth scenario occurs when technical readiness falls behind, as it did in scenario two, all the while failing to manage sales velocity properly by accelerating too much early on. A product falling behind on its technical roadmap is excusable, however failing to acknowledge it, and overstating technical readiness, typically leads to the product being ‘oversold’ early on, which eventually results in dissatisfied customers. This will affect internal confidence, particularly with the Sales team, for a prolonged period, even beyond the point at which the product has improved. Once that point of improvement is reached, most of the previous efforts into sales readiness will need to be repeated.
As was the case in scenario two, selling too aggressively early on ends up putting the Product teams under unnecessary pressure. Meanwhile Sales grow frustrated with a dysfunctional product that repeatedly falls short of customer expectations. As customer escalations eat up the resources of the Product teams, product improvements slow down, starting a vicious cycle that culminates in Sales teams dropping the new product in favour of the already proven, traditional alternatives, or another supposedly more attractive new product. By the time the product recovers from a technical standpoint, the progress with sales readiness has effectively been lost. At that point the sales strategy effectively needs to be redesigned and training needs to be repeated, with the goal of eventually restoring the confidence that was lost in the process. While generally easy to recover from, this zigzag pattern slows the go-to-market motion, which may profoundly impair its success in the long-term (i.e. by giving the competition time to catch up).
Scenario 5
Unlike the fourth scenario, which can largely be attributed to poor timing on the sales side, the fifth scenario is the result of unforeseen product iteration. At first similar to scenario three, the mistake that caused the initial trajectory to go off-course is a failure to engage prospects and customers early on. But in contrast to scenario three, a significant setback in technical readiness follows, before finally recovering.
In the absence of sufficient early sales efforts the realisation that certain product changes are necessary to achieve technical readiness will never come. By testing an innovation in the field, as opposed to in a vacuum, and trying to get a few early adopters, the zigzag pattern can be avoided and the time it takes to go-to-market is reduced significantly. Furthermore, once it’s obvious that a “zigzag trajectory” is inevitable, instead of falling for the sunk cost fallacy and investing in a “technical rebound”, sunsetting the product altogether may be the more prudent option. If sales readiness is increased while technical readiness declines and the technical team subsequently fails to deliver to revert that trend, it will inevitably erode both internal and external trust in the company.
Part 4: Synthesis
Relatively speaking, Cloudflare is still a tiny company. When our team started out, there was no Sales enablement team. There were no organised marketing efforts for early products. The pricing team did not exist. We filled those gaps, and as the company grew, we were thankful to hand many of them over to specialists in their respective fields. Undoubtedly, our tasks as a team will continue to change dramatically.
In summary, another way of describing our team’s work is to use the analogy of a synthesizer. They are instruments that take a multitude of inputs — literal sources of noise — and compile them into cohesive output: music. Similarly, the NPGTM team synthesizes information about a new product and funnels it back to the Sales and Product teams. Our core strength lies in quickly and efficiently synthesising information, as well as distributing it to the right people at the right time. We use that strength to navigate the trajectory of sales and technical readiness, to facilitate a go-to-market strategy that is as fast and effective as possible. Ultimately, it enables us to help with bridging the gap between a small and a large organization, turning a small experiment into a successful product with a significant customer base.
No matter the stage or scale of an organization, this capability of “bridging the gap” (or crossing the chasm, as Geoffrey Moore called it) will always be vital to ensuring commercial, and thus overall, success of any new product. The approach outlined herein has worked for a very specific environment, at a very specific time. But the learnings can be applied to anyone struggling with the difficult task of releasing new Enterprise products at an established organization. Give it a try.
