Monetizing SaaS: Episode 24 with Tommy Noonan, Product at Tropic

Ami, it's so fun to have you on the podcast. Thank you for joining us. You have been really instrumental to Schematic since we started the company. You've always provided incredible feedback and been a great thought partner to the company, but your career is really an amazing one. You've been a product leader at companies like FullStory and Cypress and Interviewing and now Tropic. I believe you got your start in consulting with Accenture. Can you tell us about it? How did we get to now? What were the career steps?

Yeah, definitely. So I was a systems engineer out of college and going to consulting and, you know, particularly being a technical consultant at Accenture seemed to be like what half of my major was doing from UVA. So it seemed like a very logical next step for me at the time. And frankly, I love solving business problems. I love being in front of clients and I loved kind of the different exposure that I got from consulting very early in my career. Um, after I was promoted to consultant though, I, I felt like I had gotten my taste of consulting and was ready to move into what I thought was maybe more innovative tech products and not another ERP implementation, um, for, for large Fortune 500 clients. Um, so I transitioned to tech by way of business school. Um, I got my MBA at MIT, um, which was perfect. Uh, it was analytical, it was pretty down to earth as far as business schools go. Maybe even a little bit nerdy, but also like obviously the very heavy tech focus. I did my internship at Google as a mobile search product manager, which I don't think I could have gotten a better crash course into software product management. I joined a product 12 weeks before it launched, so I got to see firsthand, you know, what does Google do 6 weeks before it launches a product to millions or even billions of users, given that I was on the search team. And that was really just, you know, I think a phenomenal jumpstart for me into tech. That being said, I begged them to transfer me to New York. That was no dice. I knew I wanted to get back to Atlanta eventually where I'm from. And so I decided to make the leap and to go into a smaller software company. And that's where I found FullStory. Really, truly, I just love the product. I thought, you know, wow, if I had had something like session replay that worked like this when I was at Google, it would've made my life so much easier. So I figured if Google didn't have it, maybe the guys at FullStory were onto something pretty special. But anyway, I joined FullStory when they were about 40-ish people. I was the first product management hire, but when you're 40 people, you do a lot of different things. I was in charge of pricing for a short period of time. I built out a lot of our internal data analytics architecture and was the admin for Looker for 3 years while I was there. And then I kind of became the core product experience product manager. So launched products like dashboards and funnels and metrics and a lot of FullStory's more, I'd call, product analytics-facing features, moving them from session replay. After FullStory, moved on to Cypress. I was a growth product manager there, so was in charge of kind of our monetization play between our open-source test runner product and our cloud paid-for testing orchestration product. That was extremely, I'd say, like helpful for me because that was the first time I was truly sitting over like a company-wide initiative. I led our move from SaaS-based pricing to consumption-based pricing. So all of the changes that go along with that, updating sales comp plans, updating our marketing playbooks, reevaluating what a product qualified lead is. But anyway, it was like great horizontal exposure for me. Moving on from Cypress, I went to Interviewing.io, which was a very kind of B2C-led product. We sold interview prep to software engineers that were in cycle at FAANG companies. This was, I guess, exciting for me, A, because I wore the head of product role for the first time, but then also grew into a head of growth role. So I was doing a lot of different SEO optimizations, different marketing site updates to track, you know, how we would convert leads to the website into actual paying users in the product. But that leads me to Tropic, where I've been for the past year. I'm a group product manager here and the lead of our intelligence products. So Tropic is, you know, helping users get control of their software spend. And we have one product that does a lot of kind of controls, intake to pay, I guess I would call it. And then my product does a lot more of the kind of aggregation and intelligence of all of the data we have on our customers on different contracts. And we help people make sure that They're buying the right amount of software and they're paying the right price for it.

It's an incredible story. I think what's so interesting about it is a lot of your product work has had some degree of overlap with monetization or growth. And so I want to talk a lot about that today at Tropic. Tell me about that work. You described it briefly, but where are you spending the majority of your time? And do you see that, given it's so analytics focused, do you see that moving towards growth and monetization or TBD.

Yeah, it's a good question. Um, Tropic has been very interesting for me, um, mostly because our software product is very new. Um, even though I've joined at earlier stages of different companies, Tropic was a services business up until the past year. And so we have been, you know, exploring a lot of different ways of how do we package our software, how do we price it, what are the right value metrics, um, to explain the value of Tropic to our users. So, you know, while I may not have the same kind of monetization responsibilities at Tropic, I feel like I'm kind of learning firsthand of, you know, what features should I prioritize to fit into these different packages? How has our software kind of thesis evolved over the past year as, you know, we've just learned as a company the right way to, you know, to ship a software product and transition from services.

