Ep. #11, Reify: An Engineering Driven Marketing Consultancy

Craig Kerstiens: Alright, and we're back on another episode of Practical Product. Thanks everyone for joining us. Today I've got Brian and Mike with me from Reify. Brian worked at New Relic and Github in marketing and Mike was actually the first employee at Code Climate. Guys, can you just tell me a little bit of your background and what you're doing now.

Brian Doll: Yeah sure, so we both actually have an engineering background, and started a marketing sales consultancy so it's kind of an odd transition probably for a lot of people.

Craig: Hang on, I thought engineers don't like marketing and sales.

Michael Bernstein: That's why we make money with our consultancy.

Brian: Sound effects, can we get the drum? So, we both came from this product and engineering background and both I think were inspired by the business side of software. Really being concerned with not just is this product good, but do people want to buy it, is there a market for this product and how do we actually develop a thesis around bringing that to market?

Craig: Now, do you do consulting around marketing and sales broadly, is there a certain focus to it, is there a typical type of company you work with?

Michael: Yeah, so within the type of company that we work with, there's definitely a niche. So we typically work with companies that sell products or market products to developers or other technical people. We kind of call ourselves a B2B SaaS marketing and sales consultancy.

We have clients that don't necessarily sell to developers, but they sell technical product, maybe they sell into a marketing department at a company. But it is a software product, so they have to get buy in from a technical organization in order to complete a sale. We help them with that.

Craig: It sounds like so by and large it's this tech focus, dev focus. It's not a B2C world.

Michael: No, we don't have any consumer companies as clients right now, it's pretty strictly B2B.

Craig: Cool. Today we wanted to dig in a little bit to some of that duality of marketing product. You both have engineering backgrounds, so I'm sure you kind of experienced some of the types of marketing that developers and product people and engineering focused companies kind of butt heads with. How do those things co-exist in a more collaborative way? How does marketing work together with product, how does product work with marketing, et cetera.

Michael: One of our big projects at Reify is really to get people to understand the interactions between sales marketing and product functions in tech companies. When those things butt heads, there are cultural components to that, in the way that people choose to run their companies, who they choose to hire, what the founders' personalities are and things like that.

And we can help with that, but we're not really psychologists, we're technologists. We tend to approach it where we try to get people to understand there's a push and pull, that when you make a decision that's a marketing decision there will be impact in product. When you make a decision about pricing or product, it's going to impact how you do sales and marketing and things like that.

Craig: And I imagine there's a lot of key areas where marketing comes in and actually adds value, right? I think, Brian, you kind of hit on that, just glossed over it, but making sure there's a fit for the product and there's a market for it, that's key. People, even engineers, do usually like to make money, right? They're happy to have a real business. How do you jump into that part of adding that value, driving that. What are some of those initial discussions that you guys come in on?

Brian: Well, I think the interesting thing, if you talk to technology companies, they're often starting with a product idea. The origin story of all these companies is I had an idea, I wanted to bring that to market. I had a problem I wanted to solve, that whole thing.

Craig: There's an itch I want to scratch.

Brian: Sure. And so the second step is they might have to have a company because someone gave them money to make a company to sell that product. And the third leg of that stool, though, is the market piece. And so if you have a product without a buyer, you don't have a company for very long. And I think

The classic blunder that we see a lot in these companies is that a lot of people think about telling people what they built without realizing that there has to be a market on the other side that's wanting to respond to that.

And so, what is the demand, where is it coming from? Who is your buyer, how much are they willing to pay, what does the competitive landscape look like? All of these things exist in the sort of market leg of that stool. And in early stage companies it almost never exists. So a lot of what we're doing now, especially with the early stage companies is filling that role to audit the thinking and the success so far, and understanding how it's hitting the market. Doing our research, talking to customers and things like that.

Rimas Silkaitis: It sounds like, we're talking about early stage companies here, but is there a dichotomy between a more established company that may have a set of product lines and what they need to work with versus that early stage company. Are there differences between the two?

