• Jane App

Allen Pike: Welcome to It Shipped That Way, where we talk to product leaders about the lessons they’ve learned helping build great products and teams. I’m Alan Pike, and today’s interview is with Trevor Johnston. Trevor is co-founder and co-CEO of Jane App, which he’s bootstrapped and grown to now employ over 500 people and help hundreds of thousands of clinicians run their practices. Welcome, Trevor.

Trevor Johnston: Hey, thanks for having me.

Allen Pike: I am so excited today to dig in to some of the stories, lessons, things that have worked, things that didn’t work in the path, building a business of this scale over a decade. Obviously, there’s a lot of learning that happens, so I want to tap into some of that and give you a chance, an excuse to tell some of these stories. But not everyone, I think probably a lot of people have context for the business, but not everyone will. And although Jane’s founding story has been well-told, I think, I want to give you a chance to do a bit of a high-level recap of how this all got started and to give people a little bit of a context for what Jane is before I start getting into, “Okay, so how did we build this? How did it go? What did we learn?”

Trevor Johnston: Yeah, because Jane is not a household name, although in some markets people do recognize the logo on the back of the laptop at a coffee shop. Jane was born quite a while ago. 2011 was when the story started, and at the time, I was running a little design studio, digital agency. We were doing a lot of branding work and advertising work and some things on the web, and an old friend of mine asked if we could do some work for her. She was opening a healthcare practice, and asked if we would just do the basics like brand identity and a website.

Allen Pike: Sounds simple.

Trevor Johnston: Yeah, we were happy to do that and started designing and naming this little business and going through that process. And in the middle of that process, Ali, she realized that she needed some software to run her practice and she really wanted to find something that had online booking. This is 2011, so at the time she quickly realized that there wasn’t much out there, and she was bringing me these options and Appointment.com was one of the options, which is maybe the Craigslist aesthetic of online booking and-

Allen Pike: That gets a vibe.

Trevor Johnston: And we had just designed this really beautiful website and we’re putting so much thought into this patient experience, and we’re just like, “You can’t click Book an Appointment on this website and get dumped into this other thing and then go through this journey.” And for me, I wasn’t a coder, I was just sort of dabbling a little bit in starting to code things at the time, and to build something app-like was actually just super interesting to me. When you’re in the design business doing consulting work, every project starts at zero and it goes to 100, and then you go back next project, zero to 100. And to build something more app-like, that just sounded so exciting, something that would live on and maybe you could actually iterate on, was very interesting. So I said, “Well, what if we just built you some of these features into your website?” And she was into that. So we took that on as a project. We had six weeks to get it done, and we built this little thing, and inevitably there was scope creep, so second thing on the feature list was like, “Well, I also really need something for electronic medical records.” I’m like, “Oh, okay.”

Allen Pike: No big deal.

Trevor Johnston: Yeah, no big deal. So we threw something in there for that too, and she opened her clinic six weeks later with this system, and it was literally built into her website. And just to give you the idea of the lack of sophistication maybe we had at the time, we didn’t even know how to really host it. We ended up hosting it on a Mac Mini on her broadband connection in her clinic. We had to get her a static IP address-

Allen Pike: Hey, this solves the data residency thing. It’s not in AWS in America or something like that. For context, actually, we hadn’t mentioned for our listeners in the States, but this is a Canadian business, so health records need to have… treat in certain ways.

Trevor Johnston: Yeah. We were concerned about privacy and we didn’t know how to have a trustworthy hosting experience, so let’s just throw it in our office.

Allen Pike: There you go.

Trevor Johnston: That was the origin, and it worked really nicely for her. And we had no intention of anything else happening with it. We made a couple little updates here and there, but the thing that happened next, which we didn’t expect, was other clinics saw her online booking, and so they were contacting my company, because we had our little name at the bottom in the footer, and they were contacting Ali at our clinic saying, “What is this thing you’re using? It looks great. I would love to have that for my clinic.” Enough of those requests came in, and thinking back, I don’t know how many it actually was, maybe 10 or 12. This was our entire market research for, “Let’s start a business.” But 10 or 12 people want this.

Allen Pike: Hey, that’s pretty good. You get to 10. A lot of startups start with less than that.

Trevor Johnston: Yeah, it was a year and a half later and I sent Ali an email and I said, “Hey, do you want to turn this little thing into something we could sell to other people?” And our mentality was to start essentially a side hustle. Ali would keep running her clinics and she wanted to franchise this little brand we’d created and open more clinics, and I was still running with my partners this design studio, which was going well, but we thought the idea of, hey, a little passive income on the side sounds good too.

Allen Pike: Sure.

