69: Sound, Actionable Advice with Jason Cohen

Hey everybody. Normally I would be starting off this podcast by welcoming Derek, but instead I have a guest. Derek has left me all alone to fly solo, but fortunately I have a co-pilot today, and it is Mr. Jason Cohen. Hey, Jason.

Yeah, you can't. People can't see this, but Jason is chugging from a large bottle of bourbon regularly.

Exactly. Now it's just a bottle. Um, so in just in case you have not heard of Jason, he is a four-time entrepreneur. He's done bootstrapping. He's done fundraising. Uh, currently he is the CTO of WP Engine, which you started off bootstrapping and then raised money for and now is enormous, like 700 employees or something.

Okay. So, a relatively small enterprise.

That's true. Yes, comparatively. So, we'll go back and like pricing logic, you know, you have to set the frame up and it can feel like it's expensive or not.

Well, fortunately, you know it. Although, even when you know it, it's still difficult to ignore it.

Yeah, that'd be great. So, I saw you on Justin's podcast and live stream extravaganza, and I really liked what you were saying. I appreciate your sort of semi-contrarian, no BS kind of tell it like it is attitude, I guess. And also, I didn't realize that you did podcasts, so I was like, 'All right, I got to get him over here.' I don't know.

That's a joke.

Yeah, right. You backed yourself into a tautology, anti-tautology. I appreciate anyone that will talk straight with people. And I got the sense that like Justin was kind of hoping you would say, 'Yeah, you can work on this business about 10 hours a week and that'll be fine. Like don't worry about it too much.' And you were like, 'Nope, no way. Sorry.'

Have you seen Paul Graham give advice to startups?

So, the reason I brought him up in particular is because I feel like he has a like 0% buffer before he's like, 'Stop talking. I have another question for you.' kind of thing. Like, the questions are great and his suggestions, at least for the type of companies he advises, I think are great. It's like if you had to condense everything down into 10 minutes, he just dispenses with all of the sort of pleasantries, subtleties, all that normal social stuff.

Yeah. And especially if you're advising like a 100 companies or whatever they were doing, I have to imagine you really need to do that. You touched on this thing that I wanted to ask you about, which is advice that's any good starts with like an hour of the advisor asking you questions about what your goals are.

And did you come to that conclusion because you had bad advice in the past that wasn't tailored for you?

Yeah. It might still be bad.

I like this actually point here of even if the advice were perfect for you, like amazing advice period and perfect for you, even then that's not really enough. Like all you know is like a blueprint at this point, but everything after this is execution, which is the hard part.

Do you still advise people at Capital Factory?

Does this position, your philosophy on advice come from trying to advise other people on the regular?

And did you experience like finding your advice kind of out of joint with the people that you were talking to that made you realize like, oh, I'm not thinking enough about the context of these people I'm advising?

Yeah, you just said something there. I liked a lot which is you characterize a company as a learning machine.

I dig that a lot.

You touched on something that stands out to me a lot, which is embracing your humanity and your smallness. And I've seen friends running like one person businesses that talk about themselves as 'we' in their like marketing copy. And I know why you would do that. I understand that the feeling of smallness or insignificance. I think that would cause you to do that. But I think we're on the same page that this just, you're abandoning something actually that's useful.

Like, it's just the reverse. It's like, that's awesome. I'm so glad I'm supporting an independent person that's badass.

I'm trying to grow a baby company right now and one of the first things we did was like slap a picture of me and my two co-founders on our landing page and it's like this is Ben, Spencer, and Joel and we're trying to make this company happen and like here we are and here's our smiling faces and like we're glad you care about this at all because we're literally just three guys in Joel's second bedroom trying to make this thing work, right?

Totally. Yeah. And like by podcasting about it and tweeting about it and sharing good and bad things, people like totally feel connected to the journey.

So, I don't want to say it will never, it will end. It may not end, but or maybe it will. It can end. That can happen.

