How to Price & Package Multiple Products Right | Ryan Burke

Ryan, thank you for being on the podcast. So good to be with you. Got to know you over the last year. You're a product designer. You've got an incredible background in payments and developer experience. Kind of going way back, you studied interactive media in college. You cut your teeth in the agency world at Critical Mass, and then you moved into product design and you spent 8 years, which I'm sure were really formative, at Braintree before 3 years at Highnote. And about 18 months ago, you joined Pagos, which is an incredibly exciting company in the fintech space. Tell us, tell us the story, the journey, how in your own words, how'd we get to now?

Yeah. Uh, it's great to see you too. It's been awesome to work together, uh, over the past year. Your team is like always super inspiring, just the pace you guys are shipping and going. Uh, I want to take that energy and bring it to Pagos with myself. Uh, so it's cool to see. Uh, the journey, I guess, like when I started, uh, I studied interactive media, which I think at the time basically meant learning Flash. Um, and I thought that's what my whole career was going to be, was trying to win FWA awards, building Flash websites. I think I got to do that for about 18 months before the iPhone killed Flash and I kind of moved on to a new frontier. And at the time I was living in Chicago and kind of working in the ad agency space, doing digital work. And I realized like we were building, like I was learning brand skills and like we were building things, but we never got that customer kind of feedback. It's kind of like you're coming back. You really didn't know if your design was successful or what was going on there. At the time in Chicago, you basically could work at Groupon or you could work at Braintree if you wanted to be a product designer. Like those were the two companies that was kind of the whole scene. So I was like, I'm gonna go to this Braintree company. The design's pretty rough. I didn't know at the time that was an opportunity. It had been built by like an agency previously and they just started hiring a design team. I went over there, I thought I was gonna be there 2 years and like leave. I had no background in payments. I was just kind of like excited to learn something new. And I ended up staying there 8 years. I was there pre-acquisition of PayPal and it really just became this amazing thing where I was able to go super deep, grow a whole design team, ship a ton of products until it was time to eventually leave and kind of get back into the startup space, which is what brought me to Highnote a few years ago and now to Pagos. And it's been really cool to like work at a faster pace with both those companies, you know, and kind of grow, go from seed to Series A at Highnote and kind of, I was like a first designer at Highnote and then now at Pagos to kind of come when they're a little further along and help kind of push things to the next level.

Such a cool story. Take us, take us back to like college or even pre-college. Like what led you into wanting to kind of be into interactive media at the time? Like where was your mind playing as a young person?

I got into like web design building, like I kind of was like following bands. I can't remember the name of it now, but there was like a Radiohead fan site. I was in my own band where I was like building the website. I was much better at building the websites than playing the music. So it was kind of like building my skills that way. In college, I had a roommate where all we would do is code and design all night. We were terrible at coding at the time, but we were kind of just always trying to push through and push each other to kind of figure out how we can just move quick and get to that next level in design. And it just, just keep pushing as fast as we could.

So cool. So at Braintree, I mean, this was like 8 years of your life. It was, it's a big chapter. In your career. Um, can you, can you just maybe reflect on like, what do you take away from those 8 years as like the, the most important things that they did for you and your career, the most important things that you learned?