Brian: Yeah, I think what's funny is almost everybody's pricing came out of a bar conversation or something. Somebody pulled a deck of cards out and picked some numbers and may have had some success. So in fact

The next phase of success for them is going to come from re-packaging the product. I think another thing that people don't do enough. They've been building product for a long time, pricing hasn't changed, and it's the packaging of that that's going to start actually opening your product up to a new market.

Potentially, that's one of the components that can do that. That's a way that we can also come in and help is talk to all these customers and find out what is the piece of this product that's actually motivating the purchase? And what's the competitive pricing landscape look like, and how should we do pricing now with evidence of data which you didn't even have when you priced it the first time.

Craig: Where do you start on that pricing data? That's the thing of yeah, I took the business courses in school where it's like, here's the supply curve. Here's the demand curve and here's my elasticity. Here's the perfect Econ chart and it's like great, I can ace this test. And then you get out and you say, how do I price this product, and it's like I don't know what these levers are. How do you test that, how do you get the data?

Michael: This dovetails actually with the question you asked earlier about what are the first conversations that you have with companies where you're trying to determine their market, try to get them to product market fit. We have questionnaires that we use with our clients and then questionnaires that we use with our clients' customers, and when we talk to our client, the first thing that we ask them is who their customer is.

We like to make founders and executives really uncomfortable by asking them the questions that they're sometimes not really willing to ask themselves or ask each other, which is really like who is this person, where do they work, let's go through your customers. We tend to work with people that have some traction, between seed and A round, or something like that.

They've sold it to their friends, they've reached their network, they know who these people are.

We ask them questions that on paper look kind of crazy. Like, what blogs do they read, what conferences do they go to? And when we do that, what we do is we bring the customer for them from the abstract to the concrete.

We try to say, let's stop talking about your buyer persona is not a developer, right, your buyer persona is not a Ruby developer. Your buyer persona is a lot more granularly defined than that. A lot of the initial conversations we have are around the who, and then in terms of bringing it to the data, how do you get to the data ? We talk to customers, we're really big believers in willingness to pay, and the input that willingness to pay has into what you can charge for a software product.

We recently did a pricing engagement with a company who's pretty far along, again between seed in A and we got on the phone with 20 of their customers and ran them through the same questionnaire.

By doing that, began to develop a sense for what they care about, what they really think they're buying. And also we just asked them "how much would you pay for this? Would you pay this much for this product? You know how much value it brings you, right. How much would you pay now, how much would you pay if we added this feature, how much is this feature worth to you?"

And sometimes, people are not willing to ask that question themselves of customers, sometimes they don't feel like customers will be honest with them. And so, we have really interesting leverage in being outsiders, where we can just come in and say hey, we're doing this project, with this product that you love. You want this product to be around for a long time, you rely on it. How much would you pay for it if it looked like this, if it looked like this, if it looked like this.

Craig: I'm just curious, what if when someone's results are spread, how far off is that delta from what the companies' thought?

Michael: Very far, very far. We are, Craig and I, we've had exchanges on Twitter about companies should charge more money for software. I think it's uncontroversial to say that developers who are building products and trying to turn them into companies tend to undercharge for their products.

Craig: But I've heard developers are cheap.

Michael: Well right, it's actually true. I think developers are cheap a lot, but they're also not always the buyer, right? And they're often your entry point into an SMB, but they're not necessarily your buyer. And additionally, the difference between $9 a month and $99 is a lot more than $90 difference. Your ability to create a product that someone will put down a credit card for $1,000 for a year, right, let's get you to that place first.

Craig: And you hit on something there for a second of like they're also your entry point, developers are. Brian, you kind of hit on that of what is the product feature set and the portfolio? What comes into the differentiating, what is the product set and what are you pricing? How do you formulate that? How does that come in? Because usually the product person is saying, "hey this is a problem, we're going to build it, we're going to ship it, and we just roll it in. Let's just keep rolling in the feature set."

