Ep. #13, Authentication for Developers with Auth0

Craig Kerstiens: We're back with another episode of Practical Product. I'm Craig.

Rimas Silkaitis: And I'm Rimas.

Craig: This week we've got Martin. I'm not going to try your last name. Do you want to?

Martin Gontovnikas: Yeah, sure. It's Martin, hard last name. It's Martin Gontovnikas. But everybody, even though my mom hates that, everybody calls me Gonto.

Craig: OK. Martin, Gonto. Although I might start calling you "Martin Hard Last Name to Pronounce," from now on.

Martin: I'm sold. However you want it.

Craig: That's awesome. So, you're at Auth0. Can you tell us really quick, what does Auth0 do?

Martin: Auth0 is a SaaS for authentication. They main idea is if you are building a custom application and you need to add authentication to it, whether it's B2C, B2B, B2E or IoT, you can do that with Auth0. We have a set of SDKs and APIs that make the integration very easily.

Craig: Cool. Makes sense. It solves a needed problem. Authentication is not a fun thing to put in place but it's consistently needed. Can you tell us a little bit more on your background? You had marketing there.

Martin: Yeah, exactly. I filled out marketing in there, but I'm not your typical marketer. I studied as a software engineer. I've done that for six years, or something like that. And then I moved to be a developer evangelist. Mostly because I built an open source project called Restangular that got popular, and then I realized that actually in order to get popular I needed to build a blog post, talk in conferences, answer Stack Overflow questions, etc.

I realized that I liked more the idea of making it popular than building it itself. I was thinking, "How can I do more of that without losing the developer part?" So I moved to developer evangelism, and now I've lost the developer part. But that's life.

Craig: That's an interesting background. Because most developers have, I don't want to say a love-hate, mostly a hate-hate relationship with marketing. That's the standard. "Marketing is sleazy, just e-mails you a bunch." It's not as bad as sales. That's an even worse relationship.

Martin: Also they're evil.

Craig: Yeah.

Rimas: I love sales. It's great. Sales is awesome. No? Yes? Maybe?

Craig: Do your developers love sales?

Rimas: It depends. See? My product management answer, right there.

Craig: But that's an interesting background to come from, engineering to marketing. We see a lot of engineering into product management, that's a fairly common line.

Product managers come from all sorts of backgrounds. There's not a product management proper training in school, usually.

You can come from a business degree, you can come from engineering. A lot of it is engineering. But I don't see a lot of engineering to marketing. That'll probably put an interesting lens on it today. We want to drill in a little bit to that.

How do you market based on your audience and segment? How do you bring some of that engineering background into it? How do you market to developers? But also, your audience isn't purely developers. Who would you say your audience is at Auth0?

Martin: Developers for sure. They are the ones who end up using our SDKs, or using our APIs, and they are one of our main selling points. But then the other audience would be a director of engineering or CTO or something like that. What we call a new economy company, like SaaS.

But then in an old economy company IT could be a security or a CIO person. The other side is definitely product managers. That's the other people. We have a big variety of different personas. And at first, we only focused on developers. Now we're focusing on all of them.

Rimas: You mentioned personas. Developing those personas, did you do that in concert with your product management team? I guess I should just back up and ask, does Auth0 have a product management team?

Martin: We do. But the product management team started a little bit later on. They started, I would say, one year and a half ago. Because before that both our cofounders were in the identity business, so they were acting as product managers.

But now we built it ourselves. It was mostly their marketing team, but now we're actually working together on the personas from the product management side to understand how each of the things that we're doing can help them out. But the ones who built it was us.

Rimas: All right. Marketing developed into personas. Has product pushed back on that at all?

Martin: It's interesting. Because they are a little bit separated from that in that regard, from the product perspective they mostly care about the developer that is implementing them. And then mostly the director of engineering or VP of engineering who is more understanding of, "What is the value?"

But in the product per-say, the product management has mostly focused on the developer experience. Something that we're seeing more and more in the enterprise now, these checklists. Where it's feature versus feature, feature versus feature.

And something that our product team is trying to shape differently is like, "It's not about a checklist. It's about the experience. What is the value, etc. that we are providing to them?" So they don't focus that much on their personas on the product level, except for the developer and the people who are using it.

Craig: Interesting. That simplifies it for them, so they've got one. You still have a bunch that you care about, though.

Martin: Yes.

