The UI Audit: Interview with Tope Awotona of Calendly

Published March 22, 2016 by Jane Portman
Categories:

This is a special founder interview from Jane’s book, The UI Audit. In this interview Tope Awotona, the founder of Calendly, shares his product development journey. To build this revolutionary scheduling tool, he reviewed over 30 competitors — all to find out their strengths and weaknesses. Tope shares how he developed his product as a non-technical founder, and how Calendly leverages free plans as a viral form of marketing.

Download the MP3 audio file: right-click here and choose Save As.

Get the book: click here to pre-order.

Show Notes

Full Transcript

Jane: Hello, ladies and gentlemen, and welcome to The UI Audit book. And today we have another awesome interview with a very successful founder. His name is Tope Awotona and he is the founder of Calendly, which is the software me and my friends use daily and admire highly. So, Tope, hi!

Tope: Hi! How are you, Jane?

Jane: I’m doing great! Thank you so much for joining us today. I’m sure listeners will take away so many things from you.

Tope: It is my pleasure to do this.

Jane: Great! So, before we get started, I know what Calendly is and I use it daily, but tell all users what Calendly does and how you got started with this software product.

Tope: Sure. Calendly is for those people who do not like sending seven emails to find a meeting time. So for people in customer facing roles, people like you, podcasters who are scheduling interviews, it could be a sales rep who’s doing a lot of prospecting, it could be a financial services advisor that has clients. They spend a lot of their time trying to find a time to meet with the clients and before Calendly went alive like this ‘Are you available at 2 PM on Tuesday?’ and then they’d come back and say ‘No, let’s try Wednesday 3 PM’ and then the other person would say ‘Hey, that doesn’t work for me’ and before you know it, you’ve sent seven emails trying to find a time that works.

A lot of times it takes more time to find a meeting time than the actual meeting lasts. I actually had the same problem and I came up with the idea for Calendly. So what Calendly does is instead of trading seven emails, you share a link with the invitee and when they click on that link they will see all the available times that you’re available to meet with them and to pick one that works for them at their convenience. It gets added to Buzz Party’s calendars. It’s a really, really powerful productivity tool for people in all kinds of different roles.

Jane: Absolutely. I second that. And I’m in a different time zone, I’m in Russia. So in addition to that, you know, all this mess of adding and subtracting 8 hours, it’s just driving me crazy — I mean, it was before Calendly appeared. So thank you so much about that.
Tope: Yeah, you’re welcome. You’re so right. I had a person in need for this so I kind of had a vested interest in making sure that we would create something that would not only be a successful business, but would also personally help me. It’s worked out that way so far.

Jane: So you started out to scratch your own itch, but how did you make sure that the idea was successful, I mean, how did it get started with the business itself?

Tope: Yes, I can share a little bit about that too. Before Calendly I had actually dabbled in a few business ideas, some side projects, nothing really serious. But what I learned from those lessons is that it’s very difficult to passively grow a solid business. So you get what you put out beneath it. Before that I found myself looking for business ideas rather than letting the ideas come to me and rather than really working on ideas that needed to be worked on, working on problems that were meaningful to people and problems that people were willing to invest time and effort into solving.

Fast forward to two years ago, I was a software sales rep for a large company called EMC. I sold to a lot of clients and I spent a lot of time trading emails with people and I thought there had to be a better way than trading emails back and forth with people, so I started looking for scheduling tools. And I found a lot of scheduling — right? But I found a lot of them, you know, there were a lot of scheduling tools out there for doctors, for dentists, for masseuses, for chiropractors, so for a lot of people in the services business, but there were not as many appointment scheduling tools for sales people, for recruiters, for podcasters. So that kind of helped me with validating the idea that it’s obvious that people are willing and able to pay for scheduling products, because we saw them being used in other different verticals and in other different industries, but none had been really created from the ground up to address the needs of business professionals.