Trevor Johnston: And the thought of building something once and selling it twice was so novel to me in the services industry. So we did that. We had to make a decision though at that point, because we had just built online booking with, had a pretty good administrative scheduling feature on the back end, and then we had the electronic medical records thing we had built was a bit weaker. So I’m like, “If we’re going to sell this thing, it probably needs to do more than just this.” Because Ali was actually running a whole another piece of practice management software in her clinic alongside this to do all her billing. And in healthcare, billing isn’t simple because it’s credit cards and invoices and cash and all that, but it’s also health insurance, which is really complicated. So she was using something else and we just thought, “If someone’s going to choose to switch their system of record over to something, it needs to be capable of both those things if we’re going to be able to sell this thing.” We’d made the call that we should take, we thought it would take six months to a year to build out that billing side amongst all the other projects at the agency, and we launched a website and made the product available to sell in spring, March of 2014. It had the minimum number of functions built out in it that we thought a clinic would need to be able to switch over to Jane.

Allen Pike: So that’s how you got started. That was 10 years ago, and you’re at the point now where you have hundreds of thousands of clinicians that are using this system. The vibe I’ve got when I’ve talked to Ali and heard parts of the story, or I don’t know, correct me if this perception is correct, that a lot of that growth in between now and then, the curve is fairly smooth. It wasn’t like, “We were in the dumps for five years and then suddenly some eureka moment and then we quadrupled in five minutes, and then we struggled for a while.” But it was this slow and steady compound, compound, comment. Is that a pretty true characterization?

Trevor Johnston: Yeah, the curve is so, it almost looks mathematical. It’s like it was an equation, and looking back, we actually have some math that explains that, which is interesting.

Allen Pike: Is it about people referring to one another?

Trevor Johnston: Yeah, it’s the referral thing, because referral growth is a fixed rate of growth because what we’ve observed is that if someone’s going to be enthusiastic enough to refer Jane, their sphere of influence is on average, two people. Our numbers show that if you refer, you tend to successfully refer to other practices. That’s this, well, it’s a very fixed curve that creates-

Allen Pike: Multiple of two is pretty good compounding.

Trevor Johnston: Oh, it’s amazing. Now, the percentage of people that actually refer is maybe 50% of customers, so you can do the math.

Allen Pike: Well, as soon as you get to 51% of customers refer two people, then even just that on its own, you got a business now.

Trevor Johnston: Yeah.

Allen Pike: Awesome. So you’ve built this mathematically, geometrically growing business over 10 years, and so we’ve a few various topics and aspects of that I think would be fun to dig into. One is that, you didn’t say it explicitly, I don’t think, but it’s the absence of any sort of, “Hey, we’re going to raise venture capital and we’re going to send this to the moon,” and that story. Jane is famously bootstrapped. That’s one example of you all not using the default playbook, in some ways. There’s a standard inherited from Silicon Valley playbook of, here’s the default Y Combinator advice of how you do a startup. I’m curious, what are some other ways that you’ve taken a different path from the default in building the business?

Trevor Johnston: I think we never realized we were taking a different path from the default, which is the reason why we took a different path from the default, is that we didn’t know about the default in tech. We were small business operators. Ali had run her healthcare practices. I had been kind of a freelancer that turned into this little 10-person agency. It was still a very small business. And in small business, there’s just some principles that you have to operate by, like you need to make more money than you spend, is the first principle. There’s no other choice.

Allen Pike: This crazy idea.

Trevor Johnston: Yeah. No one’s loaning you money as a small business, even in early Jane days, we tried to get, whatever, a line of credit from our bank, and it was almost impossible. We had to do personal guarantees and all these things to get a line of credit from the bank, and then we we’re like, “Well, I actually don’t want to do that. We don’t even need this line of credit.” So yeah, small business has a certain mentality and we were really blissfully unaware of the way tech startups typically were funded and grown. I think I knew about that idea in big disruptive, “We’re going to change the world,” type startups like Uber, obviously you need a huge amount of money to change a whole ecosystem, but Jane was not that. Jane was practice management software. This was scheduling, billing, medical records, little business management tool. There was nothing groundbreaking about Jane. We were just creating some software that literally did the exact same things as all the incumbents. It just did it in a more modern and lovely, delightful way. I think because we were realistic about that, we never even felt like it was an idea worth having an investor sink a bunch of money into.

Allen Pike: Well, now in retrospect, you could say if you wanted to send an investor pitch back 10 years later, you could say, “Oh, well we’re hitting on this at the beginning of this wave of vertical SaaS. We’ve become the system of record for all these clinicians. Then we can have all these additional revenue opportunities as we sell into that.” All the things that you could say now. But in 2012, it’s like, “We’re going to build this thing that seems obvious, that’s just a nicer version of whatever was already there,” is not a VC pitch.