Where does that kind of dichotomy work? You've worked at a couple of interesting places that I think started with developers, also targeted large enterprises. How does that split happen, what's that dichotomy, how do you start to evolve? I imagine a lot of these early stage companies start at developers, and then at some point you start to go up market in a way. How do you do that and not alienate? What's that look like?

Brian: There's a lot of interesting strategies to think about there. The first is the fact that

You have to have messaging for each different tier of people you're trying to communicate with.

If you are talking to individual developers in a specific context, that have a definition that you're solving a particular real problem for, the communication of that might come in the installation process and the documentation and that kind of stuff. The pricing for that is probly going to be relatively low. You're also looking for traction feedback, those early customers are really valuable to you, more than the dollars they're paying.

Craig: So your metrics there are completely different. It's active users, just word of mouth growth.

Brian: And also once you've got a volume of those customers, now your job is to learn from them. And so now it's understanding well, how can we segment these customers into piles, and what communities are responding to what features. And it's almost impossible to do this by industry. Every product is going to have a different way of approaching segmentation. And then from there, you mentioned pricing.

That's a different person looking at that page often. How you're communicating pricing, and the kinds of things you're talking about to that audience is going to be a little bit different than what you're doing for documentation for onboarding. Here you might say, for example, individual developers that are looking at a product feature page on Github, are looking at features that make my life easier as a developer.

It's about personal productivity, it's about community, but if I'm selling to a business manager who's going to by thousands of seats of this product, now we're talking about collaboration and innovation at scale. Those are different motivating factors for that sale. It's the same product, but you're now talking to two different audiences.

Craig: Same product, and you sell it the same way? How do you create that different value there?

Brian: Right, so I think the value actually comes, it's going to be obviously different for products but a lot of times what we see this pattern, there's an individual user account type, and it's usually the developer version of the product. It's single user, it's probably all-access kinds of things. Interestingly,

As you go up market, some of the features that you add to a product to make it cost a lot more and get a bigger relationship with that company, is not a new feature of the product, it's a restriction of access.

So if an organization, for example, can say I'm in control and this group of users can do these things, and this group of users can do these other things, that that level of management and organization, is something people pay for. Because there's a risk of a super-user screwing something up. It's interesting that you can actually do a lot around the edges of a product to make it much more valuable to a larger organization and that you can charge a whole lot more for it that's not even part of the core product, really.

Rimas: Can you pull back on features that you have once released, like so to speak more tactically, can you launch something as the product manager and say, "oh here's this thing, it's valuable to these up-market type customers." Can you pull that back to then, put a restriction in place to then charge more or once it's out there, it's out there and that's it, it's done?

Michael: I mean, nothing's permanent. I think the answer to that question, if we're speaking tactically, it depends on the volume. It's like, is it tens, is it hundreds, is it thousands? I think that particularly in startups that are in this early stage, trying to grow, trying to get larger, they sometimes underestimate the goodwill that they have with their customers. Their customers are developers, they're a developer too, or used to be.

Being honest with your customers goes a long way. I think we've both been in that position probably to write emails to customers to explain to them why these things are happening. You give them six months to do this, you give them a nice discount, you roll them into it eventually, but I think you have to think really hard about not making a decision, to ameliorate your customers at the expense of potentially taking your bottom line.

It's a really tight rope to walk but I think communication and the quality of communication has a lot to do with that and that's something that Brian and I really enjoy working with clients on.

Craig: So you can roll it back. I assume the better option is to know where you package it in the first place. How do you get to that, like if you haven't had some of those customers, you're trying to go upstream. My usual product answer is, "hmm, which way is the wind blowing today? Does this feel enterprising not being in that market or how do you know how you bucket features?"

Rimas: Yes, like alternatively I was going to say as a PM, the question I would ask is how would I know or where would I go to get that kind of information and then be able to make that decision, right?