There's a bunch of great reasons to tell people like the behind-the-scenes stuff. I think like I just philosophically I'm into that. Like I like to share the good and the bad and let people see what it's really like. And it tends to I think people think of it as a cost, but I think of it basically as a positive where it's like people get bought into the journey. It becomes like a drama they're following along with. And that just only helps.

I've literally had people reach out to me and be like, I don't even think I need your product, but I'd be happy to like send you like prepay you for something just to kind of support the effort.

You touched on something, this concept in your conversation with Justin that I liked a lot where you're saying when it comes to making decisions, I really like filters as in like you just you decide a thing and that lets you eliminate a whole class of decisions. Do you have any like favorite filters that you apply right now these days or in the past?

You know, I feel like you've kind of touched on one possibly. Oh, this is I'm not sure this is exactly a filter, but like you said earlier, I do two things. Like I've decided that my life has space for two. Home and WP Engine are them. Therefore, I have a filter and I know I don't need to go work at Capital Factory right now.

Yeah. And get to work.

Stop the planning phase. There's a part I want to quote from a blog post you wrote, which is kind of getting a little bit back to this advice like what's good advice and how do you recognize it and all that and I'm going to quote you which says as you accumulate a set of principles that you have a lot of energy for, you throw yourself into it and run to the extreme. Doing that is perhaps one of the truly universal rules of success that you are all in. Applying an extreme amount of energy is more important than exactly which path you're taking.

That's good. That's pretty good. You can print that.

Totally. I've had the same experience.

Mhm. But it's way less scary to add the feature. I already know how to do it.

I'm probably your target market in that rant right there. So, I'm a technical person. I know how to write code pretty well, but I'm in the CEO role for this and I'm on sales and marketing duty and trying to make sure that sales actually happen. Assuming that I've drunk the Kool-Aid, which I have. I agree. I shouldn't be writing code. That's not going to help the business that much and I want to get better at this stuff in a hurry. Is there anything beyond just like build the learning machine, try to get awesome, pay attention to what works, try lots of stuff, see what works for you. Is it like everything else where you just learn it by doing and trying to figure it out?

Right. Can I describe where we're at and just have you like ask me questions slash do a health check? I'm like I'm at the doctors and you're just like let's check this and make sure this is okay.

All right. So, we started this company back in May. It's me and two co-founders. We're all technical. It's called Tuple and our goal is to build an app that lets you do remote pair programming. So, two people on one computer writing code together. We think all the solutions out there are pretty crappy because you need to make something that's really, really fast, screamingly fast. And the existing things out there have too much latency and people don't like them. I started off by doing pre-sales. So, I reached out to a bunch of people. I have a bit of an audience. So, I came to this with an audience, which is nice. I've been working in public for a long time. So, I had a bit of a Twitter following and some email people and a podcast and through that started getting people on an email list and actually populated a paid alpha. So, pre-sold about $8,000 worth of people on that. So we have a handful of teams and a handful of individuals who have said, 'Yeah, I want to try it. I want to be your first customers.' We're hoping to launch that alpha early next year. Get the first people in there. We have a bit of a like minimum viable versus smallest lovable product thing where if our whole pitch is like it's going to be really fast and we know that's the most important thing, but it's really hard to make it really fast. So, we're like we're kind of racing the clock to make it fast enough by the time that we want to hit.

No, it's a desktop app, so it could be anything. So you can use your terminal, your IDE, whatever you want.

That's right. Yep. And like really good keyboard support and dual mouse and also pairing specific features like I can...

That's nice. The interest is great. We got three like 3,000 people plus on our email list. People are asking me pretty frequently to get into the next alpha beta. Like I'm telling people no and they're like no please, I really want to. So the market feels very there where people are dissatisfied by the existing tools. We've promised a lot and it's a kind of a hard thing to deliver. So that's like one of my concerns is like I think we eventually will have a great product that will deliver on these things that we're saying but to do it fast is hard.