Yeah, I mean, I'm grateful for so many opportunities there. A lot of the folks, both Highnote and Progress, that I work with are all people I met at Braintree. I mean, I got to work with some incredible people over the years, and I keep a very tight network. I, I have a friend who's like, you know, you can work with people that didn't work at Braintree, but it's just like, I think it's a lot of really good people that were really good at their jobs and are really fun to work with. But I mean, I started And I, they gave me the opportunity to really learn product design. That was the first place I ever broke production. I kind of just like really go for it and they had a lot of trust. I worked at a really talented team that's gone on to do some really cool startups, work at Apple. Everyone that kind of worked there on the design team has been able to kind of go do something else that's also very cool. Like being able to work with that team was amazing. I eventually kind of got the opportunity to manage and grow that team. So we went from like 4 designers up to 16. I think I was like managing 12. I did that for many years. It was kind of just like like, I think the whole company went from about 100 when I started to 500 or 600 in the end. So to go through that hypergrowth is just like, you can't, until you do it, you don't understand like the lessons kind of along the way as far as like where you might slow down as a team, where you gotta keep pushing and just how you try to like bring people into that culture to still move fast as the company scales. So I think that was a huge, a huge takeaway there. I also learned like doing just pure management is not my thing. Like, I'm very grateful for all the designers I get to do and work with and manage over the years, and I still manage today and I'm passionate about it, but I really need to be building. I cannot just do, you know, management meetings and go advocate in a room. Like, I'd rather just go build it and push it. And I think that was towards the end of my time at Braintree. I worked really closely with a few engineers where we were kind of more responsible for building out like prototypes and spinning those into new products. I think that was a time where maybe the velocity at that company had slowed down compared to where it had traditionally been. And we didn't really have the foresight to where things should be going. So an example would be like, maybe Braintree should expand into in-store payments because, you know, we have these logos on our website and I can go to the physical stores of those customers and we don't offer that product. Like, where are they maybe going to churn out or go to someone else because we don't have that? Um, so we kind of put together the prototype, order some hardware, build it, integrate it with the stack. And then go kind of shop it around internally until we can get a team to go spin and do that. And then it was kind of off to the next one. It's kind of fun to see. I think some of those projects are still going many years later. Yeah. So I think it was like the full range from individual contributor to manager, back to individual contributor all over again.

That's such a cool 8 years. Like one, one thing that I've kind of thought about a little bit, maybe a little bit more than a little bit, I'm curious to see if you've thought about it much is like the difference between managing artists, creatives, designers versus engineers and sellers. And there's just kind of different management skill sets that people use in those contexts. I'm curious the extent to which you've thought about those differences or had to apply differences in the way you learned to manage at Braintree.

Yeah, I think one of the biggest challenges with like managing a design team, or I think the same is true for product managers, is, you know, if you're an engineering manager on a team, you're probably going to stand up with that team every day. You probably see all of your directs or most of directs every single day in meeting settings. Where when you're a designer or product manager and you're managing many folks, it's like you cannot be in all their meetings because it essentially spans the whole company, right? Like anything that involves design. So I think one of the biggest challenges there is like, how are you actually getting good feedback? Is it that the engineering person or the product manager doesn't know how to work with a designer? Or is it really that the designer on that team might be struggling and you're trying to figure out how to orient that? And then you have the same challenge of like, how do you try to manage that situation if there is a misunderstanding when you're not there every day. Like it's just really hard to get a pulse. I think that that becomes a really, a really tough part of it. And I also just think that maybe I've just been very lucky with the designers I've worked with, but I think designers are just naturally pretty huge optimists. Like they're always fighting for what they know the experience can be. I think that's like very rewarding to always be working with, but also it can be like a challenge when Maybe we don't always achieve that when something hits prod, maybe it's a little bit different. I mean, there's a lot of memes of like what the Figma looked like versus what prod looks like. So yeah, I think that's like one of the hardest parts about it.

Take us into HighNote. So HighNote was after Braintree, before Pegas. I think a really interesting part of your career. You know, you were kind of there from very early on. So tell us about it. Tell us about that experience.

Yeah, I think, I think this is a lesson maybe that I took away. I don't know if it's unique to me or if this resonates with anyone else, but like For all the years I was at Braintree, I spent more time managing than kind of building out those new projects at the end. And everyone that wanted to work with me after Braintree only knew me from doing the projects. They did not know, like, my brand is like a manager or whatever the case, like, no one frankly cared at all. I think they're just like, that was a, yeah, he's the design guy or whatever. But like, that was it. I think when people realized that I could spin stuff out and I can ship and move pretty quick, I mean, the same engineer that I worked with on a lot of those projects, his name's Corey. Like they brought both of us over to Highnote on the first day, like the first official day that the company was there. I think there was 6 of us on like kind of that first day. The founders did some work ahead of time, obviously. Um, but we kind of started there and I mean, there was literally nothing. There was not a repo for the front end. There was not dev documentation. There was not APIs. It was just like clean slate. Where are you going to go? What are you going to build? And I think like that was, I just couldn't say no to that opportunity. It was incredible. The space was also very exciting. It's Highnote does a card issuing platform so that other startups or companies can launch their own, like kind of branded credit or debit card. And I'd been on the payment processing side for so long. So to be on the issuance side was just like a totally different flip, a great opportunity to learn. But yeah, it's definitely terrifying after you've been in a company like PayPal with 20,000 employees for 8 years and everything's kind of baked together to be like, we don't even have a repo to commit to. Like, where do you start? That was a change.

