Product releases can be painful for many reasons. Employees may not be fully aware of what’s included in the release. Customers may have been waiting with bated breath for a feature that may or may not become available. Moreover, the product release cadence may not align with your sales cadence (e.g. quarterly targets) or your customer cadence (e.g. monthly check-in’s), which means it’s another rhythm that customer-facing team members need to think about.
In this podcast episode, I dove deep into the challenges of product releases with Jake Brereton, Founder & COO at LaunchNotes, which just announced its Series A from Insight (and me!). We discussed:
How can you make sure that both your employees and customers are well informed about the product release?
What are the biggest mistakes that teams make when releasing a new feature?
What does a best-in-class release process look like?
I hope you enjoy this conversation as much as I did, and feel free to reach out to me with any thoughts. Let's dive in!
If you’d like to hear more about topics related to scaling SaaS and Web3 businesses, you can subscribe to my newsletter (for free) here:
Leadership Roles
As always, I’ll share a few leadership roles at companies I’m excited about:
LaunchNotes (the company that Jake cofounded!): Director of Engineering
Workstream: Head of People
Kingdom Supercultures: Head of People
VendorPM:
Palette: Product Marketing / Head of marketing (US/Europe)
Guide: Head of Marketing
Transcript
Allison: Jake, thank you so much for joining us on the podcast today. I'm very excited to have this conversation with you about how to communicate with respect to your product, which, for a lot of customer facing folks, whether you're in customer success, sales, or marketing, tends to be something that you care a lot about. Certainly customers care a lot about it. And product teams are trying to enable all of these groups to understand what's going on the product much more effectively. So I'm sure you have a big audience. And I'm excited to dive into the details.
Jake: Thanks so much, Allison. Yeah, it's a pleasure to be here. And congrats on the podcast. I appreciate the opportunity.
A: So to start out, I want to talk a little bit about your product, because I think it'll provide some context on the best practices that we talk about the rest of the conversation. Tell us about what inspired you to build LaunchNotes, which is your current company. Was there a particular incident that you can recall, for example, that you were trying to help prevent other organizations from dealing with?
J: Happy to. The era when my co-founder Tyler and I got into the software game was between 2010 and 2020, which we describe as a renaissance era for dev tools. As a result, if you're on an engineering team, life has gotten really good for you. You've got dev ops and agile and automation and CI/CD. Every single day, there's something that's coming out that's helping you be faster, more efficient, get code out and get value to customers faster and faster.
The realization that we both came to from different ends of the spectrum — he's on the technical side, and I'm on the product and marketing side — is that no one was very thoughtful between 2010 and 2020 on the impact that this rapid software development has on the rest of the organization. If you’re shipping code, now multiple times a day, what does that mean for your sales, support, and customer success managers, and ultimately, your end user? Because that's really who you’re there to serve.
Over time, we saw that problem get worse and worse — the complete misalignment between the non-technical half of your organization, in terms of knowing what was coming, when, and what they should be communicating to customers.
There was a catalyzing moment for us. The universe basically sent a sign. Tyler had left Atlassian, where we were both working at the time to start LaunchNotes. We were grabbing lunch one day, and he was catching me up on what he was working on. I led product marketing at the time for the JIRA business unit and for Atlassian. After lunch, I went back to the office for our biweekly product roadmap review. We would sit down my entire team in San Francisco, all the product folks on the JIRA team, and a lot of the engineers, and we would run through the roadmap. All the PMs would talk about everything that they were working on, everything that they had shipped that very afternoon. Of course, the entire point of the call was to drive alignment and make sure that everyone, specifically my team, which was responsible for the release, and the communication around the release, knew what was coming.
We were watching a demo of a feature that in the two-week span since our last meeting had been designed, QA’ed, and rolled out. And no one on my team even knew what had happened. This was a feature that we could have made some made some noise about. It was significant. And it was a very bittersweet moment: one the one hand, we had finally unlocked the team to be able to ship value that quickly. That's a great sign for the organization. However, it was completely hampering my team's ability to do their job.
This was a few hours after I'd had lunch with Tyler, when we were talking about this problem. I thought, this must be a sign. So wrote him an email that night and said, Hey, I've seen this problem get worse and worse. And now I'm feeling it acutely. So if there's room for me on board, let's go solve it together. That's how things got started.
A: So you said I'm committed now wholeheartedly, emotionally, no going back. Tell us, why is this a problem? Our teams have been building and shipping software for decades. Why is it become such an acute pain point right now?
J: The first thing is just as I mentioned, the rise of all these tools that are unlocking R&D teams to be faster and more efficient, which, again, for the end user can be really good. What added more gasoline to the problem was the move to remote and distributed work. It’s already tough to coordinate if you work in an organization where different teams sit on different floors, or you've got a few different offices across the country or the world. You put the COVID pandemic on top of this, where everyone started working from home, and people started living all over the world wherever they wanted. That was the straw that broke the camel's back. When everyone is remote, they're on different time zones. How do you know who's working on what, and specifically in today's age, when things change so quickly, so your weekly update meetings are no longer going to be any use?
A: What do you notice are the biggest mistakes that teams make when they're releasing new features?
J: The first one would be not involving customer-facing teams soon enough. We had a rule on my team at Atlassian: in their kickoffs, at the beginning of a new agile sprint, I wanted one of my PMs to be there at the table, to know what was being worked on. I don't think it's malicious by any means. But there's still this walled garden, and people get stuff thrown over at the last minute. LaunchNotes has a built-in roadmap functionality to make everyone aware of what’s in the next release. Whether it's an internal roadmap or an external roadmap, you can share different versions based on the audience that you want to communicate with, since not everyone needs to see everything. There should be a way that is worked into your product development lifecycle that proactively communicates, hey, this is where this feature is in the process.
We're big on collecting feedback, soliciting feedback on a regular basis from customers, from internal teams. But we often talk to customers about turning things from a monologue into a dialogue. It builds trust and leads to better product outcomes. As things are coming down the pipeline, it allows your customer facing teams to ask questions, and there's someone there to answer those questions. It’s about collecting feedback, having a way to synthesize that feedback, and giving people the opportunity to ask questions, give their thoughts, and give praise.
A: Those big mistakes that you mentioned really resonate with me. I think so often customer support teams are left in the dark about some of the critical issues. And then when the product is released, they're often on the front lines of defending why the product was released in this particular way. And also, they're helping to figure out, what's a feature versus a bug, and are generally swamped and maybe not as well educated about how the new feature works as they could be. I've also noticed many situations where customer facing folks, whether it's sales, customer success, or customer support, they're held accountable by their customers for knowing what the future product roadmap is, but even if they were equipped with knowledge about it, that knowledge might be in the form of an outdated PowerPoint deck that happens to be living on their laptop, and then they're at risk of communicating the wrong deadline. Also, often PowerPoint isn’t a particularly good medium for describing a new feature. It might include some flashy terminology and screenshots, but probably doesn't explain things at the level of depth that you might in some more purpose-built platform. So yes, I noticed these mistakes, and I imagine many of the people listening to this podcast are thinking of their horror stories.
J: I love what you said about customer success and support. We actually just today released the new version of our feedback collector. One of the things that we added is the ability for customer success managers to privately share a roadmap as they're reviewing what's coming with the customers they support. Then we added the ability for that customer success or customer support person to be able to submit feedback on behalf of their customer. So as you're walking the customer through the roadmap, if they have feedback, or thoughts or questions they can submit on behalf of the customer, which puts them in a position of empowerment, to be able to better serve their customers versus, as you say, being behind the eight ball, and the customer feels like they weren't enabled. They don't know what's happening, they're frustrated, and the support or success people are equally frustrated because they didn't know enough, either.
A: We've talked about what mistakes you can make when releasing a new feature. One question that I get a lot from founders that I work with is, what does a best-in-class release process look like? What does it look like in your opinion?
J: Philosophically, there's a few different things that people should be thoughtful about when building a release process or trying to modify a current one. The first is an idea that we talked to a lot of our customers and prospective customers about, that change is a constant, especially in today's SaaS world. That's the reason that the SaaS world exists: so you can be continually updating, improving, fixing on a regular basis. But at the same time, there’s a desire to be like Steve Jobs — to have big releases, stand up on stage, and unveil something that's been worked on for months or years. I understand that, coming from a product marketing background. However, that's not practical in today's world. Getting people in the mindset of, let's just continually talk to customers about the value that we're shipping on a regular cadence, and we don’t necessarily have to have huge marketing moments every month or every week. It's just about the value that you've created. There’s a cycle of: “change that’s coming”, “change that’s happening”, and “change that happened”. That's a cycle that's going to constantly repeat.
The second thing that we often talk to teams about in terms of a best-in-class release process: consistency. Especially in the product marketing community, there's a constant conversation around, what's the right cadence? People say, How often should we be releasing stuff? Weekly, biweekly, monthly? The answer is, it completely depends on what kind of software you have, your maturity, and all sorts of factors. What I encourage people to do is not think about cadence, but think about consistency. Humans are creatures of habit. We like consistency. We like to be able to know when to expect something. So, choose the consistent basis that works for your team, whether that's weekly, monthly, whatever it is. The important thing is that you're continuously communicating with customers and showing them the value of what you're creating for them.
The third thing is — and this is a core value of ours — transparency. Obviously Atlassian is a big champion of a building in the open, and open teamwork. In the year 2022, there's a lot of software out there, everyone's building quickly. It's very competitive. So I say, use transparency to your advantage. If you don't share your roadmap, someone else will, and whoever shares it first, everyone else is going to be chasing them. There's a lot of heartburn around sharing roadmap. But I think in great release cycles, you can see the change that's coming, you can excite users about it, you can give them a sneak peek. Think about, how do you use transparency to your advantage? You're doing all this great work behind the scenes, so don't have your engineers working on something for a month and then just have it pop up. Because you've just wasted a month to get users excited about it and collect their feedback on it.
A: A great list. One of the questions that I get a lot is how to ensure that go-to-market teams are able to provide ideas and feedback on the product roadmap, and specifically upcoming feature releases before critical decisions are made by the product team. You can imagine that these questions are coming from go-to-market leaders that want to make sure they have input, as well as from product teams that want to show that they're being really thoughtful partners to the customer-facing folks, and that they are making the right decision. So I'm wondering if you've noticed best in class companies using certain recurring forums between go-to-market folks and product teams, or perhaps other types of communication that ensure that go-to-market teams can be involved early in the decision making process?
J: Absolutely. It's one of the reasons why we built the LaunchNotes roadmaps to be internal-facing. One of the things I've seen some of our customers do with great success is build specific milestones into the process for incorporating go-to-market teams’ feedback. They have a column that says, “ready for review by go-to-market.” So you, the go-to-market team, have the next 48 hours to look at what we've done and offer feedback on. They’re very deliberate about it. We've seen at least two or three teams do this with pretty great success.
A: Those are great ideas. I know that you've spoken with probably hundreds, maybe 1000s of product teams. I'd love to know from your perspective, what's the greatest misconception that product teams have about the release process?
J: If I had to pick one — and I don't think this is just related to product, I think product marketing is equally as guilty of this — it’s that a spray-and-pray approach is going to work. I think there's this idea of hey, something is released. Let's just go down the checklist. Let's just get an email out, throw it up on the blog, put some release notes in Zendesk, and call it a day. And we assume that everyone is going to visit one of those three mediums. But you're likely reaching 10, maybe 20% of your users when you do that. Repetition is important. We encourage people to do a weekly launch, but then also do a monthly roll-up, and a quarterly roll-up. Even if you're tweeting about it, putting it up on LinkedIn, do a couple reminders, do it several times, do follow-on content, but just on launch day, just kind of pressing all the buttons and hoping that everyone is gonna see what you've done — it's just not going to happen for sure that way. That's something that I think is a pretty big misconception that's pretty industry wide.
A: I know a lot of founders who are gearing up for their big launch announcements, so I'm sure they're listening very closely. I've learned a lot from this conversation. Jake, thanks so much for joining us.
J: Thank you. This was a lot of fun. I appreciate it.