Jane: Absolutely. So you got that need that you were ready to satisfy and how did you set out to build the product?

Tope: Initially, when I first had the idea, I was not committed to actually building a product. I just wanted to do a ton of customer discovery and see if there really was an opening for yet another scheduling tool. So I spent 2–3 months without being attached to a specific outcome, I just let the discovery lead me to whether a new product needed to be built or not.

And once I confirmed that there was large market and that we could do something that would be compelling and introduced new users to the market and also convert users of their legacy scheduling tools over to this new product, I was committed to developing it. Initially, I tried to find a typical co-founder and it was difficult to and I did not want to wait, so what I ended up doing is I ended up finding a great development agency in Europe actually. And that’s how we got it started.

Jane: Awesome. And, you know, your way is completely different from most founders experience, because you have so much sales experience upfront and this is a rare occasion. At the same time, you spent the first few months validating the idea and growing the market, which is also a rare occasion because, you know, most founders have a development background and they have a tendency to dive into development from day one. And this is not the right thing to do. I’m so glad that you’re completely approaching it from a different side.

Tope: Well, yes, there’s two good reasons for that. One of the reasons was that I had two failed projects that didn’t work so well. So the first one, I thought I knew everything there was to know about the market, I launched this e-commerce website and then I found out that after I launched it there was a lot I didn’t know about it and I had no business. If I would’ve known what didn’t know about it before I went into it, I would’ve probably not gone into the market.

Jane: What kind of obstacle did you face then? Tell us more.

Tope: I’ll be more specific. So it was an e-commerce store where I sold projectors. But I didn’t even bought a projector in my life before. I was not a projector enthusiast, I knew nothing about projectors besides the models that I wanted to carry and sell. So when people would come in and they would ask questions about projectors, I didn’t know the answers, I didn’t really know how to guide them. I had no good reason for being in the projector business besides the fact that I wanted to start a business.

So I had two options at that time. I could either learn about the projector business, which I decided I didn’t want to learn about projectors, it was not exciting to me. And I thought that not only is it important for you to know the market that you want to be in, it’s important that you’re generally excited about things, something that you’re passionate about. And I just was not passionate about projectors.

So that’s one reason which once I had the idea for Calendly, I spent a lot of time doing customer discovery before I even went into the market. I wanted to know exactly why this product would be better and be able to articulate why it’s better than the competition and who is good for, who is not so good for. You have to know those things. It should be able to wake you up at 5 o’clock in the middle of the night and be able to tell you why Calendly is the best scheduling solution for you. So that was one big reason I wasted a lot of time.

The second big reason was because I was bootstrapping the company and I was not an engineer, I knew that I had to pay for every single dollar of development, I thought that by doing customer discovery and doing a really good job at customer discovery, with the smallest budget possible, I could build the most compelling product. If development is key to you, it doesn’t really matter if you build something and it doesn’t work, you can scrap it and start all over again, but I knew that I had a good budget but it did not allow for too much of an error. My failure margin was kind of thin so I knew that I needed to get it relatively right and I needed to build the right set of features that would be compelling for a user on day one. And that’s also the reason why I doubled down on customer discovery.

Jane: Absolutely. Before I ask you questions on how you nailed the design, can you tell us more about the customer discovery phase? Because this is extremely important and you just seem to have been very successful there.

Tope: Yeah. I think customer discovery for me was… that I had an opinion about scheduling myself. I scheduled a ton of meetings and I still schedule a ton of meetings. There’s a few users out there close to me, but I’m still one of the heaviest users of Calendly two years after the fact — right? And there are people who’ve gone on to whatever. So I know a lot about scheduling just because I scheduled a lot of meeting as a sales person. So that’s one thing, it’s just being able to know and having your own judgment about what matters and what doesn’t matter; that’s extremely important. The second part is placing a lot of premium on not what people tell you, but what they actually do. One of the most interesting parts of the customer discovery process for me was I did not interview one single person. What I actually did instead was I used a lot of the legacy scheduling tools, I think I maybe used probably 30–40 different scheduling tools.