Trevor Johnston: That’s right. That’s a very tough pitch. I think what we didn’t really realize that we had tapped into though, which was the beauty of good timing and having solved a real customer’s problem, Ali’s problem, was this tier of healthcare was really, really under-serviced. There’s a ton of software out there for primary care, like doctors, your family doctor, lots of options. And then dental was really, really well-serviced. They had, I don’t know, whatever, there was a boom in the ’90s for dental software, all on-prem, so it was old, but just very saturated. But this tier that we were looking at, which was the definition of Ali’s clinic, and her clinic actually is kind of a unique practice in that it was multidisciplinary, so it consisted of physiotherapy, chiropractic, massage, acupuncture. There was a counselor, there’s a naturopathic doctor, it was this other layer of healthcare. And the thing about this layer of healthcare is that they’re all in small business. These practitioners that chose this thing and they got trained to do this way of healing people, and then they find themselves out in the wild having to own and operate a small business in order to do that thing with feeling like total imposter syndrome and inadequate on how to run the business part. That, I think is the profile of the customer that Jane was just gobbled up by. It’s people that, first of all, no one had ever made software for them before, so they were excited to see something modern and helpful. And then Jane, one of the founders was, Ali is not a practitioner, she’s a clinic administrator, was her background. So we got to provide this expertise to these business owners, these practitioners on the part of the job that they actually didn’t feel very good at and didn’t really like doing.

Allen Pike: Which is now one of the main playbook things of building a vertical SaaS business, find a group of people who, they’re good at one thing. I think we’ve had two, if not three founders on the show so far that have built vertical SaaS in one piece or another where they’re like, “Hey, there’s a bunch of people trying to do this one thing and they’re not experts at this other kind of distraction stuff. Let’s build a great solution, use our expertise in that to make their jobs easier.” And turns out that’s a really compelling way to scale a business if you have the right timing and build a better, more effective, delightful product.

Trevor Johnston: Yeah, and it leads to very, very happy customers that in some cases tend to refer you.

Allen Pike: Yes, which is awesome. We got the kind of, “Well, why didn’t Jane follow a lot of the standard venture capital-backed tech company patterns?” It’s just that you weren’t in that world, you weren’t immersed in it, you weren’t being driven by your investors or any of the dynamics that create that, that wasn’t your background. Now that you are the co-CEO of a company that’s at scale that is doing all this, you’re obviously exposed a lot more, both through hiring people and reading and the people in your network and stuff of, “Oh, well, typically this is the way that we do compensation, performance, growth, hiring, capital, offices.” There’s so many different facets of the default playbook, obviously any individual company that customizes it. Are there any things that in addition to this bootstrapping thing that you sort of, I guess maybe accidentally or just from first principles, common sense chose as a path that, now as you have scaled the company and you learn more about how other companies run, puts Jane as an odd one out that’s maybe been an advantage that people wouldn’t necessarily know or come across on their own if they’re following the default playbook?

Trevor Johnston: Yeah, I think the fiscal responsibility that was baked into this whole idea of make money, then spend money, it does a couple things. It helps you grow in the most efficient way possible. You’re being very cautious about every spend decision, which means you’ve got to be pretty shrewd about what you’re choosing to do, which is a helpful limiting factor. And then it also just allows you to grow at a pace that makes sense for your business. Because I think if you’re in that other model where you have this big chunk of money in the bank and the looming zero cash state, that does lead to this idea of, grow as fast as possible. And we didn’t have that option to grow as fast as possible. We had the option to grow as fast as we could earn money, which is very, very different. And I think where that led to good things for Jane is that it allowed us to really focus on quality through that whole period. Ali and I attended an accelerator program, and there was one of the sessions one day that was teaching about the customer journey, where this whole go-to-market funnel where you start with awareness and you move through to consideration, and all these things through adoption and activation, and then eventually churn. It was the first time we had been thinking about that and we were like, “Oh, how does this apply to our business?” And Ali and I just realized we had only been focused on this thing in the reverse order. We’d only been thinking about churn, because when you don’t have a lot of money, losing a customer is not good. We needed that money in order to meet payroll. So our entire focus was on, why would a customer choose to leave Jane at the beginning, or not take Jane after a demo? And we obsessed about it, and it got baked into our stated strategy as a company when we talked to our team, was, “We’re going to do two things. We’re going to perfect our product market fit and we’re going to provide amazing customer service.” And those were Jane’s two, we called it our growth strategy, which is funny looking back, it’s just so simple, but we stuck to it. Those two things, they’re in our decks going all the way back up until even this year.

Allen Pike: A story I heard Ali tell once that reflected that hierarchy of priorities was that at least at this time, and maybe this is still the case, was that your support people were answering sales inquiries, and at one point you had too many support queries, so you deferred not answering the sales inquiries because you’re like, “Oh, we need to provide the support first for existing users, and then if people want to onboard, we can help them.” And that’s to venture back, go-to-market things would probably not be the choice, let’s say, that a lot of companies would make. And I feel like that’s a good reflection of you living that value, even if it was maybe not, I imagine you’ve probably addressed that tension, so you can do both now, but…

Trevor Johnston: That’s a great example. When you look back, in retrospect, it’s 85% of our new customers still come from a referral from an existing customer. The things that led to that are, yes, we have a good product, the customer service is the number one thing that’s talked about in those referrals. I think of how you allocate that or think about that spend, that’s not a cost center, that customer service engine, and you could describe them as doing, they’re being our inbound team too, because we do have people kicking the tires on Jane and they want a demo. Our customer service team does the demo. That spend on providing that level of customer service, it’s almost like CAC to turn our customers into our salespeople. When we look back on it, we can see how you could justify the financial decisions there, to build it this way.