Walk me through why you made that decision to go from such a large established company back into really early stage.

I was definitely addicted to building and as fast as the prototyping and stuff was going at PayPal, I mean, like we were kicking out new stuff every week or two. That was rewarding, but it wasn't becoming real or not becoming real fast enough. I mean, some of the, the, like I can go, I mentioned the in-store example, I can go to a mall today and go pay on, you know, the project I helped build there. That's great. But it just would take so long to realize that. So the idea of kind of spinning something up and getting folks using a new product and to really have that greenfield experience, like that's, you got to do it. I think that probably resonates with you too. But yeah, it was incredible.

So Hyno has grown into a really nice size company. It's grown really well. I think this is the period in your career, correct me if I'm wrong, where like you really started to care a lot about developer experience, but tell me if that's off kind of from—

I mean, I really, that was like a journey at Braintree where I also like did dev docs. I did SDKs. I was involved in our dropping UI. We did some, a lot of interesting stuff around checkout very early on. But I mean, my Braintree journey started where I still remember my first year, someone's like, no, the client does this and the server does this. I mean, that was my starting point. And then we got to really advanced stuff in the docs and all that. But I think, you know, at Braintree, we were kind of working on like, well, there were REST API, change managers were hard. Braintree has an incredible policy on backwards compatibility, but that also, like, from working on a perspective, makes things more challenging. So you go to Highnote, it's like, we're going to spin up a GraphQL API. We're going to build new, new experiences where we can run all the code end to end and the documentation, that kind of stuff was, I mean, that was just like, we can do all the cool things that were really hard to do before.

Cool. You were there for about 3 years?

Uh, almost 2.

Yeah. Almost 2. What do you look at when you look back at that? What do you kind of view as the key? The key learning, the key takeaway, the key lesson?

A key lesson is if you get the technology choices and like the major decisions that are going to be the hardest to change right up front, things just be way easier. That was like when we stood up, it's like we had the stack that we chose. And even now I've been gone for a year and I still stay in touch with people over there. No one's sending me nasty text messages to say, Ryan, why did we choose this service? It just— the iteration speed was so much faster when you start from there. I'd also say when you put the tools in place that allow the team to move fast, some people make fun of— I'm a huge Vercel fanboy and it's like, we set it up so that we could do CI/CD and we can have a frontend team that's deploying 25 times a week. And when you do that and you take away all the barriers to shipping quickly, your team is just going to ship really, really quickly. And being in other environments where that wasn't the case, I mean, the tooling and the messaging that that sends makes a huge difference. I'd also say just like when you're growing that team, I mean, we grew from, it was 2 of us to we had, I think 12 kind of working on the front end by the time I left and kind of grew in the 2 years I was there, it was 6 of us to over 100 by the time I left in 2 years. It was crazy. But it's, it's very like if you grow the team in a way that you're teaching the right practices, like we value speed, we value not taking production incidents very seriously in fintech, like that kind of stuff, your team will just run with that and they'll reflect all those awesome skills that you want the team to have. Out. I think it's great.

Can you, can you dig into maybe specifics specifically? Like how did you promote a culture of speed? What are things you do? You know, I mean, lots of people do different things, but what are the things that you do?