Michael: Yeah, that's a good question. Competitors and what competitors do is one answer. We never recommend that people just copy competitors' pricing and packaging, but seeing what a more successful company in your market segment is able to charge up market for is typically a good indication. Talking to customers, talking to users that are using your products for free early on is reasonable.

But that's hard, that's a lot of where the art is. What I think is an interesting thing that Brian and I have run across is there's the product set, how you package that and provide that to customers, and then there's on top of that, what do you communicate to your customers, right, what goes on the pricing page? What are the three features that are the three most important features to your customers.

We had a client who when we started doing the pricing engagement with him, they were like "cool, our product has 64 different features, here's a spreadsheet."

Rimas: I fit all this on the presentation. I have this flashback to those check boxes .

Craig: Oracle feature product, where it's like a binder, here you go.

Michael: Yeah, we're interested in seeing how you're going to fit this in. And we're like, we're not, that's how we're going to fit it in, we're going to erase 61 of them. We have a process that I think that has been successful for us and might be interesting for your listeners regarding just doing really simple things like talking to customers or thinking about customers and making lists, dividing them up into groups.

Craig: I'm kind of curious to walk through this. Let's say I've got like 50 customers.

Michael: Yeah, 50's a great number.

Craig: And now where am I going from these 50? What am I doing with that list?

Michael: You're going to talk to as many of those 50 as you can. Well, first of all, you know the existing list right, you've got your 64 item spreadsheet, right? You're going to talk to your customers, and really ask them the question, these are hard questions to ask.

The question to ask your customer is "If this feature didn't exist, would you still use our product?"

Craig: And you go down the whole 64 features?

Michael: No, of course not, but what we like to do is so, the customers are one input into it, but and Brian might want to chime in on this. The founders and the executives in the company, they have, particularly at this stage, they have incredibly good intuition most of the time for what their customers really care about. We like to do the exercise first with the people internally and then use that as the input into what we talk to customers about.

If you've got 64, we're going to turn that into three groups of whatever that is, whatever 64 divided by three is, and then we're going to whittle those three groups down into three features in each group. Now you've got nine things, you're not allowed to talk about more than nine things, and those three groups of three, those get a name. And naming those three groups of three is crucial, in order to be sure that you're able to communicate the value proposition of your product.

An example would be, if you were selling an infrastructure product and you're talking about redundancy and you're talking about your SLA's for support and you're talking about whatever it is, response time. Those three features might go under a category that's called reliability or something like that.

Craig: So it's not any three arbitrary.

Mike: The most important three. Yes, the semantic component to it is super important. What you should be able to do, is you should be able to take this big list, whittle it down into three tiny lists, name those things, and if those three pillars, we call them, of your messaging, if those aren't the right thing, you screwed up. You picked the wrong features. You were not being honest with yourself about what people care about.

You chose the thing that you implemented most recently instead of the thing that people actually buy, you write down a feature that might not even exist yet that you've always wanted to do because you think people think it's important. In reality, we've seen that when people actually go through this exercise, create a framework for them to be able to do this, when they're done, they're looking down on paper of like of "wow, I recognize this. This is my company." These are the problems that we created this product to solve.

Brian: What's funny,

Going through this framework is super useful when it comes to the pricing and packaging as well because we would also look at this layer on the pricing plans that we're trying to develop. And you should see differences across all three pillars in all of your plans.

You kind of want to run this check. This is oh, okay, so there's more of something or there's some kind of scale in each of the plans. What people tend not to have, at least in our experience, which is probly another great input if we ever had it, is a map between "here's our 50 customers, right, and some of those are in different plans." What features are they actually using.

And what's really compelling about that information if you can get it is that you might find out that it's a very tertiary feature that happens to be in this other tier, and that's why they bought it. The headline is not the thing, it turns out that it's some esoteric feature down the list. And so that's where you start pulling out this actual value that's motivating a sale, that's maybe different from what you think.