Allen Pike: Yeah, certainly I’m predisposed as a product person to be like, “That’s the way to do it. Make your product your salesperson.” I think it just depends a bit what kind of business you’re in, and you are fortunate to be in a business where that actually worked.

Trevor Johnston: Yes, in the market where that works. It doesn’t work in every market, and I have friends who have businesses in slightly different markets and it’s not going like that. And there’s a couple of things that was maybe a little bit unique to this tier of healthcare we’re working in. One is that they talk to each other and they’re not that competitive with each other because they’re not thinking of themselves as businesses. They’re thinking of themselves as helpers, as healers. They’re at capacity, for the most part. Most of these businesses are doing well. They’re not afraid to recommend a good thing to their colleague down the street when they ask. And the other aspect that was interesting to us is that they’re kind of forced to collaborate, these people, because they have to attend annual conferences to get their education credits, which puts them all in a room together and they have conversations about things like what software to use. And then that leads to the online version where there’s all of these private Facebook Groups full of these practitioners where they ask these kind of questions, like, “What are you using for medical records? What are you using for fax?” Or whatever it is they need. And it allows for this viral thing to happen in this non-competitive way. So yeah, it was an industry where word could spread.

Allen Pike: It’s an interesting dynamic, and how that resonates with what I’ve been learning building tools for developers recently, which you even think of a developer and a physiotherapist as a very different market, and in some ways they’re different, but developers also share that dynamic that you just mentioned, which is, they do a lot of talking to each other and saying, “What tool are you using?” And if a tool really is 10 times better than what people are using today, like the Cursor IDE, I hadn’t heard of it six months ago. And now, it’s just like everybody’s talking about it constantly. Everyone’s either saying, “Oh, I’m using it.” Or they’re like, “Oh, I’m not allowed to use it based on this or that, but I’m curious about it,” or whatever. And that’s just completely gone from zero to 100. It’s pretty fun to have a market where in theory, if you build this, just a product that really solves the problem well and it’s delightful, that your users will advocate it to one another, rather than maybe enterprise ETL backend software, where probably you have to do every single sale.

Trevor Johnston: Yeah, I think that’s a great parallel.

Allen Pike: Speaking of engineering, I want to touch a little bit on hiring and building great teams. Obviously, you mentioned the support piece, which is a super fascinating part of Jane’s success. How big is Jane’s engineering team these days though?

Trevor Johnston: If we include product management, design and engineering as the product org, it’s just over 200 people, and that consists of 25 teams in there. I think 20 of them would be value stream teams focused on owning parts of Jane’s feature set, and then the rest on the platform and enablement side.

Allen Pike: That 200 person size is in this, just on the other side of the infamous Dunbar’s number, you talk to various leaders, people who have built engineering teams, and often you hear when you surpass that 100, 150th thing, that sometimes patterns that you were following didn’t stop working or you end up having to change or rethink how the teams are laid out and work together. Were there any lessons or stories from crossing that chasm, or has it been pretty seamless so far?

Trevor Johnston: It has not been seamless. No. The Dunbar’s number thing is interesting. Just as an entire company, you hear that talked about a lot and we were always thinking about it, like at 50 people, “Okay, we’re going to be 100 people in a year, and then 150 six months after that, that’ll be the point where we hit that number.” When the COVID shutdown happened in 2020, we were just about to hit 100 people. So this whole anticipation of what that was going to feel like, it kind of evaporated because we didn’t get to see it because we weren’t together anymore in that transition from being an in-office company to a remote company, which ended up being a permanent and very successful transition for Jane. But it just meant that we never got to see that change in the way that it’s written about. And it actually makes me wonder, Dunbar’s number, is it different for in-person companies versus remote companies? Because I feel like in a remote-first company, there’s already this inability to really know everybody in the same way that you might in an in-person company. It sort of takes away some of the importance of that whole concept that’s in the Dunbar’s number being a remote-first company.

Allen Pike: It seems like if there was a number, it would be lower if you’re like, “At what number could everyone…” And obviously, Dunbar’s number-

Trevor Johnston: How many Zoom friends can you have, versus in an office? Yeah.

Allen Pike: Yes. If you actually in purpose ran into somebody in the elevator or whatever.

Trevor Johnston: Yeah, exactly.

Allen Pike: That makes a lot of sense.

Trevor Johnston: Jane was a bit slow to add process and structure to our engineering org, and I think that was a lot just about my bent, being just an entrepreneurial type who likes to just figure it out as we go and just make good decisions and be very full stack in every way. So I resisted the idea of bringing in engineering managers for probably too long, and then in all the layers that go with that. When we first realized things were starting to get unwieldy, essentially the team was me and 20 devs and a designer. I didn’t know what product management was at the time, and I started to learn about that from a guy I met in a coffee shop and he started teaching me about product management, and then we ended up hiring him as our head of product.

