DEV Community: ted carstensen

Dear Founders: Start with Messaging

ted carstensen — Tue, 14 May 2019 18:51:48 +0000

This post was originally authored for the Heavybit blog by Heavybit General Partner Dana Oshiro. It has been reposted here in its entirety.

So here’s the thing: building the messaging framework isn’t just a marketing exercise. Don’t hand it to your PR agency or marketing leader to deal create while you’re off building features or closing sales. And don’t just sit in a boardroom for an hour and poof random tag lines into existence. A messaging framework, along with your persona document, can help you do a couple of things including:

Increasing productivity by removing approvals on every site change, sales deck or asset;
Aligning your team around your core persona, brand pillars, and overall mission; and,
Mapping key features to the promises you’ve made to end-users.

Sound interesting? In this post, I’ll walk you through the simplified version of building your first messaging framework. If you’re not familiar, this format is pretty standard.

But marketing experts like Reify suggest building a messaging framework from the bottom-up. Based on the above image, I have to agree. So here’s the actual order of how to build a messaging framework.

Building a real messaging process

Choose the Minimum Viable Stakeholders to Start: This probably includes the CEO, product leader, CTO, and the customer-facing head of support, marketing, or community. Each individual brings a different lens to the exercise. Schedule at least 3 meetings with all stakeholders in the room and set meeting objectives on how far you want to get in each meeting. Some of these discussions will get heated. My suggestion is scheduling a minimum of 4 group meetings in order to truly gain consensus.
*Start with Target Audience & Tone of Voice: * If you don’t have product/market fit, then you probably just have one core audience (or should). You probably also have a tone of voice (Eg. playful, professorial, informative, straight-forward). Aim to gain consensus around these two sections with the stakeholders in the room. This should be a fast exercise as most of it should be fairly uncontroversial.
*Now work on Brand Pillars & Supporting Examples: * This is harder. Every brand pillar represents a differentiator and why your users choose you. And every stakeholder in the room will WANT the brand pillars that support their aspirations. But this section isn’t about aspirations, but about what is. It’s for this reason, that every brand pillar is created with several supporting examples. Do NOT start wordsmithing. These are just “idea buckets” (mostly nouns) and supporting examples. Sometimes supporting examples are your high-use features, and sometimes they’re common comments from press, customers, and even dissenters. At Heavybit we’re currently working on refining our messaging. We never wanted to call ourselves an “accelerator” because there are weird early-stage connotations to the word, but the reality is that press and portfolio companies still say it. So yeah – we’re an accelerator for seed and Series A companies, and that’s one of our brand pillars.

It’s likely that it took you a while to gain consensus on the brand pillars and supporting examples. It might’ve even taken multiple meetings. Don’t take shortcuts here. Gaining consensus (or at least willing compromise) means your founding team and core executives are aligned and will use this to inform their teams. This next section is a good time to set new meetings and break out the thesaurus.

Commence wordsmithing!

The point of the next stage of the exercise is not to sprinkle all your good teamwork and “idea buckets” work with nonsense adjectives. Everyone thinks their baby is the “first”, “stellar”, “brilliant”, “superior”, “best”, “brightest”, and most attractive baby that ever crawled the earth. That might be true. But if that’s the case, you can probably just say what needs to be said.

**Headline Benefits (25 words): **Use your brand’s tone of voice and munge each brand pillar into a single sentence. I limit this to 25 words max. This encourages brevity. Saying something quickly and plainly is the most respectful thing you can do for end-users.
**Elevator Pitch (55 words): **The elevator pitch is 2-3 sentences that speak to your target audience. In this section, munge together the best parts of your headline benefits. This is sometimes referred to as your boilerplate. I limit this to 55 words max and it’s always written in 3rd person objective point of view.
**Positioning Statement (25 words): **This is often just used internally, but it’s still good to craft in Mad Libs style as a single sentence at max 25 words. Eg. For [target audience], our product provides [brand pillars 1,2,3] because [short-form headline benefits].
**Brand Promise (10 words): **This is basically your tagline. Use all you’ve wordsmithed above, reduce word count even further, and make it pithy. It doesn’t even have to be a proper sentence. Eg. github: how people build software

Mission Statement: Are we just typing here?

Some early startups just build their benefits and elevator pitch and create their mission in a completely separate exercise. That’s fine, but the point is you need to be ready to discuss a higher purpose and you can’t just say “Making the world a better place through [list of features].”

*Mission: * Unleash the BHAG! (big hairy audacious goal) All your effort to deliver customer benefits and value should roll up into something really meaningful. Create the single sentence that rallies your employees, users ,and community. Eg. Environmental Defense Fund: To preserve the natural systems on which all life depends

You are Not done

Once you’ve come to an agreement on the above (or even most of the above), you should have a working messaging framework. This needs to be revisited as you release new products, launch platform efforts, or when there are major inflection points in the company’s growth. But for now, you’ve got what Betty Junod calls, “your source of truth.” Here are some common ways to cascade the messaging framework:

*Headline Benefits: * These 3 sentences often form the 3 hero images and text on an early company’s website. They’re also incorporated into site nav, given separate landing pages and case studies, can be made into separate nurturing campaigns, become paid text campaigns, and can be used as swappable modules in the sales deck depending on a customer’s needs. Even if they can’t be recited in their perfectly wordsmithed form, your employees and community should be able to repeat the key tenets of these headline benefits.
*Elevator Pitch: * The elevator pitch is generally the sentence that gets appended as the boilerplate on a press release, is at the top of your “About” page, and is carried over to your company LinkedIn, Crunchbase, AngelList, and gets added to signature lines for every employee.
Positioning Statement & ** Brand Promise: **These often appear on field marketing banners and signage, SWAG, short-form descriptions like the corporate Twitter description and meta tags, presentation titles, and as snippets.
*Mission: * There’s a reason most messaging frameworks offer this at the top of the document and move on to the “how” and “why” your business exists. Your company’s mission statement can be used at all-hands, off-sites, in larger community and user conferences, and becomes the rallying cry that positions you as a positive player in a much larger industry or global narrative.

Testing Your Framework

Once you’ve landed on a messaging framework and your execs have shared it with the team, you’ve given everyone the tool and permission to launch more assets into the world. This should reduce bottlenecks and cut time on manager approvals. This alone is validation that the time spent on a messaging framework is time well spent. Further analysis of public comments, customer feedback, site engagement, and search campaigns etc. will also tell you what is sticking and what needs further tweaking. In essence, you’re never quite done with messaging, but you need to start now. If you understand what it takes to build a sustainable and useful developer or enterprise startup, then you also understand that all aspects of your company will continue to evolve over time. Messaging is no exception.

Interested in joining Heavybit? Our program is the only one of its kind to focus solely on taking developer products to market. Need help with developer traction, product market fit, and customer development? Apply today and start learning from world-class experts.

Product Marketing Best Practices with G Suite, Pusher and Measure

ted carstensen — Thu, 14 Mar 2019 16:35:00 +0000

Taking a product or feature to market requires more than just buzz. Great product marketing requires deep consideration of community feedback, customer discovery, product onboarding, positioning, content creation, demand, sales enablement, and adoption.

CRO of Pusher, Sylvain Giuliani, moderates a panel on product marketing success metrics, launch best practices, and the intricacies of managing a team ultimately responsible for platform adoption. He is joined by:

Indy Sen, Product Marketer at Google Cloud
Ursula Ayrout, CEO and Founder of Measure
Astha Malik, VP of Platform and Product Marketing at Zendesk

This panel was recorded on September 26th, 2018.

Full Transcript Below

Sylvain Giuliani: We’re going to talk about product marketing. Product marketing for me is something that is actually really important in my experience because people usually see this more as a call center or like doesn’t really provide revenue but in my experience, product marketing done right, has a significant impact on your company. And actually as a force multiplayer in your organization. Mainly, because they’ll be able to find new revenue channels by looking at the market, for example, optimizing your conversion funnel by mapping user journey, mapping content to that user journey, for example. And also understanding what feature to build in your product to win the market by listening to what’s going on in the market and getting customer feedback. And, obviously, at the end of the day, it’s about revenue, and that will empower the sales team to close more deals, bigger deals, faster deals.

So, before we jump into this with our panelists, let’s quickly introduce ourselves. So I’ll start. I’m Sylvain, I’m the CRO of Pusher. Pusher has been around for a long time for people that don’t know. We provide APIs to developers, so as to enable them to build real time features into their application like chat, in-app notification, activity feed, and so on. I just recently relocated to the Bay Area, so if anybody has food recommendations, activity recommendations for me, please talk to me after the session. Now the panelists will introduce themselves.

Ursula Ayrout: Hey everyone, I’m Ursula Ayrout. I actually work for myself. I run a small marketing agency that helps startups and mid-sized companies with their marketing. So we do three things. We help companies with their messaging and positioning, their demand gen and content, and, finally, their B2B strategy.

Indy Sen: Good evening everyone my name is Indy Sen. I’m a Product Marketer over at Google Cloud, our enterprise facing business. I work specifically on G Suite which is our collaboration and prodigy platform and I market specifically to the developer audience so developers and partners to get them to build integrations and add-ons and custom applications on the G Suite platform.

Astha Malik: I’m Astha Malik and I’m the Head of Product and Platform Marketing at Zendesk, and I recently inherited the sales enablement team as well, so I’m doing a bunch of things at a very high-growth, intense and fun environment.

Sylvain: That’s great. We’ll talk about sales with everyone later on so we can definitely talk about that with you. But I thought for tonight we could start with, essentially, looking at the differences between product marketing and developer evangelists and community marketing, because that’s usually where devtool companies start, and would love to hear your thoughts on that. So, maybe, Indy, you have a background doing these things, so tell us the difference between the roles.

Indy: Yeah, happy to. So, you know, some of the background I have, before Google I was head of Developer Relations and Marketing over at MuleSoft, and then I also kind of dabbled, and I’ve always done some of this platform developer facing things at other companies, including Box and Salesforce. So, I’ve been both, in the shoes of community manager, developer evangelist, or certainly work with them. I would say, there are a couple of differences.

I think community managers are the first line of defense with developers. They’ll be the voice of your organization, and almost like the brand, from a cultural and ambassadorship standpoint. Where I see the overlap with product marketing, specifically, is that I think product marketing can be, at its core, the messaging arm of what that organization’s going to do. So, if you think about it, product marketing might create the content, or the main strand of messaging and then folks like community managers or developer evangelists will be the ones spreading that message through the appropriate channels. So, that would be the major handshake that comes to mind, is that product marketing, provides some of the direction, the backbone, either from the structural standpoint or a messaging standpoint, and then community managers and evangelists are the ones who execute out in the field and leverage that messaging.

Sylvain: OK, what about you, Ursula, do you have any thoughts on this?

Ursula: Yes, so I worked at Pantheon for two years. It’s a website platform for Drupal and WordPress websites. And developer evangelism was a big thing for us, because we had an open source community. So we probably went to over a 100 different meetups. When you think about developer evangelism, it’s always all about the meetups. It was the responsibility of the marketing team, and within the marketing team, the larger marketing team, to actually tell the developer evangelist what was on offer, what were the products they needed to promote, give them notation, et cetera, and all those fun things, and what the demo was. And I think, the big thing is with developer evangelism, specifically around product marketing, is how you measure it. And so we worked very closely as a marketing team to really measure those results, to have them tie into product development.

Sylvain: OK, both of you mentioned brand. You think brand sits within the product marketing organization, or is that something owned by someone else?