Makes a lot of sense. You know, one thing that also stands out to me about your career is in some ways, in some ways, I wonder if you'd agree with this, it's kind of industry agnostic. Like you've touched large-scale consulting. It sounds like with a lot of ERP integrations, you've touched session replay, you've touched, um, you know, obviously with Tropic Procurement, you've touched dev tools with Cypress at Interviewing, you touched a kind of like interesting B2C play. When you think about— well, hey, let me stop. Do you think that that's valid, that you've kind of been industry agnostic?

Yeah, I think that that is true, and certainly not something that I set out to do, but I've always tried to find myself wanting to work with great people solving interesting problems. And so that doesn't necessarily limit you to one industry.

Yeah, I mean, it just seems like there's like a huge breadth of curiosity and that's led you kind of on the path that you're on. But I wonder if you know, if you were to zoom out and think about all those experiences in aggregate, what are the trends in B2B software that drive the most curiosity for you right now that attract most of your energy and focus?

Yeah, for sure. Um, you know, it may not surprise you to hear this, but like as, as a product manager, the product is probably the first thing I look for, um, when going to different companies and It's, you know, maybe not a new trend, but particular, maybe even becoming more important is, you know, people want to go buy the best products. It's a very emotional decision when people decide to use or buy a product, and maybe they rationalize it with logic later. And so the, you know, being able to create a product that can be used and adopted very quickly regardless of if it's, you know, a PLG product, DevOps like Cypress, or even a sales-led motion like, like Tropic, you know, being able to put something in front of people that they want to use is incredibly important. And even though Tropic is very sales-led, I think that some of the experience I've had as a growth product manager or even selling B2C software where it's always the individual that's making those choices, has been super helpful to me in, you know, thinking through, you know, what type of software do I want to put in front of people at the end of the day?

Is that trend to play it back like something like product-led growth or like removing friction from the buyer's experience? Like, is that kind of a good playback of the trend that gets you really interested?

I think so. And, you know, even if it's not the buyer's experience, again, product management bias, like I want to ship something that people use. And I think that For me, that's the most important, and the monetization will potentially come. Uh, and so yes, it's super important to have very clear pricing pages for people to understand what value they're getting out of the usage that they're doing. Um, but I think of that as like the foundation of what, um, good products are built upon.

Let, let's shift into monetization. We've, we've talked about your experience in growth and monetization, but maybe kind of What's a good framework if you're talking to a bunch of other product managers, product leaders? What's your framework for thinking about monetization? What is it in B2B SaaS?

Yeah, for sure. Man, I wish I had some sort of silver bullet framework that could solve, you know, all monetization problems. So, you know, maybe I think about it in a couple of different ways. One is, you know, Certainly you never know where a user is coming from when they see your product for the first time. And I think that we get a lot of biases as people working at the company and shipping the products on what people expect when they log in for the first time. So one of my frameworks is marketing doesn't end when people get into the product. People need to be very aware of what things do, what value it's going to provide them and why they should take those actions and why it's important to them. I think that being able to show things like that in the product can just really help reinforce the value proposition that your product is giving to people. It can be super important. Some of the other things as far as like pricing and packaging and monetization go, to me, simple is always better. People need to be able to understand it very clearly. People need to be able to track it very very clearly. And then people need to be able to maybe from a certain extent forecast it very clearly. You're asking people to go to bat for your product for their own internal processes. And that's something I've seen a lot more at Tropic now that I'm, you know, working on a product that literally helps people go through all of these different approvals and checks and budget constraints. And so, you know, being able to arm people with that knowledge and being able to articulate it clearly to their finance leads, their managers, et cetera, to me is extremely important. Again, probably more of a product-centric approach to how we express and show these things in the product. But, you know, these are the things that I work on day to day.

Yeah, but in a world where products like are more responsible for driving revenue, like it's a really great framework. And the way I kind of interpreted your framework was like, hey, a good way to think about monetization is it's this like connective tissue between external messaging about a product's value and then the actual product experience. And another kind of like way to say that might be monetization is effectively, um, I'll come back to that, but I like kind of where that direction was headed. It's really interesting.

There's a consistency about the whole experience that's extremely important and maybe even more so in a remote-first world where You know, you need your SDRs to say the same thing that they see on the website, that the AE says when they're in the first demo, that the user experiences when they get into the app. And a lot of times that can be lost on people and it just makes it harder for them to circle back on like, why am I using this in the first place? What is this doing for me? How do I fight for this tool? Why do I like it? Um, and so, uh, I don't know that that's been something that has been kind of dawned on me in the past couple of years that I maybe would have overlooked earlier in my career.

With that connectivity or that kind of cohesion across the customer experience is actually really difficult for companies to deliver and it's very difficult to support operationally. Why is monetization in B2B SaaS complex for companies to both build and to support as their businesses change?