So, you know, one thing to consider is that they may be wrong because like you said, you may be promised a certain thing and that's what they're thinking and they won't get it and they'll be upset. So, they may be incorrect, but what if they're correct? What if you're right about the in the long run about having the best product? But what if you're wrong about what people will pay for today, pay for now? So for example, if I'm used to a workplace that has pair programming and on the other hand the engineers in the building say we'd really like to work from home sometimes but there's no way to make those two things work, pair programming and working from home is hard to do simultaneously. So here's Tuple, a way to do that and they're like oh my god I could transform the way that I work except you're saying because the latency is 100 milliseconds not 50 milliseconds I'm not allowed to do that. Dude I will take a slightly higher latency so I can work from home. Do you understand the transformation that is? The difference between not having Tuple at all and having a slower than it will be Tuple changes my life and the other part makes me go from Tuple required to and also I love it even more. Why would you stop one until you have the other bad? No, no, no. Let them do it. So, I don't know which one's right because, you know, maybe you're right like the experience is so bad right now that actually they would be disappointed. I don't know. But my guess is usually creators are extremely self-critical. If it's not all the things that you imagine, it's just not good enough. And you're in fact not you're not even proud of it. And you certainly feel bad charging money for it because it's not that good. But this is the wrong mentality for a new product. It's the right mentality for an immature product and maybe even a mature company who can't really have a crappy product cuz it would be like Apple has to make a product that's all the way done even if it's new cuz it would be contrabrand otherwise. Fine. But none of these things are relevant to you or me for that matter, right? There are those phrases like if you're not embarrassed by your first version then you released too late and all that kind of stuff and you know that cuz you said SLP and all that stuff. So you know all that but still maybe you're doing it anyways. Maybe allowing all those people to do it and charging them for it even would work and they would say yes and then look your company would have a lot more revenue which would be great. It would help you do everything. Revenue solves all problems. And so, you know, maybe maybe they're wrong because they don't understand how bad the experience is, but maybe they're right. Maybe they don't even need link sharing. You know, maybe there are certain use cases like the one I just mentioned, but there's probably I'm sure there's other more common ones where no, you don't understand. They have zero. You help them go from zero to something and that's huge and they'll pay for it already. Then you can go file the edges so you can charge more or they can be more thrilled and tell their friends cuz it's that good. Yeah. Then but going from zero to something could change a lot of people. So when is that when is remote workers just in general like companies that have remote at all? Also I would ask like who what kinds of organizations are obsessed with pair programming at all? Like whether or not it's remote. So like if I'm an extreme programming organization, then I have to. I doubt there's very many of those, but just, you know, whoever whatever is, you know, maybe some famously are. If I'm just obsessed with pairing at all, I might need this. I mean, who knows? Like, who knows what the use cases are. Even if I'm in the same office, it might still be there might still be a reason why we don't like it's actually nice not to sit next to each other for some reason. You know, even we only have 610 total people and we have engineering on three different floors right now. So we have pairing rooms, but sometimes they're full. So like even if everyone's in the building, you might need this. I don't know. So I don't know. But I wouldn't arbitrarily restrict those use cases. Maybe someone would pay for it. So I think it's good to maintain that high standard for what you think is good. That's good. But it's bad if it means like I feel bad about charging or I'm not sure if I like then it's bad.

Well, why would you not take their money?

Well, putting money in the bank is one utility of revenue but not the only one. It's a commitment by the and a signal by that customer. And that is valuable. Yeah. And by the way, if someone right now would pay to use it because they Why would you stop them from that? Cuz you need to ask them more product management questions.

Well, why don't they have it? You launched in May, you said. So why don't they have it?

Yeah. Okay.

I wonder just the fact that you're obsessed about a link pasting opening in a browser. It's like again I go back to like you are preventing me from switching my work style from having to commute to the office from being able to work from home. And because you want to add some link browser crap, you're stopping me from doing that.

Yeah. I guess my concern is there are other things out there that do similar things and we want to make our like we think the value we can add is to be faster and better than those things.

