December 20, 2017
SF Metrics: Richard Waid & Ben Hartshorne
Watch the talks from October's SF Metrics Meetup, including LinkedIn's Richard Waid on the evolution of monitoring at LinkedIn, and Honeycom...
In episode 20 of EnterpriseReady, Grant is joined by Yvonne Wassenaar, CEO of Puppet. They discuss her experience serving on boards of enterprise software companies, transitioning from a single product company to multiple products, and the role of professional services.
About the Guests
Yvonne Wassenaar is a seasoned C-level executive with broad experience scaling, diversifying, and transforming businesses throughout the Americas, Europe, and Asia. She is currently the CEO of Puppet, and an advisor at Snyk.
Grant Miller: All right, Yvonne. Thank you so much for joining me.
Yvonne Wassenaar: Thank you, Grant.
Grant: Cool. I'd like to just dive into your background and hear about how you got into enterprise software.
Yvonne: Absolutely. Similar to many people it's a bit of a curvy path, but I started my career as a software engineer at Accenture.
I like to say, "Back in the days when COBOL was cool."
After a handful of years of doing waterfall and big system development I went back to business school, and reemerged at Accenture in what was then the strategy practice.
Initially I was a generalist working across a bunch of industries, but given my interest in technology and my software engineering background, I ended up serving high tech clients on a global basis.
One of the biggest problems and challenges that these companies had was scaling their go-to-market.
Oftentimes large companies like Intel and Cisco and others would hire great engineers and they would be looking for expertise on marketing, selling, and channel leverage to figure out where and how to accelerate growth.
That became my deep area of expertise during my time at Accenture.
I was there for a little over 17 years, all said and done, and then I moved from Accenture to VMware to help VMware transform their go-to-market motion.
They'd been my client for a couple of years and was really looking to go from selling vSphere feature function in the organization that they were serving, to selling higher up in those organizations and getting beyond 30% virtualization to expansion across the entire estate.
I went in and ran that salesforce and I've been in enterprise sales, really, my entire career. So, I fell into it and just never left.
Grant: What is it about enterprise software that just keeps you coming back? Accenture, VMware, New Relic, everywhere-- Puppet.
You're on the board with a bunch of different companies, what is it about this this ecosystem that keeps you excited?
Yvonne: I like the impact that you can drive.
I think it's trite to say, but software is fundamentally changing how everything in the world works.
Large enterprises are increasingly on the forefront of that, in terms of what they're doing and how they do it.
I think consumer technology is interesting. It can be a bit fickle to me.
Enterprise selling and being successful in driving technology into some of the largest enterprises around the globe has impact, but it's also for me the right blend of art, science and psychology in terms of how you get people to--
Particularly if you're a smaller company, to trust your solution, build relationships, drive impact and scale.
There's a lot of things that I think apply very generically across how you execute that, and a lot of that's changing.
For me it's that right blend of challenge and impact that I find exciting, and it keeps me interested and on my toes.
Grant: Definitely lots of problems to solve in the enterprise software space.
I would say that we spend so much more time at work, so it does have a lot of impact. You're actually right about that.
So, your time at Accenture. I think it sounds super informative for you.
You probably had a great cross-section of all the different best practices that people were using in go-to-market, is that the most important part of your career?
Or, do you think that experience--?
Yvonne: Accenture has definitely been incredibly formative in how I think about scaling companies, and how do you effectively sell it into the enterprise.
What's interesting when you're a consultant is you get to focus on whatever the top problem is that company has, and you get a lot of cross-company alignment around solving the problem because they're paying you a lot of money to go do it.
The CEO or some C-level executive has prioritized that problem, and so you get a great opportunity to really focus in on the solution itself.
Grant, to what you said, on being able to pull from all of the other experiences that have happened for the firm.
In my case Accenture, which is quite large, as well as some of the best research that the firm has access to and can draw from.
From a practical standpoint, you do get to advance the thinking, leveraging some of the best inputs around in an environment that is highly conducive and supportive to actually executing the strategies that you come up with.
During my time at Accenture, I had the fortune of falling into the go-to-market space in tech and became one of the leading subject matter experts in the firm on how you scale in the enterprise, "How do you sell higher?"
"How you move from feature functions to solution selling?" "How do you effectively leverage different types of channels?"
That was a great basis upon which to then go into industry.
I think the hard lesson for me going from being a partner at Accenture to being an executive at VMware, even though the problem I was solving was in many regards the same problem, they hired me to help drive the sales transformation at VMware and run services and education and a lot of those go-to-market functions.
The context in which you're operating is very different.
You have lots of peers and they all have their to do lists, and there's a limited amount of money, so learning the other side of the coin and not just "What is the solution?"
But how do you actually rally an organization to drive change in what you do is different when you're operating in a company or leading a company, so I would say my time at VMware and New Relic in particular were equally as informative to who I am today as a leader and my thoughts on what success takes in selling to the enterprise.
Because I now better understand what it takes, not only to come up with the right idea, but to rally a company and people across the set of organizations to actually do that work.
Grant: That's super interesting. So as a consultant, you end up having a little--
Maybe there's more alignment, because there's a lot of spend that's happening to get you to deliver this strategy.
Then internally, when you're operating at a company, you have to realize that everybody on your team or the other execs and folks all have competing and aligned but different plans and strategies and priorities.
So, trying to get everybody on the same page requires a lot of cross-functional conversations in trying to figure that out.
That's really a great point. At VMware, this is a company that has done an incredible job of growing and becoming a real--
One of the most important part software companies in the world. When you joined, was it massively adopted across the enterprise?
What were you really looking to bring, in terms of transformation when you when you joined VMware?
Yvonne: VMware is such a powerful story, and it's interesting to me having worked there, and I'd say New Relic falls in the same category.
That when you look at these companies from the outside they just, in some regards, look like rocket ships and everything's always gone great for the most part.
Yet when you're inside, I think it feels hard and challenging, and there's lots of things that you have to sort through.
I always tell people, "Any job is hard and there's a lot of challenging growth.
The main problem that I was initially brought in to VMware to help solve, and this was actually when they were my client when I was at Accenture, is that they had crossed the hurdle of product/market fit in terms of people who were nay-sayers about virtualizing to a true understanding that was a highly effective and powerful way to run your infrastructure.
What was happening, however, is that VMware would get to about 30% virtualization of a data center, and in some regards hit a brick wall.
They were trying to figure out how to continue to expand the footprint.
What we started to realize, and I think this is important across many types of technology that are transformational out in the marketplace today, is that part of why we were hitting a brick wall at 30% virtualization is that happened to be the amount of penetration for the role we were selling into that things got scary.
In terms of shifting how many data centers you need, what the roles are that you need to do, and "What did that mean to my own career as a VI admin?"
One thing that we started to realize is that we had to do a few things to drive continued success in this sphere, and then we obviously over time had to extend out beyond that one product into a broader portfolio, but as it related to scaling vSphere we realized that we had to start selling higher in the organization to get above that fear point.
Because ultimately if you are 100% virtualized you don't need as many servers, you don't necessarily need the same infrastructure setup, so we had to speak to people who understood and valued that broader value proposition.
We at the same time needed to take care of the people who had been our big sponsors in these accounts over time, and we had a large focus on "How do you make heroes out of the VI admins themselves? How do you help them grow in their career and be change agents, in terms of how their companies are evolving, so that they can do more and be successful and advance their careers and their skill sets?"
Really through both of those mechanisms, reduce the fear and increase the opportunity for the customer, for the individuals, for VMware in the accounts to drive that accelerated growth.
At the same time we were doing that, and I think this is true for all companies who are looking for longevity, is we had to go from one product to "What was our Act II going to be?"
So during my time at VMware I spent a lot of time with Paul Maritz and the broader executive team on the various acquisitions and experiments that we did to really build out what VMware would grow into over time.
We did a lot of rounds building out Paz and Cloud Foundry and what ultimately spun out as Pivotal, we did a lot of rounds like the very notable acquisition of Nicira that helped build out the cornerstone of the software defined datacenter.
There was a lot of work to think about understanding our customers and their broader needs and the advancement of technology, what would be next?
We had to do both those things in parallel and expand the opportunity that we had with the current product/market fit that we had in a way that gave us runway to then build out Act II and effectively figure out what we were going to double down on, what we were going to divest and how we were going to grow that success.
Grant: Interesting. So when you joined, it was a one-product company, basically. It was vSphere?
Yvonne: Yes. A very successful, $2 billion dollar one-product company.
Grant: OK. So, $2 billion dollars a year in revenue at that point?
Grant: Then the transition to add in new products, that in itself is a pretty big transition for any company to make.
One, it's pretty amazing that vSphere was able to take the company to those heights. That's a pretty massive amount of revenue to drive from one product.
Especially from a go-to-market perspective, adding in multiple products is a pretty significant undertaking.
Can you talk to us a bit about the challenges around aligning the whole team behind introducing new products?
It is incredibly hard to go from one product to multiple products, and I'd say it's hard on a couple of fronts.
One is just mathematically, and organizationally.
When you have one product, when you're a startup and you've got one problem you're trying to solve, you inherently tend to be aligned as an organization because you all know that one problem you're trying to solve.
When you expand into multiple products, you're all of a sudden solving a multivariate problem and organizational alignment and prioritization and decision making and resource allocation inherently become more complex.
It's one of the things that I spent time on at VMware, I spent time on at New Relic, I'm spending time on it at Puppet.
It's incredibly hard and you have to be really careful, one, that you don't expand too quickly or too fast.
Both in terms of the products that you're trying to bring to market as well as the personas that you're trying to go after in an account, it's exponentially expensive when you add new things.
Because not only are you building or acquiring that something new, you have to figure out "How do you market it? Who are you marketing it to? How do you enable on it?"
I like to say, "It's taking space on the truck."
Salespeople only have so much time that they can learn new things, so now they're spreading that time across multiple things and they only have so much time to go make meetings and go on sales calls.
If they're selling to different people in an organization, that's now getting spread thinner, or you're setting up a separate salesforce.
There's a lot of internal focus and work that needs to be done to successfully go from one product to multiple products, and yet if you don't do it your growth will at some point stall out or you'll get acquired and become part of something bigger that has multiple products.
So, that's one piece of it. On the other side of it, you have to figure out what those other products are going to be.
I think that is equally challenging, and to a certain extent I believe that it requires a level of experimentation and that you need to be careful that you don't put all of your eggs in one basket and just assume you're going to get it right out of the gate.
It's almost like you have to go through that whole startup process again to figure out, "What are the market needs that need to be met? What are you uniquely positioned to build or buy or somehow create a service for that need? How can you get credibility? How do you go from a more nascent product to a more mature product over time, and build the referenceability and the sellability of that?"
For us at VMware, I think Paul Maritz was the perfect CEO at the time, an incredibly visionary leader who deeply understood where the world was going.
Very active with the benefit given the great success of vSphere, of having a significant amount of resource, both talented engineers as well as money to do acquisitions.
He did a fair number of acquisitions, a lot of organic development, and then we had to figure out what was going to work and what wasn't.
What's interesting is VMware was a public company, so there were a lot of demands in terms of the type of financial performance we would deliver.
When you're starting new products, it's hard for them to perform the same level as something like vSphere would.
We ended up doing a lot to understand, "What could the VMware salesforce effectively sell? What were realistic objectives from a revenue standpoint? How do you handle the mis-balance of how much you're investing to grow new product relative to how much it may return on the top line?"
Usually you have to invest a lot more relative to return early on.
We had a lot of conversations, particularly when we were looking at the cloud area back in the day and the public cloud offering, whether or not that should be a separate salesforce or not.
I do think as you go through that expansion of one product to many, you've got to think about "How do you align within the organization? How do you experiment, figure out what's really going to have traction with your customers, or in an adjacent market?"
And then, "How do you align the investment and the go-to-market to effectively deliver the results that you want?"
Grant: It's interesting, because I think about that.
You mentioned earlier the idea of working with your customers to expand beyond 30 % penetration, and needing to take that as a two tier approach, both protecting and highlighting the value of VI admin.
But also, leveling up the conversation within these organizations.
It seems to me if I just think it through, that the effort to level up the conversation is actually enhanced when you start to have multiple products.
Because you can bring, instead of a single product to market and into a conversation, you're bringing a whole suite.
Maybe that's a higher level conversation that you can push up. Was, is that--? Did you find that those two things were fairly complimentary?
Yvonne: Yes and no. What I would say, when you're selling to large enterprise there is some truth to the fact that as a CIO or a high level executive, you have limited amount of time.
Best practices, you want the smallest number of partners to service your needs, but you want best of breed technology.
How do you get that perfect balance? Often times the highest level executives in an organization are focused on the largest partnerships that they have.
So, dollar size matters and the scope of impact a particular partner has within their organization and or the strategic value.
I think the key thing that I look at when you're trying to level up is understanding from an empathetic standpoint, "Where do you sit in the eyes of the person you're trying to reach and sell to?"
And "Is there a good balance?" If I use Puppet as an example, I don't think the CIO is the right target for Puppet.
I think Puppet is an amazing company, I think we have phenomenal technologies, the CIO definitely gets involved in the purchase of some of our big deals. No doubt about it.
However, who we need to convince of the value of the solution and who is going to make the budget decision versus just approving that for us is oftentimes the SVP or VP of operations.
So, we've moved from just our open source community using the technology to managers and directors of project teams using it, to at our largest engagements the VP/SVP of operations.
All of the people I mentioned are important, but we're not as focused high up on targeting the CIO with that specific messaging.
Grant: OK. Interesting. So, let's dive a bit into Puppet.
I think what you're talking about here is really interesting.
As reference, Yvonne joined as CEO of Puppet seven months ago, eight months ago, right around then.
So you're talking about not going necessarily over the top, but continuing to build almost a bottom-up approach to go higher in the organization.
You mentioned taking on and layering on top of the open source in your products to reach more senior-level managers.
Has that been through messaging, has that been through new features and functionality and reporting?
Or, what methods have you used to get higher level folks in the organization to engage with Puppet?
Yvonne: In terms of getting engagement, I believe one of the big shifts in technology that's happened is the CIO role came out in the 1980's, and it was because at that point in time companies were spending large amount of monies on back-office systems and they needed a central control point to ensure they got value out of that spend.
Back in those days it was very much a top-down decision process, and somebody bought technology and organizations needed to use it to run their back office.
What has happened with how technology's evolved is it's much more democratized, and it is no longer a command and control structure by which technology gets consumed.
End users, developers, they have a lot of choice in today's world on what technology they will use.
I believe that the most successful companies are the ones that figure out how to develop end user love and excitement and adoption of the technology that they're creating, in conjunction with being able to articulate the value of that technology at a higher level to somebody who may never touch it.
Who may never have that miracle minute of downloading and using New Relic, but is willing to spend hundreds of thousands, if not millions of dollars supporting the use of that technology within their environment.
I think you need to have both of those spectrums and everything in the middle at the end of the day to be highly successful.
Now, how do you create that? There's a lot of different ways and I think they're different at that ground level, at the user level, versus at the executive level, at the ground level.
One technique and one approach is what Puppet's done, which is to be open source.
I think there is a lot of benefits to being an open source based company, and there are some challenges with it as well.
But through our community we actually engage with the users of the technology they're helping build, and improve a core component of what Puppet the company brings to market every day.
That's really powerful from an engagement standpoint.
New Relic did it in a very different way, New Relic had an amazing product that you could download and get immediate value out of.
T-shirts and downloads led to a $100 million dollar company in a short period of time, that's now grown much larger.
There's different ways you can develop community and get at that grassroots, but messaging can really be effective higher up in the organization.
What I remind the folks in my company all the time is, "Those people aren't putting hands on keyboards. They need to understand the value in a very different way."
If I think about Puppet, how we position and get the love of Puppet at the ground level, it's through the amazing technology that we build in a blended open source and commercial way.
How we get advocacy and love of Puppet at the higher level, at the SVP of operations level, is the fact that through our declarative model approach in the auditing and reporting that we can support, we can reduce the time that a company needs to spend on an audit if they're in a highly regulated industry by days.
We can increase the comfort level and the security of a company. I had a CISO tell me, "I love Puppet because you always return my environment to a known good state."
This is a CISO of a Fortune 100 company, they are not putting hands on keyboards, but they understand the value that Puppet brings in a way that's meaningful to them.
I think really understanding the different value drivers across that pyramid of who you need to engage in the adoption and purchase of your solution is important, and that messaging could be different.
The forms you reach out are typically different, and that's where I think a lot of companies struggle, is understanding that and then understanding how to allocate the resources effectively in service to those different key players in the buying and usage process.
Grant: As a company, how do you make sure that you're surfacing that information so that they know that you're saving them time, and they know that you're accomplishing the objective?
What are the--? Because at New Relic, the value proposition is probably being able to profile and create better applications with less downtime, and being able to say "When we use New Relic our app crashes less and we have a better, more performant application."
When you use Puppet, it's "We haven't known good state. We're more compliant, more secure."
But how do you make sure that message is delivered beyond the people with hands on the keyboards?
Yvonne: It's hard. In my experience, the most effective ways to get mindshare in time at the higher levels in an organization are a combination of the team itself in that company advocating for the broader use of your technology.
So early on, you've got the champions inside who are asking their bosses to support the broader use--
In our case, of the enterprise version of the software to advance what they're trying to do or use it more broadly across the department or the organization.
The second thing that is wildly influential is customer reference.
For example, we had a large consumer products company and I was talking to the CIO there.
And he said "Yvonne, I know we're not a large bank but I just want you to know that the testimonials of these two large banks that you serve that were shared with me were incredibly helpful in my ability to get sponsorship to make this large purchase with Puppet, because my executive team felt if Puppet was good enough for these companies who were highly regulated and cared deeply about security and so forth, that they would be good enough for my company even though we're not that regulated.
Our brand is incredibly important to us, so we want to know that the technology is reliable and it's secure and it's scalable."
So that referenceability of customers, oftentimes large customers won't allow you to create large public references. Sometimes they will, sometimes they won't.
But oftentimes they'll be willing to speak to other customers on your behalf, or to do internally usable testimonials.
Those are incredibly powerful.
The third thing that I would say is from a public company standpoint, you always want to CYA.
To have a Gartner or a Forrester put you in a strong spot in a wave, or in the top quadrant in the Matrix, that's important as well.
It doesn't guarantee that you're going to win, but at least you're a known solution and you've crossed some hurdles.
People will more likely give you a chance to show your wares relative to the other leading performers in your category.
Grant: Yeah. It's a really interesting topic around analyst relations. I think about how there's these publications, Forrester and Gartner, and there's a handful of other ones in our space. 451 and Red Monk, et c.
These analysts have influence in enterprises in terms of what technologies they adopt.
There's this concept that's similar to public relations, which is if you're working with reporters where you're engaging with them to tell them about the stuff you're working on so you can get press, there's a similar function called analyst relations.
Where you engage with the analysts who are basically technology professionals with the objective of understanding your offering, and then helping to summarize it and compare it to the rest of the market.
You're on the board at Forrester, so you're obviously very familiar with how this whole ecosystem works.
Can you talk a bit about like how you think founders in tech and software companies should be leveraging these publications, and how they should engage with them?
The first thing to recognize, and I think this is hard for us sometimes because our job is focused on building great technology, is we tend to ground ourselves in how great the technology is and all the wonderful things that technology can do.
One of the powerful things about the analysts, the best of them--
If you take the Gartners and the Forresters and so forth, is that they approach it from a very different perspective from a company standpoint.
What they are focused on is "How is the marketplace evolving? What is the new way of doing business? What are the people, process, cultural technology changes that you as an executive need to be considering as you work to keep your company a leader in whatever space you play in?"
They tend to be very end customer and business-centric in how they view the big picture.
Then within that, they will have deep experts on the specific technologies that are part of the solve for a company.
If somebody is going to have a user relationship with a Gartner or a Forrester or one of these other companies, it's oftentimes like having a relationship with an Accenture or somebody else.
You're looking for them to provide you context on market shifts, and the bigger picture.
Then as part of that you're going to want to think about the technology that's supporting where you're going.
That's when how these analysts perceive your technology relative to others becomes very important, and typically no technology does it all and is perfect. How an analyst portrays the strengths and the weaknesses or the opportunity areas of your product relative to your competition is very important.
As a founder and CEO of a tech company you really want to be thinking about from an analyst perspective, "What is the market trend? What is the business change that's driving the relevancy of the technology that you're building?"
Oftentimes we look at it the opposite way, "We've got this great technology. Look at how it's going to change business."
Customers usually look at it, "My business needs to change. What technology is the right one to help me get there?"
Understanding how you fit in that piece of the puzzle, and then working to influence and ensure that the analyst accurately represents both the vision that you have for where you're taking the technology over time, as well as the current strength of it is really important.
Because people will use that in two ways, one, they'll use it to help them understand "I'm going to go in this direction. Which company should I be looking at?"
Typically in today's day and age there's so many different ways to get information on what solutions are out there, they probably know before they looked at the analyst report, but they analyst report will help validate or provide next level detail in context of what's important.
The other thing is that the analyst report will help ensure that they're looking at the right collective set, so when they go and take it to the CEO and the CEO says, "That's a lot of money you want to spend, are you sure this is the right investment?"
They can say, "Yes. I've looked at the Forrester way." Then, "This is one of the top three companies, and the reason why I think this is the right one for us is X."
So it helps them develop that top track and build that level of comfort that you're mitigating risk of adopting a new technology, and that you're really positioning the company from a business perspective for success.
Grant: It's interesting, so thinking about it as so much of enterprise software is really sold without the salespeople in the room.
It's the conversations that are had, and just providing another piece of referenceable collateral that's very reliable and trustworthy, that your champion can go into a conversation with the CFO and use as an additional piece to justify the spend.
Those increase conversion and add a lot of value.
Yvonne: One thing I want to pick up that you said that I think is critically important, is that the sales rep is often not in the room.
That is particularly true when you're selling to large enterprise and big deals.
Oftentimes, what your job is as a sales team, both the technical and the relationship sales rep, your job is to educate your sponsor in the account and their technical teams to be able to articulate and advocate and get approval for your solution when you're not in that room.
Being able to do that in an effective manner, so that they can get the various--
And there are always various steps of approval across a large number of functions within a large enterprise, is really critically important and something that's good to think about when you're assessing "How simple or complex is the messaging that I have to sell my product?"
And "How simple or complex, or risky or not, is the technical architecture that's required for it to scale effectively in an account?"
Being thoughtful that you're not always going to have your experts doing it, but you have to be able to educate others to do it within their organizations.
It's a good thing to keep top of mind as you scale.
Grant: It's that game of telephone, right? That second order, you have to deliver a message that somebody else can deliver simply, so it can get complicated.
If we look at how you mentioned you're on the board at Forrester, which is part of this conversation, but you're also an advisor and you're on the board for a handful of other companies.
I think that there's this really interesting piece where to provide or to find a independent board member who understands your business and your industry and ecosystem, and to be able to bring them on.
Because most of the folks that are starting to listen to this podcast are venture-backed companies and their board consists primarily of venture capitalists and the founders.
So if you want to find an independent board member, what do you do to find someone like you who has great experience?
How do you convince them that they should join your board?
Yvonne: The setup of your board is critically important, or can be as you look to scale the company.
What I often talk to founders about is thinking early on, "What is the expertise? What is the support that you need as you're going to grow and scale?
And not only how do you get that and build that out across your executive team in the company, but how do you build it in the board room?"
As I think about my own board, you sit there as a CEO and oftentimes you figure out, "Who's going to help me when I need to think about raising my next round?
Or doing some debt financing, or something like that? Who's going to help me out when I really need to think about the scalability of my product and the engineering velocity, and how I'm going to drive new product development and product-led growth?
Who in the room can help and really push my thinking on go-to-market and go-to-market expansion, and relevancy as we get to that next level?"
So what I do, and what I think the best CEOs that I've worked with do, they'll sit and they'll figure out "What does that ideal boardroom look like? What is the experience they want sitting around that table?"
And then, "Who's sitting in those seats and how did they get the right experience?"
Oftentimes your venture board members are going to bring the expertise and the networks and the support around the fundraising and the strategic exits, and all of that great stuff.
So oftentimes what you're going to be looking for in an independent board member may be more around somebody who's actually been an operator, who can relate to your experiences and how hard it is to actually scale a company, who may have deep expertise in either the engineering area that's a critical area for you to focus on, or the go-to-market.
Starting off with getting some clarity on what experience you really want to have in the room to help you grow and scale the company, and then the board, the one thing that they can do is fire you.
Typically you want to put a board member on who you have some inherent level of trust or relationship with, or understanding of how they tick.
How they're going to contribute in the boardroom, but also how they're going to help navigate the hard decisions as they relate to scaling the company and even potentially your own role.
In that, in my experience on the boards that I've served on, I've typically had a relationship with the founder or CEO of the company for a while before I've actually joined the board.
At Bitium, when I was looking to leave VMware a friend of mine introduced me to the CEO and we just hit it off, we got along really well.
He'd periodically call me to ask for some perspective on some go-to-market issues and scaling, and when it came time for him to want to add an independent to the board I was a natural choice because he already knew me as a person and I knew him.
He knew my level of expertise on the go-to-market side, and so it was a good fit.
Similarly with Snyk, which is a company I advise, Guy approached me when I was CIO with New Relic, I was at one of the venture capital of CIO round tables.
He approached me and we talked about philosophical beliefs around DevSecOps and where the market was going, and then he took the initiative to stay in touch over a couple of years and asked me to get involved in the company.
So, I would highly recommend if you're looking to put an independent on your board to start developing relationships with prospective board members early.
It's not something you just want to get a list, call up some people, and in a month you make a decision on who you're going to add.
I think you'll get a better outcome if you start thinking about it earlier on, start talking to the venture folks around who they have in their network who might be a good board member for you to consider over time.
They have very wide networks.
I've been introduced to companies through some of the folks at the different venture capital companies that I know, so I would say it's really all about developing and cultivating a network.
It's about having a strategy for what type of skill and personality do you want to add to your board, and then putting in the time to really cultivate, so that when you get to that trigger point of when you're ready to really put that next person on, you've got one or a couple of good choices where it's a natural fit.
Then they'll also be much more up to speed, and be able to add value more quickly.
Grant: That's incredible advice. I know both Guy and Scott, from Bitium and from Snyk, and they've always spoken very highly of you.
I think that Scott was actually the first person who ever introduced us, so when we started Replicated he was like "You have to talk to Yvonne. She's going to get this right away."
I think that's exactly the right way to approach it, is find relationships that you can build some trust and you can understand how that--
You mentioned with Guy that you were just on the same page, and you had this-- You naturally clicked.
Because to your point, if you try to run it like a hiring process where you're just trying to interview a bunch of candidates, you're probably not going to get a great result.
At the same time, if you only look at the folks that your venture investors suggest as independents, you have to question "Will you work well with them? Where do loyalties lie?"
By cultivating these relationships over a long period of time, you can find someone who knows you well and who knows the company, and is going to come in and add a lot of value from day one.
So, that's great advice. Another topic that I'd love to pick your brain on is around professional services.
We've talked a bit about sales and go-to-market, and I think there's a pretty good amount of people who will understand some of these concepts and sales.
Professional services is a bit of an enigma in my mind, at least for me personally, where it's hard to determine "Should you be offering professional services? How should you start?"
What are the signals you should be looking for that decide, "OK. We should be doing professional services," and then how do you make that a important part of your go-to-market and your strategy?
Yvonne: Professional services is a really tricky topic for technology companies.
I've had the fortune of being able to work with companies of all sizes on the specific question of "What type of services should we have? How much services revenue should we have relative to other revenue?"
All of those great questions, "How much should we leverage partners for services?"
Some of the most interesting stories and comments that I've had on this journey around services have come from a technical founder perspective where--
Lou Cerny at New Relic for a long time declared we would never have services, that New Relic's product would be so easy to use that you wouldn't need them.
Grant: That is the dream that we all have, right?
Yvonne: It is. When I was at VMware, I was responsible for the services strategy, and McKinsey came in my office and said "Yvonne, what do you want to get done as a services strategy project?"
And I explained to them my vision, and they said, "That's not what Paul Maritz wants."
And I go "OK, what does Paul want?" "Paul wants us to figure out what feature functionality we need to put into the product to eliminate the need for services."
So, it's an important part of appreciation that oftentimes services can be this stop-gap on feature functionality that's missing from your product that's required for a customer.
But in enterprise, it actually can be--
There's a much bigger role that becomes important over time, and one of my friends who is a CIO, his comment to me was "Yvonne, I don't care how easy New Relic is to use.
If you don't have a robust set of services that I can buy alongside of this three year deal, I don't want to invest in your product.
The reason for that is if I'm going to spend this much money and I'm going to bet this piece of my business on your technology, I want to know that my people are trained and know how to use it.
I want to know that we implemented it in the right way, and I don't want to waste a lot of time getting it set up and getting it running.
I could do it, but there's an opportunity cost to me to do that."
I think it's important to understand both sides of that equation, and to be very thoughtful on what you build out.
So for me, when I think about services I think about the spectrum of "What are you doing with education to ensure people know how to use your technology? What are you doing with what I would call 'Out of the box services' that might be a health check or a services check or a fast start, that just allow your customers to more effectively implement, adapt, use and run over time your technology?"
And then "What are, if any, the custom services that you want to provide?"
The larger the accounts that you work in, more likely the higher the demand for that, because they'll have unique things that you may not want to build in your product but they won't buy your product without.
So understanding that spectrum, understanding how you can leverage technology in that spectrum.
For example, at Puppet we have a software-based health check that people can run that our support team created, just to help ensure efficiency in the process.
But we also have people who will go on site and help companies upgrade from open-source to Puppet enterprise, things like that.
We also have service delivery partners, so to me, really understand what your customers need across the lifecycle.
From understanding your technology, implementing it, using it, upgrading it, and maintaining it over time.
Get a perspective on how much you want to use services as an enabler, and what the role is in your business financials.
Is it a money maker? Is it a loss leader? What are the financial expectations? There's many different answers you can have on that.
Then I'm a big believer, if you're a technology company be a technology company.
Don't try to become a services company and do all of that, it's a very different PNL, a very different business model.
Think about who are your partners who can do the services work that may need to be done for the success overall for your customers that you don't want to do yourself, and how are you going to cultivate those service delivery partners?
That can be service delivery partners who are doing implementation, who are doing customization, who are doing change management, who are doing business process.
Figure out what your customers are going to need to truly be successful and how you scale that out.
In my experience, companies serving large enterprise are going to have to have some level of services themselves, but then you can create that IP and train up some pretty powerful parties in the ecosystem that can help you scale much more rapidly than if you built it out yourself.
Grant: There's so many areas I want to talk about here.
The interesting piece of what you were last talking about is leveraging these partners, and it bleeds into channel in some regard s because many of these partners if you're bringing them business and you're working with them--
Let's say these are oftentimes described as SIs, "System integrators."
These can be consulting companies that spend their time helping large organizations implement and integrate new technologies into their processes and workflows.
These companies will oftentimes take the technical lead on actually doing some of the work to implement, and again integrate your solution into the whole ecosystem of tools that a specific company is using.
So you're saying, "Find these partners." Do you think it's--? Is it just the big consulting companies, or are you looking for more niche companies? How do you figure out who those integration partners should be?
Yvonne: In my experience, you first have to figure it out for yourself with your customers, and you need to understand what customers need to successfully scale from an education standpoint and from a implementation standpoint.
You have to understand what that work is, and you likely have to build out those capabilities yourself to understand that before you can engage any partners at all.
The second thing that I would say is that--.
Grant: Real quick, you're saying that you think it's important to have some type of internal services team that's doing this or some education that you're delivering before you start working with partners?
Yvonne: You need to know how to do it.
It's a little bit like when you first start a company, typically your first salesperson is the founder or CEO, and then you figure out what it takes to sell and you get enough critical mass that you actually hire salespeople.
I think services is somewhat the same way, and so it may not be creating a services team, it may be sufficient to have your SEs or your engineers figuring out what it takes to implement your technology in a customer.
Maybe your technology is so simple, it's an application and you don't need that.
I'm a bit biased by the fact that I've worked in scenarios that are more complex. I would say at New Relic, Lou was right.
You didn't need services for a very, very long time.
But when we ultimately did need services, we first were figuring out how customers were asking us to help them integrate New Relic into certain other systems that they had.
Customers were asking us to help them configure certain dashboards, and originally that work was done by engineers and SEs and solution architects, but over time that becomes inefficient.
That's when you have to make a decision, "Are you going to build up your own services capability? Are you going to leverage partners? Are you going to do both?"
I think there's a learning phase that's involved, and if you do decide to go down the route of working with partners what I would say in my experience is that partners typically aren't going to sell your solution.
There are exceptions to that, but in general partners are going to fulfill the demand that their customers have.
They might recommend technologies that help on certain solutions and change that you're trying to drive, but in general you're still going to have to help create the demand for your technology.
But they may be providing the broader capabilities around it, which is something just to keep in mind.
I would say in general, I tend to have a much stronger preference as a smaller company in focusing on more the boutiques, more the regional SIs are relevant.
I come from Accenture, I know a ton of executives there, I've worked with Accenture when I was at VMware and at New Relic. It's tough.
They're 500,000 people, it's hard to get traction.
It can kill a company trying to get some of these larger SIs to understand and be educated and actually drive market impact with your technology.
I would caution you on not betting everything on the larger size.
They're incredibly powerful when there's momentum, but it can take a lot of energy to get momentum.
For me on the services side, the first thing to do is think about "What are your customers going to need for success? Do you know what it's going to take to deliver on that?"
To the extent that it requires services, "How much of that do you need to and do you want to do yourself?"
If you feel you can benefit from having partners in that ecosystem, I would recommend starting small and testing out "What do those relations look like with a couple?"
To really start to figure out how you drive momentum, and then with momentum, then it's a lot easier to scale out.
Grant: That's great. I think the analogy to founder-led sales and then transitioning to more formal sales team is a great one, because I think the process of that is fairly well understood.
Basically start to document your go-to-market motion and how you do it, and if you don't have a formal sales playbook you likely have an informal one, so the first step --
I'm guessing the first step is also true within thinking about starting a services organization, which is just document the work you're doing with and for your customers, and document how you integrate them and how they get onboarded.
Once you've done that, then you can decide if there's a-- You talked about having this menu of services, health checks and fast starts, and start to group things together and package things up and be able to identify what that services offering looks like.
Does that sound like a viable path?
Yvonne: Yeah, absolutely.
I think you articulated it very well, and the ideal scenario is when you can put in as much repeatability and predictability into those services, because that will give you leverage over time.
What I mean by that is one way is to do some of it through software helping you deliver the services, another thing that's becoming increasingly popular is the leverage of remote services.
Do you actually need to put people on site or not, from an education standpoint? There is a lot of great innovations around even education on YouTube, and that may not be a paid-for service, but that type of education service can be really valuable as you're trying to get people not only to know about your product, but to know how to effectively use it in a self-service way.
So all of those things, there's been a lot of innovation on the services side as it relates to technology, implementation, adoption and scale out.
It can be incredibly powerful and I think really differentiate the winners from the losers.
But to your point, Grant, it starts with really understanding it from a customer perspective and documenting it out.
Being thoughtful on how you scale it out, and evolve it over time as your customer base changes and as you change as a company.
Grant: Then once you have that services organization, is this an org that you would lean on?
You talked about some of the stuff at VMware, and I'm sure you've had similar experiences at Puppet and New Relic and Airware.
But like, is that an organization you're leaning on to help make transition within your customer base and get more adoption?
Or, how are you using them strategically beyond the inbound demand that you have for adoption or integration?
Yvonne: There's a few ways that I think about services, and I like to take a customer journey viewpoint, which is all the way from "How do you create awareness and interest in your offering through the sales process, the education and implementation of the technology to the customer, the use of that and the scale out?"
Unfortunately at some point the retirement of that, but hopefully the expansion into other areas.
As you think about that, to me I lean on the education group across VMware where I ran it, and at Puppet where I am ultimately responsible for it, to really ensure that were keeping the prospects and customers that we have as well educated and capable of getting the ultimate value out of Puppet.
I look at the services organization to have a breadth of services, so a set of like what I talked about with packaged services, that allow everything from vision creation.
So while we're not trying to be a BCG or McKinsey, if you look at Puppet for example, we're one of the leaders in thinking around DevOps and we do the state of the DevOps report.
Grant: I was just thinking about the state of the DevOps report.
It's such a great piece of content that you guys put out every year, and I was wondering, is your professional services team involved in that? Who's all engaged in that?
Yvonne: What's interesting is, and this is why I say "Keep an eye on how your customers are evolving and how you're evolving."
Initially, the state of the DevOps report was really thought leadership for Puppet and where we were trying to bring the industry and help the industry progress.
What's interesting is some of our largest customers and prospects have come to us and asked us to leave dev ops workshops, and so we'll spend some time with our team and we'll run 1-2 day workshops with them, which quite frankly, then frame up their journey of which the Puppet technology is a piece of.
We're not doing the extended tale of cultural and process change, but we're arming them with a roadmap of what needs to get done, of which our solutions set is part of.
There are what I would call those "Strategic context setting services," at VMware we created the cloud advisory group.
Again, it wasn't to replicate what Accenture or other people would do, but sometimes your customers need you to help them create that 12-18-24- 36 month vision of the transformation they're going to drive.
If you can set that in place upfront, that will lead to much bigger, much more successful projects and implementations of your technology.
I look for my services team to do that, I look for my services team to build ongoing customer success.
For example, we have technical account managers, which in our largest accounts they will pay to have somebody onsite or remotely working with them on an ongoing basis.
We typically build out joint success plans with the customer on what are the milestones for how they want to see the technology evolve and be adopted and drive impact within their organizations, and we partner with them on that.
That's incredibly helpful, so there are some things that we're doing to ensure the successful setup and adoption of the technology.
Then there's the basic implementation services.
Great that somebody buys something, but if they don't use it they're not going to renew it.
Then there's back to the very beginning of the conversation, there's the filling in of the gaps.
We have customers who will want our technology to do more than it does today, and we can build that out in a custom way.
We've got customers who want our technology to integrate into their environments in a certain way, and so sometimes we're doing that with custom services.
If you see enough of that demand, then you start to look at "How do you package that up and make it part of the product?"
So you'll see Puppet coming out with new modules on the forge that make it easier to integrate with different types of services and capabilities, so I look to the services organization for all of that.
I would say what often happens in companies is you go through a period where your services are very reactionary, and I'd encourage folks as they grow and scale to take a step back periodically and see "When do you hit that point where you would benefit from having a more proactive services strategy, and what would that look like?"
Just recognize that's going to evolve over time, and what the right services strategy is for you today may be different 18 months from now.
That's pretty normal, but just keeping a finger on the pulse of that because it can be incredibly valuable.
More so in, I believe, the framing up for the true transformational impact your software can have, or your technology can have.
Then also in the true adoption, which also leads to greater stickiness and expansion over time.
Grant: So, one of the things you mentioned a little bit was customer success. I think about services, and there's obviously some overlap with customer success and you talked about TAM.
I also think there's probably some amount of at least interaction with support as well, and how these different functions within an organization--
Where do you draw some of those lines? Where do the handoffs happen? I think they're always really interesting, do you have any thoughts on that.
Yvonne: Customer success is increasingly getting the limelight as companies look at how they evolve, and this whole concept of customer success managers.
There is increasingly with more and more SaaS solutions, software that can allow you to see how your technology is being used and identify red, yellow, green customers and things like that.
I think at the end of the day I'm biased from having started my career as a consultant, but most companies hurt themselves because they get caught up in organizational boundaries and role definition.
True success for a company and for a customer oftentimes get solved across function, so to me, what I look for and one of the things that we're doing at Puppet is actually looking at, "What is the customer journey?"
The customer journey typically isn't even that they learn about the product, they purchase the product, they implement and they use it.
For most large, successful enterprise companies they certainly go through that cycle, and then they expand it and they have some issues.
They buy some adjacent products and it can get pretty complex and very extended over time, so what we've been looking at is "What is that customer journey that our customers go on, and what are the touchpoints that we have across different organizations?"
Grant, to your point, "What are the handoffs?" More importantly, "What's the shared data set of knowledge?"
You want to make sure that if a salesperson is going to go reach out to an account that's coming up for renewal, that they're aware that there was a support issue and that support issue was either resolved or not.
Or if customer success is finding that people are calling in with really use questions around the technology, or issues because they're not using it or haven't configured it effectively.
They're recommending that they might take some education, be it free or paid for.
I think that ability to understand how you plug in the different pieces over time is really important as it relates to CSM and customer success managers.
I've seen probably 20 different role descriptions across 10 different companies, and it's an evolving role.
I think what's most important is just being really clear on what are the expectations you have of your sales teams, if you have renewal teams and if your renewal team is relative to your sales team, if you have CSMs of that role relative to these other roles.
How do they integrate into and understand what's going on in support?
How do they integrate and understand what's going on in terms of education and training in services?
Those connection points are really important, and they can vary.
I've seen lots of different configurations, but understanding what's right for your customer and what's most effective and scalable for you today, and then just on a periodic basis checking in, because it will evolve.
If your business is scaling, you're probably going to create more specialty roles over time, and how are you ensuring you've got the right data integration and analytics is all going to be really important.
Grant: Yeah, I just think that perspective of taking that very customer-centric view is so important here.
Because your job is not to only support only customer success, or only professional services.
If you take a customer-centric view, everyone's job is to make your customers successful.
Any activity that you're doing in that pursuit is part of your job, and I think that's a really great point to bring up.
I think oftentimes as engineers we like to have and create systems and processes and swim lanes and all these things, but you have to step back every once in a while and remember, "It's about the customer.
We need to make them really successful, and if we do that everything else will fall in place."
Yvonne: Yeah, that's right.
Grant: Yvonne, thank you so much again. I really appreciate having you on. It was so much insight shared, it was perfect.
Yvonne: Wonderful. Thank you.
There's never been a better time to be in technology, so it's fun to see what's going on.
I learn tons of new stuff every day, and I look forward to where we all go from here.