Ursula: Well, if you think about a marketing organization, you’ve got the CMO or a VP of Marketing at the top level, and then, in a mature company, let’s say you’ve got 10 employees, I would think the head of marketing typically owns brand. In a larger company, it’s probably corporate communications, probably similar at Zendesk?

Astha: We have a very different structure. I’m happy to talk about that.

Ursula: OK, for smaller companies, you’ve got product marketing, and you’ve got your demand gen team, then you’ve got your developer evangelism, then you’ve got marketing operations, and then you’ve got your web team. So, brand kind of sits in within every one’s purview, but it’s run by the head of marketing, specifically, and the CER.

Sylvain: OK, and what about at Zendesk?

Astha: Yeah, so I think Zendesk is pretty unique. I would agree with Ursula for the most part, I think, in all the companies that I’ve worked in the past, brands sits within marketing, typically, under corporate marketing, and very small organizations, like you said, it becomes a responsibility of product marketing. But at Zendesk, for those of you who’ve seen our brand, and maybe the evolution over the last 10 years or so, we have a very strong and a very unique identity. We’re this quirky, fun brand, and very specific about the ethos that we want to communicate around simplicity and also sort of user-centric messaging.

So, from the very beginning, our Chief Creative Officer has reported to our CEO directly, and that’s still the case. And I think, in a way that’s helped us retain that brand identity, while evolving it, of course, to meet the growing needs of the company as we scaled. But that’s the structure of Zendesk, and we went through a recent messaging refresh exercise, which my team led, but it was in close collaboration with the brand team, because it’s important that when you’re sending out new messages to the market, when you’re positioning yourselves differently, you are looking at the entire picture of like how the brand comes across to people. Both, prospects and customers, so, it’s definitely a very close partnership between the two teams.

Sylvain: On that front, staying at that more general level, can you tell me a bit about the biggest mistake you made around product marketing? What was it, and what did you learn from it?

Indy: Let’s come up with something that’s not too sad. In product marketing, specially, if you think about where we are going in terms of when you’re helping set the structure and direction of what types of activities you’re going to focus on especially at smaller companies. There’s tons of bets you’re going to place. There are things you can do from an awareness standpoint, like ads, you can do webs, you can use things like Optimizely, and conduct experiments, cause you own that.

When I was at MuleSoft, I thought of myself as sort of more like a full stack marketer, I was responsible for everything that was developer facing, awareness, consideration, all that we do adoption. One example that I have in terms of lessons that I learned was that, strategy does not always travel, and what I mean by that, is that you may have knocked it out of the park with a specific event or template, a playbook that you had at a company like Salesforce or Box, and then you try to take it over to your other company, and you execute the same playbook, it’s not going to always work out. And I think the main reason why it doesn’t work out is that every developer is different, obviously, your product is different, where you are in your cycle as a company is also different.

So, one example that I learned was I tried to execute a very similar play that I had when I was at Box, where the idea was to graft onto a bigger event, like Google I/O. We at the time, were marketing this ecosystem of applications called OneCloud, which is, basically, all these applications that integrated with Box as a file system, and we just launched the Android version of that ecosystem. So we had this awesome party, just couple of blocks down over at the Cartoon Art Museum, during Google I/O, and developers just showed up in droves. We kind of did a little bit of word-of-mouth, and some marketing, and all these people with I/O badges just showed up, and it was a great event. Fast forward to a couple of years afterwards, we were trying to do something again, very high-touch and high-quality with our developers from MuleSoft, and I said, hey why don’t we try this venue, the Cartoon Art Museum, developers love it. We had our founder Ross Mason come and speak with us. But the big difference was that the demographic was different.

MuleSoft is an enterprise integration platform. The developers probably skew a little bit older, they probably used tools that give them PTSD to this day. Most of them work for bigger companies, so it was not the same demographic, and it wasn’t the same type of developer. A party in the middle of the week, which meant you wouldn’t have time to pick up your kids, that kind of stuff. So it didn’t quite work as well as the one we had for Box with the younger developers.

Sylvain: That’s definitely something that happens, as he said, playbook doesn’t always travel really well with every organization. What are the different types of launches that you dealt with as part of the programming function, like, Astha, you have a big suite of products now under your umbrella. Can you tell us a bit more about that?

Astha: I think, product launches are product launches. You can, basically, tier them. My team manages seven different product lines now. When you tier them, you can imagine that, maybe it’s a brand new product that you’re introducing that requires a different kind of effort. If it’s a feature update, it requires a different kind of effort, so, we have come up with a structure that helps us, to just organize the different type of launches that we roll out at Zendesk.

One thing that is critical to any product launch success and, you talked about templates and it kind of goes back to playbooks and templates that we’ve all used in different companies, and we try and repeat them in different places, I think it’s good to remind yourself that when you reengineer your product, you have to reengineer the conversation. And for that you have to go back and look at the people that you’re going to sell this to, so, instead of focusing on just what’s new in the product, or if it’s a new product, what are the features going to do, you have to focus on the storytelling. And the storytelling only works if you know your people.

So, I think this is one of the mistakes a lot of product marketers make as well, like not investing enough time in understanding the personas that they’re going to target. And we operate in an attention economy, so it’s not so much about technology being the barrier to entry, or technology being the barrier to success, but it’s actually storytelling and relaying a message, and brand becomes sort of like a memory game. So, do people recognize what you do, do they really understand what the company and their products stand for, and the value it delivers? Product launches are not about, OK, we’ve released a bunch of things and like what do each of these features do, that’s great, those descriptions are very important, but focusing on the jobs to be done, focusing on, how they’re going to sell and solve problems for the customers is important.

One orientation that always helps is like most of the companies here, I know there are many B2C too, but majority of the companies here are B2B companies. But at the end of the day, you’re selling it to people, and having that B2C mindset in a B2B environment really helps to succeed with products and launches.

Ursula: One thing that I’d be upfront with your leadership team is, what are the metrics for success? Why are you launching this product? Is it for awareness? Great, so what are the metrics for awareness? Is it for usage? What is the awareness for usage? Is it conversion? What are the metrics for conversion? Et cetera. And just to dovetail on your message around storytelling, I think if you can’t figure out your key differentiation points with your product, then don’t create a product launch. Don’t go out to market, if you’re not clear with what your differentiators are. Recently, I was working with a client, and we just couldn’t get to the differentiation. And I think we realized that they wanted to create this product, because a competitor had it, but yet, they didn’t have the right differentiation. So, really think about your messaging tray, your positioning, what it is, and why you’re doing it.

Indy: If I could just quickly add to that. At Google, we have different stages, we have what we now call, alphas, betas, and then GA, Generally Available, and sometimes, we’ll use the alpha and the beta as interim stage gates where we do work, not only on the minimum viable product, but also what we call, the minimum viable positioning. There’s so much input that you’ll get from some of the smaller cadre of developers, who’ll influence your ultimate messaging. This happened maybe about a year ago, but a lot of times, given our consumer heritage, we blog something, and people will be like, Oh, let’s try it, it’s from Google, it’s great.

In the enterprise, and specifically to enterprise developers, it doesn’t work that way. You have to work on the messaging. It’s not just about the launch, it’s actually about the landing. And so we have a whole team that sits within product marketing called the landings team, and before every launch, they’ll ask, what are the metrics, is it awareness? Or is it the messaging pull through, is it the coverage, or what’s 30 days, 60 days, 90 days pattern of usage?

Sylvain: Another question that I had was, product marketing is usually not a goal or KPI-oriented team, because most people think that’s content generation, or positioning messaging. But as we just discussed, there’s actually KPI involved with launches, so what are the KPIs or how do you come up with goals for the product marketing team? Astha, you have a large team. How do you manage that?

Astha: We’re very particular about making sure that we have measurable success tied to our product launches and execution. I am of the belief that the product marketer is an expert on the product and the market, and that’s why they’re developing the positioning, the messaging, and that ends up getting used by both sales and the rest of the marketing organization. That’s the reason why they have this obligation to own the business matrix, like pipeline generation. If you are feeding that content into campaigns, into digital programs, et cetera, you need to go on that number. So my team does that. We have ownership of those numbers directly, alongside, of course, our campaigns and digital team. And then on the product side, when we are launching new products, et cetera, my team is also responsible for making sure that the product launch is successful, which, again, depending on the launch, the metrics can be different, but typically, they are around product usage. We have measurable KPIs.

Sylvain: Google is famous for using OKRs, what do OKRs for product marketing look like?

Indy: One product that my team just launched is a product called AppMakr, which is a local development platform that’s built on the G Suite infrastructure. Here we’re looking at adoption and number of customers, number of domains, number of apps created. As a developer product, it’s mostly going to be adoption-based. We do look at the pipeline in terms of influenced deals. The way the product is packaged is that it’s included in business and enterprise versions of G Suite. What I have been tracking is, for example, the number of signups from the G Suite signup page, for the overall product, which includes Gmail, Sheets, Slides. AppMakr is already among the top influencers of signups. Nobody really thought to ask that question, but as a product marketer, it’s really good because if anything, that helps you influence decisions. If the web page is restructured, what are the things that we want to put out there? In this case, it looks like people are interested in this product.

Ursula: One of the big things I find when you’re doing product launches, especially with startups, they always offer you an opportunity to bump your revenue up, because you’re getting your entire company in your team, your product team, your marketing team, and your sales team, aligned on one vision and one timeline. So, a lot of great things can happen if you have an end day that’s very specific, and everyone has to meet that goal.

When I was working at Pantheon, and with these startups, whenever one gathers around a product launch and a product launch day, you actually get to see a really nice bump in pipeline, in revenue. So if you’re struggling with getting to the right pipeline, or the sales numbers, find an opportunity to create a product launch, it’s a great way to package all of your features that you’re sending out every two weeks, or every three weeks, or every four weeks, in a more meaningful way that then helps the customer understand what your product is and what your position is in the marketplace.

Sylvain: Let’s talk about the relationship with the rest of organization. You mentioned sales enablement. How does the PMM function interact with sales? I’ve seen sales as part of PMM, I’ve seen sales enablement being its own team that reports to the VP of Sales. What’s your experience with that?

Astha: I think product marketing is unique in the sense that, product marketing sits in between sales and product. So, if I think about the two most important stake holders in the organization, those are the two organizations and teams that we work with a ton. Product, of course, because of the knowledge of the product and the market. If we want to influence the product roadmap, the product strategy, work with them on pricing, packaging, and other more strategic things that are tied to the overall product strategy. And then sales, because if you are responsible for product messaging and positioning, et cetera, you want to make sure that the messages that marketing is sending out in the market are consistent with the messages sales are going to be relaying to their prospects and customers. They have to be both consistent and compelling.

Sales enablement, positioning is very different from what you tell to the customer and prospects. There are a variety of things that go into it which are, how to sell the product, but also how to tell a story, and skills development also because we hire sales people from a variety of different backgrounds with a variety of different experiences, and you just have to nurture their skillsets too. The way that it worked out at Zendesk was that product marketing and sales enablement were working so well, close together, it made sense that the two organizations merged and started working together. Sales and partner enablement, both, by collaborating so closely, by being a part of the same team, helps boost efficiency and influences and informs the priorities for both the teams. So that’s working beautifully for us.

Sylvain: Ursula, in the startup world, who usually owns the sales enablement, is it sales people owning it themselves, or is someone else pushing it?

Ursula: I think it’s a combination of both. I think whoever has a bit more bandwidth usually takes ownership of it, but, typically it’s marketing and sales collaborating together and just really coming up with the very short list of deliverables that the sales team needs to be super successful.