Jane: And you did that yourself. Amazing!

Tope: Myself. I didn’t outsource it to the engineers, I did it myself. I signed up for every single one of them, became expert at using every single one of them, I read through their support portals, what did people really like about the product, what did they hate about the product, what were they complaining about, what kinds of things were they…just what did they like, what did they not like. And I had a really, really good idea. That’s what customer discovery was for me. So just looking at the people who were actually using it today, who were using legacy scheduling tool at the time and try to understand what they liked, which is very important, to know what people already like and exists in tools they have and what they feel like it’s missing or what they feel like it’s poorly executed.

Jane: This is eye-opening. Because you entered a saturated market, a super saturated, very mature and you managed to scrape all the best features together into an amazing product that clearly was a winner and is a winner today. This is amazing.

Tope: Thank you. And I guess the one other thing I wanted to act about is just knowing who your user base is. So while I took a lot of time to learn about the legacy scheduling tools, I also knew that we weren’t building a product that…we weren’t trying to just modernize the legacy scheduling tools, we were trying to build a different scheduling tool. Because, for one, a lot of the legacy scheduling tools were really built for, like I said, people in the health and beauty market, so doctors, maybe people who owned saloons and things like that and we knew those are not the people who we were building for.

So from day one we eliminated a lot of the features that a business professional wouldn’t need. And just the way we thought of the availability…look at the health and beauty market for example, they have the same set hours, Monday through Friday, and they don’t need to be able to customize different availability based on the different types of meetings, there are other things that needed customizing. But anyway, we just kind of knew that our audience was the business professionals and we were laser-focused on building the best set of features for the business professionals and not try to build a product that worked for business professionals and health and beauty folks, but coincidentally, because we’ve done it so well for business professionals, probably 10–20% of our user base are people in the health and beauty space, but that’s not really our core audience that we’re building for, if that kind of helps.

Jane: Absolutely. Interesting, because I had a question for you that you’re appealing to a very wide audience, but from your standpoint I see that you’re appealing to a narrow niche as opposed to that health and beauty and medical industry and everything. So it’s very interesting how we look at the problem. But you still don’t have a very defined target audience, like ‘designers who are 30-years-old, live in America’, you’re targeting an audience that seems to be quite big still, even though we imagine that you don’t include beauty consultants or whatever. Still, how do you find people online who you market to?

Tope: Our marketing strategy to date has been primarily an inbound marketing approach. So what we do is we know that if we make Calendly super useful for our existing users, we know that they’ll use it and when they use it, they cannot use it in a vacuum, so it’s not really worth your time to schedule a meeting with yourself. So we know that if we make our users happy, they will invite other people to schedule meetings with them and once that happens, there’s new people who find out about Calendly and then the cycle repeats itself. So that has been our primary user acquisition strategy to date. And what we do is once those people then arrive on Calendly, we educate them on the different use cases and who the ideal Calendly user is and how they would use it. So far what we’ve done is just doing a job, trying to focus our efforts on once people find out about Calendly, we try to highlight the fact that they’re probably the ideal user or not.

Jane: You have the viral component built right into the app itself.

Tope: Correct. A very strong viral component.

Jane: That’s awesome. Could you share some kind of numbers with us? I know it’s very confidential, but maybe the number of your user base or some hint. We’re especially interested in the free and paid breakdown.

Tope: I can tell you that about 8% of the total registered user base is on a paid plan. The majority of our users are on the free plan and we’re perfectly okay with that. We actually made our free plan very, very powerful to have that kind of distribution so that only the super advanced users would be on a paid plan.

Jane: Why would you do that? Because I’m on a free plan, even though I like paying to other businesses. It’s just really very feature rich.