Craig: Can you tell me how that changes your focus, what you spend time on? Because they care about the developer do you care about that less, or do you still have to care about it equally?

Martin: We care about all of them but the developer is our "golden egg nugget," as we call them. Or something like that.

Because they are our main advocates and the ones who then end up recommending us to somebody else.

So something that we did is we went backwards. On all of the deals that we won, that started from a developer, "What kind of people were involved, how, what were they interested in?" And that's one of the things that we did.

And then the other part is that I'm a big, big, big fan of interviews and surveys and qualitative stuff. Something that we also do a lot for the other personas, to develop for, was for example, a LinkedIn campaign where from our target accounts we were just offering a $50 dollar gift card for people in exchange for half an hour with me.

And I was asking them about, "How do you learn on different things? What things are you scared about? How do you search for technologies? What are your habits? What do you do during the day?" That's partly what we ended up doing to build the different personas. All of them are a big focus for us.

Craig: That's a huge tip there. For a lot of people they wait until they have the customer and then they come back and do the interviews afterwards. For example you've been building a product for years, you land one customer, then five, then 10 if you're a high value product.

And you wait until you have 10 and you start doing customer interviews with the ones that are around, you can know your target audience and for $50-100 gift card they'll give you some of their time. You can learn the exact same things without waiting that one to two years before you get those first few customers.

Rimas: We talked about personas a little bit. I want to pull the conversation up a little higher and ask, what do you think of as a healthy relationship between marketing and product management? What's the most ideal scenario in your mind?

Martin: That's a very good question. From us we have two different interactions with products, from one side we have the product marketing team. Which handles the go-to market and sometimes moving from explaining a feature to what is the value. The product marketing team also helps a lot with research.

We would research on analysts, and research on the web on what our customers are saying. Then based off of those we send the insights to product to see if we can build features or do things. And at the end of the spectrum it's like, "OK. What is a big feature? How do we do the launch? What is the PR?" Etc.

The other team that works very closely with product is the growth team. The growth team sometimes is in product, sometimes it's in marketing. They are in different places. In our case they're in marketing and they work very closely with them because of two things.

First of all, the growth thing is very metrics-oriented. They are the keeper of their metrics. So any feature that we are going to ship, they're the ones who take care of maintaining the feature. And then if we see that something is wrong after it was shipped, nobody is using it or people are using it but getting stuck or something.

We, the growth team, push on the product. Like, "Hey, what's going on, and how can we fix this?" It's like a post-feature ship. The other thing that we worked very closely with is the growth team is the owner of the new user expedience. The onboarding, retention, activation etc.

We have worked mostly on the UX part of that, but that's something that we definitely collaborate with products on. Doing user testing, and doing calls for insights and those kind of things, with people who got stuck and people who didn't.

Craig: I'm curious how much of that was timing. Because you mentioned marketing came first as a proper function. The founders were there and doing product management, sort of. It's very different when you bring in a full time product manager and build out that unit. I've seen a lot of growing pains and challenges when it first happens.

But marketing was there, it was doing a lot of these things, you had the growth team embedded in marketing. Was that a nature of timing, or would you say it's very explicit that it's embedded with marketing for you all for some reason?

Martin: It's been an interesting ride. I think it started with growth mostly because I've been talking about it a lot. I was always pushing on the executive, saying, "We need to focus on the retention, because it's about generating habit, it's about people using the product." And because I was passionate about it, it started there.

But we had a lot of back and forth with product on understanding, "How does the growth team help and how does it work?" At first we thought that, for example, the growth team was only going to be a consultant to product and that's it. Then what happened was that we were a consultant to product, but the engineers were working on innovation and they didn't have time to work on onboarding.

And we thought it was important. So I ended up hiring my own growth engineering team to build up and work on those while at the same time the growth team does act as a consultant to product. But product is starting to do more Jobs to be Done interviews, so we're sending some of those things.

Right now we're in this middle ground where we're starting to see where and how we can operate together. What things that the growth team owns, what things that the product team owns, and how well can we collaborate and work together.

Craig: So, talk to you in six months and you'll have it perfectly solved and you can come back and tell us how everyone should do it.

Martin: Of course. And in six months I'll have another problem, and then in another six months...

Rimas: That's funny. I might ask this question, and may be a little contentious here for our product management folks. But I love your website. I'm looking at it right now, Gon.to, if anyone listening wants to go check it out. Your tagline here is "an engineering approach to marketing."