Sylvain: When you say deliverables, what kind of deliverables?

Ursula: Deliverables could be a sales deck, it could be the demo, or it could be the demo script, it could be sales scripts, it could also be the competitive stories. How do you compete with this new product offering, how do you then compete with the competitors? What are those messages, how do you rebut them? You’ve got this thing called the competitive battle card and then the customers’ stories are really critical, as well, so how do you tell the new product offering through the eyes of the customer? So, those are really important tactics or deliverables that I think you can’t launch, you need those before you can launch a product.

Indy: So much of what product marketing does, a lot of people think of big ticket messaging, the billboards, the branding, the messaging, but, especially in the enterprise, it’s all about that field enablement. When we have launches, at Google, there’s this term that we call the bill of materials, that’s attached to every launch. That’s where you work hand in hand with the product organizations, sales, and be like, Hey, do you want battle cards, you want the sales deck? It’s not the glossy stuff that you’re going to see on the billboard, but it’s the stuff that the field is going to carry with them. And that’s where the real battle happens. That’s extremely important from the sales enablement standpoint and having some kind of agreement on the bill of materials and the scope also sets you up for success, because you, as part of marketing, can quarterback the assets, you don’t have to do all of it yourself, but at least you agree on what’s going to be part of the envelope.

Sylvain: You mentioned billboards. We are in billboard city for tech products. What’s your take on billboards?

Ursula: When I worked at Salesforce, we had a billboard for recruiting. We had just launched a new campaign around, Welcome to your dreamjob #dreamjob. Remember that? A billboard made sense, because we needed to hire sales reps, and it was such a competitive market for hiring. We wanted to shift people’s mindset that Salesforce was a sexy company, and we were hiring sales reps. It just really depends on what your objective is. For us, it was around awareness.

Astha: That should be the objective with billboards, you can’t expect anything more than awareness, so if you can measure the brand recall, that should serve you really well. There are a lot of success stories out there. Box for example, its billboard caught everyone’s attention when, they compared themselves to SharePoint. You just have to have provocative, succinct and concise messaging. Your point should not be to tell your entire story and what the company does and how everyone on the company is working, but it should be about making a strong statement. And I think those are the ones that are really successful, if you look at Apple and Box, you’ll see a couple of new billboards popping up because of Dreamforce this week. They are very provocative. That’s when they catch your attention. I’ve seen billboards that I really don’t want to look at when I’m driving, even if I have the time, because there’s just too much going on on a small real estate.

Indy: It has to be really succinct. I do have one Box story about the space where we had the “SharePoint sucks” billboard. That’s a space that, as a company, you have to rent out, months in advance. It’s actually pretty expensive, in the thousands, double-digit thousands of dollars, at a time. We had rented a space for three months at one point, when we launched this OneCloud ecosystem but had no major campaign. So we actually used that as a rallying cry for the OneCloud ecosystem, where we told all these partners that were integrating with us, we kind of dangled this carrot being like, if you integrate in time for this announcement, you will be one of the logos on our billboard.

What was amazing about that is the outcome. We were all enthralled with the idea but what ended up happening, which was great, was that the partners came back to us and some of them stopped on the highway to take pictures, and then the investors were driving by, and they would say, Hey why is Breazy Locals on the Box thing, that’s awesome. So, it was just one of those things where you took advantage of not just your awareness, but you created like an umbrella of awareness for others as well. It was almost the equivalent of the Bat Signal on Gotham City. This is what we stand for. It can be pretty powerful that way too.

Astha: I used to joke with my team during my days at Citrix and even afterwards, that you should indulge in a little opium, which means, other people’s money and brand. Partnerships from that perspective can really help boost the brand awareness and there are many cool stories out there that help validate that.

Sylvain: OK, cool, well thank you for that. It’s time to open up the floor for questions.

Astha: I’m happy to take that first, and I’m sure you guys have input there too. I run a team of almost 42 people now, so I’ve got a large team. And the way that I started structuring my team, and you’re absolutely right, that in the beginning it’s all about a few people and they’re the jack of all trades and trying to do as many things as possible. Then you start getting specialized, and a lot of people tend to specialize in terms of the product lines that they own. I have a different approach, I think it’s best to structure in terms of how your customers are purchasing the product. So, if you orient your teams around certain solutions, initiatives that the customers are taking, I think, that’ll serve you well, and that also gives you agility and fluidity you need as the strategy of the company evolves, as you scale, to restructure the team, again, based on how customers are purchasing from you. So, that’s the way that I structure my team.

Ursula: Your metrics change, obviously, so that’s the first thing you say. You think about is this product now created for upsell, which you’ve got your existing customers, so it’s a great strategy to do so. It really doesn’t change, actually, it’s just the mindset shifts, because your metrics just are shifting to upsell, and I think it becomes more account management. So, you’re rather than arming the sales team, or you can be arming the sales team. You’re also arming your account management team to sell

Indy: I think one thing that changes is, tactically, there might be some core product marketing disciplines that you can take to task to do that. pricing and packaging comes to mind. You may want to think about, if my goal now as an organization is to upsell, are my things packaged in the right way? If you were just focused on conversions and net new customers, you probably were not thinking about pricing and segmentation, as a way to foster that upsell opportunity. You may want to go back and really think about, are my things packaged in the right way and am I talking about them in the right way? That would be at least one thing that comes to mind.

Astha: I think in addition to that, your go to market execution changes. The teams that are involved in selling, that drastically changes. I can tell you, like in organizations where you have brand new product launches, or you’re just trying to sell existing products to new customers, you tend to leverage your SDR teams, et cetera. When you’re upselling, you have to focus on what the value propositions are for existing customers, and how you engage the account teams more. From an enablement perspective, the focus changes on, how do we tell a compelling story to existing customers and what additional value are we really providing for them?

Ursula: Also the success organizations and customers success then can also be the pool that also enables the upsell.

Astha: In a nutshell, the short answer is a lot.What I do want to do here is give due credit to our creative team. I think we have a super strong creative team. We can have the best messages, and we can create the best content out there, but the delivery, the way it comes to life, and pictures and videos, et cetera, that is our masterminds and the creative team, who do a fabulous job. So to me it’s a partnership, from the ground up, meaning whenever we’ve had a new project or whenever we’ve had branding and messaging refresh, in addition to the videos and stuff, we uplevel the messaging.

If you remember the tagline for those of you who keep track of Zendesk. Relationships are complicated, used to be our tagline years ago. Because we play in the CRM space, it was all about maintaining great relationships with customers, et cetera. But as the company evolved and we started selling more and more upmarket and to enterprise customers, we started thinking differently about, you know, how we go about and make more than just a statement. How do we tell companies what we can help them do. So, when we went through the refresh last year, product marketing took the lead on doing a bunch of surveys, because I’m a big believer that with messaging, for those of you who are in marketing and product marketing or brand, everyone has an opinion on it. And you can’t really compete or discuss opinions rationally.

So, I am a firm believer in backing things up with data. And we did qualitative, quantitative surveys, both, internally with our employees, and then, of course, with our customers as well. And the result was that beautiful partnership that I talked about with the creative team. And now we’ve upleveled our messaging as well, and if you go to our website, instead of Relationships are complicated, you’ll see, We help companies become the companies that customers want them to be. So, it’s beautiful, it’s simple, very close to our ethos. Become the company your customers want you to be. It has a powerful meaning to it. And that also tells you that, we are here to help you with that. And the subtag there is , The best experience is that built with Zendesk. We remain a company that is averse to buzzwords and fluff, and all that stuff. We speak in simple terms that people can understand, because we think that we are marketing to people, and not necessarily brick-and-mortar companies if you will.

Indy: The relationship between product managers and product marketing is really important. If you’re a product marketer and you don’t talk to product, then there’s something wrong. I don know if this is still the case, but when I was at Salesforce, product was in a different building. We would get some of the messaging strands all the way from like Marc Benioff, who famously knows exactly how he wants to steer the company. But to me, it’s an essential partnership. Engineering and product, figure out what the plot is, of what you’re going to be doing, and then product marketing can help you build the narrative If you remember me talking about alphas, betas, and GAs, in the interim period, where you’re testing the product with a small amount of customers, that’s when you really have got to be in sync and keep your ear on the ground as a product marketer, listen to what people are saying about the product, because, all of a sudden, something that might have been like voted a priority in prioritization for product people and, “we want to build this because this is cool” but other people are like, “people need this because they can’t get anything done if they don’t have this.” Your job as a part of marketing in particular is to be more attentive to those kind of things because you can parse what the customer is going to say, as opposed to what engineering might be hell-bent on wanting to build and deliver. It’s not always the case, but that’s where the partnership works really well.

Ursula: Also, product marketing should always be on sales calls and really speaking to the customers. All of a sudden, you have customer, product, marketing to product. So, you’ve got all of that information that really connects nicely, with product marketing being right in the center of that.

Astha: My team contributes or represents the voice of the customer. We run the market strategy in competitive team as well, so, for us gathering information on win-loss, gathering information on churn, regularly keeping in touch with our customers, helps us sort of build that credibility with the product team. I don’t really care much about the organization structure, I think you have to look beyond the silos. I’ve been part of product marketing teams that were wrapped under product teams and then here, that’s not the case, we’re under the marketing team. But to me, that partnership is absolutely critical, but then that relationship is only meaningful when you’re doing your part and really understanding your customers better. And you need to own that, as a marketer, as a product marketer.

Astha: When you start talking to customers as frequently as they do.

Ursula: Invite yourself to the meetings.

Astha: I think that’s absolutely important. Split up the work, product and marketing is about= being an expert on the product and the market. And the market, basically, is a representation of your prospects and customers. Getting a strong hold of that is important to build that credibility. There’s no other way, there’s no shortcut.

Sylvain: I would also add on that that the best way to win the heart of a sales team is to, if you train them properly on how to push your product, and you enable them to sell more, usually that brings a lot of credibility and they will love you for it so that’s a great way to show them that you support them.

Astha: Listening is important. Just listen to customers, both internally and externally. One of the things that we did differently with the sales enablement team, when I inherited it back in January of this year, was to apply that same customer journey mindset thatwe applied to our clients that are paying us. So, when you think about sales enablement, you have to treat them as your internal clients, and listen to their needs, what are they struggling with, and that comes by not only by just being a part of the conversation with them, but then being with them in their situations, meaning customer calls and keeping direct touch with the customer.

Sylvain: I have one final question for the panel. Hopefully, if you weren’t convinced that you need to hire product marketing, you should be convinced by now. If you were giving advice on hiring the first product marketer, what would be the thing to look for in those first candidates?

Ursula: I would say how well they can tell the story, and how well they can get the leadership team aligned to work with them on creating a consistent and cohesive messaging manifesto.

Indy: We were talking earlier about minimum viable positioning. I think you need somebody who can come on the ground and help ask those questions. We were talking before this panel, about how so many of the conversations with early stage founders, you realize that they’re not even in sync about what they’re building and why, until you start probing around. Hey, what’s your messaging, what’s your narrative? So, I think somebody who can deliver, help that narrative, it kind of goes hand in hand with the platform that you’re building. To me a good platform’s a good story, but a good story is also a good platform.

Astha: It’s also important to keep in mind that, the answer to the next set of requirements is not going to be consistent. So that depends on what the company is doing, what kind of market is it operating in, and is it highly competitive, and the goal is first to get some brand awareness, and then move towards more differentiation.Those factors definitely play in. Storytelling, that’s just key.

Customer Security Questionnaires: The VRA Two-Step