Tope: Yes. So why do we do that? We do that because the free users help us acquire paid users even in spite of giving so many people the app for free, the free users help us find the paid users and when you look at the cost of acquiring a customer for us, it is still cheaper with the kind of distribution that we have.

Jane: Got it. Yeah, very smart.

Tope: It’s a lot cheaper for us to have that kind of formula model that has a rich free component to it that it would be if we had to acquire each customer through paid advertising, for example.

Jane: That makes perfect sense.

Tope: Just to give you an idea of what the size of the user base is, every single month we have roughly about 200,000 people using Calendly and that number is generally growing about double digits every single month.

Jane: Amazing. I’m so happy for you. This is a bootstrapper’s dream right there.

Tope: It is. But we’re hungry to do more and we’re working on so much more.

Jane: Great. So going back to design, when I first opened up Calendly a year and something ago, I was immediately struck by the quality of your UI. It’s esthetically pleasant, it’s clean. And I know you hired an agency to do that, but I’m sure you did manage the process very much.

Tope: I did. So I think it starts I guess with some of the other things I mentioned earlier, you have to have your own judgment about what’s important. It’s easy to say simplicity is important, it’s easy to say design… aesthetics have to look good, but it’s harder to make the call about when it looks good and when it’s simple or not.

Jane: Oh, yes.

Tope: Everyone sets out to build a simple product, nobody ever sets out to build an advanced product, but I think the challenge that you’re faced with as a product manager or as a company is what’s really, really important and what can 80% of the user base benefit from 80% of the time versus what helps 5% of the users 5% of the time.

Jane: So as far as you didn’t ever interview a live user, how did you know?

Tope: Well, in the beginning I did not interview real live users. Before we built the initial version of the product, we didn’t interview live users, but today we do that every single day. As a matter of fact, the very first probably several thousand Calendly users, I sent them direct emails from me and just asked for unsolicited feedback and whenever people would take me on, I got on the phone with those people and I learned a lot about all the things we got right and the things we needed to improve on.

So going back to your question about how did I know, I think… That’s where also I’m not so good at describing, I don’t know how to make somebody else a good judge of simplicity. I think I have the eye for it and I don’t know that I can break it down into a set of certain qualities, I just think I generally have that judgment. And I think part of that comes from being in software sales for a long time.

So one of my very first software sales jobs, I worked for a large enterprise software company and we would win a lot of deals when we sold to the management or when we sold to the IT leadership, because the product was so complicated. But if there was any user facing component of it, we did poorly. It was too clunky, it was too difficult for them, so I learned very quickly there, you know, about the importance of simplicity in design and how the product I was selling at the time lacked it.

Fast forward — after that experience I worked for another company which placed a huge emphasis on getting buy-in of the end-users, and I saw how the end-users responded whenever we were demoing the product to them and I saw the kind of things they liked. I saw what kind of features made them get it, and when they didn’t get it — in short, I learned a lot about what people respond to very well in terms of simplicity and usability. And I guess kind of acquired that knowledge over the years and it’s helped me kind of make product and design decision. I think a lot of that starts with the judgment of the person that’s building the product. And another way to find out is how people are using it. If they’re not using it, it’s probably very complicated. And if they are using it, maybe you got some things right, but nonetheless there’s always room for improvement.

Jane: Absolutely — and for your kind of software is incredibly important how it looks like, because it’s not just user-facing, it’s facing the clients of the user. And myself, I’m very sensitive to what my clients see, what kind of software I use. And Calendly just looks perfect, so you did the job 100% good.

Tope: Well, thank you. It’s interesting that you say that — in doing my customer discovery, one of the things I decided it would be an important differentiator for Calendly would be design, right? But nowhere in my research, did anybody say they wanted design? Nobody said ‘Hey, these existing tools are ugly’ They were ugly, but people weren’t really — it’s almost like they were happy to have, there were so excited about the utility they got from the product, they weren’t so focused on design. But it also so happened that at the time, I was coming up with an idea for Calendly, until today the most successful technology company is Apple and they built their whole business around simple, usable and powerful products. If it works well for the most profitable company of our time, surely it’s something that scheduling can use too, we can learn some lessons from them too.