Craig: Is there ever a case where there's one pillar that's only focused on larger companies, or is it like no, you want it spread across all three of those, right?

Michael: That's a really good question.

Craig: I think reliability's a great simple one. Even developers care about some level. They may not care about 24 by 7 phone support.

Michael: Right. I think that if you're going to sell across a spread, if you're going to sell to people, single devs, SMB's and enterprise, my gut tells me you wouldn't have a pillar that only pertains to only one of those markets. All of your market segments care about some level of this particular thing.

Brian: Yeah, and you bring up support as an example. There may be an open source version that doesn't have commercial support. Right, that would be an example of that, where it's going to scale over time.

Michael: Yeah, support is a good one, various enterprisey authentication protocols, access control lists, things like that. The enterprisey stuff.

Rimas: To change the conversation just a little bit. How do we take all of these learnings and apply this back into the product to give the product its own personality? That's something that I don't see a lot of PM's actually think about or talk about, is that your product actually has a personality, when you build this out there and how it communicates.

Michael: I love that idea.

Rimas: It's voice, everything else. How do we rope this back in as PM's?

Brian: Yeah, I think at the end of the day, this process that we go through is about messaging pillars. And when you come to product, you've got a little bit of a different framework, because you're mostly thinking about use cases. Sometimes those are going to be spread across those different things, but what's important is it's a very similar process of lists, grouping, naming, filtering.

Then, I think what's super important, obviously is consistency. And so, if I'm logged into your product and I've been using it for a while and then I see this marketing page, or a Twitter campaign, if that seems like an entirely different product, you screwed up. Even though I said earlier, you want to have different messaging available for these different kinds of buyers, but it shouldn't shock them.

It's not going to shock somebody. An individual developer is not going to be shocked by the fact that I'm talking about corporate innovation at scale when referring to Github, right. That's not the feature they're buying, but they would understand if it's related. In the same way that your product features need to be in that same kind of architecture, that they relate in a way that's harmonious with messaging and has the same voice.

Rimas: We're not necessarily saying that every pixel of every text box that we create has to look exactly the same across the entire product, it's just that you're communicating something that is of same type that you're trying to show across all of these segmentations.

Brian: Yeah and I would argue what's important is if you have your key pages in this app, so maybe there's a dashboard or there's different kind of views, right, you could probably use this messaging framework to say how via the product are we communicating across these three things. Even though you're in a work channel, if I had an issue, what's my support, how am I supporting you when I'm looking at this dashboard page?

How am I thinking about reliability, how am I communicating that to you. If these are the three pillars of the company, and your page talks about none of those three, you missed something. It's really handy to have these two things for everybody to use for those reasons.

Michael: Yeah, I like the idea of the personality, too. We've done more work so far with our clients kind of on the front end, like more further up the funnel stuff, but, when I was at Code Climate, that was a thing that we took really seriously in terms of the voice of the emails that we sent from the app, the voice of tweets that we did for marketing and inside the app, trying to make sure that there was a level of consistency so that people could kind of tell that this was from the same personality.

It's interesting,

There's almost an interesting kind of moods analogy you could make here of "okay, this personality is being a little bit more business-like over here, and they're being a little bit more fun over here, but it's the same person."

It's coming from the same perspective, the values are clearly aligned, stuff like that.

Rimas: I want to pick on that word, values, just a little bit. How important is it to have the same values across product and marketing, and or to ask that another way, how does product and marketing interface such that those are shared values, so that they're creating the same personality. Because, what I see in a lot of my work is that product marketing can just be over there doing their own thing, whereas I'm just building something and I'm in my own silo and just policing how I think.

Craig: Ideally, marketing should just listen to what product says. Right? That's the healthy world. That's the Craig answer.

Michael: I think that it's not easy. That let's us go out there and say that, finding people that are good at both, or who can understand both or translate between both, sometimes challenging. If one group is silo'd from another group, clearly there's going to be divergence there, that's not going to be healthy for anyone.