ted carstensen — Tue, 19 Feb 2019 17:00:00 +0000

This was post originally authored by George Chamales and published on heavybit.com.

Vendor Risk Assessments (VRAs) are the consistently annoying security questionnaires that pop up at the worst possible time in your sales cycle.

Don’t let the long spreadsheets and intimidating web forms fool you: VRAs are not a rigorously developed, objectively analyzed test of your security. Instead, they’re a lot more like convincing your date’s overbearing parents that your intentions are honorable and you’ll be back by curfew. It’s a game of diplomacy and impressions where your best bet is to show up well-dressed, be polite, and get out of there as quickly as possible.

The common approach of dumping VRAs on your CTO wastes valuable time and limits your ability to maneuver. You need a way to appease your Reviewer, delight your Champion, and set a high bar for your Competition. You need to do it all with a minimum amount of time and effort.

What you need is the VRA Two Step.

Here’s how it’s done. Background and roles are next, click here for tickets and here for tips.

Step 1. Arm your Champion

Before the VRA process is started the Sales Lead sends your Champion a ghostwritten Framing doc that describes what your service is, how they’ll use it, the risks, and some highlights of its security. The document helps your Champion pitch your product internally and should be sent to the Reviewer – providing useful context that can shape the rest of the VRA process.

Step 2. Charm your Reviewer

The Sales Lead manages all interactions with your Reviewer. They’ll stay upbeat in every interaction and promise a completed response in two weeks. Your Reviewer is guaranteed to be an overworked professional that never gets enough respect. Save them time and show them some kindness; it’ll work wonders.

Step 3. Fill Out the VRA

The Sales Lead passes the VRA off to the Verifier (a play on VRA-ifier [0]). The Verifier should be a team member with enough availability to complete the form within two weeks, enough technical savvy to understand the material, and enough diplomatic savvy to deal with questions that are vague, irrelevant, or just pants-on-head crazy. The Verifier will leverage the company’s security policies, previously completed VRAs, a list of tips and tricks, and their own hard-earned experience to send the completed questionnaire back to Sales by (or before) the deadline.

[As Needed] Fall Back to the CTO

Questions that the Verifier doesn’t know the answer to should be forwarded to the CTO who will find the right answers from the tech team. When this happens, the Verifier should capture the answers in the form of an updated policy or their list of tips and tricks.

[As Needed] Clarify

If the Reviewer comes back with “concerns” about your answers, the sales lead will loop in the CTO who will do whatever they can to resolve any misunderstandings. As part of this, the CTO may need to throw the Verifier under the bus, apologize profusely to the Reviewer, and lament about the difficulty of finding good help these days…whatever it takes to get the sign-off.

VRAs: Where did they come from, where do they go

Chances are good that the last VRA you slogged through was created over a decade ago by a committee who were forced by their industry’s compliance requirements to DO SOMETHING about third party risk. The members of the committee had non-technical titles like compliance, insurance, officer, and esquire. After much deliberation, the team agreed that the best way to design a VRA that’s custom-tailored to their company was to copy and paste the contents of a questionnaire someone had used at their last job.

Since then, the recycled questionnaire has undergone yearly reviews where new members of the committee have to add something in order to show that THEY’RE PARTICIPATING. Like all committees, these contributions are driven by a combination of good faith, bad faith, blind faith, and the faith that they’ll be retired long before anyone realizes just how bad things really are.[1]

That stream of additions (never removals) is why VRAs are full of questions that range from boilerplate to inconsistent, confusing, outdated, uninformed, and irrelevant. Inevitably, someone on the committee decides that their contribution will be to “streamline” the process by migrating it to an enterprise web app that used to be top of the line, but today is guaranteed to be broken on every web browser except the version of Internet Explorer that shipped with Windows XP.

If you’ve ever felt like you’re going insane while filling out a VRA, that is completely understandable – these questionnaires are bureaucratic schizophrenia in spreadsheet form.

And if you think that’s bad, imagine having to review them day, after day, after day, after day.

Chances are good your Reviewer is sitting at the bottom of a highly political branch of the corporate org chart. They could be in a security team under the legal department, or a technical team under the risk department, or a compliance team under the insurance department…and wherever they are, it’ll all get shifted around in the next re-org.

The Reviewers themselves may be fresh out of college or a hardened professional, a technophile or technophobe, a security expert or just plain insecure, aspiring to rise in the ranks or headed for the exit. The only consistency is that they’ll be overworked, underpaid, and know that they’re taking all of the risk for being wrong and getting none of the rewards for being right.

That combination of personal and political variables means that there’s absolutely no way to know how rigorous the VRA review process will be at any given customer at any given time. A billion dollar financial institution may wave you through with no more than a cursory glance, while a five year old SAAS company will take months and require everything from detailed background checks to blood sacrifices.

While there have been attempts to create standardized questionnaires or outsource the review process, these strategies have not caught on. The rise in popularity of compliance regimes like SOC 2 or ISO 27001 are beginning to be integrated into the process, but it’s an open question if shelling out for a compliance report will replace VRAs or come to be seen as table stakes for the future. The VRA gauntlet isn’t going away, you need to strategize accordingly.

Role Playing

The following are some notes to each of the players in your company that will take part in the VRA process. Everyone involved read through these notes to get a sense for what the rest of the team will be doing.

Sales Lead

The good news is that you’ve made it far enough through the sales cycle that your prospect is willing to burn time and money putting you through the security review process. Your role now is to be the face of the VRA process – you’ll handle all back-and-forths short of pulling in the CTO to clarify things.

Arm Your Champion – The Framing Doc

Sending the Framing Doc is a gamble, but since the Reviewer will put you through the maximum level of scrutiny without it, it’s a gamble with limited downside and plenty of upside.

One of the main things that’s missing from VRAs is any sort of context about what your company actually does. Without that, the Reviewer will be forced to assume that you pose an existential threat to the company (and therefore their job) and will put you through the absolute highest level of scrutiny.

The Framing doc gives you the chance that by adding context up front you can get the Reviewer do dial down their professional paranoia, ideally giving you an easier path through the review process. An added bonus – the champion could also pull sections from the doc to use to advocate for your company in their internal briefings, presentations, etc.

How much you customize the Framing Doc is up to you, but taking a minute to put it in your champion’s voice and listing specifics of how they’ll us it can make it easier for them to play it off as something they put together.

Charm Your Reviewer – Be Relentlessly Positive

Your communications with the Reviewer should carry an air of cheerful, positive deference…no matter what is happening in the process. Your approach should always assume that if there’s any issues it’s likely a misunderstanding that you’re happy to get patched up by finding better answers or pulling in the CTO to help clarify.

Always Open VRAs Upon Receipt

You’ll want to make sure the document hasn’t been corrupted or that your credentials to the online portal work before promising the Reviewer to have it done within two weeks.

Respond Promptly

Reviewers hate it when they send over a VRA and don’t hear anything back. After you’ve opened up the VRA, respond with a thank you note letting them know you’ve opened it and plan to have it back to them within 2 weeks.

Verifier

Congratulations, you’ve been made the company Verifier. It’s a thankless, annoying job, but it’s absolutely critical for your company to be able to close deals. You’ll be taking a huge load off of the sales team and CTO so they all owe you beer at the very least.

2 Weeks is Aggressive but Possible

What makes this doable is that there’s a huge amount of repetition between VRAs – by the time you’ve filled out four or five you’ll have answered 90% of the questions you’re ever going to see. The remaining 10% will be weird stuff you’ll need to deal with on a case-by-case basis.

Shoot to Finish Early

Don’t leave filling out the doc until the end of the two week deadline, you never know when you’re going to hit questions that will require the tech team to answer. Finishing early will make your company look great.

Fall-Back to the CTO As Needed

There’s going to be questions you don’t know the answer to. You’ll need to take them to the CTO for answers – the CTO can then direct you to the right person on the technical team and make sure that person will answer you in a timely manner (you’re easy to blow off, the CTO not so much).

Build a List of Tips

Your list of tips is an internal doc where you should jot down specific tactics and strategies that you’ve come up with to make this process work. It’s a helpful reminder and the sort of thing that can be handed off to the next person who inherits the job. Here’s some tips to get started.

Remember – This is Highly Subjective

You are not being compared to some golden ideal of security – you’re being compared to everyone else…and that’s an extremely low bar.

CTO

You’ve been saying for ages that you have better things to do than fill out these damn spreadsheets. You’re right. The trick is building a process to offload them to somebody else. Here’s a set of helpful tickets to set up the VRA Two Step inside your company.

Support the Verifier When They Ask For Help

If the Verifier is stuck you’ll need to direct them to the right people inside your team to get them answers. Be sure your team members know that the Verifier is on a deadline and they need to respond ASAP. Most answers shouldn’t take more than a few minutes.

Clarify == Own the Issues, Fix them Quickly

Whenever you get pulled in to help the Sales Lead deal with issues the Reviewer has sent over you should be prepared to treat it like one big misunderstanding, which you and your team will take all the responsibility for – even when the issue is that the questions were vague or the Reviewer doesn’t know what they’re talking about.

Playing it humble and taking it all on yourself is your best bet to figure out what the Reviewer wants to see to give you the go-ahead. Once they do, give it to them as quickly as possible and get on with your life.

Outro: An Apology for VRAs

One of the most annoying things about the VRA process is that it’s not a bad idea. Third party services do pose a significant, ongoing risk that a company’s sensitive data can be compromised by malicious hackers or accidentally exposed to the Internet.

Regulations and compliance regimes that force security as a precondition to enterprise contracts have done more to move the needle on computer defense than anything the security industry has said or done in the last thirty years. The existential risk of hackers is real, but the financial risk of regulatory fines or not closing a deal is a much more effective motivator.

As easy as it is to complain about the VRA process (and it is so easy), we benefit every day from security controls that were forced in place to mitigate third party risk. Yes, there’s problems with the designed-by-committee, reviewed by God-knows-who approach to the VRA process, but until we come up with something better it’s the best we’ve got.

In the meantime, there’s the VRA Two Step. It is 100% guaranteed to not work perfectly every time, there’s just too much variation between people and processes. What it does promise is give a standard, efficient approach with the maximum amount of flexibility. That flexibility is essential as you fight your way through each customer’s uniquely weird VRA gauntlet.

Good luck.

George Chamales is a useful person to have around. Please send critiques of this post directly to george@criticalsec.com.

[0] This is compliance humor. You can tell because it’s not funny.

[1] These faiths are known collectively as the Four Horsemen of the Corporate Apocalypse

Do you have valuable insights and experiences in the developer tool space that you’d like to share with our community? We want to hear from you – join our contributor program today.

From 0 to 1, Hiring Your First Product Manager

ted carstensen — Wed, 06 Feb 2019 17:00:00 +0000

This article was originally written for the Heavybit blog by Connie Kwan.

I had the opportunity to meet with several Heavybit member companies for office hours recently. During my sessions, two major themes came up that I wanted to detail for the larger Heavybit community: platform contributor incentives , which I covered in this post, and product management organization design which I’ll be detailing in this two-part series.

For any founder, particularly technical founders who are closer to the code than non-technical founders, hiring the first Product Manager is risky business. It’s usually prompted by the founder or engineering leader declaring

“I’m too busy fundraising, hiring, and/or fill in the blank, to manage the product too. I’m worried that the product will suffer for it. Let’s hire someone.” Or,
“I’m worried that we’re building a snowflake product for every customer. Will my product scale?” Or at larger companies,
“Sales is saying we will win accounts if only engineering can build faster, but engineering is saying that sales is asking the impossible. There has to be a way forward here, maybe we need someone to champion our priorities.”