So, from the contentious question perspective, do you even need product management if you have an engineering approach? You can just go straight from marketing to engineering and get things built?

Martin: That's a good contentious question. I like it.

Craig: Just remember which podcast you're on.

Martin: "I love product managers. They're all great. Marketing sucks." No, I think it's a very good question and I don't think that product management will cease to exist.

As time evolves more things are merging together, engineering is applying to more and more things. As time goes by we'll start defining how this collaboration works.

For example the growth team, I've seen it both in product marketing or even separated, like a separate entity that only focuses on growth.

So I think that will definitely continue to happen. And then to me, the most important part for product management is understanding, "What is the space?" Doing the interviews and doing it all from a product background that they have, using theories like Jobs to be Done or those kinds of things.

Where I think we can help more and the growth team can help more is talking to customers on more specific problems or things that we see on things that shipped. Something that I always say is that the product team is working on, "What new features, what new, cool things can we add to the product?"

And the growth team is focusing on the things that were shipped, "How can we make it easier for people to use them? How can we make them retain on there?" But the growth team will never come up with a new feature or the new thing that we should be adding to the product.

Rimas: OK. Let's dive into this a little bit more. You talk about the engineering approach in all of these various functions within the organization. My question to you then is, if an engineering approach requires data and requires measuring and all of that, how do you do that for verticals that are very B2B driven? Because you don't necessarily have lots of data, because you may only have a handful of customers.

Craig: If you're going after the Fortune 100, there are only 100 companies. There's only so big of a sample size. Even if you're giving out not $50 gift cards but $500 gift cards, your sample set is small. How do you get that kind of input?

Martin: In those cases it's really hard. Some of the things that you can do is that some of the things that apply sometimes to smaller companies might apply to them as well. Some, of course, won't. But something that we do, for example in Auth0 we have a lot of different trials.

Some from big companies, some from smaller companies, but we try to focus on retention and activation and what are the insights in all of them and then try to cross-apply between those. Having said that, I do agree with you that with a small sample set it is very hard to drive conclusions or causation from data.

But I do think you can start to draw correlations. And once you draw a correlation you can start doing experiments. Something that happens to us is that when we have a lot of data, that's it. We know what to do. When we have very small data, it's around correlation. And we try to do continual experiments to start moving the needle little by little.

It's like you're a blind person and you're shooting. You are shooting in the dark and then trying to get closer to shooting the bottle, and getting tips on how you get closer.

That data starts happening as you start trying things instead of just using what people are telling you.

Craig: I like that analogy a lot. It makes a lot of sense. I'm curious, do you have any tips from this? Because it sounds like you've thought about this for a while. Someone's new to it, practical tips, where do you start? You've got your B2B, you're going after seven figure deals, and you're focused on one of those the first year.

You may have one potential opportunity there and your eggs are all in one basket. How do you test along that way? Do you have tips for someone as they're getting started in this process? Where do you even begin?

Martin: Yeah. For us what we do is when we have one big bet that we want to do, what we try to do is smaller experiments, basically an MVP that can give us insights on that. For example we've done a lot of interviews lately, and we know that people need some hand-holding on setting up the Auth0 product.

So instead of starting with an onboarding that is interactive that people can fill in fields, it's a customized product edition, we just start with something that is not interactive, like an animation or demo, showing them how to do things. And then if we see that starts moving the needle a little bit, then it says, "OK we're in the right direction. Let's start digging deeper there." But we tried it. All experiments don't take more than one month, two at the most.

Because otherwise you're waiting so much time until you get some sort of result that maybe you've screwed up and you don't know, and you've taken a lot of time to do that.

I definitely recommend doing small experiments and then we use basis in A/B testing analysis, which at least if you can see a 5% difference or something, that is enough that we say, "OK. We're going in the right direction."

Craig: Yeah, I think that makes sense. For a person that's not familiar with running a lot of experiments, making it smaller and smaller and smaller, not trying to be the perfect experiment the first time. Because otherwise it seems overwhelming and daunting and you have to get it right. The smallest one you can run to learn something, starting to learn is key.

Martin: We do everything time-based in experiments, because before we were telling the UX, "We need the best experience for this." And then it was taking like two months. But then if you make it time constrained, you have two weeks to make a good enough experience. That works better.