Because they don't like them.

So but like I don't want to be like the next thing they don't like. Like I'm just sensitive to this idea of like so like I've seen this happen to other tools in our space. Like someone goes, 'Yeah, we tried X. It sucked. We're not into it.' And like they tried it 6 months ago and like that they just don't get another shot at trying it again because they tried it six months ago and it sucked. So they're like, 'Well, screw that tool.' And I just don't I'm wary about getting that rep or like just being like, 'No, no, it's going to be really good. I promise. Trust us.' Like no, no, we've moved on to other things. Goodbye.

I mean the biggest reason is it's a hard problem to solve period. So you have to really care about this particular use case and almost no one does. Like most people want to build generic screen sharing and maybe remote control and they don't think about low latency and programmers and that kind of crap.

I think the best use case is you have a distributed development team and you want to collaborate. It's easy to feel super isolated and get knowledge silos and all that particularly when you're remote and so it's nice if you can pair program anyway even though you're home.

And the problem is that it's high latency and other things.

Right. So you want to wait till it's better than Hangouts.

How long do you think it'll take for it's better than Hangouts that the three guys who are good at engineering will beat Google at desktop sharing?

Here's another interesting thing. Your audience is devs and that's great and bad. The bad thing is they all know, they all want to tell you like you should add this feature and it'll be easy and they have some reason in their own mind why it's easy and they're probably wrong. The good news is they're devs and so they geek out about the same kind of things and they understand what alpha means. They understand a graph that shows latency and how it improves over time and how that might imply that in the future it can continue to improve. I remember at Smart Bear, of course, we also sold to developers only and that was really helpful when there was a bug. We could actually explain why it was a bug and a lot of times they were like wow yeah yeah no I totally see why that would be a bug and in a way that you could never do to another type of customer and you really got this understanding that was really really cool. Same with features we really want this feature and then you could really geek out in crazy detail about why it's hard or why well but in these cases it doesn't really work and we're not sure how to solve that and so and they're like ah I see that. Dang. Yeah. And like, wow, I just said no to a customer feature and they understood. What the hell? So, with that spirit that you can if you communicate about the geeky stuff, they actually typically come along. If you publish, what if you publish the latency chart week by week? And so, you're like, look, we're entering alpha and I'm telling you right now, it's not good enough because here's our chart and here's the line of what good enough looks like. And look, see how we're not there? See that? Right. Like I'm telling you right now, it's not good enough. But look at our trajectory. So if you want to, you can start using a tool that we know is not good enough, but might be enough to get the job done better than not having it and you can follow along.

It is. And but I guess what I'm doing is trying to tap into what you said which is it isn't good enough. And so you get this reputation of this tool sucks and I'm not trying it again. So how could you dispel this notion of the tool sucks today and so it will always suck which I 100% agree with you about that that people do that. Well, one way would be if you were crazy about this graph. Like what if it's so crazy that when you install it and it comes up it says hey all this is our graph like in the tool like they not at the blog but in the tool. So like when you run the tool you cannot escape the fact that you know it's not fast enough and it but you're working on it and it's improving so hang in there. And if it weren't a dev audience you're probably still screwed. Like what are you even what is this? But with a dev audience you can geek out about this crap. Learn more about how hard latency is. Click. Here come a bunch of tech articles you wrote about, well, even measuring latency is hard. Is it the 99th percentile? Maybe it, you know, is median right? Not really. But there's this other way because when you're really using it, if it hiccups every 5 minutes, but otherwise is clean. That actually is good. Whereas if the average is a little higher and it never hiccups, it's actually bad. Exactly the opposite is true in audio. And that's why all that shit's wrong when it comes to us. Blah blah. I just made all that up. I don't even know if that's true. But like just geek out about like this is what even latency means and how we think about it and measure it and all these algorithms. And then so because of the way we define it, we have these like here's a little test harnesses we use to micro test some of these things because of this macro thing. Of course the only the macro matters and in the end and you don't want to pre-optimize but and blah blah blah blah blah. You do that and they see that graph and it's not fast enough but they know that. Now do they stick around? I don't know, but it's better bet. And if you can get that revenue going because revenue is this, it's a commitment. They're part of it. They're loyal. They'll talk to you about stuff and maybe they'll talk now, but it's different when they're really using it. Then you're getting real product feedback, right? Maybe they share it with others. Maybe they share the articles about the latency cuz everyone, you know, we all like to geek out about stuff like that. That doesn't mean you release it now, but like there's got to be ways to say, well, I'm worried like you just did. I'm worried that it's not good enough. and we'll get a reputation. It's like, well, what if it's not good enough, but you actually have the reputation of being super awesome geeks as opposed to the reputation being slow, even though it's the same product because of how you show it, right? Now on the one hand, you've just set yourself up. If you can't get it there, but you just told me if you can't get it there, it's done anyway, right?