Unless there is absolutely no product experience whatsoever in the founding leadership team, it is unlikely that a VP of Product is necessary at this stage. Nonetheless, product is a role that is central to the life-blood of the company because it is responsible for so many decisions. These product decisions are foundational to the company going forward and not so easily reversed. And so, one of the trickiest parts about the first PM hire is trust with the founding team. This trust is essential to setting up your first PM hire for success. An important question to ask then, is whether the founding team is ready to have its product beliefs confronted by this hire?

Depending on your answer, there are commonly two ways to go about this hire:

Path #1: Hire a junior whose main function is to funnel data on the voice of the customer (VoC), maybe alleviate project management loads and help product marketing streamline the conversion funnel. The founder will primarily drive the product strategy here, and the junior PM is unlikely to set roadmaps, nor will he rally the troops on the product vision. But he will set up the analytics pipeline, gather VoC insights and make recommendations, collaborate with engineering on sprints, and get product out the door.

This path requires ongoing mentorship from an internal leader who has PM experience, or the mentorship services of an experienced outside PM. But, if the business direction requires little adjustment, and execution is the focus, then this path can be very beneficial with minimal disruption. This junior PM will grow over time to handle the company’s strategic needs, but this path is unlikely to fully address issues such as snowflake-product or product priorities in the near term.

Path #2: Hire a senior who will bring in her own opinions on the product strategy. On this path, the founders need to be willing to spar on the tough questions she will inevitably bring up about the business. In fact, if no arm-wrestling ensues you might not have a formidable enough partnership.

This senior is likely to have 3-8 years of experience as a PM who has ideally built product for a similar customer audience. This PM will set roadmaps and rally the troops, and she will almost certainly do it differently than the founder(s). Her arrival will disrupt the balance in the leadership team, sending the team back to the storming stage before re-emerging in the performing stage a few months down the road. It is essential that this PM has a seat at the leadership table in order to be effective. The ideas she brings in may well take the business down a different direction.

This PM requires mentorship during the ramp, but then takes the reins and runs with it, accelerating the team’s performance. While this PM can benefit any team, this path is only successful if the founding team is ready to be challenged on the product strategy. That’s because path #1 can be pursued at a lower cost, in terms of dollars and disruption, but at a higher cost of mentorship.

OK I know my path, so what PM characteristics should I look for?

For any PM hire, I recommend five basic attributes: passion, smarts, judgement, communication, and empathy. I wrote about these attributes in detail in this post. The rest depends on whether path #1 or path #2 from above is being pursued. Path #1 will require an execution focused go-getter who is good with details. Path #2 will require a bigger picture thinker and problem solver, who is complimentary in personality traits to the rest of the leadership team.

But where do I find the PM candidates?

There are many PM communities now where PMs hang out. Posting in those communities can be helpful. Women in Product (Slack channel), Products that Count (email list), Roadmap.com (forum), Mind the Product (event). Do you have a favorite PM community I didn’t mention here? Let me know on Twitter.

Who should the first PM report to?

If you’re pursuing path #1 and hiring a junior, then whichever leader is currently holding the reins on Product, typically CTO or CEO.

If you’re pursuing path #2 and hiring a senior, then CEO, always. And be sure to give this person a seat at the leadership table. Keep in mind though, that as you scale and hire more PMs to take the reins, your first PM hire may stop reporting to the CEO and lose this seat at the leadership table. Anticipate this change and do what you need today to enable that transition later.

What about team structures – what’s a good ratio between PM’s and Engineers?

For a product with front-end and back-end, I’ve seen successful team ratios as high as 1 PM to 1 Designer to 7 Engineers. That often includes development, ops and test engineers. For a product with mostly backend, such as those with an API interface, I’ve seen ratios as high as 1 PM to 0.2 Designer to 12 Engineers. This last ratio assumes that the engineers are writing technical specifications as well.

At what point does it make sense to bring on additional PMs? What makes these hires different from your first PM – are there distinct characteristics you’re looking for in these additional PM hires?

I will explore these questions and more in my next article focused on growing your PM org from 1-5.

Do you have valuable insights and experiences in the developer tool space that you’d like to share with our community? We want to hear from you – join our contributor program today.

Deployment Best Practices

ted carstensen — Thu, 29 Nov 2018 17:20:00 +0000

Thanks to the evolution of devops & the emergence of containers, applications are more portable now than ever before. So now the question is, how do startups build products to satisfy the needs of on-prem, cloud SaaS and hybrid cloud customer deployments?

Join HashiCorp CEO Mitchell Hashimoto, Heptio Co-Founder Joe Beda (Kubernetes & Google Compute Engine) and LaunchDarkly CEO Edith Harbaugh as they discuss the impact of architecture on a company’s deployment options, and their visions of the future of deployment.

Mitchell Hashimoto is the Co-founder and CEO of HashiCorp, where he focuses on helping teams of all sizes deploy modern applications into complex infrastructures spanning physical, cloud, virtualized, and containerized workloads.

Edith Harbaugh is the Co-founder and CEO of LaunchDarkly, where she helps customers like Microsoft, CircleCI, and Atlassian serve and manage over 10 billion features per day.

Joe Beda is the Co-founder and CTO of Heptio, where he continues his work to support and advance the open Kubernetes ecosystem.

Joe Ruscio: We’re here to talk about deployment. I wanted to put a really fine point on it. Deployment is how you as vendors figure out how to get value into the hands of your customers, in a mechanism that meets them where they want to be to receive that. Ideally, in terms of the last panel, monetize that in a way that’s beneficial to you. We should start today by running through, historically there’s been a couple of different models of deployment. Whether it’s on premise, there was a brief period of delusional-ness in the 90s with ASPs. We don’t talk about that anymore. Then SaaS of course, which some would say we’re in the golden age of SaaS right now. So we could just run through, start with Joe and go down. What you do for deployment, what models you use?

Joe Beda: We help enterprises make best use of Kubernetes. A lot of what we’re doing is on the ground with field engineers, helping them and training helping them understand and run Kubernetes, providing tool sets there. That’s really the teaching somebody to fish type of thing, but then we’re also building out complimentary services. We’re still pretty early on with that journey, and we’re dealing with really big companies. So we’re still evaluating the spectrum of choices from pure SaaS to shipping people’s bits, and everything in between.

Joe R: Even some exploration going on right now. This panel will be useful to you.

Joe B: Yeah, I’m listening. I want to see what these folks have to say.

Joe R: OK. Great.

Edith Harbaugh: I’m Edith, I’m CEO and co-founder of LaunchDarkly. We are a feature management platform. We’re primarily helping SaaS and IT companies manage getting their own features to customers. By definition we started off as SaaS, so we have customers for example, HashiCorp is a customer. We have customers like Meetup who use us to say, “This is what features that people get in that very agile quick environment.” By necessity we were SaaS. That’s just what we started as.

Mitchell Hashimoto: Cool. We have a number of open source tools and we have enterprise variance of a subset of those tools, and it varies by a tool but we deliver– I’ll break it down by revenue. That’s the easiest way to do it. About 90% of our revenue today comes from on premise installations. When I say on premise it can mean bare metal, or it could just be in private VPC, but you are managing it. Another 10% is SaaS. We do have a SaaS offering that’s growing, and then more recently but too early to talk about revenue numbers, is we’ve been working with MSPs as well. Looking at our own managed services, single tenant. I laugh because we end up doing everything.

Joe R: Yeah. At some point, the whole basket.

Joe B: That’s where we’re headed too.

Joe R: A quick timeline on that. With open source background, naively it seems like the on-prem would be the first move. Did you start– Is the SaaS relatively new for you?

Mitchell: Our first move was on-prem. Because with open source we’re used to delivering packages and binaries to people. It was fairly straightforward to deliver the on-prem, I would say that the hard parts for us were the non-technical parts.

Joe R: It’s interesting because, Edith, one thing we were talking about is there are different classes of SaaS applications. There’s some where we’re just wrapping up business logic in front of a database, it’s conceptually easy to package that up and to shrink wrap. LaunchDarkly is not one of those, right?

Edith: At its most basic you could think of us as a set of SDKs, which our customers actually install in their own software. Then we have a centralized dashboard where their developers, product managers, marketers, customer success are controlling functionality. You could say in some sense that we do have an on-prem, and that we have a lightweight SDK that people have to use.

Joe R: You have an edge piece.

Edith: Yeah, but the heart of it is really our own dashboarding which is in the Cloud.

Joe R: With your 90% of revenue on-prem, what’s the biggest challenge of that model for you?

Mitchell: The biggest model is the variety of the installation platforms that we’re going on. Everyone always says during the sales process, “We’re normal. It’s an easy network layout.”

Joe B: I like to say, every enterprise is their own little Galapagos Islands.

Mitchell: But they think it’s normal, it’s like “Our disks are reliable, everything’s good. It’s easy. It’s just Linux,” or something. And it’s almost never the case. There’s almost always something that’s weird, and that’s been hard. Then the product development gets affected quite a bit too, because on premise customers don’t want to update.

Updating is a thing they have to plan for and do it, and if something’s working why change it if it’s working for them? It’s really hard to get them to update, so you want to move in a more agile fashion.

You want to ship features every week or something, and then on the flipside you have paying customers being like “Please don’t ship any features. Please stop.” It’s funny because it’s counterintuitive, but our contracts have clauses that say you not only lose support but you lose your license to the software if you don’t stay within a certain release period. The support period.

Joe R: So what’s that, when you’re thinking about long term support. What’s your LTS term typically?

Mitchell: Right now it’s very short, and that’s because we say no. A good tip to you is just try saying no. We’ll get customers that come to us and say, “We want three years LTS support.” “No.” “OK.” That’s the end of that. Our current LTS is one year, which is really short. That’s not going to last that much longer, but it’s really important early on in a startup’s life to try to bring that LTS down as short as possible. Because we’ve had some features we’ve deprecated, and the fact that you can’t code remove a feature for what turns out to be effectively two years, is really painful.

Edith: I have all the scar tissue of working as an engineering manager in the 2000s, and it was this immense tax on every release. It was a tax in multiple ways. We had to do a supported platform matrix, of just, what databases and app servers can you install this on? What crazy Sybase version is this one big customer running? That’s its own tax.

Joe R: Kerberos was mentioned earlier.

Edith: Then the other tax of just like, you start to accrue I’d even say technical debt of, “Does this old feature work with the new feature?” You want to do this cool new thing that your new customers are asking for, and there’s one customer desperately clinging to this thing, then you’re like “Please God, no.”

Mitchell: That realizes itself as real cost to the vendor, because you usually have to maintain that test matrix internally. We’re a Cloud-ish company but we have in our office, we have physical racks of servers with clunky pieces of hardware that our customers sent to us just to do validation.

Edith: It just adds up to so much tax on every release that you’re like, “Is it really that hard to test three database versions versus two app servers?” And it’s like, “Yes. Yes it is.”

Joe B: One of the things that– 100% of our revenue is what we call behind the firewall, either about half AWS half on-prem. One of the arguments we use with customers to stay up to date, because we support N-1 with Kubernetes right now. That’s a six month window.

We really want folks to get on that train so that they get to benefit from the larger ecosystem. It depends on what you’re shipping, but if there’s a set of tools and if there’s other things that they want to integrate, if they get too far behind then they get stranded.

That’s one of the reasons why they’re looking to move to Kubernetes, is so they’re getting to take advantage of that ecosystem. We really help them help themselves in that way.

