Triple Shot Saturday - Edition 5
Three of the highest signal-to-noise ratio snippets from the startup/tech podcasts for founders/operators.
Hey there,
Here are my favorite three snippets from the podcasts I read this week.
Slack's VP of Product & GM Jaime DeLanghe goes behind-the-scenes on how Slack is using AI to (a) improve user experience and (b) convert that better user experience into revenue for Slack. She was on the Product School Podcast.
How Slack is using AI to address the challenge of information overload by separating noise from signal.
We launched recaps earlier this year, which takes sort of the ability for you to say like all of these channels. I don't actually care about reading them that frequently, but I do kind of want to know what's going on. So I want them to roll up into a digest and I can read that once a day. I could read it once a week but that sort of idea of giving you a way to say, this stuff, not that important to me. I think we need to keep pursuing that. We also need to do a better job of helping you find the stuff that is important to you. Because if everything is noisy, then how are you going to find anything, right?
The difference between using AI in a communication hub like Slack vs a documentation hub like Notion.
Slack is a perfectly natural place to have something like an assistant experience, right? Like it's you wake up, you check your Slack. That's what you do. Like what are you going to do that day? What meetings do you have? What's the most important thing for you to pay attention to? I think there are opportunities for Slack AI to help with all of those things in a way that like I don't, I mean, maybe someone at Notion would tell you differently, but I don't really see Notion AI having the same, you know, set of data to work from and also like place in a user's life that Slack has."
Finally, their decision to charge separately for AI features (much like Notion) rather than bundling it up in an existing plan.
Yeah, so I think there's really two parts to the rationale for charging. One is the value that we think we're giving the customer. So I think this is like the most important one, which is we have a lot, a lot of data inside of Slack. If you're a company that's been using Slack for years, there's just a mountain of information inside of Slack much more I would venture than what's in your Notion and what's in your Asana or your Miro. This is actually kind of a database for your company, even though it might not feel that way. And so the part of what we're doing with our AI product is giving you access to all of that data that we're already storing. And I think when you think about AI products or machine learning products, historically, a lot of where the cost has come from is in the data processing and the data management and the value you're getting from that data. Right. So I remember looking at SaaS products for AI, everyone charged you by data or by query. And so I think, you know, value per interaction that you're getting from Slack, I think it's higher, honestly, than it is for a lot of those other tools.
Brian Halligan, co-founder of HubSpot and now a senior advisor at Sequoia talks to Shane Parrish on the Knowledge Project podcast on the importance of culture in a company.
Treat culture as a second product and not exhaust fumes of everything else you are doing.
And we basically treat culture like our second product. Like our product HubSpot. If it's unique relative to the competition, it's good quality product and it delivers value. It's like a magnet that pulls customers in and retains them. Same thing with the culture. If it's unique relative to the competition, it's high quality and adds value. It's like a magnet that pulls in employees and retains them. And so we put a lot of thought into that culture stuff. And I think a lot about how do you take, how do you go from startup and scale up. I think a key part of that is getting your culture right and writing it down and institutionalizing it.
How they used Net Promoter Score surveys to drive culture at HubSpot as it scaled from 2 people to 8000 people.
Culture is how people make decisions when you're not in the room. Culture is how HubSpot's gonna scale. And he said, okay. And it's very hard for me to assign work to my co founder to this day. Somehow I assigned him to drive the culture at HubSpot. And he did an excellent job and still is doing an excellent job of marshaling the culture from, you know, 50 employees to 8000 employees. And he did two clever things. First thing he did is we're big on net promoter surveys. So he surveyed all the employees, scale of one to ten. How likely to refer HubSpot as a place to work and then why again, people wrote novels about it and he kind of broke it all up into, you know, different topics.
And then he wrote a PowerPoint presentation called the HubSpot culture code and just sort of outlined how we thought about culture. And then he posted it on the Internet and it blew up on the Internet. But we continue to do that net promoter score once a quarter for the last 15 years. And we've been tracking our net promoter score per quarter and that's been very, very useful. Then we post every response to the net promoter survey on culture on the wiki, and then we address the issues that come up that best practices served as well. Every six months we refactor the PowerPoint deck. It's a living, breathing document.
Akash Gupta, co-founder and CEO of GreyOrange (Blume Fund I co), an automated warehouse fulfillment company, on how to build AI-led products when selling to B2B companies. He was on the AI in Business podcast.
The importance of prioritizing features on your roadmap with the requirements of your Fortune 100 customers.
I think when you're looking at B2B enterprise, I would say one of the biggest challenges is prioritization. Here you're working with the Fortune 100s of the world and making sure that you are kind of building your roadmap while making sure that you're prioritizing things in the right way for them. So I would say for any enterprise SaaS vendor, prioritization is one of the biggest challenges.
If you're going to spend this time on a particular feature set, particular algorithm or likes of that, do you have a very good understanding of value it's going to create for your customer? What is the fulfillment outcome that's going to create? So I think prioritization and being able to clearly articulate the value, it's going to drive things that's hard to get right. But once you get right, very, very valuable.
To build quickly, let different teams or modules within a company follow different approaches based on their specific needs and expertise.
One thing that we learned in last few years is that you cannot take a development methodology and apply to all your modules. I think it's okay to have different microservices or different modules and different teams follow different development methodology. Our core platform team releases much, much less frequently than kind of analytics team or some of the applications teams and things like that. I think it's just okay to, I would say have different modules run in a different, you know, software development methodology. Initially it creates a little bit of chaos and mess, but once things settle down I think it's better.
We've also stopped thinking about this whole rule set that even I used to have ten years back that we should choose just two or three languages and two databases, and that's going to be the stack all across and likes of that. And today I think we have been very, very flexible on saying, okay, as this module you can go and write in Golang and rest of it is in Erlang and you know, some of this is in python and things like that. Because I think if you can encapsulate your modules, you know very, very well, and kind of make sure that the contracts between them are well defined, there is a value in writing certain things or using different stacks for different things. And lastly, I think no matter what stack you pick, it has to align with the expertise and the folks in the team because you can take the best stack in the world and if you don't have the right set of people, they would still write worse code on that stack. So I think matching the stack that you are choosing with the right skill set of people is critical.
That’s it for this week. See you next week.
Rohit