Request welcome jerk. Yeah, run the Docker container with the integration test and see if you can make it faster and suddenly it's a contest. Now, I'm not saying that that's necessarily a good idea, but what I am doing is trying to say like how creative can you get in engaging what you have, which is a very specialized audience, which is other developers. That's really that's not the normal customer. You can throw away a lot of the normal customer playbooks. You can talk about all kinds of weird stuff. In fact, it's better. It's better. Totally. A developer would rather buy from a geeky developer who's Why do people buy Marco's podcast crap? Cuz it's Marco and he geeks out about microphones. That's why, right? Like, this works. This works. So, geek out about the damn thing. And I'm sure his software wasn't so good at first, but everyone knows Marco's going to obsess over everything and it's going to be better. You can win that. You have a platform and things like the podcast and blogging and the email list and stuff reputation. and you have a platform in which you can do that, great. Take advantage of it. Do it. Take advantage of the weirdness of your audience. I would say I like that a lot. Now, open sourcing is that's a whole another thing like what if no one contributes? Are you managing pull requests, which is now more work? Just making open source is kind of you got to pull it out and I don't know do things and document stuff in a way that you don't need to do now and that's just time. What if you don't want to accept someone's pull request? Now that's a thing. People use it for purposes other than yours, so they want to make other changes that don't really make sense for you. Do you do that anyway cuz it's open source? So like pro unless you're super into open source, in which case maybe it's worth it because personally you want to have open source stuff, then awesome. If not, probably it's too much work. Another thing, and we think about this at WP Engine too because we do release open stuff as open source on purpose. One of the things we think of is, you know, whenever someone looks at our open-sourced item, they will judge our engineering prowess based on that code. So even if this the whole point of this was it was a skunk works product that's not at the normal standard that we use, nevertheless, we will be judged on that standard. So even though it's on the side, we actually have to make it really really good in terms of everything quality and tests and documentation and you know CI/CD and whatever because we'll be judged and actually so it turns into a whole lot of work cuz we'll be judged and we want to be judged well. So again maybe not a great idea at this stage for those reasons but it's kind of fun to talk it through anyway because it's a possibility I guess.

Well, what if you had a tool like that and it said, 'Hey, it's not good enough.' I bet you'd use it and go, you know, it's okay. Hey, if you're going to make it even better, great. Like again, it's just like we said at the top of the podcast, you just anchored it as like I know it's not good enough. That's actually could be good. People say, 'Oh, it's pretty good.' you know, if this is going to get better, then okay, I'll come along for the ride, but it's fine. You know, I like the link thing or whatever, you know.

Yeah. And what if you do and the latency is still not better yet? Will I come along for the ride on the latency given that you're honest about it and you're doing other things that I do want?

Yeah. Interesting. Just think of it yourself. If you got a tool like that, how would you react to that? Right.

Which is not a great question actually because you're not like your customers at all. They have jobs and they write code. So like you're not actually like your customers. So that's not a really a good question.

What is that for? I don't know.