Yeah, one that we did, and this was like kind of a really silly thing when I started it, we as a team, I was like, every Friday I'm going to write a weekly update and publish it on an internal blog. We were just using like Confluence at the time. But the update had a very clear structure. So at the top, it was always, it eventually, I think it was the highlight of the week when we started, when we changed the company name to HighNet, it became the HighNet of the week. Like that would be on there. And there was always a GIF. And the thing was like, it had to be in production to put it in the update. So basically by saying every week we're going to have this major thing that went to production at the top of this, that's like, okay, we're shipping a major feature every week. It's just implied, right? And then everything else underneath that, we'd have usually 10 to 20 additional, maybe it was a small bug fix, maybe it was secondary features, right? What started to happen is like the team would compete for like, who's going to have that high note? Maybe some weeks we had two because like people were kind of going for it, right? Like that kind of thing. We also just put core metrics that were important to the team at the bottom of every single one of those updates. So we'd be like, our target is our P95 for APIs at the time, I think we're 750 milliseconds or something like that. We would just publish that P95 every single week. We would say, this is how many new customers we onboarded every single week. And when you had a rate that you missed, you know, and we didn't miss the P95 or anything often, but like if you did, it felt horrible to write that down. Or if you're like, I don't know what our high note is this week, or I'm struggling, like I'm kind of, you know, fudging it a little bit. Like you don't feel good about it as a team and the team can talk about that. And if it happens 2 weeks in a row, it's like, what's going on? We have a problem. So I think that it's like finding ways to drive accountability in your team and drive that out to the rest of the organization and keep everyone else in the loop of what your team is doing is, is like the best way to be like, okay, we're still on it. You know, cause I think we've all been parts of those projects that's like, oh, we're gonna ship soon or whatever. And it's 3, 4 weeks later. If you're writing it down and pushing it out, it's just, it's a huge culture shift.

Yeah, that's such a good one. Okay, so couple years at Highnote, lots of growth, then you go to Pagos. Yes. Why do you, why do you decide to go to Pagos? What attracts you to this company?

I love Pagos. So I mentioned when I went to Braintree, I had no interest in payments. By the time I left, I was obsessed with payments. I absolutely love it. I love the depth of the problems. I love that the problems don't get old because they're so deep. That's why I went to Highnote. And I knew a lot about payments at this point. I've been doing it for over 10 years. I've been involved in some very hard challenges. And the co-founders of Pagos, Klaas and Albert, They're two people that just make me feel like I know nothing about payments all the time. Like they are just in a different level. I'm like first day back at Braintree. I don't know what I'm doing because they're that good. And I was like, this is the way to kind of really push myself further along in the stack. I also think like I'd done so much developer experience, so much B2B, like both Braintree and Highnote were like, okay, a customer has an API. They make a call, we show it in a dashboard. But there was really kind of no growth levers that you were really throwing in that kind of way. It's like the more people use the platform, the more, you know, the numbers of my team went up kind of thing. Where Progress is like an analytics tool, there was a different way that we had to deliver value to customers in different ways that I had to make the product valuable in a way that I maybe wasn't challenged to do in the past. So the combination of like working with the founders, really kind of closing this payments analytics gap, that's a huge problem in the market. And then like kind of having a new space and a familiar one at the same time was undeniable.

Really cool. Okay. Can you tell us a story about like an area where you kind of went back to elementary school and now you're back to high school or middle school or college, like one of those stories where you learned a lot over the last year and a half? There's—

I think there's a lot of those. I mean, I think one is I think payments is oversimplified. Like people think nowadays, like you go to a Stripe or whatever the case is and your payments are kind of done. And the payment space is truly so much more complicated than that. The biggest merchants that are out there, they're using many payment processors at one time. Those might be because of different market needs. They might be because they're contractually negotiating that, like, I'm going to send you this percentage of volume to get this rate to you, and then I'm going to do it to the other. They will flip on and mess with processors just to scare them. Like that, I remember that happening at a past life at a payment processor where someone was like, we just dropped the volume because we're mad about something you, you all did. So I think like going into when I started Apagos and being like, oh, customers are really routing at the BIN level, the BIN being the first 8 digits on the card. And they're saying this is an Amex that was issued by, you know, issued here, or this is a Visa issued by this bank. And they're choosing which processor to send cards to based on that kind of granular information. That's just like wild. I mean, I think it's like that, that is much more complicated than the, just go use Stripe or whatever the case is. I think that the people assume payments is today.

What about the payment analytics gap? Talk more about that and talk more about Pagos and like what the, what the company can do when it achieves its vision.