Yeah, that's a good question. And I feel like not only have I had some experience in just wildly different go-to-market models, open source, B2C, PLG, sales-led as I'm in right now, and then FullStory that probably ran the whole gamut of all of those over the course of while I was there. You know, there's technical challenges to these things and then there's also the internal operational challenges. And the larger you get, the harder that those can be to navigate. So maybe I'll start on the technical challenges. You know, just being able to ship a product and enable, you know, lots of teams to be able to support, sell, etc., is difficult enough. Being able to constantly having to worry about, does this piece go to this package? Does this piece go to this package? What if this changes down the line? How flexible is this? Can be a problem in and of itself. And not only is that on the technical architecture side, but also the user experience side. Do we want to just hide experiences if people don't have them? You know, that is easy to do, but it doesn't talk to that kind of monetization or growth strategy that we're talking about of wanting to introduce people to potentially more higher value things that they could pay for. On the internal operations side, this gets very complex very quickly. You know, you're talking about potential comp plans, potential metrics for customer success organizations on, you know, customer renewals, etc. So people will get, you know, rightly so, very, you know, animated about which, about which products should be in which packages, how much you should charge for different things, etc. And so, you know, not only is there kind of like a large lift technically to handle some of these changes or to do these evolutions, but you also have a very long kind of like approval process of making sure people are on board with the projected changes, communicating very clearly why different changes are being made, and maybe even projecting to a certain extent of what's going to happen when you pull one lever or twist a different knob.

I think those are such good dimensions for why this gets so complex. There's the people problem and there's the systems and tools problem. If we were to isolate on the tools problem for a second, I'm curious if you can tell us a story around one of the companies that you've been involved in around what were the systems that govern monetization? How did they work together? What were the benefits of that setup? What were the shortcomings of that setup?

Yeah, for sure. God, I almost want to think back to FullStory because we had a very custom, I would say, org configuration plan and that, you know, was built like most of these things. They're never designed or planned. That's an MVP that gets shipped out the door so you can sell to your first customer and then just gets tacked on to over time, over time, over time. And so what started as a PLG model then shifted to a sales-led model. You have a tool that was kind of built to, you know, take people's Stripe credit card fees and turn on an org automatically to, oh, now we have a very complex and advanced sales org that's selling multi-year deals, different discounts, different tiers across different plans, et cetera. So I don't know, some of the initially, like the biggest challenges we faced are, you know, trials in a PLG world are very well-defined, very, very strict, and they get turned off automatically after a certain number of days when someone signs up. Trials in a sales org are completely under the behest of the AE at times until you get more sophisticated. And so some of the challenges we found were just, wow, there's some orgs that are, you know, still in trial for this package or this plan or even this whole org entirely, and we forgot to turn it off after months. Um, you have problems with, uh, people are selling, you know, multi-year deals that automatically tier up to a new plan at the end of year 1. But someone has to then go remember to actually tier it up because their system's not built to actually handle the complexity of sales deals that are sold. Um, so I don't know, that, that was a good example for me on something designed as PLG that then added a sales motion on top of and how the two different systems have wildly different needs, um, and different scenarios that need to be accomplished. Um, but again, No one's— there's no product team that's working on your org configuration page. And so these always create challenges down the road.

It's such a good story too, because like, I think it speaks to why monetization is complex. Monetization is complex because like inevitably you end up supporting multiple go-to-market motions.

Exactly.

Then you've got to figure out like tons of different ways to both provision customers in the app and also like build them correctly and support, you know, and then like, let's say you layer on top of that, like different billing models or like another product or, you know, et cetera, et cetera. It starts to get really complex. I want to see if we can do a little bit of a thought experiment here. If imagine we're in a room with 20 product and engineering leaders and we can give them some advice on how to build monetization infrastructure, like the actual components that they will need to consider so that they don't get dragged down or bogged down in the quagmire of systems complexity as their businesses scale. If we could run that thought experiment, like, what do you think are the services that they need to have in place from an architectural perspective? And the reason this question is really interesting for me to ask to you is because the more people I talk to, the more there just doesn't seem to be a pattern. So product engineering leaders are often just like reinventing things recreating the wheel, trying to figure it out, but there is no pattern. So if we were to try to create a pattern from a services perspective, what would be those services based on your experience?