And then the other struggles that we had was working with design, because they are pixel perfect. And the idea of an experiment is that it's not going to be pixel perfect. It's something you've got to ship, and then if it works you are going to improve.

So to us it was also working on that. It's not going to be perfect. It's going to move us on towards the direction, and then you just keep on pushing and pushing and pushing on that direction that you find.

Craig: Yeah. It sounds like shortening and having that time constrained experiment is good.

Martin: Yes.

Craig: Is your perfect time right now two weeks? Or what is the time frame, and why is it that time frame?

Martin: For UX in particular we do it in two weeks so that we have time to do exploration and it's not just one week. But if it takes three weeks or one month in our experience, we started to have a lot of conversations on getting deeper into a lot of opinions from everybody, and then it took forever.

The other thing that definitely helped us on that was having a RACI model, like the responsible account that will consult and keep them informed. Because being a remote company everybody has an opinion, and if everybody has an opinion all the time you never get shit done. So it's around, "We get opinions, but you're making the decision. And at some point we're making that, because otherwise the experiment is never going to end."

Rimas: If you haven't told from this conversation, we're both very much data people. So we're driving into this fact and trying to understand the parameters around this. I want to shift the conversation just a little bit and talk about more strategic situations. The question I want to pose is, how do you extract a business value from anything that you're doing while not alienating developers?

This is a situation that we deal with at GitHub day in and day out, because we really love and foster our open source communities. They're special and we want to see those communities thrive. But in the same token, we also do have our enterprise business. How do you balance the two from your perspective?

Martin: I don't have an answer yet. That's something that we're definitely working on and improving on all the time. I think that being able to target both the developers and the enterprise is hard.

And at first, I remember our first try was adding an enterprise page, and then we were like, "If we have an enterprise page that means that we're not enterprise and we're trying to convince people that we're enterprise." So we've removed it, for example.

It's an ongoing iteration. And at least for us, the two things that we've decided so far is that we should make the home page have appeal to both developer and enterprise. Something that we do is like, the hero appeals to both, and then we have one section, developer, one enterprise, one developer, one enterprise, etc.

And the idea of that is that people can self-select themselves on, "What section am I interested in?" And digging deeper, and we do the same with the header and the navigation. Like, "Solutions" section.

I'd never expect a developer to go into a "Solution", because they don't care. They would probably go to a "Product".

They will never go, for example in our case, to "Why Auth0?" and see the "About" and the press releases, but they will go to the documentation and blogs section. So what we've tried to do is without asking them who they are, you are showing them the different information that is clear, and they can self-select themselves on one area or the other depending on what they are interested in.

Rimas: If I may ask, how has that transition been? I assume that you started in one place, maybe just appealing to developers, and now have gone to this approach. Have you noticed a considerable self-selecting or more traffic, or whatnot? I'm not sure the metrics you are using to judge success.

Martin: It's interesting. We don't have that much more traffic to the enterprise pages, we actually have a bit more to the developer ones. What we have seen is that people that go through enterprise pages like the "Solutions" are more likely to submit a doc to sales. They are more likely to send a form fill.

So what we did is we went back in time, we rewrote blog posts, we rewrote a lot of content so that it links there. But the reality is that the enterprise content has helped us mostly for two things. One is optics. People get to the site, they go to solutions, they see a retail or they see application modernization and they say, "Oh. These guys focus on what I do."

That's definitely something that has helped us. There's not a particular metric for that, but our sales team tells us about that all the time. And then the other part is that for our outbound campaigns, when we send e-mails or direct mail or a call, or whatever. We mention all of them and then we truck, and they are very useful for those outbound conversation.

Maybe not as much as for inbound. But even when we were talking to a more enterprise persona, like a product manager but from an old economy company or maybe a C-level, they really didn't go to the website much. So it wasn't that important for that, but it was important for when we were sending it outbound because then they were clicking on there.

Craig: Cool. That makes a lot of sense on the website having content for both, it reminds me of one thing that Twillio did that was super, super clear. I forget exactly what it was, it's not on their website anymore, but I loved it at the time. I forget which direction they went. But they basically said, "Are you a developer? Click here." Or, "Are you not a developer? Don't do engineering? Go here." Like, self-identify. People seem to do that very freely and very willingly.

Rimas: You don't think that's too jarring? By straight-up asking, right up front and saying, "Are you either?" Maybe I'm both.