Jane: Yes, but it’s much easier said than done, actually. What was your process? Did you put together wireframes, prototypes, did you test it? How did it go?

Tope: Yes, so our process is, before we build anything, we wireframe everything, right? As a matter of fact, depending on the complexity of the feature, we actually we’ll go as far as high fidelity mockups. And probably more often than not, we do high fidelity mockups than we do just wireframes, right? We try to mockup as much of the entire interaction as possible before we write a single line of code. And a lot of things we would find by mocking up every single state and every single case, what happens if there’s X amount of availability — what happens if you have all 7 days available versus if you had no dates available?

There’s all kinds of different scenarios, but one of the things we found is you can make some decisions about complexity in the design process. If it’s complex to — if it’s too many screens describing all of the different states of that page, it’s probably too complex, right? If you have to put a lot of text in on that page to explain what’s going on, it’s probably too complex. So before we ever started writing a single line of code, we kind of — the wireframes and the mockups give us an idea of are we overbuilding this or is it just the right amount of complexity? So that’s one the things we do that works really well for us.

And then the second part is, when we actually fast forward to the implementation piece, we don’t really develop any functionality without having fully mocked up what it looks like. It’s easier said than done, because a lot of time you’re anxious to — you want to move fast, but what we found is that every time we skipped our process, we end up rebuilding the stuff all over again. So that’s just a hard and fast school that we follow.

Finally, we involve the entire product team in testing the product, right? So the designers test, all the engineers test and when they test, we test not only from functionality and also stability and does a feature work, we also test for usability. If I wasn’t given a manual to read before, would I know how to use it? Right? So we involve everybody in the implementation process, the design review process is a very collaborative process between the engineers and the designers.

I, as the product manager, and the designer, we team up in the beginning to bring the initial concepts, to take them and advance them to the point in which they’re mockups. But as soon as we have 40–50% of the design is done, we show it to the engineers; they’ll present and they’ll give us their feedback on it. What you designed here looks good, but it’s going to be technically complex to implement that, or vice-versa. So we involve the entire product team in the design review process and again, once the product is ready to be tested, everybody’s involved on testing. So a combination of all these things is kind of what’s helped us for with building products with a good design.

Jane: What can I say? This is no small win, really, there.

Tope: It is not, and it’s an ongoing process and there’s even more that we want to do to get even better there.

Jane: Is it an in-house team that you have today or is it still the same agency working on your product?

Tope: It’s a mix of in-house talent and some offshore talent, right? But the design team is in the house.

Jane: So you’re investing heavily in that part.

Tope: Absolutely, absolutely. Yeah.

Jane: So, I imagine you receive like hundreds of thousands feature requests all the time, but you managed to keep your product lean. How do you do that?

Tope: I think it kind of goes back to being users of the product ourselves. This is just going off on a completely different angle there, but it’s amazing how many feature requests that we get that are really essentially people who may not have a full understanding of the capabilities that they already have in a Google Calendar, for example. So we spend a lot of our time probably educating people on how to use Google Calendar. So we want to make it clear that we’re not a calendar program, we’re a scheduling layer on top of Google Calendar, right?

But that aside, we use the same judgment that we used to build features in the first place: who needs that feature? We have about 8 core groups that we build the product for, right? So we talked about some of those earlier. It’s like sales people — so, is this something that, how many of these different persons will benefit from this feature? And of the different — if all of them do, how often do they need this feature? Is it something that comes up once a year, is it something that comes up 50 times a year? So you try to quantify — if we had this in place, who would use it, why would they use it and is this the best way for this problem to be solved.