Yeah. So I think Pagos in general is really great for a lot of the customers or merchants out there that are using these kind of multiprocessor setups and that they have teams that are like really kind of focusing on payments as an opportunity area. So I mentioned kind of some of these companies have multiple processors, right? So you're going into the Stripe dashboard, maybe the Braintree dashboard, the Adyen, maybe using Chase or BAMs, Bank of America Merchant Services. You can't even answer in a meeting what your approval rate is or what's driving your chargebacks or even what your chargebacks were. So Pagus has a few different components to the analytics side. Like one is we pull all that information together. And a transaction looks different in all those processors. A Stripe transaction object is different than a Braintree transaction object. So we take all of that, we harmonize those transactions to look the same and make it so that you can actually do apples to apples comparisons. And you can start to answer very quickly, what is my chargeback rate? You know, why are we getting these chargebacks? Why are we getting these chargebacks by reason? Break all of that down. I think the first part is just like, where do we actually stand as a company? And that benchmarking aspect comes in as like the first part. Then we also kind of layer more advanced tools on top of that. So we have like observability where we're just going to start proactively looking like once we understand your processing, I think a lot of people are familiar with like engineering observability, but like, why did your approval rate drop last week? We're going to let you know about it and investigate. And usually it's some kind of thing based on a segment. So it's not just like Visa had a bad day. It's like Visa had a bad day in Canada, you know, and breaking it down that way. So we open all those segments to visibility that you didn't have in the past. And then we do have developer tools as well that'll help you essentially boost those numbers. So we have like an account updater tool to refresh the card credentials if the card expired since the last time someone tried it. You can make a real-time API call out to our service, actually pull in the new expiration in real time in the transaction, which then goes back to boosting the analytics on your page. So it's kind of the benchmarking, the monitoring, and then a bunch of tools to improve all those metrics on the top line.

Very cool. So is it fair to say like you guys are selling into big merchants who are using multiple payment processors? You're largely entering with, you know, basically kind of solving the analytics gap when you're using multiple payment processors, but then you've got multiple products that they could also go buy to solve observability problems, benchmarking problems, and we could carry on down that list. It'll be a multi-product offering.

Absolutely.

Yes. Cool. I want to dig into what that means from a pricing and packaging perspective.

Yes.

But before we do, maybe one last question. I mean, you know, you've been at the company for about 18 months. What have been the, you know, besides some of the incredible learning, what have been some of the biggest surprises, things that have really surprised you about the market, about the space?

I think the market, the fact that it's really hard to answer a question like how many transactions were attempted last week across all your processors. I think that's surprising, right? That seems like a very easy metric. I think number like Payments numbers seems like something that should be easy to get. They're not. So I think that, that part always blows me away that even that there's so much value just in doing that. And that's like the very baseline of what we do. I think the other is just the, like how varied the sophistication is across customers in this space. We have amazingly sophisticated customers. And then even within that, there's like a gradient of different, you know, attention, like what different merchants care about or where they're focusing or where they're seeing the opportunities. It's just the depth of payments in that, in that way is crazy.

Yeah, it's interesting. Okay, so, so to pricing and packaging, I mean, I think, you know, I think one thing that we could obviously agree on is like how companies go about designing pricing and packaging has a massive impact, of course, not only on kind of their ability to sell and grow, but also on internal operations.

Mhm.

And I'd love for you to maybe just start off by kind of describing a little bit of your own journey with pricing and packaging products and thinking through that and kind of maybe sort of like give us a little bit of the high level about what you feel like you've learned on that front. And then maybe we can start to talk a little bit about the journey that Pogos is on with pricing and packaging.

Yeah, it's, it's interesting for as long as I've been doing this, some of this pricing and packaging stuff is very new to me. Like if we look at Braintree, that has like a Stripe type model where you pay per transaction essentially, and there's enterprise tiers based on volume. That's kind of like the original usage-based pricing in a way almost. And then Highnote was the same way. It was like if you ran transactions, Highnote collects some of the interchange, off each of those transactions. It was also usage-based in a way. So Progress has kind of really been the first time that I've been exposed to how are we going to roll out this packaging and pricing? How do we use this potentially as like a growth lever? And it's kind of like starting up hard mode because we have all these multiple products that are very hard to manage. And I think some of it might have been skimmed over at the start of the company, right? So we don't have like, it was not super automated before I kind of came in. So we're like working through and that's how we met is like, how do we go ahead and make this in a way that's more self- service, it drives a higher average contract value through upsells, that kind of thing.