Martin: That's what we thought. We didn't put that because of that. We had the technical and non-technical and we were having people like the VP of engineering saying, "Am I technical or non-technical? Because I know how to code, but I don't code."

Craig: But at that level all of the VPs of engineering I've talked to, they don't get alienated by either side. In that role you're experienced with both. You talk about ROI, you talk about, "How do I not have my engineers do certain things? How do I outsource certain things?" I had this conversation regularly with VPs of engineering.

They'd say, "Man, I used to code. I don't anymore. I love this blog post that was on this engineering thing, but the meanings I'm in and the conversations I'm having are completely different." It doesn't actually alienate that person, but the person that does get scared away saying, "This isn't the product for me," knows where to go and self-identify.

Rimas: OK. Fair enough. So, I want to ask a question about the developers sign up pages. Can you give me some context as to what that work was like initially, and how you transitioned to where you are today?

Martin: For us what was interesting is that approximately three years ago or something like that, we were flat on sign ups. And by using this engineering approach we started to run small experiments to start acquiring more users. I remember that at first we said, "Let's write more blog posts about Auth0 on what cool things you can do."

And then we'd run the experiments three weeks, we wrote six blog posts and then we wanted to see a result. And when we saw the results we saw that we had more page views but we didn't have more sign ups. When we dig deeper, we saw that the page views were from people that were already using Auth0 and they wanted to learn more. So we said, "This strategy doesn't work. Let's try another thing."

Craig: So you killed doing any sort of content going forward, right?

Martin: No. We killed all of the content that was around Auth0, and we started to say, "Can we do a greenfield content? Can we write, for example, how to do authentication with React but without Auth0, in general how you can do it. And then a small aside, "You don't want to do this. You can use Auth0."

By doing that, again it was a three-week experiment, we didn't have that many page views but we did see that the conversion to sign up was bigger. So we said, "OK. We need to dig deeper in here, but what can we do?" It was more around, "What type of experiments can we do?" We started focusing on SEO for particular keywords.

We started focusing on what is our distribution list. We also started to focus on doing bets for frameworks. For example back then, like four years ago, when JS was starting up we said, "We should bet on AngularJS. I think it's going to be huge." So we started going to conferences, for example, and talking to people who were talking in there.

They were the creators or the maintainers at Angular. And then by building that relationship they were sharing our content, because it was good and interesting content. That increased our distribution. It was basically around doing lots of experiments on how to distribute, how to create that content and what sort of things worked. And by that we were able to grow 30-35% a month on sign ups.

Craig: I'm curious, how long is someone in your pipeline? Does someone read a blog post, sign up, and then become a customer in two weeks, or how long do they read? Because it makes sense if you've got a product, someone comes and reads and converts right away. If you've got a long pipeline, enterprise software is typically 12-18 months--

Rimas: Or even enterprise hardware, that's even longer.

Craig: How do you test on that? How do you run a three week experiment and know you're headed in the right direction?

Martin: We have two different things for that. First of all, we have the quantity of how many signups we got, which was understanding, "Are we driving free trials at least from this?" We didn't care if it was revenue at that point. And then what we tested out is, we have a metric for quality signup.

Which is, in 20 days we can know whether that person is going to be retained or not. I don't care if they are free, paid, or whatever, but they are retaining the platform. So then we can also measure with that, if it's a quality sign up. And then by using those two measurements we can know if it's worth to continue digging down in there or not.

The other proxy that we use is how many people click on "Talk to sales." We don't care if eventually it's going to become an SQO, an opportunity. But we know that 80% of those will. We know that if we drive more of those we're going to have more SQOs. For us it's around, "What are the proxy metrics that are going to tell us that in the future it's going to be an SQO where we're going to close that deal.

Craig: Do you want to spell that terminology for the fresh PMs or people that are just getting into it, or fresh marketing people?

Martin: Yeah, sorry. SQO is a sales qualified opportunity.

The main idea is that this is an opportunity that has BANT. They have the budget, the authority, the timing and the need.

But getting to an opportunity sometimes, as you were saying, takes like one or two months, and then we take like two or three months to close it.

So if we come and find, and we actually did analysis with random forest prediction analysis to understand what things predict an SQO, or predict that we're going to close the deal. And then we use those proxy metrics for any A/B testing or any experiment that we run.