We try to think of the problems holistically — users are really good at suggesting very specific features, but what we’d like to do is step back and understand, okay, they’re asking for this specific thing, but what are they really trying to do? And what else is related to this, and how can we find a coherent and comprehensive way to deliver this? We also like to really understand why people need things. Again, people are very good about requesting specific features, but how does that help them in their entire workflow? Their entire business process? So one of the things we try to do every single day is we try to understand what step into a larger, entire workflow is currently participating in?

So let’s take the case of an insights sales person — they use Calendly to schedule prospective calls and schedule demos, but before that happens, they’re using maybe automation systems to send out emails to this prospect in that same place. After that meeting is scheduled, this information now needs to float to this URL. We try to understand the larger picture and understand the job they’re actually trying to do. So some of the things we try to understand and figure out — is this something that’s useful, and how many people is it useful to, and how often would this even come into play?

Jane: Got it. So you’ve been out for 2 years, correct? And since your launch, how many new features did you introduce? Do you keep building stuff all the time?

Tope: We’re building stuff all the time. So there was — it would be hard to quantify the number of new features that we don’t. We use Pivotal Tracker — I don’t know if you’re familiar with it — and we follow the Agile development process, I would say every month we’re delivering about 100 stories or so. And maybe 70% of those are new features, 20% are maybe improvements for existing features, and then maybe 10% are things that are not even user-facing. Just to continue to beef up the architecture.

One of the first things we did when we first launched Calendly was when we first launched a product, we took about a 3-month hiatus in which we did not add a single new feature. And part of that was actually because of the availability of the engineering team that was working with us at the time. There was like a 3-month gap in which we couldn’t really get — I was building up the team in the early days and I didn’t have a full-time engineer.

It was actually a blessing in disguise. We launched the product and an interesting thing happens when you launch a product — either you’ve done all your research and you think you’re building something that’s gonna change the world. In the early days, you still don’t really know, right? So this is the first time, putting this in the hands of people, and you get all kinds of requests. I would use it more if this button was blue, I would use it more — it’s hard to sort of what’s trivial or what’s a deal-breaker.

Jane: It’s particularly tricky because most of your user base is on the free plan and those are specifically troublesome sometimes.

Tope: And the same people who would love the product for its simplicity want to add a lot more complexity to it. They say they want to keep it simple, which is true, but then if you add in all the features, it wouldn’t be simple anymore. And in the beginning, we had all these requests and people were coming with all kinds of great ideas. But we didn’t really know which ones were deal breakers, which ones were not. So I feel like, too, I thought I had enough feedback and I was ready to act on all these different things people were saying left and right, but I didn’t really have the resources because of the availability of the engineers.

I had to wait another 2–3 months to act on them. But an interesting thing happened in that time, is after 3 months, I’ve done a lot more feedback and I’ve actually been able to compare the feedback to the usage. So people were complaining about — the same people, I guess long story short, we found that we were able to really sort out who needed additional improvements to fine-tune the user experience, or who was never, who was probably never a good fit for the product, no matter what we added for it, right? Not being able to act on the requests right away helped us get better quality information to make really good decisions on, so when we had the engineer resource available, the features we ended up working on were complete different from what we would’ve worked on if we had all those resources right away. That happened to be a blessing in disguise for us, but at the time it felt frustrating.

Jane: Absolutely. So what is your philosophy? Do you believe that your product can be in a stable state of things or, why do you keep evolving? Do you think that you’re alive while you’re developing new features?

Tope: I’m a consumer myself, so I use a lot of different tools, and there’s nothing that makes me more happy than when I log into, let’s take Intercom for example, it’s a product that we use to communicate with our users. And nothing makes me more excited when I log in and I see a little update from them — we’ve added this, we’ve added that. It’s super exciting for an end-user when you release these new features.

We like the apps that we use that continuously innovate and we want to be that company. We think that constant innovation is super important, but you should also stay in tune with who you are, you should know who your users are, what they really want and you want to innovate without making the product bloated, right? So for us it’s just a question of we want to make sure our users continue to stay happy.