Yeah, well, I'm glad you gave me an out that there's no right answer on this one because it's definitely hard. Again, as a product person, I'd probably go back to— God, it's hard to build a general system. I immediately want to jump into, well, what is the company's go-to-market motion right now, what type of product is it, how are people purchasing, you know, what they're selling. But if I had to think of some like kind of key things, you know, some of it is just visibility. Can people quickly understand which orgs— I keep saying orgs— but which customers are on which plans and which features they have, you know, available to them at that time? I think that there might be a second point that's about control. So how can people across the app, whether they're in support or sales or product and engineering, change the groupings of different features or the different plans that orgs are on in an elegant way that, you know, does not affect orgs that need to be on other plans or new plans that are going to be created in the future. And maybe, God, I almost think a last point could be leverage of like, how could we create this new monetization plan in a way that benefits our company? So that could be whether it's flexibility of allowing customers to purchase or add on different things from the app itself or from sales to be able to quickly add them in. It could also be, you know, how do we enable our human go-to-market processes? Like, I'm going to give you a 14-day trial of this specific package. And at the end of that package, it's automatically going to come off of your system. And we'll have a record of that so that we can see it. And, you know, maybe even we'll be able to tell from some sort of analytics of which specific features of these packages were actually used during that time. So again, like a bit of a high-level answer and maybe those build on each other. Visibility first, control second, and then leverage of actually making this system like a, you know, a competitive advantage for our company.

Honestly, what you described feels better than high-level and it aligns with some of what I've heard from other people when I've asked that question. But a lot of people describe on the visibility side what you just described, and I've kind of started to call it company profile, like some view of the company that's like a universal profile of what they have access to, what they're paying, what they're being billed. And then on the control piece, like I'm kind of starting to call that more and more just like flags or permissions where the business user in support or product or whatever can like make changes and those flow through to the systems downstream, but also to the product itself. Without having to get engineering involved. And I think the third you described around automation is really interesting because it like gets into— I'm not sure exactly what I would call that as a service, but I want to, I want to call it something like components. It's like front-end components that the user interacts with around monetization that end up just being like excellent experience. That's really hard for companies to produce because like, you know, it's always changing. It's like you got to check multiple systems and you've got to design it really well.

Yeah, no, totally agree. And you're right, I like the way you put the components as that third piece because that could be for your internal teams or it could be for external users. I think both would want to interact with the system in different ways.

Yeah, yeah. Tommy, if you had to, we're in front of that same product and engineering group and you had to say like, look, 2 or 3 kind of things that I think can constantly improve the way you approach monetization. Any kind of top 1, 2, or 3 lessons from your experience that you would share? These are things that if you employ, you will likely get better.

Yeah, for sure. You know, maybe just thinking back on my past experiences, I wish I had been bolder at times on pricing and packaging. So there's, you know, there can be a fear of not wanting to rock the boat or, you know, being very careful about which knobs and levers you pull. But I think that there can be a disservice in not setting up things in a way that you could at least test big different actions in your pricing and packaging. So if I could give one piece of advice or one thing to consider, I would say, you know, do things well thought out, but don't be scared to take big leaps. And, you know, if you need to, you can always find ways to, you know, unwind these different things, particularly when you're earlier in your company history. So that would certainly be one. If I had another one, I would say, you know, I mentioned it earlier, but I think it's so important that everyone at the company has something to gain or lose from pricing and packaging changes. So making sure that, you know, it's everything is very clearly articulated and people feel heard and their suggestions, or you at least, you know, have an understanding of we're doing this change, it will affect you in this way. So because of that, we're changing, you know, this metric that you're supposed to hit because in this, you know, in this new world, it makes a little less sense. So I, you know, I say that just to make sure that, you know, people need to feel like you're on board. And because pricing and packaging changes can have such, I guess, dramatic changes in user behavior, you need to make sure that, you know, that the company is ready for such changes.

It's really good. One of the closing questions I like to always ask is, what was the kind of experience, but really the specific moment in your career that has been most formative or influential?

It's a good question. I think it's hard to, uh, substitute being at a place that's growing rapidly, um, in terms of your own personal growth. There's a lot of opportunity at, you know, a company that's growing very fast and being successful. You learn from the best people. You get to see, you know, what a $10 million ARR company looks like and a $50 million ARR company looks like and all of the changes that happen in between there. So if, you know, if I had to pick, you know, one instance, it would probably be, you know, some of the growth I saw earlier at FullStory. But that's not to say, you know, the growth I saw at the other companies I've been at has been, you know, just as instrumental. It just was probably, you know, multiplied by a factor at FullStory.

Yeah, especially given it was the first time you'd seen it. That's also true. Where can people learn more about Tropic or reach out to you if they've got questions about product and growth?

Yeah, absolutely. Definitely feel free to visit Tropic's website at tropicapp.io. And if you want to reach out to me directly, I'm on Twitter at te_nunnen, um, or, uh, you know, we'd be happy to give you my email address.

Awesome, Tommy, thank you so much for doing this. It was a blast.

Yeah, you too, Fynn Glover Glover. Always a pleasure.