Yeah, because like in a, in a multi-product world, pricing and packaging becomes more complex. And a lot of that complexity often falls on product and engineering to figure out how to support, how we're going to build for this. So there's kind of like, I often think there are kind of two sides to this question. There's like, what is the strategy? How will we price and package across multiple products? And then how will we operationalize that and implement that in our products? Walk us through maybe just a little bit of the journey that Progress has been on. Like what has changed? What have been the learnings? Maybe take us back to the beginning when you got there and what you were noticing and how, how things have evolved.

Yeah, I mean, even before I was there, I think the original, cause I, I've know I've been very familiar with the company for a long time. The original products, each product had its own website. Like there wasn't even like necessarily like a way that was all tied together. And then that manifested itself all the way into the product. So like the leads were separate. Then the products were separate. Like you would kind of jump between various products one at a time, like the whole UI would kind of shift. So the biggest thing that we've been focused on is we realized by having the multi-products be too separate, it was really hard to cross-sell. We were actually getting amazing adoption across many of our products, but that was also creating a poor user experience, which is how I got kind of more involved there. So the first thing was kind of like, how do we wrangle this down to like definitely one set of credentials, one login, and then we can serve up kind of the appropriate UI as you get in there. And I think it's been a lot easier thinking of it as like you're kind of, there is a base price kind of to just use Pagos. And then we figure out how we price and package the rest of the tools on top of that kind of base buy there.

How do pricing and packaging strategy decisions get made at the company at this point? Is there like an internal pricing committee that's meeting or is it, is there kind of some function in the business that really owns this?

Tell us a little bit about that. Yeah, it's kind of been, I work very closely with the commercial team on this. Like I definitely am more on the implementation side. Like I'm definitely out setting numbers and all that kind of stuff, but the commercial team has been selling very successfully for several years at Pago. So we're kind of taking the learnings of what's been kind of these bespoke, more enterprise deals over the years, trying to better understand by comparing data that we're getting in post-hoc and some of the feature usage, like what are the value drivers and kind of like informal cohorts in the app to see like, how can we break some of this out? And then I'm just kind of obsessing over it from the UX side of like, how is someone create the account? What does that sales motion look like? And then how do we enforce those entitlements once we have them kind of on a plan and upgraded?

Yeah, very cool. It's, it's kind of a nice position to be where like there's been a successful enterprise sales motion that's taught you a lot about market sensitivity and different product receptivity and what could be add-ons, what could be upsells. That's, that's a really nice position to be in.

It's very nice, but it's also, this is like a challenge. And like, I think for anyone that's like, I mean, the challenge is when, like, when you start that way where everything is bespoke, there is not like a great way to enforce entitlements. Like everything, like, like currently we enforce through like some things are in like a metadata on a company or a user. Some things are now feature flags. I think we have a third method. I forget what it even is on how we're enforced. Way before I was there. And it's hard to now standardize all that because you have all your customers that are now using the product in a lot of different ways. It's hard to even design a migration to a more formalized system because we don't, it's like, there's not even a baseline for where everyone is. It's almost individual. You kind of have to try to go look at it and like, are we going to round up and down or like, what's the plan there? I feel like we definitely made things harder on ourselves than if we would have approached this potentially at an earlier stage in the company.

So it's like it's hard to normalize and rationalize SKUs effectively and you end up with like a bunch of cohorts of one, for lack of a better term.

Yeah, yeah, absolutely. And it's, it just, it's almost hard to explain it. And then it's like also hard for folks to track internally. Like, how do you even know what's the source of truth for what all these customers are on, that kind of thing. So we have a great path forward, really excited about it, but it's It's one of those things that's like, if someone's just starting today, I would think about this sooner rather than later because otherwise it's going to be a lot harder with a lot more people involved down the line to try to straighten it out.

Yeah. How do you think, I hear some people describe this type of problem as like commercial debt. It's like a type of tech debt, but it's also like a type of commercial debt. Like how would you, how would you kind of explain it to folks?

I think it's, I think it's absolutely both. I think it also just the drag it creates, assuming a company has customers is like, you have to both be careful. In doing this, but also it's not a thing that you later do when you're super successful and I've hit $100 million ARR, right? Like you're kind of doing it at a stage where you have just enough customers that the migration and like cleaning up is annoying, but not so many customers that like it's, you can't do it. So I just, yeah, it's hard to kind of, it's just unraveling this kind of ball of yarn to get it all straightened out.