We know that all the apps around us are evolving every single day, so it’s important for us to be able to make changes, to be able to keep up with that. The innovation of other people — and maybe they’re in our space, maybe they’re in related spaces, but by constantly innovating, that’s the only way we can ensure that we’re constantly delivering value to our users. But we will always be that company — we won’t ever have a product that we’re not aggressively innovating.

Jane: Right. So you managed to bootstrap a company from scratch to super-successful consumer product which is gold, and the industry is very hard, and what would be your number one takeaway for our listeners when it comes to product design, product market fit?

Tope: I think those two things are the most — for me, because I did a lot of work around customer discovery and design, I was basically effectively able to grow the company to where we are today with a 10th of the resources that I would normally need. I look at it this way: there’s price on math you can do out there to figure it out, for each month of really good customer discovery you do, you probably save yourself $200,000 in developing costs. And maybe another 3 months in time to market. Doing those things upfront and getting them right upfront really saves you a lot of time and money. And that’s been my experience. Everything we’ve done, we could’ve done — if we didn’t get the design right, if we didn’t get the customer discovery right, maybe we have a product today, but maybe it takes us another 3 years to get to where we are today because we didn’t do all the research up front.

Jane: Absolutely, that’s great advice. Your advice on researching, existing products and using them actually, is something I’ve never seen before in such scale that you mentioned — 30 products!

Tope: It’s true. A lot of that comes from my business, from my sales background. So a lot of times, when you’re selling — I guess one of the things I learned in sales is when you’re selling to somebody, there’s always direct competition, there’s always indirect competition, right? So if you came to me today and said hey Tope, I want to sell you — every single day I get 30 different vendors who are looking to sell something to me. And all those things are probably important for their business, but there’s maybe we’re engaged in 3–4 other initiatives right now that, even though whatever they’re selling may be important, I’m still occupied with the different products that we’re working on right now.

We don’t have the time or the bandwidth to — let’s say we have the money, we don’t have the time to work on this other initiative that they have, just because the timing is off, right? Their competition in this case is not just whatever competitive product that exists, but it’s also how does this initiative compare in priority against all the other initiatives that we have? So it’s good to think about who your direct competitors, and also who are your indirect competitors as you build your product and make sure you have a really good strategy to address both of those.

Jane: Yes, and nobody is building products in a vacuum environment. Absolutely. So Tope, tell us where people can find Calendly online.

Tope: Yes, the address is calendly.com.

Jane: Surprisingly, yes.

Tope: Exactly, calendly.com. As you mentioned the product is free for the basic version and the basic version is very powerful. So what you can do with the basic version is all the things you do Jane, which allowed us to schedule this meeting. It’s very powerful — it has integration with your calendar, whether it’s Google Calendar, whether it’s Office 365. In a few weeks here we’ll be introducing integration for Outlook, so for all the Outlook users out there, we will now have a solution for them. And all of that comes with the basic plan. And with the premium plan, they just get more additional options to customize the experience even further.

Jane: Absolutely. All my consulting friends said hi and big thanks to you, really, when they learned I’m going to interview you for the book.

Tope: Thank you all for being users. You guys make it all possible.

Jane: Yeah, we live off it, seriously because there’s no easy way to schedule a consulting meetup, really. So, Tope, thank you so much for sharing your advice. This is incredible and I’m sure our users will take away so many things while building their own products. And I hope your business keeps blossoming.

Tope: Thank you very much, and I appreciate the time, and hopefully, like I said, our experience helps your users and if there’s anything else we can do to help, by all means do not hesitate to let us know.

Jane: Thank you so much!

The 1-Hour UI Audit: Get the Free Course

With this free email course you’ll conduct a simple do-it-yourself audit of your web app: eliminate the obvious design flaws, gain control of your features, and start building the UI that customers really want.