PreSales Unleashed | Sales Engineering im B2B Software Vertrieb
🇬🇧 License to Demo: Everyone Should Have a Q (Gadgets & Tools for PreSales at Scale) - With Micah Joel (201)
Tue, 17 Dec 2024
What does it take to succeed for 15 years in the ever-evolving world of technology? With our guest, we'll talk about one of the fastest growing companies in the world and learn how to build effective support systems, manage change and completely redefine pre-sales excellence. You will learn how a team of “support engineers” can transform into a James Bond type of department that excels in breakthrough innovation and strategic direction. What's the secret to keeping solution engineers engaged and effective? How do you balance demand, scale and talent development in a high stakes environment? We'll also talk the fascinating dynamics behind demo engineering and customer-centric strategies, and Jonathan explains why the right organizational structure can make the difference between success and failure in the pre-sales ecosystem. Whether you're in the SaaS or pre-sales industry or just want to know how high-performing teams work, this episode is packed with stories, lessons and practical tips. Micah at LinkedIn: https://www.linkedin.com/in/micahjoel/ Salesforce - Everybody's Demo Org (EDO): https://edo.my.site.com › edo https://edo.my.site.com/edo/s/ ---------- 💌 Discovery E-Mail Kurs: https://m.serockstars.com/DojoKurs 🔗 Alle anderen Links: https://paths.to/presales 👍 Viel Spaß & Inspiration beim Zuhören wünschen dir Jan & Tim Kapitel: (00:04:52) Q Branch: Entstehung und Bedeutung (00:07:15) Aufbau des SE-Support-Teams (00:08:19) Aufbau und Entwicklung des SE-Supportteams (00:10:36) Indikatoren für den Bedarf an SE-Support (00:17:06) Vorteile des SE-Support-Teams (00:24:24) Priorisierung und Kommunikation im SE-Support (00:35:20) Entwicklung und Management von Demo-Umgebungen (00:51:43) Tooling zur Effizienzsteigerung für SEs (01:00:00) Patentierung innovativer Lösungen im SE-Support
Mein heutiger Gast ist eine absolute Koryphäe im Pre-Sales. Er hat 15 Jahre bei Salesforce gearbeitet. Er hat miterlebt, wie dieser Konzern von 2500 Mitarbeitenden auf über 70.000 gewachsen ist. Und er hat dabei, und jetzt halte ich fest, es mit seinem Team geschafft, 6000 Sales Engineers mit einer Plattform auszustatten, die jährlich über 438.000 Live-Demos ermöglicht.
Er hat dabei automatisierte Tools entwickelt, die über 480.000 Arbeitsstunden gespart und somit 42 Millionen Dollar eingespart haben. Also wirklich Wahnsinnszahlen, Wahnsinnsdimensionen. Dieser Mensch hat alles gesehen, wenn es darum geht, wie man Presales, Teams und Prozesse skaliert.
Nun, solche Koryphäen findet man nicht alle Tage, deswegen bin ich besonders stolz, dass wir ihn für ein Gespräch gewinnen konnten. Er ist aber Amerikaner, wobei er inzwischen in München wohnt. Ich habe tatsächlich mich mit ihm persönlich getroffen in einem Podcast-Studio. Wenn du Lust hast, schau mal bei YouTube vorbei, da siehst du uns in dem Studio sitzen.
Also der Mensch ist wie gesagt Amerikaner, spricht deswegen natürlich Englisch. In diesem Moment haben wir die Ausnahme gemacht und ich glaube, es ist es wert. Wir haben auch ziemlich lange gesprochen, knapp anderthalb Stunden geht der Podcast. Wenn jetzt du dich fragst, wann ist eigentlich der richtige Zeitpunkt, so ein Pre-Sales-Support-Team aufzubauen, um noch mehr zu skalieren?
Welche KPIs können dabei helfen? Und was hat das Ganze auch mit James Bond und der Q-Branch zu tun? Dann könnte diese Folge was für dich sein. Voller Inspiration, konkrete Ansätze mit unserem Gast Micah Joel. So, I took the liberty this morning and checked out your LinkedIn profile once again, even though I already looked at it a couple of weeks back. And then I saw you've been working.
So your last stint was at Salesforce. That's correct. And you were there for, correct me, 15 years? 15 years. And that's a long time to work in tech. Wenn ich meinen Großvater anschaue, ja, er hat den gleichen Job für 30 Jahre gearbeitet und in dieser Generation ist das normal. In unserer Generation, ich fühle mich vor allem, wenn ich in der Technik arbeite, wechseln wir die Arbeitnehmer.
Vielleicht sogar nach fünf, sechs Jahren, auch in Deutschland, das ist normal, obwohl wir konservativ sind, wenn es darum geht. Es gibt einige Leute, vor allem, wenn man auf Marktfunktionen geht, vielleicht zwei oder drei Jahre ist ziemlich normal. Du bist da seit 15 Jahren. Was hat dich so lange gehalten?
Well, I would say this. At a company that's growing that fast, every year is different. So it feels like a new company every few years. When I joined, there were 2,500 people. And so everybody knew everybody. We were all in the same building pretty much. And then, you know, within two or three years, they had a new headquarters and there was new work being done.
And the products were different and the markets were different. So it was an interesting job for the number of years I worked there. Also habe ich auch die Plätze verändert. Ich war in San Francisco für drei Jahre und dann bin ich nach Sydney, Australien geflogen und habe dort vier Jahre gedauert. Also eine Veränderung der Szene, neue Leute, neue Märkte.
Und dann ist etwas, was ich sicherlich später erzählen werde, aber etwas, was wir gefunden haben, ist, dass wir, als wir die Solution-Ingenieure über die Jahre erfunden haben, und wir haben es über die Demo gemacht. Wir haben gesagt, was denkst du über die Demo? Was ist dein Niveau von Satisfaktion? Wir fanden, dass es eine Dippe gab. Nach drei Jahren. Neue Leute lieben es.
Nach ungefähr drei Jahren haben die Leute es nicht gefallen. At five and six years, people did like the demo. And seven years of tenure or so, they started to get itchy again and not like the demo. And we took that to mean that it wasn't us, but it was something about the cycle of three-year itch, seven-year itch. And at seven years, I got itchy and I stopped being a solution engineer.
And this is when I went into the whole demo field in it. So I basically changed jobs at seven years, even though it was within the same company, and moved to London, so I had a new place again. So it was, I think, at least for me, even though 15 years is a long time, it was an ever-changing job at an ever-changing company. So it made it a little bit easier.
I mean, the time when Salesforce had 2,500 employees, that's a very different animal to what it is today.
It was. Es war lustig. Es ist immer noch lustig. Ich kann nichts schlechtes über die Firma sagen. Ich hatte wirklich viel Spaß dabei. Es ist eine gute Firma mit einem guten Herzen. Aber es ist ein sehr anderer Charakter, wenn es eine kleine Firma ist, als wenn es eine große ist. Und um durch diese Phasen zu sehen, wirst du der alte Mann der Berge werden.
Oh, als ich angefangen habe, mussten wir, weißt du, die Steine auf die Höhen drücken, beide Wege, richtig? Ich hatte keine Leute, die mir meine Demonstrationen helfen konnten. Es gab keine Lösung, keine Unterstützungorganisation. So it was definitely a different time. But I think you develop closer camaraderies at a smaller company.
There were 10 of us on my team and we all worked elbow to elbow out of San Francisco. Later on, your teams distributed. By the end of my tenure there, I had 20 people on my team and I had met three of them. And the other 17, either through COVID or other reasons, I hadn't actually met in person before. They were all in different countries.
So the camaraderie, I think, is much closer when you're physically close with people, but also when the company is smaller. 100%.
Und jetzt hast du bereits einige von den Fakten verlinkt, die wir heute weiterentwickeln werden. Also du hast gesagt, hey, Solution Engineer Support Team. Und tatsächlich, wenn du auf dein LinkedIn-Profil gehen würdest, was ich dieses Morgen wieder gemacht habe, sagt es, dass dein letzter Titel war Senior Director Q-Branch.
Nun, wir haben hier ein paar deutsche Zuhörer, also Q-Branch ist vielleicht nicht ein Wort, das jeder kennt, aber ich bin sicher, dass jeder James Bond kennt.
So maybe you can take us there. What's the story with the name? I'm so glad you asked. So in every James Bond film, there's this scene, usually near the beginning, where James Bond meets this guy in like a tweed jacket. And that guy gives James Bond all the tools that he uses. He gives him the exploding pen and the watch with the laser beam and the car with the missiles.
And that guy's name is Q. That's his role. He's Q. And everyone has code names in MI6. So he's Q. But the people behind him, usually in those scenes, there's a couple guys behind him in lab coats. And they're usually like blowing up a mannequin or something. Und sie sind wie coole Nerds. Sie machen diese interessanten, edgigen Sachen. Sie nutzen die neuesten Technologien.
Und diese Organisation, die Q runs, heißt Q-Branch. Und so haben wir den Namen für unsere Organisation genommen. Die Organisation existierte bereits. Sie hieß Sales Support Engineering. Ein sehr sexierter Name. Und so haben wir uns entschieden, etwas etwas mehr zu ermutigen. A more shiny surface. A much shinier surface. And it did a couple of things.
It was actually really fun because it gave us some branding language. So for the first couple of years of QBranch, we got to do some, you know, I always had like an Aston Martin in my slides because James Bond drives an Aston Martin or we'd have sort of spy themed stuff.
But what it also did is it gave us the ability to recruit people into the organization because we went from just being an organization to being a cool organization. Having a cool name, right? You wanted to be there. QBranch is where like the smart people went, right? The cool nerds. So it made it a lot easier. Wenn du gesagt hast, hey, willst du für Q-Branch arbeiten?
Und sie sagen, oh ja, ich habe alles über dich gehört. Das hat uns einfach viel Talent erzeugt.
Es ist so lustig, wie so ein kleiner Detail so eine große Unterschiede machen kann. Aber ich freue mich wirklich auf die Analogie. Und um die Analogie zu fortsetzen, wer ist James Bond in diesem Szenario?
Oh, die SE for sure, right? And I think that's one of the reasons it worked. Because SEs, you know, they're at the pointy end of the sales cycle. They're out in front of the customers. They're the agents out in the field. I mean, even the terminology in sales is the same as with Spycraft. So the SEs are out there. They're exposed. They're dealing with competitors. They're dealing with customers.
And so it made it really nice to think of ourselves as equipping them for their mission. Okay, you know, your mission, if you're going to go out and sell this customer, here's the tools you need to do that. Und es hat auch mit ihrer Selbstbildung geholfen, weil wir sie nicht ganz als Agenten bezeichnen, aber die Bedeutung war da.
Und die Bedeutung, dass wir ihre Beine hatten, war auch sehr wichtig. Wir waren das Team hinter den Szenen, das sie erfolgreich gemacht hat.
Du bist der Protagonist, du bist der Superstar und wir helfen dir.
Wir sind wie ein unterstützender Charakter, wir sind die Komedien.
But that already triggers my first question. So obviously, solution engineers, sales engineers were at the center of the services that you provided. And we can go a bit deeper in what that entailed in detail. But were account executives, customer success, they were not part of the picture, not part of your internal customer group, so to say?
They weren't explicitly part of the internal customer group. Aber eines der Dinge, die ich über die Jahre gelernt habe, ist, dass Demos absolut alles anfangen. Also gab es AEs, Account-Executives, die Demos machten, besonders in der kleinen bis mittleren Business-Area, weil Lösungs- und Ingenieur-Ressourcen niedrig sind. Also mussten sie ihre eigenen Demos machen.
Also benutzten sie die Tools, die wir bieten. Und in der Tat haben wir später angefangen, Tools bei Account-Executiven zu targetieren, auch einfache Demos, die sie einfach erledigen konnten. Bei Customer Service kamen auch neue Produkte raus. Wir waren meistens der erste Team, um sie irgendwo zu implementieren.
Customer Service nimmt also ein Demo-Environment und verwendet es, um den Kunden zu zeigen, was in der Pipe herkommt. Wir hatten also einige offizielle Publikationen. Und wir hatten immer interne Gespräche innerhalb unseres Teams darüber, ob wir unseren Scope erhöhen sollten, ob wir mehr Finanzierung bekommen, ob wir mehr Aufmerksamkeit bekommen, wenn wir sagen, dass wir alles unterstützen.
Aber am meisten der Zeit, weil wir in der Organisation verabschiedet waren, das war die Solution Engineering Organisation, und sie fundierten uns, war es besser für uns, die Arbeit, die wir gemacht haben, zu positionieren, wie es SE-fokussiert war.
Jetzt würde ich gerne an der Reise beginnen. Vielleicht können wir auch das Salesforce-Exempel nehmen, weil das das ist, wo ich für es bin. Hat Q-Branche existiert, oder was auch immer es damals genannt wurde, als die Firma 2500 Mitarbeiter groß war, oder war das etwas, was während deiner Studie entstanden war?
Ja, ich wünschte mir, dass ich dafür Kredit nehmen könnte, aber ein Mann namens Todd Jansen, der Vater von Demo- und Demo-Automation bei Salesforce, er hat die SSE-Organisation gestartet, die Solution Support Organisation, Solution Support Engineers. Und was es wirklich angefangen hat, war nur ein Team von talentierten College-Graden. Es war ein Rekrutierungsprogramm.
Er bringt diese jungen Ex-Studierenden ein. to do the scut work that the SEs didn't want to do. So there was a lot of work on demos that took time and you could put in a request to this team and one of these talented, relatively young employees would take this request and would do what needed doing, branding or loading data or changing something. And so it was a labor of folks.
And from that grew a part of the team that started focusing on demo environments themselves because SEs were kind of maintaining their own demo environments at the time. And so he started to have a couple of people kind of half timing. There was only one demo environment at the time. So we'll keep an eye on this demo environment and make it better. So the organization existed.
But like I said, it didn't have a particularly sexy name, but it was already well liked by the SEs. Anyone, you know, when I was a solution engineer, I would definitely put in an SE assist and someone would help me with things. In particular things I wasn't technical enough to do. Most of these folks were coming out of technical difficulties. Programme oder Computer-Science-Programme.
Und wenn ich also etwas wirklich Flaschiges in meiner Demo machen wollte, aber ich nur nicht die Möglichkeit hatte, es zu tun, konnte ich einen von ihnen engagieren. Und, weißt du, wir gehen zurück und forth und sie zeigen mir dieses coole, glänzende Ding. Ich könnte den Kunden ein Beispiel zeigen, zum Beispiel, etwas, was wir auf unserer Plattform tun können.
Was würde ich verstehen wollen, was die Ausstattung des Departements betrifft? So you say, okay, even at 2,500 employees, there was already the first instance of that function available. Looking back at my own history of SaaS employers, we didn't always have that. There were a couple of examples where we did have it and we can maybe talk about those as well.
I would like to understand what are the symptoms, so to say, to look out for that tells me, hey, maybe now is the time zu einer solchen Solution-Engineer-Support-Team. Und ich möchte es in den Kontext stellen. Wir sprechen hauptsächlich mit deutschen Firmen. Wir haben auch hauptsächlich deutsche Zuhörer in dieser Konversation.
Wenn du zu irgendwelchen Events gehst, wie Events, wo SaaS-Mitglieder zusammenkommen, wo Go-To-Market zusammenkommt, Germany or maybe even like venture capital funding and startups and scale-ups and so on. And you go around and you ask anyone, hey, what's pre-sales? They quite often think we are talking about cold acquisition. We're talking about cold calling. We're talking about cold emailing.
So the front line of the funnel, so to say. So what I'm trying to get at in our country, in this ecosystem in Germany, the sales engineering and pre-sales function itself is not even that, let's say, popular yet. I think some companies have
realized they needed, to give one concrete example, and there's a startup or not startup anymore, they are unicorn by now, but they were funded here in Munich, founded and funded in Munich, Personio, right? But for the longest time they didn't have the function. Now they are big enough and they realized, okay, we need it. Now they have a team of 10 servicing Europe. But this is...
Quite contrary to most SaaS companies that come from the US, where it's basically a given, we need pre-sales. Now you tell me, okay, there's even an idea to be even one step further. Not only do we need pre-sales, but we need a pre-sales support function. I would like to distill it out. What are the indicators that tell me we need a pre-sales support function, even on top of our pre-sales team?
Ja, ich würde sagen, es gibt ein paar Dinge. Wahrscheinlich die erste Sache ist, wenn du bemerkst, dass SEs eine schwere Ressource sind, wenn Sales Management oder wenn Sales People über SEs kämpfen und wo es nicht genug SEs gibt, um zu gehen. Ich denke, das ist ein wirklich gemeinsames Problem. Ich denke, wahrscheinlich jede Firma hat dieses Problem.
Weil ich glaube, es gibt wirklich keinen Weg, genug SEs zu haben. Wenn du einen SE eins für eins mit jedem Verkäufer vergleichst, dann schrug die Verkäufer mehr ihrer Arbeit auf den SE. Also gibt es keinen Weg, genug SEs in einer Organisation zu haben. Und SEs sind teuer. Also willst du sie nicht haben. Ich glaube, das ist eine Sache.
Eine Sache, die Sie bemerken, ist, dass Ihre SEs niedrig sind und Sie anfangen, den Effekt auf Ihren Geschäft zu fühlen, dass Meetings gedelayt werden, weil eine SE-Resource nicht vorhanden ist. AEs demoen sich selbst, weil sie keine SE bekommen können. Und manchmal sind diese Demos einer weitgültigen Qualität, ich sage es charitativ.
Über 1000 Menschen im Vertrieb und Pre-Sales von Unternehmen wie SAP, Salesforce oder Lina X profitieren bereits heute vom Disco-Deck. Mit den 60 wichtigsten Fragen rund um Entscheidungsfindung, wirtschaftliche Faktoren, Technologie und fünf weiteren Kategorien bringt es deine Discovery auf die nächste Stufe. Das Disco-Deck ist in deutscher und englischer Sprache verfügbar.
Klick dich jetzt rein und sichere dir dein Exemplar unter discodeck.shop. Direkter Link findest du auch in den Shownotes. Vielen Dank für deinen Support und jetzt zurück zur Folge.
So thing one is just seeing the resource constraint and realizing that you have a problem with the number of SEs compared to the number of deals that you have. I'd say a second indicator is the language that people use. When an organization says things like, oh, SEs are heroes, they do everything, they're so important to us, that tells me right away that their SEs are overpriced.
Die SEs machen eigentlich alles. Sie sind überall, an allen Zeiten. Es gibt viele konkurrierende Prioritäten. Und so sind diese SEs sehr dünn.
Und das sagt mir, dass es eine Möglichkeit des Burnouts gibt, eine Möglichkeit des Unhappnisses der SEs, dass sie fühlen, besonders wenn man eine SE mit einem AE paart, wo der AE all die Glorie bekommt, wenn der Deal schließt und sie die SE auf den Kopf packen. Sie bekommen manchmal einen Teil der Kommission, aber nie den Teil, den der AE bekommt. Ja.
You can see the impact on the business and you can also hear the impact in the organization. And those are the things that tell you that you need to do something to help SEs be better at their jobs, not just more SEs. But how do you take the SEs that are there and help them be more successful, help them go home at night after, you know, before 7 p.m., help them not work weekends.
And when you hit that moment, that's when you are at the right spot to consider a supporter.
I fully understand what you mean. I'm still trying to puzzle together, to be honest. Because now I'm thinking, you rightfully say, what do we have in SaaS business? We have an AESE ratio, maybe 1 to 3, 1 to 4, 1 to 5. I've seen cases of 1 to 10, like in the S&P market or so. Yep. So that those are the typical ranges we see.
Now, as you rightfully say, and this is, I don't want to start building silos here, but it's maybe in the natural way of working that yes, AEs are demanding our capacity and they will do so in any case.
Und ich frage mich jetzt auch, ob es auch ein Element gibt, um sicherzustellen, dass ein SE die richtigen Möglichkeiten hat und qualifiziert ist und bestimmte Checkboxen erfüllt, bevor wir sagen, dass wir dir diese Fähigkeit geben, um mit diesem SE zu arbeiten. Du wirst also immer den Fall haben, dass es mehr Anforderungen gibt.
Gibt es vielleicht bestimmte KPIs oder etwas, das mir sehr konkret sagt, dass das etwas ist, das ich nachvollziehen muss?
Ja, ich würde sagen, eine der Dinge, die man tun kann, und ich wundere mich, weil es etwas wirklich Nützliches ist und es auch etwas sehr Bedauerliches ist, nämlich Aktivitäts-Tracking für Pre-Sales. Wir haben Aktivitäten seit 15 Jahren bei Salesforce getrackt. Und niemals habe ich jemanden gesehen, der etwas mit dieser Information gemacht hat, das besonders nützlich war, richtig?
Und das ist wahrscheinlich nicht recht. Es waren wahrscheinlich Exekutive, die lange Gespräche darüber hatten. Aber auf die meiste Art und Weise war ich nicht zufrieden mit diesen Gesprächen. Aber die SEs füllten ihre Aktivitäten jede Woche. Und jemand würde sie irgendwo aufrollen. Und ich sah die Roll-Ups.
Wo wir in späteren Jahren eine Distinktion gemacht haben und wo ich mich konzentriert habe, als wir die Daten hatten, war, wie viel Zeit die SEs vor dem Kunden sparen. Yes. And how much time are they spending doing everything else? Yes.
And our theory, and I think this is probably true, our theory was that the more time an SE spends in front of a customer, the more successful the SE is and the more successful the customer is. Right? SEs are clever people, they have lots of insights, they can guide a customer, they can set their expectations, I don't need to lecture you on this.
So I think the ratio of customer-facing time to non-customer-facing time is what you can look at. And if your SEs are spending more time behind the scenes than you'd like, and I don't think there's any threshold for that, that's when a support organization might make sense, because they can offload some of that non-customer-facing time.
Ich denke, das ist ein guter Hinweis. Eigentlich erinnere ich mich an eine Leader-Konversation, die ich vor ein paar Monaten hatte. Und sie sagten, wir verringern unsere Aktivitäts-Tracking, aber wir wollen wirklich verstehen, wie viele Stunden pro Woche wir vor Kunden spenden. Und für diese Person war das einer der Haupt-KPIs, die er schaut, um auch die Effektivität des Teams zu beurteilen.
Das ist ein tolles Beispiel. Danke für das. Now, I would like to understand a little bit, let's say, the entrepreneurial side of it, or let's say the business aspect of it. Maybe that can go a bit of a direction of looking at humans at capacity, but maybe you can bear with me for a second.
My theory or the reason why I always tell people when pre-sales is a good idea is that you basically, you have a complex buying center, which means there's maybe 10, 15 stakeholders that you need to sort of convince that your solution is the right fit. In order to cater for these 15 people, it makes sense to match eye-to-eye level on expertise.
So if you let, for example, an AE talk to someone who is super technical, they might not be able to lead that conversation eye-to-eye level, which means, hey, maybe a pre-sales resource could be the right fit here because they would be able to and therefore convince this person that we are a great fit. Now, you rightfully say SEs are a costly resource.
We look at the salary reports, there's consensus out there, they publish this once a year. I mean, this is not incentivized by them or anything like that, but I'm reading this report every year because I think it's great information. It tells you something. SEs are earning great money in Europe and in the US.
Now, if we're looking at business efficiency and we're now saying we would like to maximize the time in front of the customer of our well-paid SE resources, is there an element that the SE support function can be, and you already hinted at it and I would like to understand it a bit better, when you say, hey, we were...
recruiting people from university and so on, probably those are not as expensive as a senior SE who has been doing the job for 10 years, but is then locked in the basement for 10 days to build a demo environment, right? You see where I'm getting at. I'm trying to understand the business impact of having such a role.
Yes. So one thing I think you should consider is that it's a really interesting role to hire people into because you're not just hiring someone who can do the work, right? Because you're hiring adjacent to an SE or a pre-sales organization, You're looking for people who have a wider view when you're recruiting.
The reason I point that out is because we found that that team of sales support engineers, of SE support, was a great feeder team for the SE organization. You're hiring pre-SEs to do the less fun work. but to have exposure to the SEs who are doing the fun work. Get in front of the customers, go eat dinner at fancy places and stay in exotic locations.
And if you're lucky, but it gives them exposure to that role. And so you're basically priming a bunch of relatively young people toward the SE role. And once they see it, it's hard when you see how SEs live and how awesome their lives are and how fun the job is.
It's hard not to want to be an SE, unless you're more of an introvert, in which case the other place we saw a lot of value was feeder team for product marketing and product management. So again, these weren't just, we weren't just hiring coders out of school, though some of them were more technically inclined, some of them were brilliant coders, so I don't want to take that away from them.
But we found that it was a great place to start them in the company and see their performance. We could see where their strengths were because there was a variety of work. And then usually after two years or three years in that role, they had some pretty good opportunities around the business because they had made a name for themselves in pre-sales. It's highly visible.
People were singing their praises and they could go have their pickup jobs.
Ja, das ist eine fantastische Insight. Und egal, zu welcher E-Leader ich spreche, der Nummer eins Schmerzpunkt ist, den richtigen Talent zu hirten.
Also ich fühle mich, dass das tatsächlich mehr als nur ein Problem ist, die Zeit vor dem Kunden zu maximieren, mit sinnvoller Interaktion und hier eine Unterstützungsfunktion zu haben, die mir mit dem hilft, aber auch tatsächlich zu rekrutieren und den Talent zu entwickeln, um in Positionen zu führen, die wirklich, wirklich schwer zu hirten sind.
Ja, und stell dir vor, du kannst sehen, wie sie funktionieren, bevor du sie hinstellst, richtig? Du kannst sehen, ob sie erfolgreich sind. Du kannst ihre Interaktionen mit SEs anschauen. Ja. Denn die meisten populärsten SE-Support-Mitglieder werden von den SEs eingeladen. Hey, ich will, dass sie daran arbeiten. Ja.
Und viele der Leute, die SSEs waren, als ich bei Salesforce angefangen habe, gingen auf tolle Dinge. Sie wurden SEs. Manche von ihnen sind Vise-Präsidenten von dem und dem jetzt. Sie haben mich in meiner Karriere übernommen, von dem ich stolz bin. Aber sie waren mehr ambitioniert, als ich jemals war. Aber es ist wirklich ein guter Ort, sie zu beobachten.
in adjacent to the role and to see if they would be a good fit. And they'll tell you, because once they've been in that role a year or two, they know what they want to do next. They have a pretty good idea, because they've been doing, you know, they've been doing configuration, they've been doing slides sometimes, they've been doing strategy discussions with SEs.
In some cases, they even get some face time with the customer. I'm sure we can talk about that more too. But yeah, so anyway, it really primes them in a good way to know where they want to be in the business, and it helps you understand where they'd be a good fit as well.
Do you have an opinion on what is a good ratio? Let's say I have an SE organization, global organization, we have 100 SEs. How big should my support team be like?
Well, I'll tell you, I think there's no lower bound. I think any number of SE support people is useful because not every SE will use them. So I think in my career as an SE, I probably put in five or six assists and I knew people who put in 50 or 60, right? So different SEs use them different ways.
I liked getting in the product and I liked, I found in my case, in most cases, it was easier for me to just sit there and iterate than it was to try to describe to somebody and have them iterate every two or three days. So not everyone in the organization will use them. But having anyone in the organization that an SE can turn to for help will be immediately useful.
And so I think it's one of those things. You don't need to start with a team of 10. You can start with a team of 3. And you'll know right away if the demand is there to grow the team to 10. It's a good problem to have. If you have 3 people and there's constant requests coming in, great. Then you're doing the right thing.
Und wenn die Anforderungen, die vorhin erwähnt wurden, strategische Anforderungen sind, nicht nur, oh, ich fühle mich nicht so gut, aber ich brauche Hilfe oder ich habe tatsächlich nicht Zeit, dieses wichtige Ding zu tun, das für dieses wichtige Deal ist.
Und du kannst diese Anforderungen anschauen, wenn es nur, du weißt, ein einfaches Ding ist, das ein SE sollte wissen, wie man es macht, dann, dann expandierst du nicht das Team. Aber wenn sie wirklich mit Dingen kommen, mit denen du die Fähigkeiten dieses Teams nutzt und die Fähigkeit der SE, mehr Arbeit zu tun oder vor dem Kunden mehr zu sein,
Dann gut, hire mehr Leute und bilde das Team auf, bis du einen Moment hast, in dem du fühlst, dass du die Anforderungen von den SEs managst.
Bevor du Salesforce verlässt hast, was war die Ratio?
Oh, ich weiß es eigentlich nicht. Ich entschuldige mich dafür. Das Team von Demo-Ingenieuren, wir nennen sie Demo-Ingenieure, die eine Anforderung von SEs nahmen, wurde eigentlich von Todd Jansen gesteuert, also von mir an der anderen Seite. Aber ich möchte sagen, für 6.000 SEs gab es, ich nehme eine Ausgabe, zwischen 40 und 70. Ich meine, es war eine ziemlich große Anzahl. Okay, also rund 10%.
Rund 10%. Und es war in einer verschiedenen Kapazität. Also es gab strategische Demo-Ingenieure und technische. Und so hat es sich bei dem Zeitpunkt gewachsen. Und du würdest Designern involvieren oder du würdest UX-Menschen involvieren. Aber in den frühen Tagen war wirklich jeder Nummer gut. Zwei war gut, fünf war gut. If they're overburdened, great. Hire more. They're relatively inexpensive.
And they don't require a lot of training. You can pull them right out of school and they're already useful to you.
But I think it's a great indicator. And right, of course, every situation, every company is different. But now we have already like two numbers that could be an indicator that it's time to think about the function first. We have the number of hours I'm spending in front of my customers.
And secondly, if my team is larger than, let's say, 10 people, maybe it makes sense to dedicate one of the headcounts towards like a support function for the rest of the team.
Yeah, and keep in mind too, so we're talking right now specifically about what I call the SE-assist process, which is, I need an extra pair of hands on a deal. But if you're worried about that person not having enough to do, don't worry, because there's demo environment management, that's a whole job in itself, but if someone needs to part-time it, that's fine.
There is tools development, someone who watches provisioning and see if they can make that better. So there's a whole field of things that they could be doing. There's support, where an SE has a technical problem and they turn to someone to help them solve it. So that role can be one of many different functions. And that's why we ended up specializing though.
So the team I ran ultimately was the demo architecture, demo environments, tooling, support. And then the other side of the house was more the deal-focused extra pair of hands stuff.
Ah, okay. So if I'm understanding correctly, in your case, there were actually two main teams, one focusing on demo architecture and integration and so on, and one focusing specifically on deal support.
Correct. We called the deal team deal and we called my team scale. Das war gut. Und ich denke, es ist ein wichtiger Splitt, weil wenn du die gleichen Leute hast, die am Deal und am Scale arbeiten, werden die Deale immer Präzision nehmen. Der Deal kommt in, oh, das hat die höchste Visibilität, es ist super wichtig, es ist sehr strategisch, wir brauchen alle Hände auf dem Deck.
Und so alle Leute, die die Managung und Erhaltung deiner Infrastruktur, deiner Architektur, deiner Demo-Environment, deiner Tooling, werden von dem, was sie tun, gejankt, um an diesem super wichtigen Deal zu arbeiten.
So that split was really good because it meant we could firewall the team that was making everybody better, raising the level of all boats from the kind of fire drill world of deal to deal work. And so that as well, you can do that split early.
You can have four people who are doing deal work and you can have one or two people who are doing the scale work and you still get a ton of value out of both of them without having to pull everybody into every single deal.
Now, you described now sort of the request process, right? And of course, this should probably ring familiar to many people in SaaS, because the request process is something we in Pre-Sales are exposed to on the receiving end, in any company basically that has Pre-Sales, right?
There's sellers out there, they're looking for deals, they identify opportunities, and then they say, hey, here, I need support, and they log a request. Well, mind you, in a company that already has reached that level of maturity, they will be able to log a ticket, maybe in CRM or wherever, right?
In anderen Fällen kriegst du eine Telefonnachricht und sagst, hey Tim, nächste Woche Demo, nächste Woche Dienstag, show up for a demo. Und dann ist es ein bisschen mehr unstructured. Also in einer Form gibt es einen Request-Prozess. Was würdest du empfehlen, wenn jemand sucht, so eine Funktion zu erzeugen?
Welche Kommunikationskanäle würdest du empfehlen, die für diese Team-Interface verfügbar sind?
So I think a request process is good. It's frustrating because you just want to sit down and talk with somebody, right? And just say, hey, I need your help. Can you do this for me? And early on, typically you can. But once the team grows to a certain size, I think a request process is important. It's important for a couple of reasons. Let's talk about what happens downstream.
It's important because there will be competing priorities. As a solution engineer, and I'm sure every solution engineer has heard an account executive come to them and say, Es ist lustig, weil es wahr ist. Es ist wahr, richtig? So AEs and SEs in our defense aren't that good at prioritizing. What I'm working on is the most important thing in my world.
So a request process, this gives that organization the ability to prioritize. And if you have a manager of that team, they can put them in priority order and say this first, this second. The second thing about the request process is, when we talk about, you were worried about locking these folks in the basement and leaving them to rot there.
The thing too that the request process gives them is the ability to measure their impact. So how much work did I do? What was the value of the deals that I worked on? What was the level of satisfaction of the SE that engaged me?
And those three things, if you have leaderboards or whatever, or even you just use that to measure their effectiveness, is a great way for that person to go make their case, the support person to make their case that they're valuable, they've made a contribution and that they could be an SE or they can move up in the organization.
So it gives them a motivation to do the job because they can see their numbers tick up on the dashboard as they do it. Der andere Teil des Request-Prozesses ist, dass der SE eine kleine Stärke im Spiel haben muss. Denn wenn ich einfach etwas über die Wand werfen kann und sage, ja, du tust es, dann werde ich es.
Und ich werde dir einfach ein bisschen halbe Informationen geben und du wirst dein Bestes machen. Aber wenn ich sitzen muss und ich muss schreiben, was ich will und es beschreiben muss, und ich muss darüber nachdenken, was ich tun will, und ich kann es nicht einfach über die Wand werfen, dann bin ich in diesem Prozess ein bisschen investiert. Und einige SEs sagen, komm, sieh mich an, richtig?
Und so, du weißt, bitte mach das, komm, sieh mich an für mehr Details. But it at least forces the SE to give some thought to what they're asking another human being to do. And that, I think, is what that request process is really powerful for, where the SE has to think about stuff in advance rather than just show up, throw up and then walk away and hope that it gets done correctly.
And insight on that, someone I was talking to recently in a demo engineering organization said about 50% of their time is spent going back and forth with the SE. Nicht in einer schlechten Art und Weise, aber klar, sie zu senden, Kopien von dem, was sie gemacht haben, um sie aufzunehmen, sie zu fragen. Also sind sie in der Hälfte ihrer Zeit auf Interaktion und in der Hälfte ihrer Zeit auf Bildung.
Das ist ein faszinierender Punkt. Der Moment, in dem Sie einen weiteren Rollen vorstellen, richtig? Ja, wir haben über die Business-Skalabilität von Pre-Sales gesprochen. Ja, ich versuche, mit Verkäufern und so weiter zu leveln. But it also introduces friction between AEs and SEs.
What you're saying is, it also introduces friction between SE and the SE support function, even though, of course, we are all supposed to pull into the same direction.
Ja, es ist Management. Ich meine, es ist ein klassisches Problem in einem Unternehmen, nämlich Menschen, die gute individuelle Beitragspartner sind, sind nicht unbedingt gute Managere. Wenn du jemandem Instruktionen gibst, was sie tun müssen, dann managst du sie in einer kleinen Art und Weise.
Und so ist es eine Art, Menschen zu fordern, die nicht unbedingt in Management-Rollen sind, zu denken, was sie jemandem zu tun fragen und ihnen klare Instruktionen zu geben, sodass sie nicht nur sagen, oh, mach das Ding. Und dann, wenn es nicht wiederkommt, wie sie es wollten, werden sie wütend, weil die Person ihre Meinung nicht gelesen hat. So it goes both ways.
Having been an SE and being on the other side of this as well, I'm sympathetic that an SE is busy. And sometimes it takes more time to make your request than it just takes to do the darn thing yourself. In which case, maybe you should do the darn thing yourself.
Now, you said the first purpose of the request process was also to prioritize accordingly. I mean, having been an SE-Leader myself, I'm looking at the number of requests I got from the sales team to my team.
And for me, it was quite clear, if there is a request for support, I would look at the opportunity, I would look at the size, I would look at sort of the maturity of the customer and so on and then judge based, okay, are we prioritizing this or are we putting this further down and we are focusing on other things?
Was waren, sagen wir mal, die internen Qualifikationskriterien, also zu sagen, die Sie ausgesucht haben, um zu priorisieren, ob ein SE-Support identisch oder unterschiedlich ist?
Ja, ich denke, es ist das Gleiche. Und noch einmal, das war im Vergleich zu dem, was ich gemacht habe. Aber weil ich das Team nutze, weiß ich, was sie von mir als SE-Supporter fragen. Ja. Deal-Size, Deal-Closed-Date. Ist es ein neuer Kunde oder ein existierender Kunde? Abhängig davon, was die Firma versucht, zu machen. Als ich da war, war der Wachstum alles, also waren neue Logos wichtiger.
Und dann, wie viel Arbeit war involviert? You know, was it a quick job we could squeeze in today? Or was it something that was going to take two weeks of someone's full-time effort? And that helped determine where you were in the queue. And it also gave the support organization management the ability to kind of chide the SEs who showed up five days before a meeting with two weeks of work.
Gave them the opportunity to push back a little bit and say, hey, you've just asked for something that is going to take, we're going to have to move heaven and earth to get this done. Ist das wirklich so wichtig, wie Sie es denken, oder müssen wir das in fünf Tagen machen, oder ist es nur eine Verlängerung Ihrer Seite?
Es gibt also an beiden Seiten die Möglichkeit, ein bisschen darüber zu diskutieren, was sie wollen. Die Priorisierung wird also von der gleichen Art und Weise gegründet, wie es in der SE-Welt ist.
Was so lustig ist, die Symptome, die Sie beschreiben, sind genau die gleichen Symptome, wenn wir über AE und SE-Kollaboration sprechen. You agreed on a demo next week, Tuesday, and you're giving me your discovery notes. And maybe you did a really good job. Could be the case, right? And based on that, I would take two weeks to actually build something meaningful together.
And we have literally like three days.
Yep. It all rolls downhill, man.
It's so funny how, I mean, I think it's also a good indicator. Sometimes it's good to look into the mirror and wonder whether what you're complaining about is not something that you actually behave yourself sometimes with.
And I get it. We're myopic. And especially in sales. Sales attracts narcissists, and I'm one of them, right? It attracts people who are deadline-driven and who are driven by the attention and possibly the money. And SEs are a step away from a direct salesperson, but they're still very much in the game. So I get it. My deal is the most important deal. It always will be.
And so sometimes you just need some coaching. And I like to think of it that way. There's pushback, but there's also like, hey, we'll do it this time for you. But next time you really need to give us more warning. And, you know, as these are smart people, they'll figure out, I'm not going to get any more favors from this organization unless I play by their rules.
So it doesn't mean they just close the door on them, but it means there's a conversation there and you have kind of evidence of both sides of that discussion.
So now I was coming from the communication channels and the first thing you said was, hey, of course, there is sort of like a formal way to lock the request and then the SE support team will prioritize and so on. We talked about it. Waren es auch andere Kanäle, die mit deinem Team verfügbar waren, wie zum Beispiel ein Slack-Kanal, wo du eine kurze Frage stellen konntest?
Oder war es auch ein Weg, sie einfach anrufen zu lassen, wenn du eine kurze Antwort brauchst oder so etwas?
Was waren da andere Dinge? Ja, also wenn du bereit bist, die Team zu finden, die das Deal-Focused-Stuff gemacht hat, dann kommst du zurück in meine Welt, die, ich würde sagen, mit Dealen verfügbar ist, aber das Scale-Stuff. Yes, so I had four teams. I'll get to your answer in a moment. I had four teams.
I had a team of people who managed demo environments specifically, a team of people who built tools to automate common SE tasks, and a team of people who were re-architecting the demo environments because we were having some challenges with the scalability of them, and we can talk about that. That's where the patent came from, if you remember my patent.
Not my patent, a patent that was generated for my team. And the fourth team, getting to your question, was a support team, specifically for solution engineers. So it was not a deal support team. It was a team of people who, if you had a technical problem with your demo environment, they could help you hunt it down and figure out what's going on.
The team could answer your questions about when is a particular feature coming down the pipe. They could go interface with product management and go ask them. They could find out if a new feature was going to be implemented in the demo soon. They could answer questions about other tools that the SEs used or other processes. Hey, who do I talk to about this thing?
So we had a team of, I think it was four people, six people. Their whole job was to sit on the Slack channel. Initially it was tickets and then we moved to Slack when we purchased Slack. Their job was to handle SE-Requests in the heat of battle, right? So an SE is out there in the field and something's gone wrong. They have someone to turn to who doesn't go, have you tried rebooting?
But says, I know you're an SE, right? I know you're smart. I know you've tried all the obvious things. Let's see if we can help you with this more complex. Okay, got it.
Really nice. All right. So that actually provided some clarity in what your team in general were doing. And maybe it's worthwhile to just talk about the different four different aspects that you just mentioned. Well, on the fourth one, we already have some clarity.
The first one you said was, and if I remember correctly, you said basically building demo environments was the task or the main responsibility of the first team. And I want to quote something because I found this quite cool how you've written this up. And by the way, anyone who's listening, I would really recommend check out the LinkedIn profile of Micah.
He has in his job description, I think, nailed what it means to talk about value-based contributions. We're all talking about like these talk tracks, they happen all the time, right? Our software is so efficient and we are so effective, blah, blah, blah, blah, AI insights and so on, all that nonsense. But you really put it down to number what your contributions were.
And I want to read out one piece because that's quite interesting. Ich war ziemlich überrascht. Equipped 6000 SEs with scalable platform for delivering 433,000 live product demos each year. Yeah, I mean, those are numbers you have to digest.
Yeah, the scale. I'm often shocked by the scale we're operating at. When I think about it, when they let little old me be in charge of all that, I was like, what are you doing? Why are you letting me do this? This is important to the business. Ja, also lasst uns darüber sprechen. Also danke, danke, dass du meine eigenen Worte gegen mich benutzt hast.
Salesforce hatte, als ich die Demo-Environment neun Jahre hervorragte, gab es eine. Es hieß die Simple Demo Org. Es war alles, was einfach war, aber es war ein einziger Demo-Environment, in dem fast jede Demo alles enthalten hatte. Wall-to-Wall, Salesforce. Und das hat für eine Weile funktioniert. Aber Salesforce begann, Firmen zu kaufen.
Und nicht alle dieser Unternehmen hatten die gleiche Architektur wie Salesforce. Dann gab es zwei Demo-Umgebungen. Und dann war das simple Demo-Org zu kompliziert. Und so haben wir das Clean-Demo-Org geschaffen, das ist ein leerer Demo-Org, der alles konfiguriert hat, aber nichts wirklich drin ist, damit deine Plattform-SEs es nutzen können. Und dann haben wir alle Demo-Orge geschaffen, um
Account executives to be able to demo and even customers could demo to themselves using everybody's demo org. And then we had the DXDO, which was the developer, blah, blah, blah, blah, blah. Anyway, so we had those. We had a series of demo environments that were each separate columns. And each of those demo environments needed some level of maintenance.
Und dann gab es ein Team neben mir, mein kurzer Freund Valerie Haas, der die Industriedemo-Umgebungen für Finanzierung, Gesundheit und Transport gestaltet hat. Und also war jeder von ihnen auch ein separates Demo-Umgebung. Also wir hatten, es waren wahrscheinlich 15 Demo-Umgebungen.
Ich habe etwa sieben der core Umgebungen gestaltet und Vals Team hat noch sieben oder acht dieser Industriedemo-Umgebungen gestaltet. Und so hat jeder von ihnen einen vollzeitigen Job gemacht. Und genau all diese Demo-Umgebungen brauchten eine Person auf sie. Weil jedes Mal, wenn ein neues Produkt herauskam, musste man das Produkt in all diesen Demo-Arten implementieren.
Und dann musste man mit dem Szenario kommen, das für die bestimmte Industrie oder Szenario oder Anwendungsfall funktioniert. So it was an expensive organization. And this is one of the reasons we changed later, why I had that separate team that I talked about doing the rearchitecting, where we went to a modular model. And I'll talk about them more if you want.
But in essence, we had this organization where there were people, individual people, personally accountable for each demo environment. And it was great, because if I'm half-timing a demo environment, other things will take precedence over.
But if my whole job is to make sure that the demo environment that I produce, the people using it is good, and that's how I'm measured and that's how I'm assessed, you get some really quality work. And so that team was full of really high-functioning people who did amazing work making these demo environments tell a story and get everything configured and get everything set to go.
Wie messen Sie, dass ein Demo-Bereich die Bedürfnisse der Menschen im Bereich erfüllt?
Surveys. Wir haben alle sechs Monate ein Survey gemacht und gefragt, was Sie an diesem Demo-Bereich denken. Welche benutzen Sie? Was denken Sie davon? Was denken Sie an die Qualität? Sparen Sie Zeit? Wie viel Zeit sparen Sie? Es war meistens qualitativ. Das Team hatte auch Metriks.
Das Team der Industrie im Wesentlichen hatte einen Zeitraum von der Eröffnung eines Produkts bis zu dem Zeitpunkt, an dem es in der Demo-Umgebung implementiert wurde. Mein Team hat sich nur für den schnellsten Zeitraum gesorgt. Wenn wir das Produkt in die Demo-Umgebung bringen können, am Tag, an dem es eröffnet wurde, am Tag, an dem es GA war, dann haben wir gewonnen.
Und wenn es ein Monat oder zwei dauerte, um es voll implementiert zu bekommen, dann war es immer noch okay. Aber wir haben immer versucht, das Produkt in den Händen der SEs zu bekommen, sobald es möglich ist.
Du hast etwas gesagt, AEs zum Demo zu bekommen. Was ist das Geheimnis der Technik?
Oh, ja, das ist heiß gerade, besonders wenn wir über Verkaufsvermögen sprechen. Die AEs zwischen dir und dem Kunden in vielen Fällen, AEs sind wie dünne Horsen, richtig? Sie sind schnell und ihre Beine brechen sehr einfach. Du musst also für sie kümmern. Ich konnte nie einen AEs-Job machen.
Ich kenne ein paar SEs, die sich überrascht haben, weil sie alle Arbeit gemacht haben und die AE alle Geld gemacht hat. Sie haben sich gewechselt, um ein AE zu werden, und sie waren erfolgreich. Aber sie lieben den Job nicht so sehr. Ich fühle mich genauso. Ich möchte nie ein Account-Executive werden. Ich respektiere, was sie tun. Ich könnte es nie machen.
Ich könnte nie auf jemanden aufs Bett gehen, im Krankenhaus am Weihnachtsabend, um sie einen Vertrag zu signen. I'm just not wired that way. So when I roll my eyes about account executives, it's with respect. I can't do that job. I never will. But some SEs very much feel like they can and they try and some of them are successful.
But most of the feedback I've heard is that they're not excited about it. Ich bin total entschuldigt, dass ich den Thread verloren habe. Was war deine Frage? Es ist alles gut.
Es ist ein guter Kontext. Und meine Frage war, wie können wir AEs mehr demoieren?
Ja, danke. Also, AEs sind beschäftigt und sie haben viel auf ihrem Blatt und sie sind unter einem großen Teil von Druck von Sales Managern. Also, die Art und Weise, AEs zu demoieren, war zuerst, die AEs zu finden, die es benötigen, um zu demoieren.
Die waren generell kleine, mittlere Business-AEs, die nicht Zugang zu Ressourcen bekommen konnten, weil die Ratio von Sales Engineers zu AEs 6 zu 1 oder so war. Also finden Sie Ihr Publikum zuerst. Finden Sie, wer es macht. Finden Sie, wer es bereits demoiert. Und wir konnten das sehen. Wir konnten sehen, wer es downloaden und die Demos aufsetzen.
knew who our audience was, talked to them, see what they're struggling with. And then what we built was a demo environment that was completely pre-configured. It was live, it wasn't fake, and it depends. I feel strongly about live demos. I think demos should be live. It's not always necessary, but in this case we were able to do it. It was an open demo environment. It wasn't on rails.
The AE could show anything they wanted, but it was locked down so they couldn't make changes. It was a shared environment where everybody felt like they were in there by themselves. They had their own dataset that they could change, but they couldn't make configuration changes.
And what we did, which I'm particularly proud of, and this is some great work by a gentleman named Hanul Park, who instrumented the demo environment with guidance so that when you logged in, it said, here's what this is, here's what this is, here's what you talk about. Like pop-up screens guide you through it.
That you could go through the whole demo and when you were done, you could turn it off and you could use the same demo environment in front of a customer. It just, all of that stuff was gone. It worked really well. Es ist wie ein Demo-Skript, das in der Software verbunden ist. Ich nenne es Just-in-Time-Knowledge.
Wenn du jemandem einen Monat und einen halben lernen willst, bevor sie es brauchen, werden sie es vergessen. Wenn ich einsteige und ich möchte sehen, was dieses neue Produkt macht, gehe ich rein, es erzählt mir, worum es geht, es gibt mir ein bisschen Positionierung und ich kann es in ein paar Minuten demoen. Ich liebe das.
Das ist fantastisch. It's funny that it's still a topic that needs to be discussed, but just last week I was speaking to a country manager of a cybersecurity firm and he was telling me, hey, for us, whenever there is an AE opportunity, they always in the first meeting already ask for SE support. They always want to show the demo in the first meeting. I was like.
Are these the type of problems we are still talking about today in 2024? Haven't we learned anything in the past 10, 20 years? And that's such an elegant solution where hopefully, I mean, in the end, I loved how you started the story. You start speaking to the AEs who are already doing it. Obviously, those are not the ones you need to convert from a mindset perspective.
They already believe in it, that it makes sense for them to be able to show at least something in those first meetings. And then, of course, it becomes a topic of just making it as easy as possible for them. And hopefully by that means also making it more accessible to the others who maybe today feel a bit Let's say they have respect for it, which is also fine, right?
Sometimes they don't want to make anything, they don't want to break it, and they are maybe a little bit afraid of it, and I think the solution that you just discussed can lower the barrier.
Very much. Yeah, it was an environment that they couldn't screw up. And if they did... They could call us. You know, we maintained the environment. We managed the underpinnings of it. So if something went horribly wrong, they could let us know.
And the other side of that, which I think is a larger conversation is, and I was against this initially, and I'm still not 100% sure this was a good idea, but it still, it worked out fine, which was, we looked and went, if an AE can give this demo, a customer can give this demo. So we created a, it's kind of a separate profile just for customers, where they could sign up on a webpage.
You can go there now. It's salesforce.com slash EDO, everybody's demo org. Yes. The reason I was against it, it just raises the risk level a lot. You really need to nail things exactly right. Whereas for SEs, a little bit of wiggle room if it goes wrong. But, you know, Salesforce was a pretty robust platform, so we didn't have a lot of outages or anything.
So, you know, 99.999% of the time, the thing was running fine. Und manchmal gab es einen Hiccup, wenn wir etwas bemerkten, was unsere Bemerkung auslöste. Aber wir hatten viel Sicherheit. Aber das Wichtigste war, dass ich denke, dass es etwas gibt, um eure Verkäufer zu ermöglichen, um eure Kunden zu ermöglichen. Und ein Kunde ist nicht so anders als ein A.E.
aus einem technischen Niveau, in den meisten Unternehmen.
Du hast etwas gesagt, das ich gerne ausprobieren möchte. Du hast es vorhin erwähnt, du bist ein großer Fan von Live-Systemen. Nun, du hast bemerkt, dass diese Systeme robust waren, also gab es sehr wenig Chancen, dass sie brechen. In meiner Meinung triggert das sofort.
Warum benutzt du nicht nur Demo-Automation und bietet deinem Kunden ein Interface wie das, in dem du dich nicht auf ein Live-System verlässt, weil es technisch auf einem ganz anderen Niveau funktioniert? Warum bist du ein Fan von Live-Systemen?
Ich weiß nicht, ob ich einen philosophischen Blick auf das habe. Ich denke, ich bin nur glücklich. Ich denke, in den frühen Tagen, bevor ich bei Salesforce arbeitete, arbeitete ich bei einigen anderen Unternehmen. Und die Produkte waren mehr temperamentell. Und es war nicht unbedingt die Fault der Produkte.
Um eine Demo zu machen, musste man einen neuen Harddrive in den Laptop schieben und hofften, dass das, was auf dem Harddrive war, noch funktioniert, weil es ein Serverinstanz war, richtig? Und er schluchzte diese Harddrives. Und es gab viele, es gab viele bewegende Teile.
Und so in meinen frühen Tagen als SE und als Industrie-Marketing-Manager, ich erinnere mich daran, ich habe das, was ich meine HTML-Demo genannt habe, was bei der Zeit HTML und CSS alles da war. Und du konntest klicken und es sah aus, als würdest du eine Live-Demo machen. Es waren nur Screenshots mit Hotspots, richtig? Ja, genau. Und so bin ich für das, konzeptionell.
Ich werde sagen, dass wir, wenn wir in Enterprise Software kommen, ich fühle mich, dass es wichtig ist, für den Kunden etwas zu sehen, das wirklich ist. I don't know why. I just feel like it feels more sincere. It feels more credible to show somebody what it looks like when they get it versus on Rails. Oh, don't click there. Oh, we can't do that.
And as an SE, I had a lot of confidence that when I clicked on something that I hadn't prepared, that it would take me somewhere I meant for it to go. Oh, what does that button do? I don't know. Let's find out. So I think I was lucky that I was working for a company where the platform was quite robust and quite reliable. And I felt pretty confident about it. Yeah.
Ob das für jede Firma wahr ist, weiß ich nicht. Ich mag die Idee von Live-Demos. Ich denke, Kunden mögen Live-Demos. Ich denke, sie mögen den Risiko von Live-Demos. Ich denke, sie mögen das Showmanship von Live-Demos, richtig? Ich denke, es gibt etwas, wenn Kunden eine Demo wollen, sind sie gespannt, dass Sie verfehlen.
Und wenn Sie nicht sind, sind sie ein bisschen überrascht, aber sie sind auch glücklich, weil wenn sie das kaufen, haben sie eine positive Erfahrung. So I can't say that I have a good reason for it, except just it's kind of where I came from.
So what I was hearing is a live environment is better at suspending disbelief that what you're looking at is fake.
Yeah.
That's what I heard. And I think there is definitely an element for it. I can see the reasoning. I think what I'm wondering is to what degree does that help you or does not help you in actually closing the deal by removing that skepticism that might be there if you're just presenting screenshots that are clickable.
I'll be the first to say, the best demo is no demo. If you can close a deal without a demo, that's amazing. Like, that's the best possible. And I stole that because I had a salesperson tell me, the best sales process has two steps, qualify, close, right? It doesn't have 19 steps in it. So I think you're absolutely right.
If there are other things that will satisfy the customer and will move the deal forward, then you should do those things. Yeah. Das ist der Grund, warum ich einen Schritt zurückkomme aus meiner Zealots-Position, dass alles live sein sollte. Ich denke, wenn wir endlich sagen, das ist eine Demo, dann sollte es live sein. Aber es gibt hundert Dinge.
Es gibt Whiteboards, es gibt Click-Thru's, Consensus ist ein guter Beispiel für Videos. Es gibt viele Dinge, die man vor diesem Moment sehen kann, die der Kunden braucht, um das Live-Produkt zu sehen, die vielleicht den Deal verbessern können, ohne dass man es machen muss. Denn Demonstrationen sind teuer. Sie nehmen viel Zeit, viel Arbeit, sie sind furchtbar, richtig?
Also, wenn du eine Demo verhindern kannst, dann mach sie. Aber wenn du eine Demo machen willst, fühle ich in meinem Herzen, dass sie die echte sein sollte.
Fair enough. Ich meine, ich denke, die wichtige Frage dahinter ist, ob der Kunde sogar die Unterschiede erzählen kann. Und das Das ist ein Nuance, das man wahrscheinlich nicht von außen beurteilen kann. Es werden Leute bei Ihrem Prospekt sein, die das URL sehen und denken, das ist offensichtlich ein Fake-System. Und dann werden andere, die das nicht sehen, einfach mit ihm interagieren.
Sie drücken keine lustigen Knöpfe. Sie sagen, hey, das ist perfekt in Ordnung. Aber ich denke, im Allgemeinen bin ich auch ein großer Fan, dass Kunden, Prospekte im Allgemeinen, Zugang zu unserer Software in einer sehr niedrigen Barriereform haben. Ich liebe das. The example that you gave with Salesforce and that URL, where everyone can go to and just click some demo org to see what's going on.
Because I think we still spend too much time in customer-facing meetings just showing our software. I think this can to some extent at least be done in an asynchronous way. Yeah. So why if we have a 60-minute meeting with a customer and the time is rare? Those are 60 minutes that need to be meaningful. Is it really meaningful if I rattle off our most fan-favorite features in the first 20 minutes?
Or should we rather talk about really what are your challenges? What are the consequences those lead to? And is it really worthwhile considering we're doing a project here? I think that would be the more meaningful conversation as opposed to we just would like to see what you're doing. Hier ist ein Video, hier ist ein Klick-Path-Demo, was auch immer du es nennst.
Was auch immer du es nennst, was auch immer du es nennst, was auch immer du es nennst, was auch immer du es nennst, was auch immer du es nennst, was auch immer du es nennst, was auch immer du es nennst, was auch immer du es nennst, was auch immer du es nennst, was auch immer du es nennst, was auch immer du es nennst, was auch immer du es nennst, Okay, I'll show you some screens, right?
Oh, well, we're going to bring in the IT guy and he's going to want to see everything. Okay, well, now I know it needs to be a demo. But I think it's okay to ask the customer, well, what do you need? Or what does your boss need to see, right? Do they need to see the whole thing? Or can we just like send a PowerPoint deck with some slides in it with some screenshots? And the customer will tell you.
I think they'll be honest with you about what they think is necessary.
For me, that's the, I mean, you mentioned the word earlier. For me, that's the essence of buyer enablement, understanding what your customer needs to make an educated decision. And if part of that is a two-day demo workshop, okay, well, let's discuss it in detail, what is really required there.
If the requirement is to go through the security questionnaire and show you a couple of screens and one use case, well, by all means, let's do that, right? Just because our process has 19 steps in it doesn't mean that every customer requires it because, well, what do they need to make an educated decision is the most important question I believe today.
Yeah, I agree with you. And I think, and this is something I do feel strongly about, is a demo is a bargaining chip. Customers like demos. Customers love demos. It's the most interesting part of the day, right? They see something live. They see something new. It's risky, right? It's a show. They get to hope that something goes wrong so they can prove that they're right.
And not in any malicious way, but it's just like seeing a live stage production, right? You could go watch a movie, but everything's been edited. You go watch things on stage because they're exciting, because something could go wrong. Und ich denke, wir sollten Demo als Bargain-Chip nutzen, als Weg, den Deal voranzubringen. Und das tun wir.
Aber es sollte nicht so sein, dass du eine Demo willst und du eine Demo bekommst. Es ist großartig. Wir würden gerne eine Demo für dich machen. Hier ist, was vorher passieren wird. Hier ist, was ich hoffe, dass es nachher passieren wird. Lasst uns alle zu dem stimmen. Das ist das Contract-Stuff, richtig? Ich liebe das.
Also, die Kunden lieben Demos und sie werden Dinge machen, um eine Demo zu bekommen. Und wenn wir ihnen eine Demo geben, sollte es ziemlich gut sein.
Seit wir auf dem Thema sind, was denkst du über den Book-a-Demo-Button auf fast 90 Prozent der SaaS-Websites? Ja.
For a small company just getting started, it may be the only way for people to get their eyes on things. But it drives me crazy because I want to see it now. I don't want to have to interact with a human being to use your software that you claim is going to prevent people from having to interact with human beings.
So I like to at least clap eyes on the product and develop my own understanding of what it is before you commit me to talking to a person. Auch, ich denke, wir Solution-Ingenieure sind im Verkauf, also wissen wir, wann wir verkauft werden. Ich denke, wir sind sehr sensibel dazu. Wenn du im Verkauf bist, weißt du, wann du verkauft wirst und weißt du, wann du verkauft wirst.
Und klickst du auf das Buch-ein-Demo-Button, weißt du, dass du auf einer Mail-Liste gehst, weißt du, dass jemand dich anrufen wird, weißt du, dass sie dich anrufen werden, weißt du, dass du fünf E-Mails über die nächsten drei Wochen bekommen wirst. Ich glaube, ich weiß, dass jeder das weiß. Wir wissen das, richtig? Ja. But it hurts us. You know, it hurts us more. But yeah, I think we sense that.
And I think customers sense that very much. And so they're hesitant to commit. I would just rather show me what you have. I'll make a decision. And if I'm really interested, I'll engage a human being. Thanks for sharing your perspective.
All right. So we talked about the first part of your team, who is fundamentally responsible for maintaining and creating demo environments. Let's move to the second piece, which is tooling. What does tooling do?
Tooling, mit all due respect to the demo environments, because that was where I came from, Tooling was definitely my favorite part of the business. And the concept behind the Tooling was, you go ask your SEs, what's the thing that takes you longest that you hate doing the most? And they tell you. Can you give them an example? I hate filling my demo with industry-specific data.
I hate branding my portal. I hate configuring the product because it takes an hour to configure the product for every demo because I need to load it with a whole bunch of stuff and make all the configuration changes. And so you find out what SEs are spending their time on that they'd rather not be. And then you go get a developer or several developers to build a solution to solve that problem.
Let's make a tool that will, if you press a button that says healthcare, it'll dump a healthcare dataset into your demo environment and you're 90% of the way there. Make a button that when you click it, it pre-configures this new product with all the buttons and switches that need to be done so you don't have to go through the documentation and do it yourself.
And in some cases, so building tools that save SEs time. And the reason I was really passionate about it was Because we could measure the direct impact we were having on the business. I would look at a manual process and SE would say, I hate loading data. Great. I would sit down with an environment and I would load data the same way an SE would, with a stopwatch.
And I'd start it when I started and I'd stop it when I stopped. And then we'd build a tool. And if you could click a button and it would do that work, let's say half an hour, then every time someone clicked that button, you save the organization half an hour. Wenn 10.000 Leute diesen Button dieses Jahr klicken, dann sind das, ich weiß nicht, 5.000 Stunden, das sind etwa 2,5 Jahre SE-Zeit.
Und wenn du das mit einem SE-Zahlrag zahlst, dann sind das etwa 500 Millionen Dollar.
Ich werde dein LinkedIn-Profil wiederholen. Ich hoffe, du hast es noch. Ich liebe es, wie du es darstellst. ...designte automatische Konfigurationstools, die den SE-Workload bei 480.000 Stunden reduziert haben, um 42 Millionen US-Dollar zu sparen.
Klick für Klick. Jedes Klick, das ein SE macht. Und nicht alle Tools waren eine halbe Stunde sparen. Manche waren wie zwei Minuten Sparen und manche waren zehn Minuten und manche waren zwei Stunden. Aber das Nummer kann ich zu meinem Graben verteidigen.
Weil jedes Mal, wenn jemand ein Button klickt, wir einen Check in einem Database legen und wir hatten ein Nummer daneben, das sagte, wie viel Zeit wir glauben, es spart. Und dann totalisieren wir das jedes Quartal und wir gehen einfach Browbeat Management mit uns.
Was war das Tool oder ist das Tool, das am meisten Zeit spart?
Oh, that depends. So I would say the tool that saved the most time, there were two. Both of them were developed by a gentleman named Tarandeep Singh. And one was called Demo Boost and one was called Demo Wizard. Demo Boost was a tool that when you created a new demo environment, there were a bunch of tasks you needed to do.
There were just things about the copying process of demo environments that you needed to do manually. And this tool would go through. When you first logged in, the screen would come up and say, we're doing these things for you now and we will email you when you're done. And then the screen would go away. And about 10 minutes later, you get an email and said, dispatch job was done.
This thing was turned on. This thing was turned off. This thing was configured. And we estimated that thing was saving SEs two hours per demo, something like that, because we'd add up each task it was doing and then we'd just multiply. Of course. So that was a really big one. And then the second was Demo Wizard, which is things that required interaction. Things that maybe I don't want to do this.
And one of my favorites was called Perfect Date Wizard, which was click a button and it will change all the dates in my demo environment. So every case was opened in the last 10 days. Every opportunity is closing in the next 30. Every contract is active. Every marketing campaign is active. So it just went through and changed all the dates and made everything look super current.
So you're not there in 2024 demoing data from 2019 and saying, hey, look at this recent campaign we did.
Oh, by the way, that's five years ago. Right, you pull up a chart and half of it's missing, right? So it was just a little thing. And in fact, that was developed even before I started in the job.
But what we did is we took the code that an SE had developed called Perfect Day Wizard and we put it on the new platform and we generalized it so you could add, as new products came out, you could just add them in the perfect data for this. So, they were really amazing and it was fun. My favorite tool was named ClickClickBoom.
I was about to ask, what was your favorite, irrespective of what the time it was saved? My favorite tool was called ClickClickBoom and it was literally, you click and it was kind of like DemoBoost, like I talked about, it was the earlier version of DemoBoost, but you click this button and it would go, I've done this, I've done this, I've done this, I've done this, I'm done. What I liked about it
And I think this is important to note. When you do automation, I think you should tell the people that you're automating things for what you've done for them. Because one, they're interested to know. SEs want to know what you're doing to the demo environment. But two, it just reminds them that you have their back.
It reminds them that there's someone out there who's doing their work for them and making their lives easier. And so we didn't need an interface for these things. It could have just happened behind the scenes. But we felt it was important to tell SEs, hey, this thing that you normally would have had to do yourself, we've done for you. You're welcome. We saved you 30 minutes.
Saved you 30 minutes, go on with your day, have a nice week. So that kind of communication was important. And it was fun to give things catchy names because, you know, they kind of enjoyed knowing that, you know, the product name is clicking on something. So we had tools like that. And then we had much more technical tools that were product specific configurators for CPQ.
And we had a data tool that allowed you to generate data and dump it in your environment. So there were a whole bunch of things that had other uses that saved us a lot of time.
Also ich denke, alles, was du in den letzten zehn Minuten gesprochen hast, ich meine, ich kann nur aus meiner Perspektive sprechen, aber ich assume, dass viele, viele SEs da draußen gefreut sind, dass sogar die Idee, dass so etwas existiert, weil alles, was du gesprochen hast, jeder einzelne Anwendungsfall, ist ein Schmerzpunkt, den ich als SE hatte.
Ich erinnere mich an eine Firma, ohne das Namen zu bezeichnen, es war ein Schmerz, ein System zu provisionieren. Und ich habe mich immer gefragt, wenn ich hier in einem neuen Umfeld klicke, warum muss ich durch diesen 20-Stunden-Prozess nachhelfen, um es tatsächlich zu einem Status zu bringen, in dem ich sogar mit ihm arbeiten kann.
Ich habe noch nicht mal irgendwelche Daten eingeladen, es ist nichts drin, um eigentlich angefangen zu werden. It already took half a day. And I mean, never mind, I can still remember, I used like random name generators, address generators and all the bunch using Excel loaders to just put something in. I mean, if you're lucky, your solution has an Excel loader.
If you're unlucky, you have to use the GUI because the database access is even something that is more complicated because you have to program something, which may be not something everyone is up to. So my heart was warming up.
Gut, ja, und das ist, warum ich so passioniert bin, weil du genau richtig bist. Das sind Schmerzpunkte. Das sind sehr echte Schmerzpunkte. Und sie kosten dem Geschäft Geld. Sie verbrauchen Zeit. Und ein SE ist zu beschäftigt, um einige dieser Dinge zu machen. Und was passieren wird, ist, dass sie es einfach nicht machen. Ich werde die Daten in meiner Demo nicht korrigieren.
Ich werde nicht alle Daten laden. Ich werde die Daten für zwei Screens laden. Und wenn wir aus diesen Screens gehen, werde ich einfach ein bisschen tanzen oder verabschieden, dass es nicht gekustomisiert wurde. Ja.
So, some of these, and this is why it was a little hard to measure impact, because changing all the dates, yeah, it would probably take me 15 minutes to change the dates on the three screens I'm going to show, but it would have taken me hours to change them everywhere.
But yes, this is why I was passionate about it, too, because I could click by click, I could see the impact we were having on the organization, and people loved the tools. People raved about them, and when they came from other companies and said, oh my gosh, you have automated all this?
I'd kind of pat myself on the back, and our team was doing amazing work, some really clever developers doing really amazing stuff.
There is maybe one example I can share from one of my previous employers, where we surveyed our customers. And those were like enterprise customers with tens of thousands, sometimes even way bigger than that, of users partially. And we were gathering data from them. Of course, not every user would answer, but there were instances where we had hundreds of responses to these type of surveys.
And what we would normally do is completely manually go through them, consolidate them, bring them together and so on. And we had... Ein Teil meines Teams hat ein automatisches Werkzeug zusammengestellt, um zu analysieren, zu konsolidieren und alle Befragungen mit dem Klick eines Knopfdrucks zu beschreiben.
Also, anstatt das ganze Morgen zu lesen, drei Stunden von Hunderten von Antworten aus einem bestimmten Survey, konnten wir es in fünf Minuten machen. Und es war, ich würde sagen, 80 Prozent da. Es gab noch einige Daten, die wir manuell überprüft haben, aber es war im Grunde 90 Prozent gespeichert.
Das ist für mich die Macht von Demo-Automation. Ich sage Demo, weil es mein Bereich war. Aber ja, Automation, wo du etwas findest, das viele Leute viel Zeit dauert. Und du stoppst es in seinen Tracks. Du machst es einfach für sie. Was ich mag daran, und ich denke, was die Entwickler auf meinem Team genossen haben, war nie das gleiche Herausforderung.
Und oft mussten sie undokumentierte APIs nutzen. Sie mussten klare Lösungen finden, weil manche Dinge manuell machen musste. Wie können wir das manuell machen? Wie können wir ein Tool wie ein Roboter-Tool nutzen, das durch den Browser geht und das hinter der Szene macht, während der SE einen Kaffee trinkt?
Es gab also viele klare Lösungen, mit denen wir diese Dinge automatisieren mussten, die nicht immer automatisiert werden sollen. Nicht alles hatte eine API, die dir ermöglicht hat, ein neues Produkt anzuschalten, sobald du es erlaubt hast, richtig? Ja.
Es gab also viele spannende Herausforderungen und ich denke, die Entwickler haben diese Herausforderungen genossen, weil es nicht nur war, so etwas zu machen, so etwas zu machen, sondern es war, dieses blöde Problem zu lösen. Okay, du musst eine Box hier im Produkt beobachten, aber es gibt keinen Weg dazu, ohne das Produkt selbst zu navigieren. Schau, ob du eine Lösung finden kannst.
Und sie haben es gemacht. Du hast also klare Lösungen erwähnt. Es scheint, dass einige dieser Lösungen so klug waren, dass wir über deine Patente reden müssen, oder die Patente, die du als Team entwickelt hast.
Ja, ich kann es nicht beurteilen. Es gibt eine Lektion hier, aber lasst mich mit dem beginnen, was es war, und dann werde ich über die Lektion sprechen.
Also, was es war, das Problem, das wir bei Salesforce hatten, war, dass wir, wie ich es vorhin erwähnt habe, diese separaten Demo-Umgebungen hatten, jede davon war eine Kolumne, die zumindest eine vollzeitige Person benötigte und manchmal auch, um das ganze Demo-Umgebung zu managen. Ja. Und mein Team hat sich mehr darauf konzentriert, was die Körpersprache ist und was all diese Dinge üblich sind.
Und ein Mann namens Jesse Chase kam zu mir eines Tages und sagte, hey, ich glaube, ich habe eine Lösung, aber ich bin mir nicht sicher, ob es funktioniert. Aber ich habe es ausprobiert und ich glaube, es funktioniert.
And his idea was to break these demo columns, these demo kind of monoliths, each demo environment, into little modular pieces and then build up a demo from modular pieces from scratch rather than starting at the big column and then having to whittle it away until it was what you wanted. The problem we were having is a new product would come out.
We would implement it in the core demo environment and then it would take the industry demos four or five months to get all of those things into their new demo environment.
Ein neues Produkt oder eine der Anwendungen von Salesforce.
Genau, also eine neue Sache musste in die Demo eingeführt werden. Also wir haben sie zuerst eingeführt und dann an sie gegeben und sie haben ihre Demos aufgrund all dieser neuen Produkte verbaut und alle neuen Daten zurückgelegt und es hat Monate gedauert. Und so haben wir herausgefunden, warum wir diese Teams nicht nur ihre eigenen Inhalte managen, sondern sie würden sie wieder implementieren.
Why don't they all just manage, if you're the finance vertical, just manage finance content, finance settings, finance metadata, and we'll manage the core itself. And by building it up out of components, we could rebuild the core, hand the core off to them, and they could just snap in their top pieces of it. I'm oversimplifying this. But it's working.
And I'm happy to say that even after having left Salesforce, the program we developed is working. This modular demo thing is really taking off. And the only problem with it is it's straining the infrastructure because there's like millions of calls a day on these things, right? So there's a scalability conversation we could have.
But the patent was around some deeply technical aspects of this modularization, of how you communicate with the servers and how you tell them what's coming. So I can't go into detail because quite honestly, I don't know all the details. But a gentleman named Stuart Anderson and Radif Masood were the two who did this.
The lesson in this, which I think is really interesting, is the way we ended up getting these patents applied for is Salesforce, probably like many other companies, has a team of lawyers whose whole job it is to find patentable things inside a company. And one day I asked these guys, we were in a meeting and I said, hey, is anything we're doing, you know, patentable?
Und sie sagten, ich weiß nicht. Und so haben wir Legal kontaktiert und der Mann oder die Frau, mit der wir gesprochen haben, hat sich durch die Arbeit, die wir gemacht haben, und hat ein paar der Projekte, die sie arbeiteten, vorgestellt. Und sie haben zwei Dinge gefunden, die sie als patentierbar fühlten. Und ich denke, das ist eine interessante Sache. Das ist mir nicht wirklich vorgekommen.
Aber was wir in unserem Team von Tooling und Architektur versuchen, ist nicht wie etwas, was jeder Kunden mit Ihrem Produkt tun wird. Ja, wir lösen neue Probleme. Ich meine, du solltest nicht... Es ist ein sehr unangenehmes Problem. Ja, es ist ein unangenehmes Problem. Kein Kunden wird verschiedene Daten, wie gesagt, tausendmal pro Woche laden, richtig?
Das ist nur für den Zweck, effizient demoen zu können und gut zu markieren zu können. Total.
Also löst du wirklich ziemlich absurde Probleme. Ja. And so I would say to anyone listening to the podcast, look at the work you're doing and if you do have a legal team that's focused on patents, go talk to them about something that you're doing that's interesting. Because they'll tell you. They'll tell you if it's worth patenting. But the company likes patents.
The company wants to patent things. They can license them later if they become useful.
Mm-hmm.
So you may already, your team may already be doing something that's patentable. And it's just really nice. It's cool to have a patent to your name. Those two developers I talked about, their names are on the patent. Mine is not, I'm just management. But their names are on the patent.
And someday when that patent is finally approved, it's in process now, they'll be able to say, I have patent number XXX on your name. So it's just a, it's a very motivating thing. And you might be surprised. You might be even more innovative than you thought you were.
Fair enough. It's a very unique problem, nevertheless. I mean, the purpose of a patent, I mean, I'm not an expert, but my understanding of a patent is that you sort of protect the intellectual property where you have put a lot of sweat, blood and tears into it to say, hey, this belongs to me and potentially you can use it.
But then we need to talk about maybe a price tag against it and so on, license it out, as you put it. All right. So we talked about the demo environments. We talked about the tooling. There's a third and the fourth piece. Please remind me again.
So we talked about support a little bit, which is the fourth one. What was the third one? The third one was a bit of what we just talked about now, this re-architecting, modularization. But I think there's a bigger conversation we can have about that, particularly when we're talking about enterprise, when we're talking about large-scale things.
So this particular team was, we called it the next generation demo team, and their whole job was to look at our scalability and figure out how to solve the problems of the future. And they did this through modularization. Aber was ich sagen würde, ist, wenn du Tools bauen willst, und das hat das Tooling-Team auch getan, ist, Tools zu bauen mit einem Blick auf die Zukunft.
Es werden Probleme sein, es werden neue Herausforderungen in der Zukunft sein, die du nicht erwarten kannst. Aber du kannst erwarten, dass es neue Herausforderungen in der Zukunft geben werden. Also zum Beispiel, kode nicht hart die User-Interface. Das ist gut Coding und Bett Coding. And just assume from the outset that things will change.
And then if you build an extensible architecture for your tooling and for your demos, that will hopefully be able to accommodate those changes. Make it possible to snap things into your interface, your demo wizard interface that steps people through things. Make it possible for other people outside your organization to contribute tools that snap in your framework. For example?
So, for example, a product manager building a new product. We provided them with APIs to our tools and they could provide us with code that we could run that would pre-configure their product when they put it in the demo. Und so haben sie all die Expertise, sie haben alle undokumentierte APIs.
In vielen Fällen versuchten sie, das Produkt auf den Markt zu bringen, bevor all die Dokumentation da war, was gut ist, das ist eine Sache. Und so hat es es möglich gemacht, dass Menschen außerhalb unserer Organisation an der Tooling teilnehmen. Und dann, wo das wirklich interessant wurde, ist, wo wir mit dem Support Team interfacen, über das ich gesprochen habe, dem SE Support Team.
all the people working on deal-focused stuff and started incenting that team to contribute automation tools to our platform. So now we had, rather than the six developers that I had on my team, we had somewhere between 40 and 70 people, any of whom could propose a tool and could get the documentation and could build tooling for it. So it made it extensible.
Und es hat es möglich gemacht, dass wir weiter neue Herausforderungen treffen, als sie zu uns kamen, anstatt zu warten und zu sagen, oh ja, ich wünschte, wir hätten etwas gemacht, das das kann.
Also von Anfang an, und wir haben das nicht richtig gemacht, das erste Mal, es hat ein paar Generationen gedauert, aber bei ungefähr der dritten oder vierten Zeit, als wir diese Werkzeuge bauten, haben wir endlich herausgefunden, lasst uns ein extensibles Framework bauen, sodass das nächste, was kommt, weil es wird, wir es einfach in dort klicken können und es schnell auf die SCs servieren, anstatt das ganze Ding von Anfang an zu bauen.
I think that's a great lesson to be learned here. I mean, I can remember in basically any SE organization I've been a part of, there have always been like one or two people who are really keen to develop these internal processes and make something better because it's inherently in them.
But I also remember a couple of prime examples where from the next product release and we're talking SaaS here, right? So product releases are not really a thing anymore. It's basically every week there's a new feature. All of a sudden it deteriorates and becomes not useful anymore because things have changed. So thanks for sharing that lesson with us.
Und ich denke, du hast einen wirklich interessanten Punkt auch getroffen. Und ich weiß nicht, ob das meine Freunde gewinnen wird, aber die Idee der Standardisierung. Es gibt verschiedene Arten von Leuten. Es gibt verschiedene Arten von Leuten, die Lösungsingenieure sind. Es gibt verschiedene Arten von Leuten, die Verkaufsleute sind.
Die Idee, alle in eine Standard zu forcieren, wie hier ist die Standard-Demo. Ich verstehe die Idee, ein Standard zu haben, aber wenn wir Zertifikate machen und wir sagen, jeder SE sollte so gestrichen werden und hier wollen wir, dass du Dinge anschaust. Ich finde, dass diese oft weniger erfolgreich sind. Genau deswegen. Einige SEs lieben Code. Einige SEs, ich code nicht.
Ich habe nie in der Schule für Code gegangen. Ich liebe zu verkaufen. Ich liebe die Demo. Ich liebe die Geschichte. Und wir können in unseren eigenen Wegen erfolgreich sein. Und es gibt nicht nur einen Weg, erfolgreich zu sein. Ja. So, that's just me standing on my soapbox. But I think it's important when we talk about things like demo, demo consistency, we're not trying to stop anyone.
We're just trying to raise the level of all boats. We just want to make everyone a little better. The people who are already good, great, they're good. They can keep being good in their own way. So, I just wanted to get that out. I feel better.
I think you hit on a point here. And maybe that's one of the reasons why our role has so many different names, right? You have solution architects, you have pre-sales consultants, you have sales engineers and everything in between and any type of combination out of that. And maybe that reflects also the diversity of what the role entails, which we all so dearly love.
Ja, es ist schwer zu sagen, was eine gute SE macht. Ich meine Persistenz, aber außerdem, die besten SEs, die ich kannte, waren alle sehr unterschiedlich von einander. Manche waren wirklich gute Beziehungspersonen, manche waren wirklich technisch, manche auch nicht, wie ich. Aber sie alle hatten ihren eigenen Stil und sie alle brachten etwas wirklich Interessantes dazu.
Ich liebte Interfaces, ich liebte UI und UX und so konnte ich hilfreich sein auf dieser Ebene. Und wenn ich es mit jemandem paare, der Coding liebte, und mein Kollege und ich haben das gemacht, wir haben einen CTI-Konnektor gemacht, wie ein Demo-CTI-Ding. Und es hat gut funktioniert, aber wir haben keine ähnlichen Ansichten gehabt, wie man verkaufen kann oder wie die Welt funktioniert.
Es gab eine random Frage in meinem Kopf, seit wir diese Konversation begonnen haben. Und ich glaube, ich habe den Punkt vermisst, an dem ich die Frage stellen sollte. Also werde ich sie jetzt nur random machen, weil ich glaube, es ist viel in SEs Kopf und es war sicherlich auch in meinem Kopf. Es ist vielleicht ein kleiner Detail, aber du kannst mir deine Meinung geben.
Wenn du ein Demo-Environment erstellst, und ich habe gerade über die randomen Name-Generatoren gesprochen, um meine Demo-Daten zu laden und so weiter und so fort. Natürlich ist das ein Thema, über das du sehr tief überlegt hast.
Was ich früher gemacht habe, als ich ein junger, ungewöhnlicher SE war, ich würde Dinge wie Tony Stark und Superman-Usernames und lustige Bilder und solche Sachen benutzen, um meine Demo-Environmente zu laden. What is your view on fake demo data?
I dislike it. So thumbs down from me. So I think it's distracting and I think it suggests laziness. And while I don't, I would never call any SEs lazy, it feels lazy when you see that someone just came up with some things off the top of their mind.
I've seen some brilliant demos that were intentionally built around fictional people like Santa Claus delivering gifts or, you know, Tony Stark running Stark Industries. Mm-hmm. Ich denke, das ist gut. Und ich denke, das kann sehr engagierend sein, wenn der Kunde der richtige Kunde ist.
Aber ich habe viel Zeit verbracht, mehr Zeit, als ich stolz bin, auf die Kern-Datasets, die wir in unseren Demo-Umgebungen benutzt haben. Und wir haben mit plausibel klingenden Unternehmen, mit plausibel klingenden Leuten gearbeitet. Und wichtig, ein diverser Set von Leuten. Oder es scheint in Japan, ein diverser Set von Leuten ist nicht das, was verkauft wird.
Jeder braucht japanische Namen, richtig? Und japanische Fotos und ihre User-Profile. Ja. So, but making sure that we were representing a wide range of types of customers and types of people that felt sincere and felt credible rather than, hey, here's some funny things I thought of 10 minutes before the demo.
So you left Salesforce in August 2023. So that is already well within the new age of AI. So I'm assuming you had some touch points also in that role still. Oh yeah, I would love to understand what role did AI play?
Ja, und ich habe sogar einige gute Hinweise darauf. Salesforce machte AI, bevor AI AI war, richtig? Ich meine, AI ist seit 70 Jahren da. Und jede Generation von AI heißt AI, und sie macht etwas anderes, und es ist ein anderer Aspekt. Also die neuen LLMs sind das, was wir AI nennen, richtig? Ja.
Aber ich nehme einen Schritt zurück, dass die vorherige Generation von AI, Salesforce hat ein paar verschiedene Unternehmen gekauft, die Dinge, die sie AI nannten, früher der LLM-Revolution, und sie zusammengeführt haben unter einer Marke namens Einstein. Also Salesforce, Einstein, AI. Und sie haben ihre unbezahlten Millionen von Dollar bezahlt. Die Einstein-Familie hat diesen Namen benutzt.
Und dann haben sie all diese Dinge verpackt, die im Grunde eine Weise waren, mehr interessante Insights aus dem Daten zu bekommen. Du hast Jahre lang in deinem CRM Daten gesammelt und jetzt kannst du etwas damit machen. Anstatt sie einfach in einem Chart zurückzunehmen, kannst du eigentlich einige Insights bekommen. Großartig für Kunden. Schrecklich für SEs. Weil... Es gibt keine Daten. Nein.
Es gibt keine Daten, richtig? Und die ganze Art und Weise, wie diese Dinge funktionieren, ist, dass sie eine schwarze Box sind. Du nimmst 10 Millionen Räume und bekommst einen Insight, richtig? Für Kunden ist das wunderbar, aber für einen SE, der versucht hat, einen Insight für ihre Demo zu bekommen, war das unmöglich.
Und die Idee, die Datensätze zu reversegenieren, damit du, wenn du deine Demo machst, die richtige Antwort bekommst. Und es gibt einen Degree von Unvergesslichkeit. Ja, richtig, du bist noch nie sicher. So one of the things we did, and the work of Hanul Park again, a really, really excellent developer, he worked with product management and he said, look guys, this won't work for us.
We can't have SEs just crossing their fingers when they do a demo and hoping the right thing comes out. So one of the things we did working with product management was had them build us a way around the black box so that SEs could inject the result into their demo rather than having to put the data in. Und es gab Dinge wie, oh, das Produkt funktioniert nicht, ohne dass es 10.000 Rows hat.
Okay, dann müssen wir das ausmachen, richtig? Also gab es Hintergrundschlüsse, die man wechseln konnte, die einen SE zu nutzen ermöglichten, was wir Marketing-Approved Resultate genannt haben. Es gab eine Liste von Dingen, die am anderen Ende rauskommen könnten, die real waren, nicht wie etwas, was sie denken könnten. Und sie konnten aus dieser Liste wählen, was sie den Insight zu sein wollten.
Und wenn sie die Seite öffnen und den Button klicken, würde das Insight für sie erzeugt werden. Ja. Und ich denke, das ist ein wirklich gutes Beispiel, wenn wir über Demo-Touch-Alles sprechen. Wir haben viel Zeit mit Produktmanagement verbracht, um ihnen zu helfen, wie sie ihr eigenes Produkt verkaufen.
Weil sie bauen, ein Kunde kommt zu ihnen und sagt, oh, ich habe diesen Anwendungsfall und ich, du weißt, ich bin ein großer finanzieller Servicekunde und wir brauchen das, um dieses Ding zu machen. Und die Produktmanager bauen das Ding, aber sie denken nicht darüber nach, wie du dieses Produkt oder diese Fähigkeit zu der größeren Welt verkaufen wirst.
Und so kann ein Demo-Team wirklich nützlich sein, weil du SEs zu deinem Demo-Assistenz-Team kommst, deinem Demo-Support-Team, die sagen, hey, wir brauchen dich, um diese Dinge zu bauen. Das Demo-Support-Team kommt zu deinem Demo-Architektur-Team, die sagen, hey, wir machen das über und über. Es wäre wirklich schön, wenn wir das nicht 100 Mal pro Woche tun hätten.
Und dann arbeiten wir mit Produktmanagement, um zu sagen, hey, dieses Ding macht viel Downstream-Effort. Können wir Demo-only-Fähigkeiten hinzufügen? in dein Produkt, damit wir es verkaufen können.
Okay, also die andere Art und Weise. Das Projektteam hat Dinge im Kopf entwickelt, damit wir besser verkaufen können, obwohl es nicht unbedingt eine große Produktion ist.
Richtig. Ich meine, es ist sogar etwas seltsames, wie können wir die Create Date auf den Rekorden ändern, die wir in dein Produkt pumpen. Weil natürlich, ein Kunde würde das nie machen. Das ist eine schreckliche Idee, oder? They're auditing. You want to audit everything. But for demos, when my whole chart is the create date of cases, I need it to be the create date.
I need to be able to change the chart to some other date, some custom date, right? So we were working closely with product management to make products sellable. And I think, and this is one of those things that took us a few years to do this. This didn't all happen on day one.
We swam upstream through the product management process and helped product management understand how to sell their products and how their products were going to be sold if they didn't do these things, right? And I think that was a really important thing to do because it widened the value that this demo team had and educated a lot of product managers. And many of them got better at it.
After a couple of rounds, they'd come to us and say, hey, I know this product works this way, but we've put this thing in this switch that you can turn off so that you can do this demo-only thing with it.
Ja, das ist fantastisch. Ich denke, ich meine, zumindest aus meiner Erfahrung, dass sehr wenige Produktmanager darüber nachdenken, dass nicht nur du versuchst, eine Funktion zu erledigen, die Wert auf deine Kunden bietet, sondern du denkst auch darüber nach, wie ich diese Feature entwickeln kann, damit meine Kollegen es tatsächlich verkaufen können.
Das ist bereits eine ziemlich mature Meinung, die ich in der SaaS-Base finde, auch für Enterprise SaaS.
Ja, ich denke, es gibt wahrscheinlich ein Modell der Demo-Maturität, das ich noch nicht gemacht habe, aber noch nicht zusammengelegt habe, das das hat. Und das ist auf der rechten Kante. Ja, wir müssen mit dem kommen. Ja, wenn du in Nirvana reist, ist das Produkt, das dir Demo-Produkte gibt, richtig? Aber bis dahin musst du deine Arme zwischendurch drehen. Und einige bekommen es.
Und einige bekommen es sofort und verstehen es. Einige von ihnen sind ehemalige SEs, die das gemacht haben. Und einige bekommen es nie. Und darum existiert dein Tooling-Team. Weil, wenn es zu dir kommt, sagst du, okay, wir werden es generieren. 10.000 Läufe und wir werden sie mitnehmen, bevor du sogar dein Demo-Environment bekommst und du alles brauchst. Ich liebe das. Danke, dass du das teilst.
Das ist wirklich interessant.
Cooles Ding. Ja, also das waren die vier Teams, in einem oder anderen Weise, mit denen wir gearbeitet haben. Und ich denke, wie du hörst, hatten wir einen Einfluss auf verschiedene Teile des Geschäfts, in verschiedenen Wegen. Aber alle waren zentriert auf der SE. Sie haben vielleicht in andere Teile erreicht, aber alle wurden von der Überzeugung, dass eine SE nötig war.
To be honest, I feel like this is a good point to maybe conclude. I was just one last question for you. Sure, of course. I mean, you've been doing this for a long time and I mean, we've been talking for about one and a half hours, so we are still actually scratching the surface of it.
What is one thing that you still would like to share that is on your mind, which we haven't talked about today, but the world needs to know?
Ich würde sagen, es geht um die administrativen Bedingungen bei SEs. Es ist sehr anstrengend. Eigentlich, lassen Sie mich zurückgehen. Wir haben nicht so viel über Analyse gesprochen. Ich habe ein ganzes... Ich kann den ganzen Tag über Analyse sprechen. Aber ich habe ein paar Dinge... Wir können darüber sprechen, wie wir einige der anderen Dinge, die wir auch gemacht haben, gemessen haben.
Was meinst du mit Analyse? Also, zum Beispiel, wie unsere Demo genutzt wurde. Okay. Knowing how, being able to describe value to the demos themselves. Yes. So let me talk about that and then lead into this final thing, because they're linked and this is why I thought of it.
So one way we measured the impact we had on the business is that every time a solution engineer spun up a new demo environment, they had the option to tell us what deal they were using that demo environment for. And about a third of the time they told us. Only a third? Well, I'll take what I can get. And about a third of the time equaled four and a half billion dollars, right?
Das ist alles, was auf deinem LinkedIn-Profil steht. Das war gut, richtig? Also hatte ich immer noch mein Geld. Aber ich meine, das ist nur ein Drittel des echten Nummers. Ja, es war ein Drittel. Und es war weniger als ein Drittel, weil SEs oft ihre Demo-Environmente wiederverwenden. Ich hatte das sicher.
Also konfigurierte ich es in einer bestimmten Art und dann zeigte ich es vier oder fünf Kunden. Also war es schlussendlich eine Demo, die durch mein Team kam, die für fast jeden Deal bei Salesforce verwendet wurde. Aber ich kann nicht alle Revenuen zahlen. Also zähle ich für das Stück, das wir messen können. Ja. Und es war ein paar Billionen Dollar. Ja.
But we had long discussions about, could we measure that better? Could we ask SEs every time they're doing a demo, which demo environment are they using and what deal is it on? And the conclusion I reached was no. We could, we could ask them to do that, but I didn't want to. Because our whole remit was to reduce the burden on SEs. It was to make their lives easier.
And if we were asking them to do something solely for the purpose of me beating my chest in front of management. You put something on top. We're adding things to them and we're making their lives harder.
So I think there's a temptation in business to measure everything and then to try to glean insights from that data that you've measured without thinking about the impact that's on SEs or anyone really for that matter. And so I would say to your listeners, think hard about the burden that you're putting on your SEs. Think hard about what you're asking of them.
If you need it to justify your existence, I get it. But keep in mind that that's something for you and that's not for them. In an ideal world, you can justify your existence as a team to management and they'll keep you going and you can keep helping SEs. If someone's asking questions and you need the data to back it up, you might have to put a burden on SEs to get the data.
But if you can avoid it, do avoid it. And try to find ways that you can understand how people are using your products and derive value from those without interrupting their flow. Zum Beispiel haben wir eine Intrademo-Messung implementiert, die bedeutet, dass wir innerhalb jeder Demo sehen konnten, welchen Screen SEs wir am häufigsten besuchen.
Und das gab uns eine ziemlich gute Idee von einer von zwei Dingen. Und ich sage das, weil ich nicht sicher bin, welche es war. Entweder konnten wir sehen, welche Produkte am häufigsten verkauft wurden, oder wir konnten sehen, welche Produkte am schwierigsten zu konfigurieren waren.
Denn man kann nicht unterscheiden zwischen dem, was gerade gedemonstriert ist, und dem, was konfiguriert wurde.
Richtig. Und wenn du 40 Mal zurückgegangen bist, vielleicht warst du im Rehe, oder du hattest einfach nur noch zurückgehen müssen, um etwas zu reparieren. Oder der Kunde fragte viele Fragen. Oder vielleicht gab es viel Interesse. Aber es war interessant, weil wir gefunden haben, und das war sehr nützlich, dass einige Screens nie gesehen wurden. Ja. Und wir konnten also in diese investieren.
Wenn niemand diese Feature zeigt. Zuerst einmal sagen wir dem Produktmanager, dass niemand dein Produkt zeigt. Ups. Ups. Aber zumindest wissen sie. Und zweitens, wir geben keine mehr Ressourcen dazu, das Produkt in der Demo einfacher zu machen. Das gab uns unsere eigene Priorität. Aber es war eine nicht intrusive Art, zu verstehen, wie SEs unsere Demo benutzen. Wir haben sie nicht gefragt, dass...
Auf der anderen Seite, ich habe vorhin kurz darüber geredet, wir haben über sechs Monate überwiesen. Und in den frühen Tagen hatten wir mehr Antworten. Sechs Monate waren wahrscheinlich zu oft. Wahrscheinlich ist es jährlich besser, weil SEs müde sind, über sechs Monate überwiesen zu werden. Aber wir haben immer noch eine statistisch bedeutende Anzahl von Antworten bekommen.
Und es ist wert, deine SEs zu fragen. Was denkst du? Wie magst du die Werkzeuge? Was würdest du besser machen? Und ich habe einen Punkt gemacht, ich weiß, du hast erwähnt, automatisch, du weißt, durch all diese Survey-Resultate, aber ich habe einen Punkt gemacht, um alle Kommentare zu lesen. Es war tatsächlich interessant und ich würde genau das machen.
Ich würde einen Morgen sitzen und ich würde alle Kommentare in eine Sprechstelle legen und ich würde sie eins nach dem anderen lesen und ich würde sie tallyieren und sagen, okay, well, these people are complaining about configuration time. These people are complaining about this. And these people said nice things, which is always good to hear too.
Aber es war nützlich, SEs zu fragen, worauf sie sich befinden, und nicht zu sagen, dass wir es wussten. Aber sie zu fragen direkt, und nicht nur zu sagen, dass wir es von unseren Messungen ausgleichen konnten, weil wir uns nicht sicher waren. Ja, ja, ja. All das bringt mich zurück zu der administrativen Bedeutung von SEs.
Halt es so leicht wie du kannst, bekomme die Informationen, die du hast, aus den Werkzeugen, und nutze diese Informationen, sowie die Interaktion mit SEs, um Möglichkeiten zu finden, sie besser zu helfen. Und das letzte Stück davon ist, die Leute, die uns einen schlechten Rating auf unserem Survey gegeben haben, würde ich kontaktieren.
Und ich würde sagen, hey, ich sehe, du bist nicht glücklich mit unseren Sachen, erzähl mir mehr. Und die meiste Zeit waren sie ein bisschen beschämt. Sie waren so, nein, ich mag deine Sachen wirklich nicht und ich bin es mir leid, das zu sagen. Aber die meiste Zeit hatten sie wirklich gute Punkte. Ja, und diese sind ehrliche Gespräche.
Ja, diese waren die besten Gespräche, weil sie nicht nur sagen würden, oh, alles ist wundervoll. Nein, ich habe wirklich mit dem hier zu kämpfen. Ich bin in dieses Problem gerannt am letzten Tag und es hat mich angestrengt. Und dann kam dein Survey raus, also habe ich es von dir genommen. Aber diese sind die Leute, mit denen du sprechen musst. Engage die Kritiker, weil sie dir sagen können.
Und viel ihrer Feedback ist wirklich nützlich. Sie können dir Hinweise geben, was andere Menschen erleben, aber nicht sagen. Danke, dass du das erzählt hast.
Das war wirklich bemerkenswert. Es triggerte eine Erinnerung von mir. Ich habe letztens einen Bericht gelesen. Ich kann mich nicht erinnern, wo es war. Ich weiß nicht, wo ich es finden konnte. Was es sagt, war basically around the same line, what you were elaborating on in regards to feature adoption. Du sprichst also von Feature-Adoption von SEs vor Kunden oder was sie demoen und vorbereiten.
Dieser Bericht, den ich gelesen habe, ging um Feature-Adoption, wenn es um den eigentlichen Kunden geht. Und das gleiche Bild wurde eigentlich gepaintert. Im Prinzip ist das Pareto-Prinzip, dass 20 % der Features für 80 % der Adoption verantwortlich sind. Und es gibt einige Features, die im Grunde nie genutzt werden oder nur bei 1 % eurer Userbase.
Das ist auch ziemlich bedrohlich, wenn man im Produkt arbeitet. Und auch bemerkenswert, wenn man in Solution Engineering arbeitet. Bist du wirklich am richtigen Ort, wenn du etwas demoest? Oder zeigst du etwas, das vielleicht flächendeckig ist, aber wirklich nirgends benutzt wird?
Richtig. Und es gibt ein paar Unterschiede. Denn es gibt das, was ein Produkt verkaufen möchte. Es gibt das, was Marketing verkaufen möchte. Und wir haben sehr kurz über AI gesprochen und ich habe das Thema verändert. Wir können zurückgehen. Aber AI ist ein tolles Beispiel. Jede Firma hat einen Top-Banner. Wir sind eine AI-Familie. Und unsere SEs, ist das, womit sie vorliegen?
Weil, sobald die Tür schließt und du im Raum bist und du mit einem SE und einem A und einem Kunden bist, ist es für sie eigentlich egal, was gesagt wird. Und also, um Hinweise zu bekommen, was du sozusagen verkaufst, was du tatsächlich verkaufst. Und dann das dritte Stück. Was verkauft man tatsächlich? Was sagen die SEs den Kunden? Was kaufen die Kunden tatsächlich?
Ja, das ist eine ganz andere Konversation, die wir hier vielleicht für einen anderen Tag haben müssen. Ich denke daran, was du zeigen musst, um zu verkaufen, und was der Kunde am Ende wirklich verwendet, könnte auch nicht das gleiche sein.
Richtig, das ist das vierte Niveau von dem, richtig? Das ist, was ist tatsächlich, zu deinem Punkt, was sind sie tatsächlich implementieren, was sitzt auf der Schale und was wird verwendet? Und SEs sind eine kritische Teilnahme dieser Schiene, aber hier kommen wir dazu, ob wir sie aufbauen oder ob du Produkte so einfach verkaufen kannst, dass der SE sie verkaufen möchte.
Ich meine, wenn du wirklich opportunistisch bist, dann zeigst du die Dinge, die so überzeugend sind, dass die Leute denken, dass sie das brauchen. Ob sie dann andere Funktionalitäten benutzen, mehr oft als das. Ja, gut bei mir, so lange ich meinen Job gemacht habe. Wiederum ein sehr simplistischer und opportunistischer Punkt der Sicht. Aber im Endeffekt sind wir da.
Wir sind Teil der Automarkt-Organisation. Wir sind da, um Investitionen zu bringen. Und ich denke, das ist definitiv eine Art, es anzusehen. Also AI, möchtest du mit mir darüber reden? Wir können ein wenig überlegen. Aber ja, das Thema ist... Es ist großartig.
Es ist ziemlich großartig. Gute Neuigkeiten, ich habe nicht viel Aufmerksamkeit. Bitte teilen Sie die Geschichte, die Sie haben wollen. Es ist mehr ein bisschen Ruination. Also ich habe Salesforce am vorderen Ende der LLM-Revolution verlassen. Das war schon los. Wir haben alle mit Chat-GPT angefangen zu spielen.
Sie haben bereits Chat-GPT-Agenten für Kunden-Service implementiert, was der erste offensichtliche Ort war. Wie die AI-Story, die ich vorhin gesagt habe, ist AI wirklich schwer zu demoen. Es ist einfach zu demoen und es ist schwer zu demoen. Es ist einfach zu demoen, weil es flaschig ist und es cool ist und die Leute es lieben.
Es ist schwer zu demoen, weil, wie du gesagt hast, es unvergesslich ist. Und du weißt nicht immer, was du daraus bekommen wirst, wenn du die gleiche Frage ansiehst. Halluzinationen. Halluzinationen. Und als jemand, der... Ich bin im Theater gearbeitet. Und das ist der Grund, warum ich Demos liebe. Es ist wie eine Performance. Ja, es ist.
Und wenn jemand mir gesagt hätte, als ich im Theater war, in der Hochschule, du kannst wirklich Geld verdienen. Und du musst nicht ein berühmter Schauspieler sein. Ich würde mich aufmerksam machen. Ich habe das nur später gefunden. But when you're doing a theater production, you're trying your best to control every part of that.
You're trying your best to exert as much control as you can over the final product. And it's very tricky with AI to do that, because AI by definition is a little bit loose. It's sort of conversational, and I don't want conversational. I want it to say the same thing that we said in rehearsal on opening night.
So when companies are exploring their AI products and rushing them to market right now, as we all are, I think it's important to think again, how do you sell this? How do you make this compelling to the customer and not just cross your fingers when you type something in that, yes, he's going to get the right answer on their screen.
And in some cases, that may mean circumventing the AI altogether and equipping the SE with tools they can use to just predict the outcome very specifically by typing it in beforehand. It gets back to our discussion about live demo versus not live demo. I think there are some cases where it may make sense to do a not live demo and in some cases where it should be live.
And in AI, I'm leaning toward simulation in cases where there's a high risk, where there's a possibility of giving the wrong answer and causing the deal to fail.
Ich meine, wenn ich es so anschaue, hast du zwei Alternativen. Nummer eins, du simulierst das Ergebnis, also es ist 100% unter deinem Kontrolle, oder du hast ein Datenset, das so realistisch ist, dass die AI, was sie auslösen soll, was sie auslösen soll. Und wenn es nicht so ist, dann ist dein Produkt kaputt und du kannst nicht die SE dafür beurteilen.
Ja. But they'll still lose the deal. And the SE. I joke, an SE can't win a deal, but they can lose one. So yeah, be nice to your SEs, by the way, because they can lose your deals for you. But yeah, I agree with you. I think functionally, that's exactly true. From an SEs world, what I see is, I want total control over what my business looks like. No, I'm with you. But what are you seeing?
Because you've been around. I've been off vacationing for a year. What have you seen going on in the AI world and how it's impacting solution engineers?
Ein Ex-Kollege von dir, Philipp Schöne, ist Manager bei MuleSoft für ein SE-Team. Er hat viel über die verschiedenen Programme und Initiativen gesprochen, die mit ihm durchgeführt werden, um das SE-Team zu unterstützen, um effizienter und effizienter zu werden, sowohl in ihren Arbeiten als auch in den Gründerarbeiten, die du beschrieben hast. Natürlich kann AI eine große Bedeutung für das sein.
Wenn ich die Arbeit bei iDo sehe, weiß ich nicht, wie repräsentativ das ist, weil ich nicht mehr im SE bin. Richtig. We are talking about SE-enablement and sales enablement, but I'm using AI daily. I'm using it daily. I'm using it to improve my writing. I'm using it for a lot of creative assets, pictures, colors, visual language, played a little bit around with video generation, just for fun.
To be honest, I don't think it's at the level yet where I would need it in order to really be useful for me. Again, I'm not so sure how representative that is for what SEs are using. If I look back, I would use AI now, of course. I mean, the types of services that you and your team are providing, not every company has the luxury of that type of team.
So I think AI becomes even more useful there because there is an individual contributor. You can benefit of many of the things we talked about. For example, dataset generation, consolidation of large companies. Look, we are in our program where we talk about discovery skills. We're also talking about how to write a good follow-up mail.
You've come off from a 60-minute discovery call and a good follow-up email should contain what were the main pain points that you discussed, a summary of the discussion points, what were the negative consequences out of those pain points that you discovered and so on. And now with AI joining basically all of our conference calls, we have a nearly perfect transcript.
Now you can combine a transcript with a smart prompt and it basically writes you the perfect follow-up email almost automatically. Very little adjustment needed. That being said, almost no one is doing that. I see, as part of our job, we see follow-up emails on a daily basis because it's one of the tasks in our program. And I read these follow-up emails and they are all not good.
They are very technology-focused, they are very self-centered, look at what we have, and they are very little concrete when it comes to what's actually the situation at the customer. But hopefully, well, if you had a meaningful conversation, the conversation should be full of those insights and you should mirror it back, maybe in different words, but
Schauen Sie zurück, was Sie in einem folgenden E-Mail gehört haben. AI kann ein fantastisches Tool für das sein. Und wiederum, so wenige Leute benutzen es für das, auch wenn es ein so offensichtlicher Fall ist.
Richtig. Es ist lustig, dass SEs, um so technologisch fortzusetzen, wie SEs können, oft die letzten sind, um neue Technologien zu benutzen, um ihre Jobs einfacher zu machen. Und ich denke, wenn wir über eine Demo-Organisation oder eine SE-Support-Organisation sprechen, ist Teil ihrer Arbeit, zu sagen, hey, wie können wir AI benutzen, um ein SEs Leben einfacher zu machen?
Wenn ein SE es nicht selbst will, weil sie beschäftigt sind oder was auch immer, hey, können wir etwas machen, wo ein SE eine natürliche Sprache-Querie schreibt und ein Datenset zurückbekommt, das reflektiert, was sie suchen und sich ein paar Stunden spart. Ich stimme mit dir. Ich bin seltsam, riesig in die Technologie und auch traurig und nicht vertraut davon.
Und ich denke, dass eine intervenierende Organisation, die sagt, hey, wir haben etwas Cooles gemacht, du musst dich nicht überlegen, wie es funktioniert, du drückst diesen Knopf und es funktioniert. Ja, das kann wirklich nützlich sein.
Ich bin super gespannt darauf. Ich meine, das wird jetzt ein bisschen philosophisch, aber ich bin super gespannt darauf, in diesem Tag und Zeit zu leben, in dem die Geschwindigkeit des Entwicklungs- und Innovationsprozesses so schnell ist. Ich erinnere mich immer noch, als ich zehn Jahre alt war, habe ich ein Game Boy für Weihnachtsgeschenke bekommen. Und das war die hohe Technologie damals.
Und jetzt, was wir haben, ist verrückt. Also bin ich super froh, Teil davon zu sein und super froh, zu sehen, was wir noch sehen werden. was nicht nur unsere privaten Leben, sondern natürlich auch unsere Geschäftsläufe und unsere Jobs beeinflusst. Also ja, ich bin hier für es.
Micah, das war wahrscheinlich eine der längsten Gespräche, die wir auf diesem Podcast hatten, aber ich habe es wirklich genossen. Ich habe sicherlich viel darüber gelernt, was es bedeutet, eine Enterprise SE-Team zu skalieren, wo wir literally über tausende SEs sprechen und was für eine bedeutende Weise ist, diese Rolle zu unterstützen, um einen noch besseren Job zu machen.
Ich denke, du hast uns einige fantastische, sehr konkrete Beispiele gegeben, worauf solch ein Team teilnehmen kann. Das war PreSales Unleashed, dein Podcast für Sales Engineering im B2B-Software-Vertrieb. Falls du tiefer ins Thema Discovery eintauchen möchtest, haben wir jetzt eine Überraschung für dich. Wir haben einen kostenlosen E-Mail-Kurs nur für dich erstellt.
Normalerweise ist dieser exklusive Coaching-Content nur für unsere zahlenden Kunden zugänglich. Aber so erhältst du jede Woche kostenlos wertvolle Insights, ein kleines Nugget direkt in dein Postfach. Klingt spannend? Dann schau mal in die Shownotes und melde dich an. Schön, dass du wieder mit dabei warst. Bis zum nächsten Mal.