Allen Pike: Nice.

Trevor Johnston: And he’s still with us today. But yeah, that was a real transition. I think the hard part of that transition for me, and I think for a lot of companies, it’s like the separation of roles that used to happen inside one brain and then you have to separate those things out into separate humans and these separate functions, and then have them collaborate and get to good results. And then when there’s 200 people in that org, you’ve separated out all those functions and then they report up different functional trees and the layers of collaboration that’s required to get to decision, it’s fascinating how the task has changed, at least with my job from figuring out how to build and design a product to now figuring out how to build and design an org structure that is capable of making great decisions to build the product.

Allen Pike: You end up having to try to build the exoskeleton giant robot that you’re piloting, rather than personally chiseling the marble.

Trevor Johnston: That was a tricky transition for me, because I’m a builder and I love being hands-on. And when it hit the point where I realized me submitting pull requests was no longer a good idea…

Allen Pike: That’s hard.

Trevor Johnston: It is so hard. It’s so fun.

Allen Pike: I went through that with my last startup and now I’m back into doing the pull requests and it being reasonable at our size, and I know eventually it will happen again. Or I don’t know. Do you do no pull requests at all, or do occasionally, you have your side thing that Trevor’s allowed to… you’re not going to get side eye from the team for trying to make changes too?

Trevor Johnston: I’ve had to go cold turkey, and it’s actually for my own brain’s benefit, because when I get into that mode of that on the tools problem-solving, I go so deep into the tunnel that I don’t want to do anything else. It’s almost like a drug. Everything else falls apart. And then if I have to go in to be a CEO and mature and attend meetings and do the rest of the job, I can’t. That context, which is too hard for me, so I’ve had to go cold turkey and just stay in my new seat.

Allen Pike: That’s interesting. It plays into something that I wanted to ask about, which is that you have these values at Jane, and one of them is fun and having fun, and I know I always said before that you and her check in periodically, “Are you having fun? Are you still having fun?” So that makes me ask, could you tell a time when you weren’t having fun, a story of that and how that came to be and what the resolution was of that? Because that was one of my moments, I remember when I stopped having fun and had to re-find the fun in not coding, not actively building. So I don’t know what your version of that story would be.

Trevor Johnston: That is my story, is when I had to go through this transition from being right in the weeds along shoulder-to-shoulder with the team, building the things, to having to lead through influence and not get to actually be the person creating the solution. That led to the, “I’m not sure if I’m having fun,” moment. And I think it was really about having to recalibrate my own personal definition of, what is a successful day? How do I measure that I was productive today? Because I used to be able to have this tangible, “I created this thing or I submitted these pull requests, or whatever, I launched this feature,” to when you finish a six hour of Zoom meetings in a day, there isn’t that tangible result that you can look at and measure yourself with. And that’s been, it was a multi-year journey for me to adjust that internal calibration. And I have settled into it over the last year and I am having fun growing this company, but it was a real change, complete change.

Allen Pike: The six hours Zoom meetings or more hits hard and I’ve been there. I think most leaders end up, if you’re not really actively working against it, the Zoom meetings will consume every hour, including the lunch hour. And if you go from first principles and you say, “Well, I want to support my team and make sure everyone’s doing the best. I don’t want to block people.” And you come with a whole bunch of reasonable intentions, and then all of those tend to add a certain scale of company leads to, “Okay, well I should take this extra meeting, and I should join in this one, and I should…” But you’ve gotten to the point now where you’re having fun. So what’s the most fun part? Obviously being in a Zoom meeting isn’t inherently fun, but you’re finding the fun in it. What’s making it fun for you or how has that settled in for you as fun?

Trevor Johnston: Being in this seat today, we have 550 staff and we have 50,000 customers, and we’re still growing over 40% year-over-year. And we’re doing it profitably, which is in the big picture of getting to run a software company, there’s a lot of fun in the stage we’re at right now, and then there’s a lot of fun in the chess game of figuring out what’s next for Jane. I love being part of dreaming up the vision for the next few years, of what are the most important things we could do to adjust our product roadmap to take advantage of all these opportunities we’re seeing in the market? That’s super fun. We have always had this, we try to follow poll, in this weird part of healthcare we’re in, where we’re servicing so many different specialties of healthcare. It’s like over 70 different healthcare disciplines that are finding success in Jane. We track all these little disciplines by their discipline and which country they’re in, and when we see them start to, the little slope of that discipline start to increase, we’re like, “Hey, what’s going on there?” And we will dig in, try to learn everything we can about what’s working, what’s not working for that customer segment, figure out if there’s some product market fit gap that could be really powerful to fill, and see if we can unlock that referral growth thing that we’ve seen a bunch of times in these other healthcare disciplines. That’s a really fun game. It’s just figuring out what’s happening, figure out what the need is, figure out how we could adjust Jane in a way that services them, but hopefully benefits everybody because that’s the best type of change we could make in the app, and then see what that does to unlock growth. That’s super fun.