Edith: The getting behind is so dangerous, because what you said about people who are on an old version. It gets more and more risky when they try to upgrade.

Mitchell: One of the challenges is because we’re an open source company, we can’t control the non-customers. We’ll get someone who now wants to become a customer, and we realize they’re on a three year old version. It forces us to have those upgrade paths ready, which sucks. There’s no nice way about it.

Joe R: It definitely seems to be a range of preferences across different– And I’m curious, Joe, in your conversations have you found that verticals impact more than others? I’d assume that healthcare or fintech, we talk at Heavybit a lot about what we call a hipster enterprise for our enterprise facing companies. Selling to Airbnb or Pinterest or Lyft is different than selling to Bank of America.

Joe B: We concentrate on big companies that are not tech forward West Coast companies, because we want to train ourselves on how to deliver to mainstream enterprises. They still have a lot, even Cloud is a force of nature, it’s going to happen. SaaS, whatever, it’s going to happen. But it’s going to take longer than a lot of folks in this world, on this this side of the country, tend to think.

You have to be flexible about meeting customers where they are, helping them along with that journey, and it’s painful.

We have a support matrix and it’s not fun. But it’s something we are also building out on complements. I view whether we do that as SaaS or on-prem, the proprietary complements to Kubernetes, that’s a negotiation with your customers. What you want to do is say, “We’re going to do SaaS, we’re going to ship every week. Suck it up.” What they want is something that is going to have all the latest features and never change, and they’ll never have to upgrade. It’s physically impossible. It’s a negotiation and it’s changing over time as people get more and more comfortable with this. We’re definitely seeing that shift.

Joe R: Edith, on the SaaS side. Someone mentioned something I did want to ask about, but in the last panel, single tenant instances. Which is the spiritual descendant of the ASPs, except the vendors are agreeing to do this. With LaunchDarkly being SaaS only, do you have any of these in the wild?

Edith: Yes. To continue on what Joe Beda was saying, we have a double Joe, I don’t know if anybody has noticed this. A lot of our customers are really large enterprises that are coming to us, and one of my favorite quotes I heard yesterday is they’re coming to us for the harmony between agility and stability. So, to your point–

Joe B: You should tweet that. I’m sure you already have.

Edith: They’re coming to us because they say, “We’re getting left behind by all the hipster companies. We don’t want to be the stodgy hotel chain where Airbnb is worth billions of dollars. We don’t want to be the stodgy bank where PayPal is worth billions of dollars.” They know that they have to move faster.

It’s not 2004 anymore where everybody sells software as a cost center to cut.

Usually they’re coming to us when they’re somewhere in a transformation from, “We’re moving from our data centers, we’re moving to Cloud, we need to move faster but we still need to do it stably.” They’re looking to a vendor like LaunchDarkly to help them with it.

Where single instances come into this, is sometimes we do have extremely large customers who say I really need a single instance. Usually the reasons are pretty much exactly what Marianna gave. Regulatory compliance, a lot of PII. Really spiky workloads that are unpredictable and they want their own instance. Our usual first comeback is we say, “We serve 40 billion flags a day. That’s billion with a ‘B.’ Everybody likes to think they’re huge, but we’re actually serving customers like fuboTV which is the number one sports app. We’re powering Atlassian, we power Hashi, we can handle your workload. They continue and say, “We really want this private instance.” We usually quote them the price and their eyes go, “You know what? SaaS is just dandy.”

Joe R: Yeah, “That sounds pretty good now.” One thing that’s interesting when people talk about on premise in 2018, and Mitchell I’d be interested in how often does on premise mean what you would think of a traditional air gap? I mean, no network connections, or a heavily firewalled data center? Or actually just, “We have our own VPC on Amazon. That’s on premise.”

Mitchell: For us it’s pretty split. I would say we still do quite a lot of traditional on-prem, physical on-prem, but I would say that’s skewed with our company a bit because we sell a lot of security software with Vault. The way a lot of people are deploying Vault is they’re in the Cloud or they’re on Kubernetes or something, but they still want their primary Vault cluster. One of the enterprise features they are buying from us with Vault is multi region. But they want the primary Vault cluster in a physical, not air gapped usually, but in a physical location. So, that breaks down but it’s just a matter of time before it all moves to private VPCs. We’ve designed everything to assume VPC. If you do that, it scales down just fine. Joe R: Another thing I want to get some people’s opinions on, because I have opinions. Multi Cloud is a word that gets me going, because it is a thing, I don’t think it means what most people think it means when they say it. In terms of deployment targets, what does multi Cloud mean for you? What do you see in the wild? Joe, are you talking to people who are multi Cloud?

Joe B: The first thing to recognize is when you’re a startup your failure mode is that you run out of money, and nobody cares. When you’re a big company you have different risks that you deal with. Multi Cloud ends up being a risk mitigation type of thing. Pretty much all of our customers, they don’t want to necessarily run on other Clouds but they want to have the option to run on other Clouds.

They want to know that it’s going to be a two to three month process to migrate some stuff over, it’s going to be painful, but we can do it.

Versus “Let’s rewrite our app, it’s going to be a three year process to move stuff over.” For us, because we’re in this position where we know that the stuff that we’re building, some of it we’re going to run ourselves in a multi-tenant way. Some of the stuff that we’re going to be running behind the firewall for folks, we’re keeping our stuff as plain Jane as possible. We’re not using fancy stuff, your little VMs, run of the mill databases as much as we possibly can so that we have that flexibility.

Joe R: Got it. Mitchell, you have multi Cloud customers. What do they look like?

Mitchell: As of today, roughly 100 out of the Fortune 500 are paying customers. Out of those hundred, 99 or 100 are multi Cloud. The first thing I always say when I say multi Cloud is there’s four totally distinct definitions of multi Cloud. There’s workload portability, which is extremely rare. That means you could run your app on any Cloud, that’s almost never true. There’s workflow portability which means that the way you deploy an app to Amazon is the same tools and process for a developer as the way you deploy to Azure. That’s often true. There’s traffic portability, which means that depending on a geographic region you’re going to a different Cloud provider.

It’s close, but not the same as workload portability. That’s semi-rare but more common. And then there’s data portability, which means that your actual data can move Clouds, which is almost never because speed of light. Those are the four things. Workflow portability is what we sell as a company, and it’s common in enterprises in particular. If only the most basic reason is M&A. When a big company is acquiring another company and that company has chosen to be on Google, and your company has chosen to be on Amazon. The big company as part of the M&A process is not going to price in an infrastructure switch from Google to Amazon.

They’re going to say, “You stay on Google, we’re going to stay on Amazon, and let’s do our own thing.” You end up with business unit level splits between Clouds, so there’s no workload portability. They’re separate apps and they’re totally siloed. The other thing we see is that the Clouds are now starting to differentiate in terms of best in class ML, versus best in class serverless, versus various different high level features. Some teams even in the same view want to leverage different technologies, so we’re seeing that a lot. But for the most part it’s pretty much everywhere. Especially if you think about the on-prem as a different Cloud, more or less, if you just bucket into that.

Because the nature of enterprises is that any paradigm transformation, like mainframe to servers, servers to VMs, VMs to containers, containers to schedulers and schedulers to serverless. All these different transformations are probably 10 years, and the 10 years overlap. They’re always in a state of heterogeneity.

Even if they have these nice new teams that are in a fully Kubernetes workload, they also have these teams that are still in their last two years of the server VM switch. You either as a vendor say, “We don’t help you with that,” and you maybe lower your impact and value to the company, or you try to figure out a way to make it work.

Joe R: Got it. Thoughts?

Joe B: Yes. I think it’s longer than 10 years. Mainframes are still a growing business for IBM. They’re making a lot of money on that stuff. The other point is on the multi Cloud data, there are scenarios where big companies, I’m thinking like movie studios. They’ll backup stuff to multiple Clouds because they don’t trust those eight nines or whatever of durability that Amazon promises. Black Swan events, and such.

Joe R: Edith, feature flags, which are near and dear to my heart.

Edith: Mine too.

Joe R: Do you find, just to take an interesting spin. As a SaaS hosting the Cloud SaaS offering, do you find customers managing features in on-prem products with feature flags?

Edith: Yeah, absolutely. Maybe you should just talk about how you use us.

Mitchell: No, you go.

Edith: No, you go.

Mitchell: All right. I’ll just say that feature flags are, I mentioned that problem earlier of how our on-prem customers don’t want to be upgraded too fast. We deliver features quickly, we just turn them off.

Joe R: You just hide them. Interesting.

Mitchell: They’re getting them. They don’t see.

Joe R: They’re deployed, but they’re not released.

Mitchell: Right. And they’re not running actual runtime components.

Edith: We have a lot of customers who use us to manage their own customers. If they’ve signed a contract and this customer says, it’s common to say, “We do a lot of training on this UI. I do not want new features.” Full stop. Even because there might be something as stringent as union rules, if you’re say an airline, about how often you can change a UI. They’ll have features and then they’ll say, “We were going to do a training on this date,” and that’s the date we want to turn them on.

Joe R: They’re not up on continuous delivery.

Edith: It’s the developers who want it. The developers that these customers are champing at the bit, they’re churning out features, and then what they really love about feature flags is that the developers can move super quickly and then use the feature flags to match with the rest of the work. For example, they can build a feature and then plan all the training.

Joe R: The other interesting thing is, and this overlaps with what the last panel was talking about with SLAs.

You can use feature flags to implement a lot of those premium support offerings, or UIs that you give people. They opt into that platinum plan and you toggle the flag on their account, and they get all the goodies.

Mitchell: A fun one of enterprise in particular is when you realize the world isn’t super flat, and there is really weird laws in different countries. We don’t use LaunchDarkly for this but we use feature flags for example, and when we sell Vault in China we have to disable a bunch of the encryption algorithms. They don’t allow them by law there, and it’s the same thing right? You have to have all these feature configurables that different regions can do different things with your software.

Edith: Another use case like that is some customers will say, “I’m a bank. Do not give me this feature until it has been battle hardened with 98% of your other customers.”

Joe R: Switching gears a little, something I definitely want make sure we talk about today that’s important for enterprise sales is channels. There’s a bunch of different kinds of channels. We could start with Mitchell, you mentioned MSP. First of all, how many people here actually know what an MSP is? OK. That’s all right. You should still define it and how that works in HashiCorp’s strategy for delivery.

Mitchell: Sure. When you get past the hipster enterprises, the hipster enterprises are like the Airbnbs, Netflix, those of the world. They want to run it themselves. Then you get more to the billion dollar beauty product business in the middle of Texas type enterprise, they want it on-prem, but they super don’t want to run it themselves and they don’t want a SaaS. They want something in the middle, and an MSP is a managed service provider, which is a business dedicated to running other people’s software for you on other people’s premises. That’s what MSP is.

Joe R: It has a channel, because there are tens of thousands of these. Then if they get comfortable with your solution they can effectively act as resellers.

Mitchell: Yes, definitely.

Joe R: Or at least you can draft off, they’ll have existing procurement in place.

Mitchell: There’s pros and cons, which is that as a vendor you bait and you really want to control the paper and control the relationship with the customer. Some MSPs are resellers, some are not resellers. Some you could bring in after the fact of your own paper, and they have their own separate service agreement, but there’s pros and cons there.

Joe R: Another, not variant, but Joe I’m curious if the people you’re working with use VARs or value added resellers?

Joe B: We’re not there yet. We still want to control that experience. There’s still a lot of dealing with those Galapagos Islands out there. But as your deployment gets more turnkey, as you understand the patterns, it makes sense to be able to bring in VARs or SIs and be able to have them extend your reach.