One other thing about DevTools, again, having bootstrapped a company that sold Dev Tools, I think in general, it's fun to sell to devs for the reasons we just said when it comes to the money and getting money, it's actually kind of hard. Like people that type code into computers generally don't have a budget. There is a budget somewhere, but they don't personally control it. Sure. Right. Ask the front line developer. Yeah. They have to go ask and it can be hard to get on the radar of that other person cuz that other person who does have the budget, they have lots of concerns and worries and things. It's hard for like some random tool for something to sort of get on the docket. I find it's different for different companies. The smaller the company, of course, the easier it is for someone to whip out a credit card and it's fine. And the bigger the company, once they decide to pay, you're on there forever because now it's a tool in the tool belt and they sort of have to pay because it's like in the list. So that's great. It just takes a little bit more effort to get in the list.

Yeah. And there it's helpful if there's more than one team. Even better is like multiple business units, but just more than one team. So, in other words, if it's just one team out of 20 teams and that team wants it, that is very hard to get the senior director of whatever it is to like even pay attention to the thing. But if there's like two different teams, then it's different. It's like, you know, we tried it and liked it. Someone else in the office tried the totally different team tried it, they like it. You know what? Maybe we should just standardize on this. Let's just buy this. That's a totally different thing. It becomes a thing that we do as in our processes as an R&D department or whatever it becomes a different thing and it's a much bigger sale too like there's more seats that's good. So typically like that helps get over the line on those bigger organizations with dev tools even though of course it takes more time it's more work but you know it can be 10 or even 100 times more revenue per customer meaning company or organization so okay so maybe that's worth it you know that timeline's it's worth it for that. Of course, this could be a viral tool in the real sense of the word viral. Two people use it, then a third person wants to use it for fourth, so they get in. So, I think it'd be very good if the business model maybe, and you probably already did this, but the business model allowed these incremental ads like just throw someone in. And later we'll come back to your boss and they won't have a choice because she'll look at it and say, 'What the hell is this?' And you say, 'Well, 10 people are using it. Wait, 11 people are using it.' And she'll go, 'Oh, damn it. What do I have to' And you're like, 'Well, you buy the license that lets you use it up to 20 times and we'll come back to you if more than that use it.' And she goes, 'Well, either I have to go and tell everyone to stop using it or I pay.' So that's almost for sure the right way to go is to make it viral that way.

The thing is you want the friends to use it for somebody else too. Like that's how viral works like you've skipped the part where someone's infected.

So another way is kind of there are other tools which come behind like Slack, like Atlassian etc. And I picked those because those are other tools which are viral and work well in the business world and are viral which is very different than consumer viral which is obviously isn't but the business world viral are certain companies. And so what they'll do is they'll say like well we're never going to stop someone from making an account and using it cuz if they made an account and they don't use it it's hard to go to the boss and ask for the money. But if you make an account and use it, then the conversation with the person with the budget is you have 11 active users, so we need to settle up. See that? See how different that is in like 11 people logged in this one time. No, that okay. Well, they don't need to log in anymore. That's the answer. 11 people are using it and it's growing. And actually, we're behind on licenses cuz you only bought five or zero. So, we kind of need to true up. Like, we don't need to go back in time. None of that kind of stuff. It's fine. It's fine. We're happy to be generous about that. That's not the point. But, we do need to true up. Let's just go ahead and get you on the 20 pack so that we don't, you know, let's just get you trued up there. And then we can go back to sleep. So, it's a totally different thing when they're actually using it than when they're not actually using it. So I think it'd be better if they were in the system actually using it and then you can have the payment argument.