Allen Pike: You’ve hit on or sketched around at least a type of fun that I hear a lot of leaders and some folks have been on the show talk about, is it’s fun for your business to succeed, which is a dumb thing to say, but sometimes Charity Majors, who was on the show, is the CTO, co-founder of Honeycomb, she talks about how, and I think she talked on the show about how sometimes people will try to create a fun environment by having mandatory fun, like, “It’s fun hour. We’re all going to have fun now, and everyone has to have an emoji on their hat or whatever.” But a lot more fun is if you hire a bunch of people who care a lot about a problem and who are awesome at their jobs, and then they kick ass together. That’s fun. And that sounds like there’s some of that there.

Trevor Johnston: Yeah, winning is fun, but doing good work is fun too. And sometimes when I think about our values, we say that one of those values is, have fun. And have fun is this litmus test to check that everything else is going well because if you’re not having fun, maybe there’s a problem somewhere we need to go fix. I like the word, you’re feeling fulfilled. I think that’s a big part of the fun definition for me. I can’t remember the name of the book, but it talks about the three most important factors in a career in terms of feeling fulfilled is having purpose, autonomy, and mastery as these three aspects that are the most important. And I’ve always thought about those three things throughout my entire career. Those three things, when they’re all there, I would say it equals fun, is at the end of that. When you’re working on something that you feel like is important and meaningful, you have some control over how you work and your role in making that thing better, the autonomy. And you’re getting better at the thing you do, you’re getting to improve your craft. That’s exciting, that’s addictive kind of fun. So when we say our value is to have fun, that’s what I’m shooting for, for me and my staff, is that people could be experiencing that.

Allen Pike: Well, you mentioned mastery, which obviously it can feel good to have mastered something and be really good at it, but I think a lot of folks, at least in our industry, share this feeling of, it’s even more to be not quite mastering it, but getting there. When you’re learning and getting better-

Trevor Johnston: Yeah, the learning process.

Allen Pike: Right. You’re like, “Oh man, this isn’t perfect, but it’s so much better than we did last time. Oh, what can we do? How can we get even better?”

Trevor Johnston: That’s true. That’s the antithesis to boredom for sure, is learning new things.

Allen Pike: Which you’re going to do if your business is growing 40, 50% every year, compound, compound, compound. You have to keep learning new things. That’s necessarily going to be the case. Going back to this path, the growth path, businesses always have a certain amount of path dependence where the way that things are done and the way the business is set up and your product and your team always, there’s a big contributor from some of the early decisions that you made that bring it to be the way that it is. How do you think about the early decisions that you were making as you were building out this business and setting things up the way that they could be as successful as they have now, in terms of obviously, when you’re early on you’re making these decisions where you have to balance moving fast versus setting a good foundation. There’s always this tension and probably even at the scale you are now, there’s this tension. Is that something you would consciously frame, or was it just on a decision-by-decision basis for setting that path?

Trevor Johnston: I think maybe one of the opinions we had that wasn’t a standard opinion was, I don’t think I believed in the idea of an MVP. I think there’s a critical mass required of value in a feature for it to be worth someone adopting. And thinking back to the decisions we made about what to build and how far to take each thing before we launched it, especially in the first five years, it was not MVP thinking. It was like, “Let’s build a really good feature.” We did do it collaboratively. It wasn’t in a vacuum where we didn’t have customer feedback. We always had early customers we’d run stuff by. And also when you’re small, you can just move really quick so you get feedback quickly and you iterate that ideal thing that’s really hard to do it, the size we’re at now, what’s happening very naturally. I think MVPs make sense in some cases for a system of record, the nature of our product. I don’t think they make a ton of sense.

Allen Pike: Were there any times where that led you then though, to launch something? I’m down with that, back to my own personal biases. I love polishing things that make them delightful. I’ll always take an excuse to do that, but were there any times where the team ended up building and putting a lot of resources into something and getting some initial customer feedback, but being like, “Well, if we’re going to launch it, it has to be good.” And then spending all the resources, making something good that ended up not really actually having been worth finishing?

Trevor Johnston: Yeah, not every single feature in Jane was a winner, that’s for sure. We built something we probably shouldn’t have built. We maybe should have partnered, thinking back on it, but we added a reputation management system into Jane to handle Google reviews and all of that, which there was lots of good reasons to do that. And there was some forward-looking defensive reasons. We wanted that review data in our database for future feature ideas. We didn’t continue to invest in that product and iterate on it, and it just never hit that bar, which is quite high, because some really good products out there that do that alone, and we didn’t put enough into it to get it to that point. It’s just been, it’s there, it works, but no one’s raving about it. Yeah, not every feature made it all the way.