Brian: I think the thing that solves this, in every environment that I've ever seen, is contact with customers. If your marketing team feels closer to the customer, that's where your attention's going to be. Because they're out at events, they're talking to people, they're much more closer to the ecosystem partners or whatever, there's a whole kind of world there that they understand because you're fitting into other tools.

There's more tools than yours in the Universe, and they understand how people see you, and that definitely informs product and voice. But the same can be said, I've seen product teams that are much closer to the customer, where there's product marketing that's back in a different room and they're just kind of asked to create collateral without the context of people and product and marketing.

Craig: I think we talk a lot about talking to the customer, engaging with them, and I think for us in product, it is very key and I think similarly in marketing, in product marketing it's very key, right?

Michael: Yeah I mean it's the same person, right? You don't become a different person once you buy the product. You're still talking to the same person. And they care about the same thing. And now that they're in your app, doesn't mean you should spend less time or energy considering how you communicate with them.

Product marketing is a thing that I think has a gigantic impact on people's perceptions of products. I think people try and buy products all the time because of marketing, but they really love products because of product marketing. Everyone loves Slack because of the stupid little touches here and there that, sorry I don't mean to call them stupid, but.

They're like completely impossible for me to ever conceive of or execute on, to me it's magic to know how to do that well, but Slack's a good example. Github had some good examples of those things over the years. Companies are better at that or worse than that and those touches, once you've gotten a customer into the product and they're using it, I think can be really powerful and you should forge a connection between those parties.

Brian: One thing I wanted to mention too, I think one of the ways that this starts to pull apart sometimes in teams is that because marketing is so focused on growth and new customers, your point of view is very skewed toward that new user.

And in product, over time,

You see product teams that know their app too well, they know their own vernacular, and they can sometimes miss that new user experience.

Because it's like, "oh we forgot to add all these communication things because I haven't seen the new version of that screen in five years. I don't think about those things." That's another way that teams need to remind themselves of what that top down funnel looks like.

Craig: We talked a little bit about product people fielding support, and helping out more customers, and getting that beginner mindset back, because once you lose it, it's very hard. But i think being out there alongside marketing, right alongside, talking to new users, customers, that are thinking about the product, why are they even considering it, whether it's at events or otherwise, it's another great way to keep that fresh mindset, of what are people thinking about when they're even considering you.

Brian: Yeah, and also the same goes for sales. In our view, product, marketing and sales are literally the same thing. You really need to be saying the same things, they're the same customer. And so, riding along and going into sales calls and talking to people and having to convince them is really healthy way.

Michael: I'm going to use that line of, you don't become a different human being once you buy the product.

Craig: Yeah, great line.

Michael: It's interesting, because I don't know, both of you, I'm interested, what companies do you think, what products that you use right now do product marketing very well?

Rimas: Is this where I mention Citus right now?

Craig: I'm thinking of a few, actually I think Code Climate's a good one, to go back there.

Rimas: Stripe, possibly.

Craig: Stripe, yeah, Stripe's a great one.

Rimas: When I think about all the stuff that they're doing between the documentation, their outreach amongst developers and everything else, it feels like I can build a relationship with that company.

Craig: Yeah I think actually Stripe jumps out to me, especially at being larger, too. I think it's really easy for a really small one to possibly do some of that because it's often the same person doing a lot of it. And the bigger ones is where you see some of the coordination issues.

Michael: Yeah. I think Heroku has been historically a benchmark in a number of ways for marketing and product marketing, both.

Craig: I'll take full credit for that, since no one else can defend it right now.

Michael: Right. I just remember when I was at Code Climate, I helped launch a whole platform developer program thing and we studied the Heroku stuff very closely when we did that. The experience of visiting this documentation page that describes to you how to create an add-on or whatever, that stuff is just killer. There's just so much energy and attention put into it, it's kind of daunting, actually, to see from the outside. Probably a lot of people listening to this podcast are like not in the position to have, obviously teams of people working on these things.