Joe R: Generally they tend to add, particularly when we’re going back to verticals, they will specialize in a vertical.

Joe B: They speak the lingo.

Joe R: They speak the lingo. They know the things that matter to the buyers in that vertical.

Mitchell: They’re usually highly specialized. It’ll be like, “AWS only, with security only and finance only.” That’s how big that market is. They could do that and still be a billion dollar business.

Joe R: Some of the big ones, I know some companies have open budget with it. So when you’re talking about, we haven’t even talked about budgeting cycles because this isn’t a procurement panel. But they’ll have actual budget set aside that you don’t have to go through budgeting, you can just go straight into that.

Joe B: We’ve done that. Where it’s like, “We want to get you through procurement but it takes forever. Just give 5% to these folks and make it happen.”.

Joe R: And all the problems go away. It’s not racketeering at all.

Edith: We’ve definitely had, we don’t discount but we’ve had people who say– It was just a large sporting goods company that said, “We want to buy you. We’re not set up to purchase from you. Can you sell to this person who will mark it up two times?” We’re like, “OK.”

Joe R: Other channels go to the way other end of the spectrum. There’s the Heroku add ons marketplace. Amazon has, although it’s been around for a while, especially in the last year or two they’re clearly starting to invest in their marketplace. Are you seeing those tend to be more in the self-serve side? Or bottoms up inside, are you seeing any enterprise adoption from large Amazon accounts going to the marketplace?

Mitchell: It varies by Cloud for us. I don’t want to call anyone out, so I’ll say I just won’t name them, but there’s some Cloud marketplaces that are really useless. They’re demo only, self-serve type things. There’s other Cloud marketplaces where they do a better job of integrating it into how you could better control the control panel flow, and the billing style. And BYOL, Bring Your Own License for enterprise software, that we’ve seen a little better adoption but it’s not as strong as direct sales.

Marketplaces are rough because you have that middleman between you and the Cloud.

You want to have that direct relationship with the customer because, as the previous panel talked about, when you have TAMs and various SLAs and so on, you really want that direct connection.

Edith: It depends on who your buyer is. If you’re selling more, or if your buyers are VP engineering they don’t want to just do a point clickwrap. They want a little bit more white glove service. They want some demos, they want some help.

Joe B: I would say in large part I view marketplaces as vendor introduction services. It’s a good way for them to see what’s there and then they’ll short circuit the marketplace to do the deal. There’s other programs the Clouds offer if you can help bring somebody on, and that drives more spend on their platform. They’ll give you a cut of that. There’s these channel programs that the various Clouds offer because their goal is to land grab as many cycles and bytes and packets as possible. If you can help do that, they’ll cut you in on some of the profits there. Those can be really good channels.

Mitchell: That’s a really cool technical thing too. It’s a lot of people on Cloud will firewall out and you can’t phone home and know if someone’s running your software. We have that problem too. We will do a phone home just to track the number of runs, it’s totally anonymous, but there’ll be firewalls.

If you can get partnerships with a lot of these Cloud platforms, and we have them with all of them, they all have local hypervisor servers running and you can set it up so you could ping that. It’s really hard to block that, and the Cloud provider will tell us how many are running. It’s a lot.

We could go to them and they say, “You ran on 200,000 cores this month.” Even if the network is off you can know that.

Joe R: That’s interesting. It sounds like you definitely need to do your diligence on the different programs. I think we’re pretty much at time, so I just want to do a quick fire. We’ll go right down. One piece of advice for people who are thinking about deploying software in the enterprise. We’ll start with you, Joe.

Joe B: I would say meet customers where they are. Don’t write letters from the future going, “Here’s this beautiful thing.” Instead, recognize that you’re going to be more successful if you bring folks with you.

Edith: We were unexpectedly enterprise. We thought we were going to be a bottoms up sale, and one of our first big sales was five figures. It was like this “Aha!” of we’re solving a big company problem. We need to grow up very quickly. So, realize who your buyers are, and I’ll echo what Joe said. If you’re getting pulled up market, go there.

Mitchell: My advice would be that a lot of the problems with selling to enterprise are non-technical. Focus on customer success, TAMs, solutions engineer, sales engineers. Because they’re going to be working realistically for four to six months before any bits hit the server.

Joe R: Thank you.

Joe B: Thank you for having us.

Carrots For Web Marketplaces And Platforms: How To Design Non-Monetary Incentives

ted carstensen — Wed, 28 Nov 2018 17:00:00 +0000

This article was originally authored by Connie Kwan.

If you have a platform or two-sided marketplace, like the App store, Uber or Etsy, you’re familiar with this scenario. One side of your marketplace is the Inventory side, the people providing the apps, rides or crafts. The other side is the Buyer side, the people buying the apps, rides or crafts.

Sometimes it’s simple, both Inventory and Buyer sides want monetary exchange. But sometimes it’s not, the Buyer side is willing to pay, but the Inventory side isn’t motivated by money. The latter is a common challenge among developer communities.

A Fictional Example: Secure.ly

Let’s consider an example of a security platform company. Let’s call this fictional company Secure.ly. This platform would rely on expert volunteers to report vulnerabilities, and sell this reporting to Buyers. Much of the world’s digital security vulnerabilities are reported by a global community of…volunteers. They’re good neighbors saying something when they see something. They’re experts, and they’re anonymous. CISOs and security directors pay attention to the chatter of this community to stay aware of the latest digital vulnerabilities and bad actors.

The CISOs are the Buyers of Secure.ly, and the information provided by the Good Neighbors is the Inventory. The challenge for Secure.ly is to incentivize this group of Good Neighbors to engage on the platform. But like any good neighbor, money is never the objective. What to do?

What you ultimately want here is motivate the behavior you want using carrots available to you.

You might find that you need to create some carrots. While money is one possible carrot, there are often more effective and cheaper carrots available to you if you spend the time to listen to your Inventory providers.

Google is an expert at leveraging the carrots of “convenience” and “functionality” to coax all kinds of private information from its users. This data is Google’s inventory, which is then sold to advertisers in aggregate. Facebook uses the carrots of “your friends on the network” to coax private information into their inventory as well. With Secure.ly we have to first unpack what their target persona is most interested in.

1. What does the Inventory provider want?

Exact quotes are the key here. Exact quotes get at the root of the Inventory side’s mindset and priorities. Word choice is often very telling. Here are some example quotes that Secure.ly’s Good Neighbors may provide:

“I want to share knowledge”
“[these people are like] my brothers”
“We learned from one another”
“I want to know others learned from me”
“[I want to be] Helpful”
“I want to be known, but only via my avatar.”

From these filtered quotes, it’s possible to discern that the following are priorities for Secure.ly’s Good Neighbors:

Community — very important
Notoriety — somewhat important
Anonymity — important
$ — not important, in fact, might even consider paying to participate

Now that priorities are understood, it’s time to figure out the carrots that connect with these priorities.

2. Mine for Carrots

Let’s touch on the first two priorities, Community and Notoriety. A number of possible ‘features’ come to mind for satisfying these priorities. Standard gamification moves like Points, Stars, Streaks and Leader boards could work. Since the community wants to stay anonymous, we can throw out in-person events. But chats and forums could work.

Skee Ball, one of my favorite games. Rack up points by landing the ball down a ramp into the hoops.

One ripe area to mine for possible carrots is within the features you already provide to the Buyer side. With Secure.ly, the Buyer side would buy a list of security vulnerabilities, and it’s likely that a visualization of this list is a feature for the Buyer side. How might this turn around and become a strong feature for the Inventory side?

In Secure.ly’s example, it’s recognizing that their Good Neighbors also want to visualize their contributions. Thus, by upgrading the visualization feature to show which Good Neighbor contributed to each security vulnerability, this feature can now be a carrot for the Inventory side.

Once you’ve mined and listed out all your possible carrots, and understood the strength of each, it’s time to figure out what you want as a platform.

3. What do you, as the platform, want?

Attracting Buyer side and Inventory side….duh! Yes, but what kind of Inventory side? Are there good ones and better ones? And how can you tell? This is an important question because your Inventory side dictates the quality of the final product your Buyer side receives. The higher the quality of your Inventory side, the more attractive your product becomes to your Buyer side.

Take Google again for example. They have this product called Google Opinion Rewards that prompts participating users to answer specific survey questions. It’s often used to gather granular data about visits to specific stores. It’ll ask “Did you recently visit one of these stores? option A, B, C D” then follow up with “How did you pay for your purchase at this store?” By gathering this granularity, they can accurately tell their Buyer side, their advertisers, about payment choices alongside other user information. Powerful.

Let’s go back to Secure.ly. The “Best Neighbors” in this case would be an expert volunteer who posts frequently with unique content, and stays loyal to the platform. So we have…

Frequency of posting — high
Unique content — high
Exclusivity to the platform

Now it’s time to connect the dots.

4. Doling out the Carrots

Remembering that the ultimate goal is to motivate the behavior you want using the carrots available to you, then

How you dole out the carrots is at the heart of your incentive design.

There’s no prescription for this, every platform will find its own way through experimentation. But there are some good starting points. For Secure.ly, let’s say their most powerful turns out to be the visualization feature. That feature can be broken down into a less powerful version, and a more powerful version. From here we can provide the most powerful visualization to the Best Neighbors.

This strategy pairs our most powerful carrot with our most important Inventory side providers.

Just as you would provide VIP service to your most important Buyer side customers, this needs to hold true on the Inventory side as well. In fact, there may be room to experiment with having the Inventory side pay for a premium version of the visualization, so that they can achieve their goals of connecting with others in the community. What’s interesting here is that the same feature might be packaged up differently for each side of your marketplace, and that’s an opportunity that can be very powerful for your platform.

So there you have it…

Non-monetary Incentive Design = Motivate the behavior you want using carrots available to you.

I would love to hear about your own examples of Incentive Designs… please let me know on Twitter! Keep innovating.

Do you have valuable insights and experiences in the developer tool space that you’d like to share with our community? We want to hear from you – join our contributor program today.

Early Hiring for Technical Founders: Product Marketing

ted carstensen — Mon, 26 Nov 2018 17:20:00 +0000

This post was originally authored by Dana Oshiro.

Heavybit works with developer, infrastructure and enterprise SaaS companies. Founding teams generally have a great understanding of their initial users and are highly technical with a good network for engineering and product hires. But I’m often asked to help build descriptions, source, and define metrics for a first marketing hire. Some of the common questions include:

What’s the right candidate profile?
How many years experience should they have?
What’s a stage-appropriate hire?

TL;DR: The right hire is often an ambitious person with a minimum of 5 years experience in product marketing at an early-stage startup including researching, positioning, and launching a similar product to a similar audience. Candidates often have had KPIs concerned with onboarding and activation, new feature releases, pricing launches, and platform adoption. Candidate keywords might include: product marketing, growth, advocacy, platform marketing, user adoption, technical marketing.

WTF is Product Marketing?

Most of the product marketing managers (PMMs) I know at early companies report directly to a VP Platform or Product. This is often very different from someone in a communications, PR or content marketing role. This isn’t to say you should only hire marketers with a past product marketing title, but they should be willing to tackle some of these responsibilities:

User Discovery & Positioning: Many startups use early user discovery interviews as a way to scope their initial product offering. But what they don’t realize is that they should concurrently be looking for patterns in user personas, common customer requests, and clues towards packaging and positioning. A good first marketer will work alongside designers and product to document all of this research and support the team towards a key persona, messaging framework and eventual rollout.
Launch & Adoption Strategy: Most founders can brainstorm or copy a list of basic marketing tactics. The key is to understand what tactics actually fit into your org’s larger strategy and the correct sequence for each. If the product manager creates the goals and timeline for launches, the PMM builds the external strategy to ensure continued engagement from your end-user. This includes co-drafting launch goals (w/ the product leader), creating the marketing budget, and calendaring all activities associated with your go-to-market. In some cases, and once you’ve checked the math, the PMM also drafts the first pricing page.
Project Management: Once Engineering, Product, and Sales buy-in to a PMM’s go-to-market strategy, the PMM often quarterbacks your rollouts. This might include working with teams to produce developer and onboarding content, building customer testimonial/case studies, creating product pages, and ensuring that the rollout supports sales enablement.
Onboarding / Activation / Success: There’s no way a PMM can be entirely responsible for your onboarding and activation, but some of their metrics should roll up to this. The PMM should contribute to your marketing copy, user path, testimonials, tutorials, and overall product adoption. If the product manager is responsible for a slam-dunk user experience, the PMM delivers the lay up. In most cases, post-onboarding, the PMM also reduces barriers through simple demos, webinars, case studies, featured community projects, and community incentives.

How do I find and hire this person?

As with most sourcing, you should ask for in-network referrals and do targeted outreach via LinkedIn. You probably already know which of your competitors and partners have great product marketing teams. Don’t be afraid to ask these teams to socialize your reqs. You can also send your product manager to events like the SF Product Marketer’s Meetup, or sponsor similar events in your locale. Experienced product managers tend to be a good source for PMM referrals as they’ll have either run their own searches, or worked with a great PMM. In short, network and play nice.

Hiring is Selling

Beyond sourcing, your company narrative and attentiveness are key to the hiring process. As most PMMs are technical, know your audience, and have a specific skill set; this is a tough role to fill.

Founders and hiring managers need to understand how to sell the opportunity. First off, you should be able to roughly match the comp package (salary and equity) of similar stage competitors and right-size the package for your HQ locale. But secondly, you need to have your story straight. Beyond comp, here are some of the reasons PMMs have chosen early-stage and often lesser known companies:

Being a Part of History: Sometimes PMMs leave their existing roles because while the technical challenges are great and they’ve learned a ton, they’d like to drive adoption towards a product/platform that truly disrupts the industry. In the early days, developer companies like Stripe, Docker and others convinced well-paid PMMs at well-established companies to take this leap. Presumably an early PMM’s role in building this industry-changing narrative also comes with a healthy financial upside.
Advancement & Autonomy: Many PMMs have worked on a team to build the product marketing processes in a slightly later-stage org, but they’ve never designed it from scratch and set budgets. Your organization offers them a chance to take something messy and unfinished, and master the creation of an elegant set of adoption-driving systems. This role lets them do everything they never got to do, and is often career-making.
Meeting of the Minds: While your company might be early-stage, your founding team might already be well-established as experts in their field. Because the PMM role requires so much collaboration, candidates may simply enjoy a higher-level of conversation and the speed at which decisions are made in a smaller organization.
A Better Puzzle: Some PMMs have led the launch, activation and adoption campaigns on portions of a product suite, but they weren’t there for the core and initial product GA. Where some candidates might see a lack of initial product marketing assets and tooling as a messy burden, others might see general availability launch as an interesting process-design and execution challenge.

In summary, as with most early hires, your first marketer should be willing to produce strategic plans, while also executing on them. At most pre-Series B startups, there’s really little room for ideation “gurus” or those interested in highly-specialized roles. In many cases, the right early hire is willing to brute force their way towards user adoption/growth using a variety of tactics, until you can afford to hire against or automate some of your early processes.

For more information on what early marketers can do, check out the below videos:

Stripe’s Krithika Muthukumar on Effective Product Launches
Stormpath (now Okta’s) Claire Hunsaker on The Evolution of a Marketing Team
Early Essential Content and Distribution with The Developer Marketing Guide

Do you have valuable insights and experiences in the developer tool space that you’d like to share with our community? We want to hear from you – join our contributor program today.

Github+Microsoft: Looking Forward by Looking Back

ted carstensen — Thu, 07 Jun 2018 20:47:17 +0000

The Heavybit community is proud to count some of the top operators from GitHub and Microsoft as active members and advisors. Over the years we’ve partnered with these folks to share their learnings with our member companies at Speaker Series events, in our podcast studio, and on our blog.

Considering the incredible news this week of the largest devtool acquisition yet, I thought it would be helpful to collect some of the best Microsoft, GitHub, and Microsoft+GitHub content that we’ve got. Watch, listen, and read about the paths these two companies took that led to Microsoft’s decision to buy GitHub for 7.5 billion.

In this episode of To Be Continuous, Edith and Paul are joined by Martin Woodward from Microsoft and Ed Blankenship from Algorithmia (ex-Microsoft). They discuss the cultural and technological shift that was necessary to transform Microsoft into an open source company. Martin talks about how as the owner of CodePlex, Microsoft’s open source community, he created Microsoft’s GitHub account. He also shares tricks he used to drive adoption inside Microsoft, such as allowing people to use their personal GitHub accounts, the subsequent challenges that this created and how he overcame them.

Watch this presentation by Brian Doll, who served as the VP of Strategy for GitHub, where he developed the company’s corporate, business and product strategy. Would you like to be acquired by Microsoft for 7.5 billion? You might want to take notes on how Github managed to grow so fast from the early days.

GitHub isn’t just a community for developers, they also drive the growth (or death) of the latest tools, languages, and frameworks. In this episode of JAMstack Radio, Brian and Ryan talk to GitHub Platform Engineering Manager Kyle Daigle about what makes GraphQL such a great query tool, especially for open-source projects. Fresh from the GraphQL Summit, Daigle shares his observations about who’s using it and why he can’t wait for it to be “uncool.”

Hiten Shah dives deep into the value that GitHub brings to fledgling developer product communities. It’s no secret that GitHub makes collaborating on and shipping code easier, but it’s also one of the best tools available to young devtool companies who are hungry for passionate new users. Shah shares some valuable tactics for finding those users using some of GitHub’s platform tools.

GitHub is a tool to host code, sure, but it’s sometimes also a tool to test product market fit. In this fireside chat, Segment’s Peter Reinhardt shares how the Segment team used GitHub to test the market for the earliest form of Segment. Turns out a concentrated community of active open source developers can be one way to short circuit the often harrowing path to product market fit.

Want to learn how GitHub approaches building its own products and features? Look no further than this episode of Practical Product, where Craig and Rimas are joined by Kathy Simpson from GitHub. Kathy discusses her approach to identifying and managing product stakeholders. She reveals how she handles disgruntled stakeholders, suggesting a proactive mindset that includes breaking bad news quickly, admitting to mistakes openly and figuring out what communication style best suits each stakeholder group.

SF Video Tech: Watching Twitch Live Stream Scores with TensorFlow

ted carstensen — Wed, 21 Mar 2018 21:25:00 +0000

Earlier this year, Demuxed held their SF Video Tech event in our SoMa Clubhouse. The event featured an exciting talk and near-perfect live demo from Mux’s Nick Chadwick. If you’d like to attend the next event in person, RSVP here.

At the end of last year, Mixer, a Twitch competitor, introduced a new feature: Hypezone. Hypezone is a channel that always broadcasts the Player Unknown’s Battlegrounds stream closest to winning, and has consistently been one of the most watched channels on Mixer. Inspired by the technical challenge, Nick built a simple version of Hypezone (Hypebot3000) that does the same thing for Twitch streams.

In this talk, Nick outlines how he approached solving this problem, from efficiently watching twitch streams and struggling with OCR, to finally creating a working version using TensorFlow. He goes over the basics of screen capturing live streams, pre-processing them, and implementing a simple TensorFlow model to extract the current game score. And he does it all live!

Inside The Tubes: An Intro To Networking Concepts

ted carstensen — Mon, 07 Aug 2017 20:22:43 +0000

On May 29th, Heavybit Member Mux held their monthly SF Video Tech Meetup at our San Francisco Clubhouse. Matt Ward, Software Engineer at Mux, gave a great talk outlining the physical infrastructure and software underpinnings of the modern internet. Curious about IPv6 or ASNs? Don’t miss this talk. To attend in person next time, check out the meetup page.

Inside The Tubes: An Intro To Networking Concepts

This post was originally published on heavybit.com

Navigating The Serverless Ecosystem, and Slack Bot Building with Cloud Functions

ted carstensen — Wed, 02 Aug 2017 18:26:00 +0000

On July 26th, Heavybit member company Serverless held their regular meetup in our San Francisco Clubhouse. The event featured talks from Brian Leroux and David Wells. Sign up here to attend the next event in person.

Brian Leroux: Slack Bot Building with Cloud Functions

Functions as a service is a recent conclusion of cloud computing. The iron age of compute racked physical servers. Early cloud compute evolved past physical servers with virtual machines. And most recently, in what appears to be an ever tightening cycle, containers have given rise to cloud functions.

Each age taught new lessons for building software architectures and this most recent iteration changes the shape of the challenges we face. In this talk Brian LeRoux shares how his team creates and deploys their bot using AWS Lambda, API Gateway, SNS and DynamoDB.

David Wells: Navigating the Serverless Ecosystem

In this talk David takes us on a journey through the Serverless ecosystem, touching on where to start, how to choose a provider, where to find examples, where to find community resources, and finishing with a look at where the industry is heading. If you’re new to serverless technology, look no further than this!

Subscribe For Heavybit Updates

Join our mailing list to receive the latest updates in the developer startup community. After subscribing, tell us your preferences to receive only the emails you want.

This post was originally published on heavybit.com

Serverless Use Cases: Real World Examples, AWS Lambda@Edge & Serverless Tips

ted carstensen — Wed, 26 Jul 2017 22:50:21 +0000

Earlier this year, Heavybit Member Company Serverless Inc. held a meetup in our San Francisco Clubhouse featuring several talks on real-world use cases for serverless, watch the videos below. Sign up here to attend the next event.

Serverless in the Wild: Real World Use Cases, David Wells from Serverless Inc.

As serverless technology moves past the emerging technology phase there are more and more great real world examples out there. David Wells, Senior Software Engineer at Serverless Inc., explores some different use cases for serverless technology with examples from companies and other open source projects. He gives an overview of the Serverless Framework and also presents some of his own open source Serverless projects that were built using the framework.

David Wells is a senior engineer and developer advocate at Serverless Inc., the makers of the Serverless Framework. He’s a full stack JavaScript developer, entrepreneur with a past life as a marketer. David is passionate about showing developers how they can do more and manage less by going serverless.

AWS Lambda@Edge Preview, Alex Casalboni from CloudAcademy

What exactly can you do with AWS Lambda@Edge? Alex Casalboni discusses the most interesting use cases and a few preview-related limitations. You’ll learn how to execute serverless functions at CloudFront’s Edge Locations to implement unique functionalities and optimize network latency.

Alex Casalboni is a Software Engineer from Italy who’s passionate about web technologies and music. After deepening his software and sound engineering background, he’s spent the last four years building, learning, and teaching at Cloud Academy. His current focus is on web development, serverless and AI.

Google Cloud Functions Lightning Talk, Bret McGowen from Google

Developer Advocate for Google Cloud Platform Bret McGowen gives a high level overview of Google Cloud Functions and the Serverless Framework integration.

Subscribe here to get all of Heavybit's developer facing content straight to your inbox.

This post was originally published on heavybit.com