Episode Transcript
[00:00:00] Speaker A: Foreign.
Thanks for joining us on the subscription Heroes podcast, Aubrey. Yeah, it's good to see you. I'm excited to talk to you today because we have been working with a lot of engineering leaders who are now beginning to focus on monetization and product led growth. And you have probably one of the best pedigrees of anybody that I know in doing that on the engineering side for sure. And I know there's blend into product, we've blended into marketing. So I want to touch on all today as we chat, but maybe for those listening, just give maybe, maybe a brief overview of your career because you've worked for some really cool names in the industry in the PLG SaaS space and just yeah, tell us a little bit about yourself and also tell us about Top View Labs and then we'll jump right into some of the discussion here.
[00:00:53] Speaker B: Yeah, so I've been a developer and engineering leader for the past 15 years. I've worked with a lot of different SaaS companies, just kind of happenstance a lot in the Southeast but, but all over too. So I started my career as a developer and consultant and worked my way into kind of engineering leadership. Worked for a long time with mailchimp and built out their API and then went on to Stitch Fix and worked a lot on their kind of onboarding. They do like a really interesting quiz and a lot of like deep information gathering and they're onboarding and so worked with them on that and then worked as an engineering manager and then director at Calendly for about three years focusing on their billing system, sign up and kind of their growth team as well. So with them we went from 25 people up to I think it was over 500 by the time I left and double digit millions up to over 100 million by the time I left as well. So got to see a company go through kind of full growth stage. And for the last couple of years I've been working with a smaller payroll startup here based in Augusta called Workful and I'm just now transitioning out into consulting with my company Top2Labs. Having worked with all of those different SaaS companies and seeing them grow, I've kind of got to see some common pain points with billing and monetization and growth and sign up and a lot of that is stuff that's not really unique to those companies. So sign up at mailchimp. Mailchimp has all kinds of cool, unique problems around email, how to make that work for small businesses and be approachable. Billing's not really a part of that and their sign up for the most part is not really part of that. There's common best practices that SaaS companies can do. And one thing that was cool about the tech community in Atlanta is people would move between companies and take those good ideas and that would kind of get pollinated and it would help the other companies around.
And so one of the things that I want to do with Hoppy Labs is be able to kind of share and pollinate those good ideas of things you can do with monetization and sign up to not shoot yourself in the foot later and make things easier. Being able to change your pricing and packaging without being in a whole six month project for multiple engineers is a big unlock for a lot of SaaS companies. So that's kind of the goal is to try and share some of those best practices.
[00:03:17] Speaker A: That's awesome. And you know, Atlanta, I think is an underrated tech hub. You know, of course San Francisco and Boston and Austin get all the attention, but Atlanta's totally underrated. Killingly.
I know there's a company called Maxio there that we've talked about before a lot of other places. And so Milkshake's not based there, are they?
[00:03:39] Speaker B: They are, yeah. Yeah. So they started in Atlanta, based there.
[00:03:42] Speaker A: Okay. I didn't realize that they've grown to.
[00:03:44] Speaker B: Have multiple headquarters and they still have a big presence in Atlanta even after their acquisition from Intuit.
[00:03:52] Speaker A: Yeah. Amazing, right? And, and I love. So I live in Charleston, South Carolina and I always tell people when I introduce myself, I've managed somehow to have a vibrant tech career in the Southeast. But you know, it's not that rare these days to, to, to be able to pull that off obviously with all the.
[00:04:08] Speaker B: Yeah, it's. Atlanta's been great. It's grown like crazy. But I, I think one advantage that it had compared to San Francisco, it was an advantage, but a challenge is there wasn't the same amount of investment available, which is tough if you want to do something kind of world changing. But it kind of means that businesses had to focus on profit and growth early. So mailchimp definitely was calmly the entire time I was there were profitable the whole time. There's not really examples of businesses who get huge and never have a path profitability In Atlanta you kind of have to focus on the basics from the beginning, I think.
[00:04:45] Speaker A: And that's so valuable especially in 2024. Mailchimp was bootstrapped, I think as well, weren't they?
[00:04:50] Speaker B: Yep. They started as a design agency and grew into a 12 billion company.
[00:04:56] Speaker A: Wow, very cool. So let's talk about monetization engineering a little bit. Cause I know that that terminology might not even be familiar to a lot of folks that listen, maybe in earlier stage companies that haven't even gotten to the stage where they would need that level of, you know, fidelity around their teams and definition. But what does that mean to you? Monetization engineering? How do we think about that?
[00:05:17] Speaker B: Yeah, so I think in a lot of early stages at startups, billing is a feature that gets knocked out as quickly as you can. You get to a point where you want to start charging customers. Maybe you're tired of having, you know, the CEO manually invoice or you're, you've got a bunch of smaller customers and that's not reasonable. So you integrate with something like Stripe and you feel like that's done, you're able to charge your customers and you leave that be. As time goes on, your support team will have more and more questions about like, hey, how do we do refunds? How do we do special pricing for this enterprise customer that we want to bring on board? And so your developers will kind of have a backlog of things that they do in between feature development. You know, they'll figure out how to get that pricing done or that one special feature. And as time goes on, you'll get to a place where that's not feasible anymore to have that as kind of like just small rocks that people are picking up in between the bigger projects that they're picking up. And you'll realize that there are projects that you can do that are a big unlock for your business that developers just don't have time on. And at that point it makes sense to have a team that's focused on monetization. So generally first, I think it's from the billing side.
At a lot of companies I've been at, it starts because of a compliance issue. Like they'll get emails saying that they're suddenly required to collect sales tax and you know, they'll face a big fine and so that'll suddenly push the priority up. But in general, it's an engineering team that focuses on the billing part of the application. So how do you charge customers? And generally that'll be tied together too with sign up. If you have some kind of self serve sign up to go from creating an account to creating a subscription to using the application. So a lot of times that can be tied in with growth as well.
[00:07:16] Speaker A: So, you know, I've worked, I've been a product manager for back in the day for some time and working around engineering teams for a long time. There's a few things that I know that engineering teams don't absolutely love. One is like building integrations, which it hurts my heart because integrations help open up new market for us. But there's billing integrations, there's fixing bugs, like everybody does like to, you know, get a good win for a customer, but it's, it's tough to prioritize those. How do engineering teams look at some of this billing stuff? Because when you talk about like you're integrating platforms, you're maybe using third party tools, maybe building some of it yourself, but like how do engineering teams look at this kind of work? Like, do they like it?
[00:08:02] Speaker B: No, I think generally pretty clear answer there, especially in startups, you know, they picked that career path because they didn't want to go do Java enterprise applications where you're thinking a lot about just how to handle money and accounting in general. So I think kind of an archetype of these types of developers is it's something that they're not interested in. And generally one of the good characteristics of those developers is they really want to be focused on providing value to the, to the users.
[00:08:33] Speaker A: Yeah.
[00:08:33] Speaker B: And so the idea of figuring out all the rules of how you prorate halfway through a subscription term when somebody cancels, like that's, that's just not going to be a fun thing for them. So generally there's a lot of eagerness to look at third party tools. I think for the most part teams have realized that there's enough complexity that it does not make sense to build it in house. Every now and then you'll find a team or developer who says, oh, it can't be that hard. And generally that'll be someone who hasn't dealt with it too deeply in the past. But I think a lot of willingness to integrate with third party tools and I think the longer you're in it, the more you want to build tooling for other teams so that you're not having to have developer time involved for customer support. Issues with billing or reporting ends up being a big time suck as time goes on. So anything you can do to kind of get developers out of the loop there? Yeah, that's also a really big interest for these teams.
[00:09:33] Speaker A: Yeah, it makes total sense. Where we run into that a lot is the build in house kind of model is with companies, you know, like Calendly or Mailchimp who've been around for a long time. Not all of them. I don't know if Those two had that or not. But companies that have been around longer tend to have implemented something themselves before all these platforms came along. So I guess, like, what's your perspective on how this industry has changed over the past, you know, five, you've been in it 15 years, so. And you've seen a lot over that time. Is it, you know, the tooling seems better from my standpoint. Do you see that as well?
[00:10:09] Speaker B: Yeah, I think it's kind of similar to what I was talking about with the Atlanta tech scene where there was kind of cross pollinization with practices. A step beyond that is kind of turning those into platforms. So not just taking those practices and building the same thing in another company, but building a kind of a common platform that other companies can use to do those things. So you'll see it with subscription management and sign up and taxes, reporting, you know, turnkeys, cancellation flow and dunning. All of that is kind of common tooling. Yeah, I think you'll see that more and more. And one of the big drivers behind that too is compliance. Yeah, having a third party tool means that somebody else, when there's change changes in credit card rules, somebody else takes care of that for you somewhat. So yeah, there's been a huge push into using third party tools and the ecosystem's grown a lot. It went from really when I started, you know, Braintree was just an API to do a credit card charge into.
Now there's companies where you can hand off the whole thing and they'll be your merchant and you know, as much as possible complete everything for you.
[00:11:18] Speaker A: Yeah. Called merchant of record, I believe. Right. Yeah. Where they actually are the merchant, I.
[00:11:23] Speaker B: Think paddle is growing pretty quickly trying to do that.
[00:11:26] Speaker A: Yeah, yeah, that's great. So, you know, people get pulled into this work probably all the time, sometimes against their will. But is there like, what kind of skillset from a business standpoint do engineers need to have or even product managers need to have around the subscription side of the business to be able to be effective in doing this? Have you, have you seen any patterns there?
[00:11:50] Speaker B: Yeah, I think it's a domain where thoroughness and details matter a lot more. So common issues that I've seen with teams like this in the past is they'll make a change, but they won't think through all of the different parts that are affected by a project. So early on in my career we would implement refunds kind of in an automated way, but then forget to account for sales tax as part of that and then forget to account for reporting and so there was all of these follow on projects that we'd have to do. So it becomes really important to be thorough and fully think through all of the parts of the building process that get touched by the changes that you're making. Testing becomes a lot more thorough and detail oriented. And in general, kind of a willingness to build spooling a little bit earlier as opposed to kind of a more MVP approach where you'll just get something out and trust that you'll come back to it. It's something that has to be thought through a little bit more than I think some other feature development generally. And software applications.
[00:12:55] Speaker A: Yeah, you know, I think the partnership between product management, design, engineering, so critical these days and actually I got something else I want to pick your brain on, on that, on that front too. But do you have stories of examples where it's worked well, where, you know, whether a calendly or mailchimp, you had sort of that collaboration going on between these teams? Like did you get other people involved or did the engineering team typically handle it on their own with some guidance from the business? Or how did you do that? How did you think about that?
[00:13:28] Speaker B: Yeah, I think our team at Calendly we kind of always talked about the three legged stool of product engineering and design working really closely together. And for us there were a couple other teams involved as well, which were customer support and then the finance team. And so one of the really big projects we did while I was there was we transitioned from Stripe billing to chargebee, so swapped out our entire billing backend and migrated all of our current subscriptions as part of that. So it was really touching every part of kind of the customer life cycle and the collaboration between products to really help map out everything that needed to happen and understand the opportunities for us to help our customers and grow our business through doing things. Like for larger customers, having being able to combine invoices, that was something we couldn't do through Stripe billing. That Chargepee kind of unlocked for us. So being able to kind of map those out, working with engineering for having a plan of how that would actually get built out and the impacts that were there, and really close collaboration with customer support on the things they needed to make sure we didn't explode their workload. Because at a company the size of Calendly, small changes could mean big staffing decisions for the support team. So we had to be really careful to make sure suddenly there wasn't a manual process for refunds or cancellations or things like that. And I think one of the successes There is. By using chargebee, we were able to lean on them to build a lot of tooling for that support team. So instead of having to build bespoke features for all of the different flows that customer support had to go through, engineering did this one integration and it unlocked all of that for that team. So, yeah, leaning on third party tooling, that worked really well. Yeah. We were able to work really closely with the finance team to understand their reporting, to make sure that all of that was covered as well. So it just really collaborative and it ended up touching a lot more of the company and a lot more teams than I think you would have initially guessed.
[00:15:39] Speaker A: I mean, it had to been nerve wracking at a place like Calendly to change out a billing system because, I mean, it touches everything, right? It's your lifeblood, it's your revenue at some point, right?
[00:15:49] Speaker B: Yeah. And the actual migration, so moving all of the data into chargeby, that was, that was definitely a stressful weekend.
Didn't go off with zero hitches, but it went off with enough that it wasn't visible to any of our customers and didn't affect kind of any of our revenue coming through or settling or anything like that.
[00:16:11] Speaker A: That's a win. I mean, if you're coming, customers can't see it and you have to deal with the complexity fine. Right. Internally, but when your customer starts seeing issues, that, that's a, that's a red flag. So. Yeah, that's great. That's great.
[00:16:24] Speaker B: Yeah. All in all, that project was a big success and let the team speed up a lot in the future. We were able to lead a lot of the kind of custom coding that we had built around the older parts of the stripe billing system.
[00:16:37] Speaker A: Yeah, very cool. The. I think there is, you know, maybe another area you mentioned, this internal tooling kind of thing. Another area that I think is under, under prioritized by SAS companies. The initial vision around SaaS was that, hey, we're going to have everybody's data, right? And we're going to be able to see what they're doing, we're going to be able to understand how their usage maps to what they pay us every month. And we're going to be able to use all that information to go drive value into the customer, drive adoption.
And I feel like that's something that hasn't necessarily come all the way to fruition in the SaaS industry because we are so focused on building features, features, features, features. We forget about the fact that the ability to measure value and connect it with the revenue is a feature of a SaaS company. Right. Maybe not the product per se, but of a business that's trying to provide value to its customers. So, you know, at the risk of going off on a tangent here a little bit, like, what are your thoughts on that? Because it does tie in. Right. Because you, you want to know with the value metrics on your website, how, how do they stack up to, you know, the price that somebody pays and the value that they actually get? At the end of the day, it's more, I guess, more of a customer success question. How do you think about that? Is that, is that an area that you play in, in your current work?
[00:17:58] Speaker B: It definitely is. And I, I think it's not like a novel idea. Right. Pretty much every company I've ever worked for has a team where they want to be able to tie those numbers together in a real way. And so, you know, not just anecdotally, but be able to say with data, people who adopt this feature end up having higher success, move up in our subscription tiers and we're able to put a dollar value to that feature development. And generally that is really difficult because all of that data is living in different systems.
[00:18:32] Speaker A: Yeah.
[00:18:32] Speaker B: So one of the nice things about being able to have a third party billing system is that somebody else is managing it for you. One of the tough things is that out of the box, all of your subscription data is living somewhere where you can't query it and you definitely can't join it to some other data to filter or segment it. So I think a pretty common pattern is to have something like segment or there's a couple other analytics tools that are measuring user behavior and kind of aggregating user activity. That's all living in one place in a very different shape than what you have in your billing system. And it's disparate too, from anything that you have within your application. One thing that's been changing the last few years is tooling around data warehousing. So tools to make it easier to pull all of that data together in kind of a centralized place like Redshift and AWS or Snowflake. And I think, you know, it used to take an entire data engineering team to just build integrations with Stripe and your analytics tool and your application and then have it somewhere where you could build those reports and then another team of analysts just to build those reports out. That's not super feasible for a team of 50 people to staff a team like that. But tools like Fivetran or AirByte are kind of making it easier to pull that data into a warehouse. You still have to have a team that's keeping that organized, understands all of that data and to be able to build reports off of that. But it's easier now than it used to be and I think we'll probably see more tooling for those types of jobs come along in the next few years.
[00:20:13] Speaker A: Early in my career I was, I was an engineer. I don't think I was a great engineer by any stretch, but I did a lot of data work that was, that was what I did. And I still love data work. But I mean we used to build star schemas in your relational databases and we used to load them up using ETL and we used to use OLAP cubes that sat on top of those data structures to be able to slice and dice things quickly. Sort of like a pivot table in Excel, but just with massive, massive volumes of data. And so like one of the, one of the big challenges back then, and it wasn't even like it's showing my age but like SaaS wasn't even really a thing back, you know, in the first few years of my career. So the idea of pulling data, big amounts of data out of Salesforce or out of a billing system or out of HubSpot and merging it with another data set was sort of like, it was sort of a non starter. Like you didn't even think about pulling that kind of data, especially like corporate data over a network, over the Internet to be able to, you know, combine it with other data sets and analyze it in the cloud. Certainly we didn't, we didn't have cloud services back then as well. So big changes in that, in that area over the past few years. I mean network speeds have gotten faster, processing has gotten faster, cloud services have become ubiquitous. But yeah, so I don't know where I'm going with this, but like things have changed a lot there and it's, it's so much more accessible. Are you finding, do you see that those data sets have to be cultivated the way that they used to be in terms of like how you structure them? Like is it star schema, is it like, does it even matter anymore? Or is it just getting all the data in one place and making sure that it's all correlated with IDs that match from these different systems? That problem is still a problem, right? You still have to match data across. So how are people solving that problem these days?
[00:22:04] Speaker B: I think it's less and less a performance issue.
So you know, especially using cloud services or most startups and growth stage companies, they're not going to have so much data that they're going to have issues running those types of reports in Snowflake. But I think it's still an issue in kind of data organization and just making sure that you have the information that you need to be able to tie an opportunity in your CRM to an account in your application, to a subscription in your billing service. And if those systems change over time, you know, do those field names change? So I think one practice that's really important is having a data model or some kind of data dictionary to say these are the things that we care about as a business, this is what they're named and where they live. So yeah, for a SaaS application, modeling someone in your marketing pipeline to your sales pipeline to a trial to sign up through activation within the application, through kind of the later stages of the subscription, having that all mapped out and documented and using that modeling in your reporting, I think becomes really important just because you're trying to tie together all of these different schemas of whatever happens to be set up in Salesforce, however you've organized things in Stripe, however things are organized in your application, putting some thought into how you want to model that I think is really important.
[00:23:31] Speaker A: Yeah. And that, that sort of speaks to how, you know, we have all these departments in a, in a SaaS company, but in all these departments tend to have their own applications that, that they bring in too. And they were little data silos. Right. But at the end of the day, what you just described is sort of an end to end customer journey or an end to end experience that we have to facilitate with all this data. A, to know what's going on in our business, but also to know what's going on in the customer's experience with our business. And those two things tie together really, really closely. So you're, you're pretty well versed, it sounds like. I mean, with, with everything from not just the billing systems and the monetization side of things, but opportunity management, marketing, you know, marketing, lead management. And so have you had to touch data that far upstream in a growth role before?
[00:24:21] Speaker B: Not in a growth role generally it's been at startups that are a little bit smaller, where you get to wear more hats, which is one thing I've always really enjoyed. And there it really becomes making sure that data is synced in a place where the sales and marketing teams are able to make use of it as much as possible. So they'll Definitely want to see in the CRM when someone has signed up and tying together things like customer support tickets. So if one of their big clients is reaching out with issues, they want to make sure they know. So yeah, kind of that process of making things visible between different systems.
[00:24:59] Speaker A: That's great. So switching gears just a little bit. You have any. I want to hear some stories from maybe your mailchimp days. You shared a couple already. Mailchimp, your calendly days. Like, what is it you're most proud of from those roles? Any projects stick out to you?
[00:25:18] Speaker B: The things I'm always the most proud of are the teams that I've gotten to build.
So at mailchimp, you know, there was no API team when I started. I got kind of handed the project from another developer and we grew to a team of about eight people of developers, testers, product and a writer, because documentation was such a big part of that. And not only, you know, getting a team to come together, but also kind of helping deform its place in the organization.
So the API team at Mailchimp was interesting because we wanted basically every feature in Mailchimp to be available through the API. Mailchimp had, I think 70 or 100, like somewhere in between their developers at the time. And we were a team of four developers. We clearly weren't going to implement every single feature in the API. Like, we'd really quickly become a bottleneck if we were there. So we had to figure out kind of what our place was in the organization and make sure it was not. We're the gatekeepers or bottleneck for everything going out as we try and implement it within the API. So we were able to figure out this place of kind of building tooling and platform or an API platform for other teams to make use of as they were rolling things out and got to do a lot of like training and working with other developers and getting to put my product hat on a little bit to get feedback on those tools that we were building. Calendly it was kind of a similar price process of there was no monetization team when I was there had been those responsibilities had been passed around between a couple different teams and so got to staff that and build it up to a team of about 20 people by the time I was there. And it was a similar thing of figuring out where we fit in the organization, how we worked with product, how teams wanted to roll out features that were part of a pricing tier. We weren't a bottleneck for that and got the opportunity too to help A couple people step up into leadership roles and see them kind of grow through that. So, yeah, that's always the thing I get to be the most proud of is when you can step away from organization and you've built a team and it's found its place. People know how to work well together and work with other parts of the organization.
That's always really nice.
[00:27:41] Speaker A: Yeah, it just keeps on going without you having to be there. So what you just described there reminds me of an article I read from Elena Verna a few weeks ago about how a growth team sort of fits in with the feature teams. Was your. The monetization team at Calendly, was it similar in that you had to depend on these feature teams and where work with them closely to go test things around monetization or like what was the interplay between those. Those feature teams and what you were doing on the monetization side there?
[00:28:13] Speaker B: Somewhat around the billing side in that we had to make sure that, you know, what every team was building fit into our pricing structure and be kind of billed appropriately, but way more on the growth side in. I think the biggest part of that was thinking through how a user would kind of activate into a feature. So going from they have no login, nothing at all, to, you know, they're using scheduling with their team and have set up kind of intelligently. You go from very simple like send the link to find a time with somebody to something more advanced where it's figuring out scheduling between an entire group and you know, for a sales team or customer success team, it can get much more complicated than that. So working with that team to figure out how we improve their activation metrics. So measuring to start just from the time someone has bought a feature to how, when they're actually able to use it and are continuously using it, measuring that first and then working with them on how to improve that metric to start it with a really manual process of the product developers working closely with those teams, trying to get it pushed into their roadmap and being a little frustrated at the relative prioritization? Yeah, one of the big unlocks for us there was implementing a tool called Optimizely that let us build out these kind of onboarding or in app experiences in a way where a designer and a product manager could work together on something like that. And it was either no or low amount of effort from the actual engineering team. And all of that had measurements baked in. It was easy for them to do a B testing and we were able to work out enough process around it where everybody felt safe around kind of handing the keys away to let product managers and designers make changes in the application. And so that was a big unlock because it got things out of a developer scrum roadmap where, you know, things can get done quickly, but they can get done quickly when there's no other big priorities and no one ever has too many developers, you know, that's hardly ever the problem. So it switched it into a place where product managers and designers had a lot more freedom to make changes. And that was a big unlock for those teams because they were able to at least test really quickly and figure out what experience made sense and they might eventually move it out of optimizely and have developers build it in that. But when they were doing that, they had metrics and a clear signal of, hey, this is working, as opposed to building the full thing and having to show afterwards. Yeah, we're pretty sure this was the right thing. So it let us get things into production a lot more quickly. And it also took a lot of the politics out of the product development because when you're asking a company to spend six months of six developers time on something, that's a big commitment. So, you know, a lot of times it was multiple meetings, a lot of presentations, it was a ton of like political work for the product managers in those cases. Whereas if they could go run an experiment, come with data, it was a lot less, trust me. And it was more, hey, we found a good solution, let's go and build this. So I think it was a more enjoyable process for the product managers and the designers being able to go that route.
[00:31:36] Speaker A: Yeah, that's awesome, man. And back to this idea of having a third party tool to leverage to do that. It reminds me of a quote. If we have data, let's use data. If we have opinions, let's go with mine. You ever heard that before?
[00:31:50] Speaker B: I haven't. Yeah. I think that's how a lot of teams operate. And it's tough to find the data for a lot of things you want to do.
[00:31:58] Speaker A: Yeah, the truth seeking. This is probably a whole nother podcast episode. But the ability to seek the truth and identify truth and not let your opinions get in the way is a superpower of a product team, in my opinion, because it's so easy to come into product development. And by the way, anything else, go to market and sales marketing with your own bias and experience and not, you know, actually prove out exactly what you think is happening with data. People do it every day. I know, I know. We, we do it. And I know I do it. So I want to go back to something you said and sort of dig into this API team just a little bit too. You mentioned product engineering, design. I, back in the early 2000 and tens, I was, I don't know if you've heard of Marty Kagan, Silicon Valley Product Group. We were lucky at my company that actually Marty came in and trained our entire product team. We had a new chief product officer join and we learned about, you know, product management is responsible for the value piece of the equation, engineering is responsible for the feasibility part of the equation, and design is responsible for the usability piece of the equation. And we actually formed little design teams to go out and do the research ahead of time on features before we load them into like the scrim process. So we actually had a really good idea of what we were going to build before we, you know, got down the path of handing it to an engineering team and a product team to build. But I'm curious on the API level work because that's a really interesting use case, right? Because you don't have traditional user experience there. You do have a user experience, but the user experience as a developer, you said you played the role of product manager on that. Can you talk a little bit more about, since it was an API, it's not a traditional feature set, right? So like, how did you publicize it? Were you involved with helping to promote it? Did you go through the normal marketing channels to get it out there? Like, how did you build and release this thing?
[00:33:55] Speaker B: I think we were kind of lucky on that project in that it was really more coming from user requests than it was anything else. So it was users of mailchimp wanting to be able to, you know, pull data out or integrate with other applications. So it wasn't a lot of us divining that. It was more interpreting it into what are they really trying to do here? How do we make tools available for that? And then focusing a lot on best practices around APIs and also conversations with developers and users to organize things in the best way possible. So really understand what are people trying to do with a list and how do we make that easy for a developer to understand. So that was a new process for me to kind of think through Personas. Because with mailchimp, it ran the gamut of someone who, you know, has their first blog, they want to add a sign up form, they'll do that through the API all the way to a company like segment that wants to have all of their customers data sync regularly Back and forth. So really, you know, low experience, low complexity use case to very experienced, high complexity use case and we needed to make that work for both. So, yeah, a lot of conversations, we had an opportunity to do a lot of beta testing with users and get feedback. And also we're lucky in that we just had a lot of developers internally who could kind of help us dog food and get feedback there.
[00:35:33] Speaker A: Yeah, I have to imagine companies like WordPress or Automattic or, you know, these other, other companies that are big ecosystem players that you knew would want to integrate. Were they, were they part of the equation at all when you were developing this capability?
[00:35:50] Speaker B: So we, we had an existing API and they were in that their use cases did not work well and they were still able to pull all the data. But on our side, it ended up causing a lot of load onto our servers and a lot of extra support load. So the usability of the API definitely was a big unlock for us, but it was also kind of an internal thing of, hey, as we continue to grow as a company, we can't support this kind of inefficient way people are accessing our data.
So yeah, it was a combination of allowing other companies to integrate with mailchimp, but also taking the ones that the existing integrations and making them work work a lot better. And for mailchimp, yeah, being part of all of those ecosystems, having, you know, pretty much any company that you want to be able to integrate with, that just working out of the box has, has been, I think, a big success factor for them.
[00:36:50] Speaker A: That's great. So, and I know you work with a lot of different companies on this area right now, particularly the monetization and billing side of things. But how do you know, how does a software company, how should they know when it's time to really start scaling a team to focus on monetization? Like, what are the signs that you would say, okay, it's probably time to put somebody in this role more than just in between the feature sprints.
[00:37:18] Speaker B: I think it has a lot to do with prioritization and you'll get to a place where you realize that there are projects that are good ideas. So reorganizing your pricing and packaging, or changing your pricing or integrating with something like ChurnKey to help with your churn or your delinquencies, and those things will always hover, you know, halfway down the list and you just won't be able to focus on them. I think that's kind of where, where it makes sense to start to staff a team that's focused on this specifically for a lot of companies, it'll stay that way for a while and then you'll get hit with some kind of compliance thing that's going to completely derail your backlog. So if you're able to get ahead of it a little bit, where you've grown enough that you know the manual processes that your customer support team is doing or your sales team is doing to get that one big client signs, you know, once those start to feel unmanageable, you've got things that you want to do in your backlog and you just can't get those done. That's your sign that it's time to have a team that focuses on it. And I think to start, if you can follow best practices and make use of third party tools, you can push that down the line somewhat. So if you're building your own billing system and you're doing it poorly to start, you're going to have to staff that team a lot earlier than if you're kind of smart about how you integrate with third party tools and really lean on them, that you can have a lot more Runway before you have to have a team that's focused on the solely.
[00:38:59] Speaker A: Yeah, that makes a lot of sense. It's a good, good case for the, for the buy versus build in that case. So. Well, I heard compliance, I heard not getting to things that need to get done. I have to imagine like new leadership could also be a catalyst for this. People who come in with maybe more experience and help the founders say, okay look guys, it's now it's time to take this thing to the next level. We're going to do a price increase, we're going to repackage things and that could be catalytic as well.
[00:39:25] Speaker B: Yeah, I think getting to a place where you've outgrown your original pricing and packaging is a really good time to start to focus on this or at a place where you feel like you're, you've reached product market fit. One of the big levers you can do is changing your pricing to kind of unlock some of the margin and just to capture the value of the things that you've been continuing to build. If you're in that place, it makes sense to have a team that's focused on that.
[00:39:54] Speaker A: Yeah, and we were just celebrating right before we celebrating it might be a little too strong of a word, but we were just talking about the today the interest rate decrease that was just announced. So you know, hopefully we, that that brings back some growth into SaaS, with the past two years in SAS, it's been a whole different ball game from pretty much to any part of my career so far, except for maybe 2008, 2009 during the financial crisis, home loans and all that, those kind of issues we had back then. But, you know, Now I think SaaS is maturing to a place where it's not growth at all costs anymore. It's not retention at all costs anymore. It. We need to monetize, we need to find ways to exchange fair value back and forth with our customers and do it in a way that works for them and works for the business as well. So I think your timing of what you're doing is, is really, is really important and hopefully well timed for you from a business standpoint. Aubrey.
[00:40:52] Speaker B: Yeah. Well, thank you.
[00:40:53] Speaker A: So if people want to connect with you, what's the best way to get in touch?
[00:40:58] Speaker B: Yeah. So topviewlabs.com or Aubrey, topviewlabs.com, reach out especially early to growth stage startups. I've seen a lot of how you can set yourself up for success with monetization and growth and really want to share those learnings. It kind of is painful to think about developers who don't care about this stuff running into the same pitfalls time and time and time again. So as much as I can do to, to help companies out and kind of avoid those problems, I want to make sure I'm doing it.
[00:41:32] Speaker A: It's awesome, man. All right, well, we look forward to plenty more conversations and thanks for taking the time to do this.
[00:41:38] Speaker B: Yeah, it was great talking to you, Jay.
[00:41:39] Speaker A: You too.