Yeah, it's not necessarily easy to design, but these are fundamental business model things that could really really change the trajectory of the thing. So unlike a Slack, like Slack is often used for people that are not at the same organization. So that's an interesting way that it becomes viral. But pair programming is probably with people in the same organization. So it colors the way you think about what viral means. So it could be, you know, when the first person signs up, they kind of establish this company object as it were and then things can slot in there. And why would you do that? Because you don't pay for it. Because it just works. Otherwise, you have to pay or I don't know like there's some or it's by your work email address. So there's a domain so you can tell and so like some way where yeah like we can just keep using this and then we'll see if we really like it then the argument is it's already here either pay or tell the developers they have to stop using a tool they like. That's hard. There is no manager who wants to have that conversation with an engineer. They might say there's no budget but like they don't want that. They really would rather not have that conversation. That's interesting. So, this is interesting because this feels kind of like a sort of like a bottom-up approach where it's like let people use it in a low friction way and then hopefully come back and we'll pick up a sale and figure out how to make it work there. I've had pretty good success so far in basically like pre-selling a certain number of seats at a pretty high price for an annual plan and like that's pretty cool too.

I'm pretty into that.

It's Yes.

Yeah. Yeah. Right. But I'm with you. Like if that's the mode is like we're going to have a sales team. We're going to marketing is going to generate leads for the sales team and the sales team is going to call in and make annual chunks and like 50k at a time or whatever kind of things. I think that's awesome. What Slack does is both. And again, I'm not saying you have to do what Slack does. I'm just these are just ideas, right? And things that have worked in similar context. So what Slack does is both. There's an easy way to just get in there and go because that's part of how anyone even knows about it in the first place. Again, even if you're having that conversation about the whole thing with someone if they have one team that's actually using it and saying, 'Oh, yeah, yeah, we like that.' How much easier is the sale now? So, it's pretty easy to argue that some kind of grassroots bottoms up thing is helpful, you know, even if you're selling from the top down. And then so what Slack does is that's easy and then maybe you just buy the number of seats that you have and that's fine. Maybe they go to the top and say, 'You know, we could do that, but then we're going to be coming back to you all the time and you're going to keep paying a different amount and your budget's going to keep changing.' And you know what? If we just go with an annual license and cover up to x people, the unit rate goes way down to this and we'll just talk again in a year. That's exactly what Slack does, right? That is also what some other companies that do dev tools in particular, will do. So there's this grassroots and this like hey man we can see where this is going. Why don't we go ahead and get this all organized and that's a good argument and then you can sell either way you can go in from the top and at Smart Bear we did both. Sometimes we would go in at the CTO level or VP of engineering level or sometimes at a big company like a Qualcomm there would be an entire group just about programming quality for the whole company like a whole group devoted to those things. So it depends on the structure, but there would be someone who in that sense that you're saying is like sort of above it all either in the org chart or cuz they're tasked that way, which this could be that too by the way, right? Pair programming could be something that a group like that would consider, right? And so sometimes it would go in there and they're like, great, here's let's buy 2,000 seats and that's the trial and if that works there'll be 8,000 seats. Like you're like, whoa, trial? That's what? Yes. Right. So there is that we had that motion, but also we had the motion where in our case it was code review. So just like you, it would be a group of people. So we'd have a group of people try it and there's just three of them or maybe 10 or something like this and if it works they go get the money and then another team looks at it. So four months later we see another sale for a little bit more and then eventually we sort of go high up the chain and go look you now four different teams across the country using this. It seems like this is what you need. Why don't we and so sometimes we would grow that way. So it did both in that case. I know it does both in Slack too. I'm pretty sure Atlassian is the same way, right? Like someone sends a Bitbucket, someone sends a Jira, it's free or it's cheap. Eventually they go, you know, you just need one Confluence for everything because having millions of wikis is not good, you guys. And everyone agrees and so then they make the one big Confluence and charge you whatever. So again, I'm not using those to prove quote unquote that this is right, but just to show well there's a lot of successful footprints along this path. So it's and you do have a viral component. Therefore, maybe although that's work, maybe that could really help the business be successful because as we all know the business model is just as important as a feature. And the business model is just as tuned into product as features is. It's not marketing, sales, and business model on the right and product on the left. We all know that's not true. And here you have a product that's naturally viral, which is amazing. Most dev tools aren't. And so a lot of these things don't apply to most dev tools. It's more like that one engineer has to want it or like you said like it has to be mandated from on high which is not very common. And so that's hard and that's like so it's super hard to sell an IDE for example. So they're all free you notice that like so some aren't like there's like two that have figured out how to do it and they're still around. It's hard like it would be very hard to launch an IDE, wouldn't it? Like oh my god, right? But you have a naturally viral thing. Wow. And I hate that word actually cuz people typically use it and it's not really viral but you really are. It really is like we need you need to use the software for us both to use the software like it actually is viral. So wow. So I would lean into that and even if that means product features that allow for certain pricing things to happen. Man though that could mint the business in terms of the business model. So that doesn't sound like a bad use of time. Now is right now the time? I don't know about that but because no one's paying anyway. So maybe it doesn't matter. But maybe architecturally you could think about that in terms of what does it mean to sign up? What does it mean to be part of a company? How do you account for that? How do you see that? That's where you could think about that. And is the key thing to think about there making it spread easily? Is that the play with the viral situation? So if you go to the breathless Silicon Valley type podcasts about super growth or whatever they call it. Yeah. Then what you just said the answer is yes. The point is spread like a virus and you know things which basically treat your users like units humanless units to go exploit with your viralness. Right. So yes in a more friendly way. Yes of course the idea is to spread it. Of course we want you to spread it. Rather than in this mean kind of heartless way, you can think about spreading it in the way that says when I find something I love, I like to spread it. It's because I want other people to use it because it is good and also it makes me look good to spread something that is good. That makes my reputation go up, right? Yeah. Or just we are a distributed team and two people use the tool and they liked it and so of course they each want to use it with somebody else because like it's actually good for them in their use case. That's why not for some nefarious reason or some weird built-in horrible thing, but because actually they want to. So yes, the point is to spread it, but you can come at it from an attitude of spreading it for good reasons like it really does help. This helps us work in the way we want to work. Hooray. That spirit of spreading. And so what kind of language goes with that? What kind of features goes with that? What would be allowed or disallowed in that case? When you have that mentality, you might have different answers to that than if you have the mentality of, you know, like the Facebook mentality. That's a different mentality for how to make people use it or make people increase engagement. It's a different reason. So, you make different choices. Even though anybody with a tool probably wants to quote unquote increase engagement or utility, like yeah, that's not bad. But like your attitude toward what that means really matters because you will make different product and business decisions as a result. So like this thing about charging, I think you do want it to be easy for someone to for the nth person to invite the n plus 1th person to do it because that is better for them and it helps you spread and the best way to do that is not make the n plus 1 person pay right now. That would be the easiest way for this to actually happen.

Yeah. One of my favorite lines, which I wish I invented, but I did not, is that there's only two industries that call their customers users. And one is the drugs you buy on the corner. Yeah. And the other is us, the users. So, if you think of them as users, like, you know, right, then it's bad that you're infecting their world. But if you think of them as customers and you're thinking about that people really want to work this way and you're helping them and of course you want it to spread so that you can get paid for that. Duh. Like that's not evil. Like if you're calling them customers so in my language if you're calling them customers it can be good and if you're calling them users then it's not.

Same. It was fun. I of course I love dev tools cuz I'm an engineer and I love dev tools companies because I made one. So yeah, I didn't even realize that overlap there, but that worked out nicely.

That's right. They suddenly get an email. Hey we're going to try Tuple.

Perfect. Yeah. Awesome. Is there anything you want to plug by the way while you're here?

I've been a customer in the past and it works beautifully. So, nothing but good things to say there. And I'm going to throw you another plug too actually which is your Designing the Ideal Bootstrapped Business talk is one of my all-time favorites. So, folks should for sure go watch that. Yeah. Microconf site. And I guess I should plug myself. So, blog.asmartbear.com. Smartbear.com is where I've been writing for about oh jeez 13 years on these topics.

Well, thanks Jason for coming by. I appreciate it.