Craig: I think you'd be surprised early on how small some of that, it depends on what time you were looking at it.

Michael: This was like last year, I'm talking about. I remember seeing it initially, and it was good because Heroku typically had a think above average documentation and stuff like that but right now, if you go look at the how to create an add-on Heroku stuff, it's killer. It walks you through the whole thing and it talks about the things you care about as a potential creator of this add-on process. This is a little orthogonal to just typical product marketing or whatever but.

Craig: Your product marketing today's just a different customer. Customers are the same customer whether they're thinking about that, whether they've launched it, how do you support it, so I think it still completely applies.

Brian: Well, one of my tenets, when I want to do anything product-related is that anything that that customer touches is part of your organization, whether it be landing pages, pricing pages, documentation. That's an opportunity to further the voice that you have with that customer, further that personality, because if you're not being thoughtful about that kind of stuff then I hope you're in an industry where cost is your only concern because you have a monopoly on everything that's going on there.

That doesn't necessarily mean that if you are going to think about all of these things, do all of this stuff to make sure that you contain that voice that you have to do a lot of things, you can do a few of those, do them well and launch them and still be in a good place.

Craig: I think we covered a lot of topics here. You basically gave away all of your business, and now everyone can go in self service, we know how to create the lists and the feature set and the pillars.

Michael: We write about a lot of this stuff on our blog, which you can probly link to in the notes.

Craig: No one should hire you if they want to know anything more. What else might you leave with some of, on the product managers side, what do you want to tell product managers while you've got a final say to, "here's what you should think about, like marketing, or should care about?"

Michael: I have a chip on my shoulder about email, so I'll take my minute to talk about that. I think that email is incredibly important in terms of how products communicate with customers, and that if I were to make a tactical recommendation to a company that wants to make sure they're doing a good job on this, it's like a really simple thing that we used to do at Code Climate which was like, print out all your emails.

All of the emails that your app sends, look at them on a table, print them out. Does everyone who's listening to this podcast know what a printer is? Print them out, right, put them on a table. First make a list, like ask yourself, can I name all of the emails that my product sends to customers? You're definitely forgetting 25% of them if your company has been around for more than a year and you have more than a handful of customers, right? Print out all your emails, label them.

First day of trial is like day zero, then you've got zero, three, five, seven, whatever you're sending,

Print out all the emails you send to customers, read them, and ask yourself, "am I doing a good job in terms of consistent voice, in terms of not being annoying?"

Did you write this email, this transactional email to get sent when a user clicks a button a year and a half ago, does the product that you're asking customers to use even exist anymore in the same shape?

Craig: It's huge, it makes a ton of sense. It's a thing that you probly don't think about as part of that perfect intersection.

Michael: Yeah, everyone thinks about their marketing site, their pricing page, their Twitter avatar but they create emails, never delete them and I think customers can have bad experiences because of that.

Craig: Brian, any personal chip you want to leave us with?

Brian: That's so good, though.

Craig: I think it's fine if we want to just end on that note.

Brian: I mean the only thing I also want to add, back to the spending time with customers thing, I think it's just encouraging everybody to work alongside people in every different team. I've learned immense amounts from spending time in customer support. I've learned a ton of time hanging out with ops folks, and understanding that the thing I was just pushing was causing a lot of other people pain.

And actually understanding the whole impact of what you're all doing together to be building a product and service that this affects every team and we all see things slightly differently. And the more well-rounded that experience is, the better you make decisions.

Craig: Everyone can't see at home, but a bunch of heads nodding yes, like talking to the other teams, super key, especially in product and I think product marketing as well is a very cross-functional role, where you need to understand all sides.

Brian: For sure.

Craig: Thanks again guys, for coming on. If people need further advice, guidance on marketing and pricing and otherwise packaging, hopefully they know everything they need to on the list now, but if not, they know where to find you.

Brian: Thanks guys.

Michael: Thanks so much.