Allen Pike: That’s an interesting one because you’re talking about how shipping these a little early MVP that proves something out. You would’ve gotten the signal if you shipped an earlier rougher version of that, but if some of your feeling, or at least your hypothesis is that it didn’t succeed because it wasn’t even yet more developed, then you would still have gotten that same data point, which is like, “Well, yeah, of course it’s not being used yet because it’s really rough around the edges. So if we’re going to do this right, are we going to do it right or not?” And I don’t know.

Trevor Johnston: Yeah, and I think that’s also, I think we’ve maybe suffered a little bit just from having too many things on the go at that point. I think it was a tricky point in our scale to be adding kind a marketing type feature onto our very administrative feature set.

Allen Pike: That is kind of the common playbook though, that a vertical SaaS company, most of the people I’ve talked to that have been founders or building in those businesses tend to think of the model of like, “Okay, we have these customers. They love us. Talk to people who work with Shopify.” They’re like, “Okay, people love Shopify. They want everything to be done by Shopify. Can we just be their credit card? Can we be everything?” And obviously, that’s a way to get more and more revenue per user. It doesn’t seem as much from the way you’ve talked, in that I’ve seen the way that Jane has evolved, it doesn’t seem that your mindset has been as much as that default playbook of just expand. “How do we double? How do we 10X the revenue we make per clinic?” Is that a conscious strategic decision or is it just a side effect of this following the poll for compound growth mindset?

Trevor Johnston: Yeah, it’s been a very deliberate decision to focus on logo growth right now because we can just see there’s still so much room in the market and it’s still a bit of a land grab in some of these markets. So first person on the scene is going to get the customers in these markets. We had, especially over the last five years, a very intentional mentality to continue to focus on product market fit for our core functions in Jane to increase adoption. We’re at a point now where we are really adjusting that strategy and we are still very ambitious to grow market share, but we are introducing new products and new features. We just introduced new plans where there’s value-based plans, so there’s upgrade paths for the first time in Jane. We’re really just starting to build those muscles around what expansion looks like at Jane. And there’s some really natural expansion that people are loving, like Jane’s telehealth product. It’s just needed by some people and they love it. And payments is a natural one that’s working really well. Finally, it’s taken us way too long, but we are becoming partner-friendly for the first time. We’re opening up APIs and we’re building an STK that works in Jane’s clinical medical records area for other products to be present in the Jane UI.

Allen Pike: Well, so you had a partnership with a faxing service, which is like, yes, it’s a ridiculous that you’re working on faxing technology in 2024, but also all the medical people, providers I know are so glad to have anything that will relieve them from the pain of actually dealing with fax machines still.

Trevor Johnston: Exactly. It’s hilarious to see the enthusiasm coming from our users about fax being added to Jane.

Allen Pike: Faxing, it’s amazing. And obviously, you could have built that entirely yourself, but if you are partnering, then that increases the pace that you can solve some of the stuff that’s a little bit outside of your core.

Trevor Johnston: Exactly. Yeah, we’re still like, “Jane’s going to keep solving these core administrative problems that are common across our entire user base.” All of these healthcare specialties have their own specific needs, and that’s where we see this partnership strategy and bringing this other functionality into Jane is a really awesome solution, because it means Jane will just be capable of so many things that we could never, ever build ourselves.

Allen Pike: It’s also still pretty wild to be 10 years in, having grown so much and still have a feeling like, “Oh, there’s still just so much land grab available.” Which is areas where this product has just no competent provider even exists in these markets that you’re finding. That’s also pretty awesome, to have that. I feel like I have to touch on a technical topic because I’m engineering, I’m a builder in background, you’re a builder by background. Jane’s build is very, I think one way you did maybe take the default startup playbook in the 2010s is that Jane’s built on Rails, is built as a Rails Monolith, as with many great businesses built in that era, and GitHub and Shopify, obviously. You now have a more than 200-person product engineering design team. It’s 10 years in. What’s the vibe? Is it just like, “Rails forever? The Monolith will grow forever.” Is it like, “Oh, actually…” What you’re finding more, you’re diversifying the tools that you’re using now that you have more diverse needs and more diverse team. How’s it going in Rails land, I guess?

Trevor Johnston: Yeah. Rails land. This is a very divisive topic, I feel.

Allen Pike: Yeah, I find it, I’m slightly trying to initiate an opinion in one way or the other because obviously it’s something that can be very personal to people. It’s like someone built their career on something, or their entire company is built on something, they don’t really feel like they have that much of a choice, and so you get strong opinions. But I’m curious if you have any strong opinions, perhaps weakly held about how that is.

Trevor Johnston: I think this is a common topic at Jane and we’re always trying to think of what the best next move is. And the thing I’ll say about Rails is, it can get you a long way pretty quickly. I don’t regret the choice one bit to build Jane as a Rails Monolith. There’s all sorts of little decisions within the way we built Jane as a Rails Monolith that yes, we could have avoided some pitfalls. There’s some things about the way Rails is out of the box. It just encourages some bad habits with-

Allen Pike: An example come to mind? Save someone some future pain.