Rimas: Does that information actually get back to the product management team? So when they think about product that they're building, that they can push on these levers as well?

Martin: To be honest, not before, but now we do. We study the notes longer. I would say two or three months ago we have an ongoing meeting with the growth team, the product and the UX team all together. We share the insights and the things we've seen, the user tests, what are the metrics, etc.

And that's I was telling you before, we also have this meeting every two weeks where growth says, "These are the metrics that are doing well. These are the products that are not doing well now. How can we improve on these and what things did we see?" So we're starting to close the loop in there. But to be honest we didn't do a good job of that before.

Craig: I'm really curious. You say you didn't do a good job before. We talk a lot about things that are working well, what did you do that that works, what's good tips. But what were the problems you noticed by not doing that before? So others can say, if they have this problem and if they see this in their organization, maybe this is a thing that would fix it.

Martin: One of the hardest problems was getting buy-in for the growth team. It's like, "We are the product managers, why are we getting help from growth people? That is outside, the same for UX." Something that was tipping us about this is that we were a lot of times reinventing the wheel.

Or we were looking for data that we already have because the teams weren't communicating that well between each other.

Those were some of the earlier lines of, "We're doing the same thing twice. We're trying to find data that we already have, or we're getting some territorial on something, so those things don't make sense.

That's when we started saying, "Growth and product and UX, the three teams need to be working much more closely together and we need to be setting up something." At the same time, for example, I was telling you before that growth, the idea was that they were going to do experiments on them and that product was going to be implementing them.

But then they never got prioritized by product, so we said, "OK we're going to build our own engineering team for that. But wait, how can we send that information then to product as well?" We ended up on something where we've run the experiments and then once we see one experiment runs well, we send it to product so that they fully implement it and pay more attention.

They don't have this time constraint anymore. They can now fully implemented it the way it is. And we also have these feedback loops once every two weeks, where we get to work with them and we share insights. Which is something, again, we didn't do before.

Rimas: Great. I know we only got a few minutes left, and I want to make sure I get this question in. What can product management be doing better for you? For your groups, growth, developer marketing, all that stuff. What are the things that product management can be doing?

Martin: From us, that's at least a few things. First of all, now we're starting to change that but the go-to market for everything was decided by us, by marketing. They were coming to us with a feature and then we were thinking, "OK. How can we spin the message on this for the landing page? How can we explain the value? How can we explain that in a blog post?"

Now we're making the switch so that is done jointly by product management and product marketing together. Another thing that we've seen a lot, I call it, the product managers were building "cool shit." They were shipping it and then that's it. That's what we're working on and we need more help with.

Once you ship the feature it's not done. You need to now see how it's performing, see if we need to upgrade things, to change things, etc.

So it's around not "sit and forget," but actually continuing to focus and work on that. That's for sure. And the other part that we are getting them more involved in is working with sales. So before, we were the link between sales and product and we were like the telephone in the middle and messages were being lost and--

Craig: It was perfectly translated. No issues at all.

Martin: Exactly. So now we're working together. Product is doing trainings, for example, for the sales team and they have a process where we hear features or things that are needed by sales. That's something that we work together with them to close the loop so we're not the telephone in the middle.

Craig: That's something we talk about a lot. A good PM interface with sales, with marketing, with engineering, with essentially every area of the org. In your case, marketing interfacing with every area of the org is equally as valuable. That cross-functional collaboration increases the way you work, the trust level there, and helps you build a better product. It's huge not just for product to do, but also for engineering to do, for marketing to do, for sales to do, etc.

Martin: It's also about trust. Something that happens a lot with us is that sites request a feature, and there was no process for that. They didn't know if it was checked, if it wasn't checked, what was going on in the middle, etc. So that's the other thing we worked on, creating processes. Where we have a process for launch, a process for the sales team to request a feature from product, etc. And that starts giving you trust, "OK when we do this we're going to think about it. This is what we can do, this is what we can't do.

Rimas: Craig, you forgot one other stakeholder as part of who we are supposed to be talking to. Don't forget about the external one, the customer. C'mon.

Craig: No. They just take the product, buy it, then it's good. Then you don't have to support them. Problem solved.

Rimas: I like your style, I guess? Maybe? Customers, number one. Always.

Thanks Gonto for your time today, I really appreciate it. This is Rimas.

Craig: This is Craig.

Rimas: Thanks for listening to Practical Product.