I had a friend recently who ran product for a number of great companies. He's not a founder, but he kind of described it as like like knowing when to pour the concrete is really hard to know.

Yes. Well, I think there's always this fear too. It's like you're going to write things down, you're going to price it and you're going to publish it. And I think all of us work on our companies so many hours each week and each day that we think everyone's going to like catch this change, you know? And I have another friend that's a founder and he's like, we've had our pricing published since the beginning and I still get asked for the pricing after every sales call. Our customers just aren't as invested in consuming the materials that we put out there, I think, as we, assume they are.

Yeah. Misconceptions, and I kind of use this word intentionally, but like, are there common misconceptions that you see particularly product and engineering teams make when it comes to pricing and packaging? Maybe they're not. I mean, maybe it's easier to think about this through the lens of best practices versus mistakes, but I'm interested if you've noticed misconceptions that are, that are relatively pervasive.

I've been mostly on the enterprise side, like dealing with very big customers for a long time. But I think one, I've always seen a hesitancy to see, to kind of just put something out there that's self-service. I think folks think that big companies are not going to go ahead and just sign up. And I think it's underestimating, like in the payments analyst example, like, is there going to be a single analyst who has a Hack Friday that's mad that they can't see their approval rate and they're going to sign up and they're going to go do a demo and maybe their boss is going to see that and say, wow, like I didn't know that we, these kinds of tools even existed, right? I've even seen that, like, not on the packaging and pricing, but like the doc side, I've seen companies companies hesitant to publish their documentation or like we're going to underinvest in a sandbox. I think there's a lot of underinvesting in DevEx being very similar to underinvesting in pricing and packaging where it's like, who's actually going to go end to end and kind of go play with this? And I think it's just, it is underestimating the people with pain points that are your end users and their ability to advocate up in their organizations to say, we should go buy this tool or this can unlock some new value for us.

That's super interesting. The docs comparison, I love. That's a place that we could probably kind of think about. That's cool.

Yeah.

You, by the way, I do want to segue for a second because the first time I met you, I feel like I remember hearing you describe a real interest in documentation. Maybe I'm misremembering that, but I kind of remember you talking about documentation. Is that true? Is documentation something that you've thought a lot about and invested a lot of cycles in?

How do you think about documentation at this I'm pretty obsessed with documentation in the whole, like, it's not making it up. Yeah, it's truly the source of truth for every company. And I think there's so many different lenses that it makes your product better. If you can't write documentation about your own product, your product is probably very, very hard to use. I think like that's where my true love came from it from a user experience perspective, because if you can't concretely say this is how you're going to sign up for an account and make your first API call or whatever that first magic moment. Is in your own product, your product is not good at that point. That's just the truth. I think it also exposes, like, if a team is kind of being lazy in the way they're rolling out a new feature or a new migration, if they can't explain to you in a way that makes sense to write down, that path is also going to be a lot of pain for customers. It just truly is kind of the general source of truth there. I own, like, when I started at Highnote, I wrote a bunch of the first docs and kind of maintained the documentation. The product managers also did a ton of contributions to the docs there, but I kind of was I was like the main editor for the first long while before we hired a full-time kind of technical writer to really take that on and run with it. But I just think it's like where I can spend some of my most valuable time is cleaning that up and driving that for companies.

That's such a cool, that's such an obvious, let me think about this for a second. That is why I think it's such a good comparison to pricing and packaging because for example, if you cannot articulate communicate basically your value through a pricing page with clarity, there's a real misunderstanding probably of your value to the market, which is like a big company risk. It's like an existential risk. I had somebody once say to me, like, if you look at a pricing page and you really think about it, like, this is the place to most clearly articulate why you exist and what your value is to a customer. And if you can't do it, there's a problem.