Trevor Johnston: The lack of domain boundaries across a really big app like Jane becomes the most problematic spot where you don’t realize that this thing is, there weren’t strict APIs between different parts of the code, so they affect each other in unexpected ways, and that’s the place where we experienced some pain with Rails. We’ve also avoided a lot of the common pain with Rails. By the way, because our customers are completely siloed, they don’t have any interaction with each other. So we can scale the Rails server side just completely horizontally. We just have these 30 something pods, or now 50 something pods of complete Jane instances that are not dependent on each other, and they host a whole bunch of customers, and they’re just happily hosted away there. In some ways, it’s worked really amazingly well. In terms of, I think where I hear the most, I think the hardest thing about a Rails Monolith is new devs joining the company. I don’t think they love joining a Rails Monolith. That’s not an enjoyable experience, for the most part. They’re walking into this thing that’s big and it’s heavy and it’s slow to change, and unexpected things happen. They’re hard to deploy. And then you have to deal with Rails upgrades, which you have to QA that across every single function in the app that has to go live all on one click of a switch. That’s a tough part of the Rails Monolith, but I think we’re just… What’s our stance? I think we realize it’s not going to go anywhere. There’s way too much invested in this thing, so we’re continuing to invest in making the code higher quality, figuring out ways we can create better domain boundaries within the app, budgeting time for that refactoring work. But we’re also just trying to figure out how to have the right attitude about it. The thing I’ve found can be a little bit harmful is when there becomes a bit of an easy target that’s like, “Oh, let’s just blame the Monolith.” Everything that comes up, it’s like, “Oh, it’s because of the Monolith.” And we kind of need to go a level deeper than that. Yes, we have a Monolith. Yes, it has issues, but let’s talk about what the specific problems are, a layer down from that and how do we make that better? I think it’s just choosing to love the Monolith and make it as good as possible, is where we’re at for the bulk of it. We are introducing new services, so if anything at Jane is needing to be more of a central service in some way, we’re letting teams choose the technology they want to use. Sometimes they’re choosing Rails and sometimes they’re not. We have some services that we’re working on that are more public-facing on the patient side of things. They’re going to be higher traffic, so we’re thinking about technologies that are more performant by default than Rails. I think that’s working well.

Allen Pike: It’s an interesting dynamic. We have known as an industry for decades that if you can get an incredibly performant application where everything is responding within 100 milliseconds, it has meaningful positive effects on user metrics and everything. But to actually hold that bar and really scale a full complex system and really keep holding that bar, it’s pretty rare the teams actually do it, which is an interesting dynamic. It’s like we can all know and we can all strive and you try to fight back down to, and occasionally you see teams where the upside is so huge that they do hold that bar, but it can feel a little Sisyphean sometimes.

Trevor Johnston: That’s right. There’s a lot of implementation decisions. You could be using the fastest tech in the world, but you still might write some slow code on top of it.

Allen Pike: My instinct, I don’t know if you’ve gotten far enough on this path to have an opinion on it yet, but my instinct is that iterating and evolving and modernizing a large Monolith code base like Rails is going to be a lot easier in 2025 than it would’ve been in 2023 with the acceleration of tools, like I mentioned, Cursor. I guess you’re not doing pull requests now, so you’re… maybe not had the blessing, pleasure of having used it, but with the where Claude 3.5 and GPT-4o are today, let alone where their successors will be in a year, the ability to do a migration, like Amazon talks about how, and obviously they have a little bit of a stake because they want you to use their AI stuff, but they’re talking about how they saved literally millions of person hours migrating from some version of Java to some other version of Java, which I was pretty skeptical of until I started actually using those tools to do mechanical migrations of stuff in our much smaller code base, and I was literally 10 times faster. Obviously, if you have to do a bunch of manual QA, that’s a whole different AI question of, “Can we accelerate that?” But just in terms of the moderators and code base, “Okay, from now on, we’re not going to do this, or we’re going to move from this version to this version.” It’s really impactful about, at least for me personally, how it feels as an engineer to be looking at a code base that I feel like I can modernize 10 times faster than if it’s just like, “Oh, it feels like an endless boil the ocean thing to port from some version of something to some new version.”

Trevor Johnston: Yeah, that is a fantastic use of these AI-powered tools, to go from code-to-code. It’s less subjective, for sure.

Allen Pike: And working code to working code, so cool. Well, this has been wonderful. Thank you so much for making the time to chat about this stuff. Where can people go to learn more about you and your work and follow your story?

Trevor Johnston: You’re welcome to check us out at Jane.app. In terms of learning more about me, I’m not that present out there, but you can always reach me if you want to, email in the company.

Allen Pike: Well, thanks for being on the show. Big thanks to Ali for connecting us and to Mark Haslett for suggesting some of the great questions on the agenda. It Shipped That Way is brought to you by SteamClock Software. If you’re a growing business and your customers need a really nice mobile app, get in touch with SteamClock. And that’s it for today. You can give us feedback, follow us on social media or rate the show by going to, itshipped.fm/contact. Until next time, keep shipping.