I absolutely agree. Part of the way I think, like, if a company wants to get really good at documentation, like another hack that we started at Highnote was like we would do these empathy sessions. I think we learned about them. I think Kelsey Hightower, who's big in the DevRel community, was like one of the first to do it. But it's like, how do you have your customers go, or how do you have people in your company try to complete a task end to end without going on Slack or anything and asking people in the company? So the way that we would like run these sessions is we would do a 10-minute kickoff. We'd say, here's the script. So like if you have that schematic, it'd be like, how do I go from setting up my first plan, assigning, you know, entitlements and traits to it, and maybe like enforcing those. That would be like your new hire way of doing it. You would then give people 40 minutes to go do this on their own off camera, or 30 minutes, and then everyone comes back on the call for the last 20 minutes and essentially just shares what they learned. So they're kind of like publishing Confluence pages or Notion pages that have GIFs and notes and they're sharing that out. And then even if someone doesn't share, the product folks, engineering folks that are core to that product, you go back and review all that and go make the improvements, cut the cards to make it better and ship that. I think there's probably also a packaging and pricing version of this. I just haven't figured out what it is yet.

Okay. I'm going to go think about that. That's a great, that's a great story and tool as well. Okay. One, I do want to just kind of go into the future for a second and pick your brain. Obviously AI is at the tip of everybody's tongue. I'm curious the extent to which AI impacts Pagoos from a product perspective and also how that impacts the way you guys think about pricing and packaging.

Yeah, um, I don't know if we've fully nailed the pricing and packaging side. Like, the part that I'm excited about as a designer and the experience that I can help deliver by using AI there is it could lower the barrier, um, of prior knowledge that someone using a Pagoos tool to do payment analytics has. I have a fishing buddy that ended up responsible for payments at a previous company he worked with. He had like a head of growth role. It's like he was texting me all the time to be like, what does this mean in payments? And it's like, how can I give tools that can help people decipher charts or go further with like, what do these chargeback reasons mean? What's the action that I should take if this chargeback reason is spiking? And how we can put that front and center for the user to, so they can connect the dots faster. Essentially, I think it's like, like, on a very practical level, it's like a better user experience, but it also just, like, grows our addressable market where you're lowering the barrier of prior knowledge to kind of have in there. I don't know if we fully figured out how we're going to price this, uh, going forward. We're kind of more in that stage where we're trying to drive growth in all our tools, and we do have an AI offering in there today, but it's not priced separately in any way, and, and, um, it's kind of worked out for us so far.

One of the closing questions I like to ask on this podcast is what's, what's the moment, like, a very specific moment in your career that you look back on and you go, that was really formative. Like that was a real inflection for me personally.

I remember, I think it was having respect for kind of like when I first learned respect for the users and just like how high stakes is for things for people doing their job. Uh, when I first started at Braintree, um, there was a very senior engineer at the time that was taking like design classes at night. So they wanted to pair with me all the time. It was great. It was like someone very senior that teach me We were kind of a very dangerous duo because like they could get anything done in the stack. And I did not have the experience level at the time to know what was like something I shouldn't be doing. So at the time we had all these fields in a search, advanced search, it was called in our dashboard. And I was like, there's too many options. Like, let's just go get rid of them. There was a bunch, it was like 0.01 users are using this and 0.02 are using this. I was like, let's just go remove all these. Features and it's going to be fine. We deploy to production and instantly the whole support team is coming over and being like, what did you all do? And it's not that people were looking for these fields. What we hadn't anticipated was people had built automated reports off the CSV files. So we were essentially dropping columns and destroying all their automation they had on the tool. So it's like some poor users just trying to like close their books with the payments for the week. The same problem that Pogos is solving, you know, many years later, but they couldn't, we kind of screwed up their whole afternoon and we screwed up the support team's afternoon. And it's just like, then you realize there's always real people using your product. I think it's really easy to look at analytics tools and abstract it, but you have to have that core customer connection and understand all the various ways you can essentially ruin someone's day and do your best to avoid that.

That's a powerful story. Yeah. Ryan, this has been so much fun. Where can people reach out to you if they want to learn more and where can they learn more about Pogos?

You can learn more about Pogos at pogos.ai. We'd love to help any of you merchants, especially with the ones with the more complicated setups. And if you have a simpler setup and we, you know, I'd love to talk to you too and kind of find out how we might have a product for you, whether now or in the future. And you can also find me on LinkedIn. Just search for Ryan Burke, uh, how to design. Pagos. So I really appreciate it. Thanks so much, Simon.

Thank you so much, Ryan. This is so much fun.

Yeah, I'll see you.