Nathan: Hello, and welcome to another episode of “The Founder Podcast.” My name is Nathan Chan, and I am your host, from Melbourne, Australia. Today, we have a super awesome guest. Her name is Janna Bastow, and she’s the founder of a company called ProdPad. This tool helps you build product roadmaps.

Now, I have to be honest. I didn’t…We don’t run a SAS-based company. We don’t build software, in particularly, at Founder. But when I started speaking to Janna, I started to realize how extremely important her software can be if you want to map out the, I guess, the roadmap of your product or your service. Yeah, it was a fascinating talk around what it takes to build a product that people love. You know? When you first start your company and if you’re working on a product or a service, you have all these crazy ideas. You have so many things hitting you, and you just don’t know where to start.

So what’s cool about ProdPad is it just allows you to build a visual representation of the roadmap on how you plan to build out that product or service. You know, me and Janna, we had a great chat around working with remote workers and managing a remote team. She has employees and team members from all around the world, and it’s really, really interesting to see how she manages everyone and keeps everyone, I guess, on the same page. Then we also talk about what it takes to build an epic product or service that people will love.

Then, you know, we take a twist and find out how she’s trying to grow this bootstrap startup and what’s working, what’s not working, what are the challenges that she’s going through right now. We also find out how she got her first 100 customers and the things you can do to get feedback. It’s really, really fascinating conversation. So that’s it from me, guys. If you are enjoying these episodes, please do take the time to leave us a review. Just go to foundermag.com/reviewpodcast. Okay. Now let’s jump into the show.

So the first question I ask everyone that comes on is, “How did you get your job?”

Janna: How did I get my job? I mean I got my first job in product management. I was basically a customer support rep for a tech company, about a decade ago. I had never heard of product management. Didn’t know anything about it, but they picked up on the fact that I was good at calling out bugs when I found them and relating them to the dev. team and working with them on that.

So one day, my boss plucked me out and said, “Hey. I’d like to make you a junior product manager.” I was like, “Great. I like the sound of that. What is it?” I honestly didn’t know what it was when I started but ended up absolutely loving the role. Basically it was a role that encompassed talking to the customers, figuring out what was working, what wasn’t working with the product, working with the developers to make sure that they understood what was to be built next and working with the business side to make sure what we were building was best for the company.

Nathan: I see. How has that helped you in what you do today? Tell us a little bit more about your job today.

Janna: So today, I run a company called ProdPad, and we build product management software.This was a long time coming. When I first started as a junior product manager, back 10 years ago, one of the first things I did was look up what tools existed for product managers. How do I do a road map? Or how do I do a requirements document? There was so little in the way of resource available. There was just nothing there. So over the course of my next two job changes, I ended up starting to put together what was the beginning of ProdPad, so a tool that I was actually using within my own company.

So I was working with my cofounder, Simon Cast, and he was building the back end. I was building the front end. It actually took us a couple years of using this thing internally and using it just with our friends and product people around us, that we’d realize that what we had was actually worth getting out there and setting up as a company in its own rite. So in 2012, we quit our jobs, and we went to go focus on ProdPad full-time.

Nathan: I see. And you guys are based out of London?

Janna: We’re based out of London. Yeah.

Nathan: Can you give us an insight, before we get into the details around products, what makes a good product, roadmaps, requirements, documents, all that kind of stuff that I’m really interested about, can you give us an update of where the company’s at since 2012?

Janna: Sure. So when we launched this thing in 2012, we had no customers. We had just the two of us, and we were just hacking away. Today, we’re a team of six. We’re based in London, Brighton, Berlin, and Slovenia, and we’ve got about 400 customers all around the world. So we’ve been growing since the day that we started, and it’s really great to see so many different companies and such a wide variety of different types of product managers making use of it.

Nathan: Yeah, wow. Okay. That’s awesome. That sounds like many different cities for a team of six. How does that work exactly?

Janna: Mostly Slack, to be honest.

Nathan: Oh.

Janna: We’ve always been a remote team. My co-founder and I have never actually worked in the same office. We’ve always worked remotely, for various reasons. We ended up picking up our development team. It’s a great company that we worked with in the past. So we wanted to continue working with them, even though they happen to be based in Slovenia. We’ve picked up the best people, wherever they happen to be in the world, whether that’s Brighton or Berlin or wherever else we find people. So we don’t want to just tie people down and say, you know, “You’ve got to be the best, and you’ve got to be based in London.” We’re happy to say, “Wherever you happen to be based, that’s okay, as long as you’re willing to come join us for an offsite, you know, a couple times a quarter, or make sure that you’re on Skype or Slack or wherever else we need to communicate on a regular basis.”

Nathan: I see. So it sounds like you outsource your development. Is that correct? Or a portion of it?

Janna: Sort of. Sort of.

Nathan: You use like a service that…Like an agency or a company that helps manage it?

Janna: Sort of. So the company that we work with is a company called D-Labs. As I mentioned, they’re based in Slovenia. It’s actually a team of about 80 or so developers, one of the biggest ones in Slovenia and certainly one of the best. We’ve worked with them for years now. Actually Simon was working with them before we even started ProdPad. So really trust them. Really knows them. The guys who are on the team, they’ve been part of our team for a couple years now. So they’re part of the ProdPad family, even though they’re not necessarily, technically, officially employed by the company.

Nathan: Gotcha. So you come to this company in Slovenia. You say, “This is what we’re looking at building and what we want to work on.” Then they’ll help you find the right person within their crew.

Janna: Yeah, exactly. So we’ve been working with a couple guys there, pretty much full-time, for the last couple years, but it’s great because it means that if we need an extra QA person for a month because we’re doing a big project, we can pull somebody from their team. Bring them in. They already know who they’re working with. They already know a lot about the company, and they can just jump on. Same thing with the designer or UX person, or occasionally we’ll need support with code that we don’t usually work in, like dot-net, for example. They’ve got basically a few people working on very different things throughout the company. It means that we can just pull on these different resources as needed.

Nathan: Gotcha. Gotcha. Gotcha. I see. How does that work around support? Or do you have devs, dedicated dev, as well?

Janna: So in terms of support, we’ve got one person, Andrea, in-house, who’s our head of customer success. She leads pretty much everything to do with support and talking to our customers. In terms of how that works with the developers, she keeps on top of it to figure out what are the big bugs that are happening right now, what are people complaining about, and talking to the developers and making sure that they know what’s at the top of the queue. We don’t have dedicated developers just for bugs. We don’t have enough to justify that kind of thing, but we do slot them in alongside all the other improvements that are constantly going out the door.

Nathan: Gotcha, gotcha, gotcha. Okay. Interesting. Are you guys 100% bootstrapped? Have you raised some funding? Looking to raise? What’s your take on that?

Janna: We are 100% bootstrapped. When we started this thing, myself and my cofounder said, “We don’t want to start a startup in the sense of creating something that takes hundreds of thousands of pounds to get started and fuels the growth, with the hopes of it kind of paying back down the line.” We wanted to start a business.

So we focused on getting revenue, from day one. We made sure that what we launched right away was something that we could charge for and that people were willing to pay for. So when we launched the product in February 2013, we had our first paying customer within weeks of that.

Nathan: I see. What has been your best source of customer acquisition? You guys are a SAS. Right? So what have you found is the best way to sell your particular SAS product?

Janna: The best way is by making sure that you appear at the top of Google and making sure that you’ve got good content that people want to read or want to learn from. Most of the people who come to us, almost our entire customer base, has come from organic means, as in they’ve looked up something like, “How do I do a roadmap? Or how do I do a user story?” And we’ll have an article on our blog about that or a guest post somewhere else about that. Then they see that we actually have a software that they can try for free, and they sign up, and they go from there.

Nathan: Okay. Awesome. Now let’s actually get into the nitty gritty, Janna, around, you know, what it takes to build a great product, what a roadmap looks like, requirements, document, user story, all these awesome things that a lot of people, when they build products, they probably don’t even know what these things are. Why are they important, first of all? Why do you need to have these core components in building a great product?

Janna: So the first thing to look at is what the role of a product manager is. The product manager, first and foremost, is a communicator. They sit in the intersection of the business side, the customer-facing side, and the technology side. Essentially it’s up to them to help figure out what is technically feasible, valuable for the customers, and profitable for the company, and outline the roadmap based on that.

Now that said, there’s a lot of different aspects being a product manager. You’ve got the really high-level thinking, which is, you know, outlining what’s your product vision and what are the big steps you’re gonna take to get to that vision, what does your roadmap look like, as well as the really nitty gritty, in terms of, “You know what? Here’s how…If we’re gonna go do this, then let’s break this down into a user story that includes these components and a mockup that includes this much and work with the developers to get it built.” So you end up slingshotting from high-level thinking to really detail-oriented thinking, on a day-to-day basis.

Nathan: I see. And what about, like, somebody like a solo-preneur or like a…Because a lot of, you know, companies that are just starting out, you know, early stage startups, they don’t always have a product manager. It tends…Would you say that it tends to be one of the founders or the solo founder that’s kind of in charge of product in the early days?

Janna: Yeah, almost in all cases. When you look at it, what you’ll tend to find are people who don’t necessarily know that they’re product people. They haven’t labeled themselves that because they’ve never had that role or thought about it that way. But if you’re somebody who’s come up with an idea for an app or a product or something like that, and you’re the one talking to engineering or talking to yourself maybe about what you want to do to make sure that it’s built properly, you are the product person. You are the one who’s talking to your customers, even if you only have one of them. You are the person who is talking to the developers, even if you are the developers, and you’re the one making the ultimate product decisions.

As the company grows, what you’ll tend to find is that this solo-preneur will end up figuring out that, you know, they can get more done if they get another developer, or they can get more done if they get another designer, or they can get more done if they get somebody to help market it. In time, you’ll find that they’ll end up taking on the role of CEO or a business manager type role or stepping aside and taking that product role themselves. So it’s up to them as to whether they end up moving into product from there. So they want to keep close to that product and what it is that they’ve created. Then that’s often the case.

If they are actually more passionate about building the business itself, then usually when the company hits 10 to 20 people or so, they’re really gonna start feeling that need for a dedicated product person.

Nathan: Yeah. No, that was a fantastic breakdown because, you know, where we’re at, I see myself or somebody in my team, David, as this product person. I’m really curious, from your aspect, you’ve seen…You know, you work with a lot of product people. What makes a good product? And what do people need to be fundamentally doing to make a good product? Let’s walk through some of these, I guess, frameworks or ways of thinking about breaking it down into a detail-orientated process.

Janna: Yeah. Well, that’s a big question right there because you’re saying, “What does it take to make a good product?” I mean to start with, you have to look at what a good product is. When you think of the best products that are out there, they’re things that are both loved by their users, useful. They have a reason to exist, and they provide value to the company. You know? They’re not to be given away for free. They’re providing something back to that company, whether it’s the data that they need or whether it’s, you know, revenue that’s coming in.

Now in terms of how you actually go about doing that, there’s a lot at play. You know? The core things are that you need to be talking to your customers, first and foremost, to make sure that what it is you’re building is in fact valuable. So many times, I see people coming up with an idea, and because they’ve come up with the idea, they think it’s the best thing, but it’s only when it’s actually aired, that they…when they actually start talking to friends and family and potential customers, that they realize that maybe it’s not such a great idea.

But, you know, there’s also…It’s not always black and white. You know? When we first started building ProdPad, we built it for our own needs. I was a product manager at one company, and my cofounder was a product manager at another company. We just needed a tool like ProdPad. Bare in mind, this is before we even called it ProdPad, but what we did was we built a tool that was suitable for two product managers to use.

When we started airing it with our product peers and other companies, we realized that they work in different enough ways that what we built wasn’t useful for them. So even though we thought we were our market, turns out we weren’t. There was so much more that we could learn from other people. Today, ProdPad’s been shown to thousands of product managers and has had feedback from those thousands of product managers, and so very much reflects best practices and what people are looking to achieve.

But very early on, it’s hard to do that because you don’t have those customers, and it can be very difficult to show your first version of a product, which is, you know, usually, quite embarrassing version of your product. It’s very hard to show that to somebody and take that critical feedback when they say, “Yeah, it’s all right, but I wouldn’t pay for it,” or, “Yeah, it’s all right,” but, you know, it kind of fell apart in my hands or whatever the case may be. That’s usually how these products get started.

So talking to your customers, even from day one, is hugely important and, also, understanding what else is in the market. What is the competition for your product? And not just strictly competition, in terms of the direct apps who are competing with you on the same keywords that your customers are searching for. But what else could they use, besides you? More often than not, you’ll find like any SAS company, any SAS tool, could probably be replaced with an Excel spreadsheet or a whiteboard if someone so wished, at least at a basic version. When you realize that a pen and paper or Post-It note is your biggest competitor…You know, hello to all the people making to-do lists, for example. It becomes very difficult to make sure that you’re building the right thing.

So they have to be conscious of what else is out there and how you actually add value and how you actually differentiate yourself from these different options.

Nathan: Okay. So let’s say you’ve launched. You know? You’re really hampering down that you need to be speaking to your customers, your users, people that are trying this product out. How…What’s the best way to go about that? Do you like intercom? Do you have a standard email that you send to people? How does that work?

Janna: So it depends on the stage that you’re at. I mean before you even so much as break code, before you start putting anything down, I would always recommend that you sketch out a few ideas on paper and start showing them around to people who are just around you, other colleagues, other peers, your friends, your family, whoever will listen. Once you’ve actually got your app up and going…We didn’t have anything like intercom or any support system at all in place for the first year of ProdPad. We just simply used an email address.

As a matter of fact, our outgoing emails, even our welcome emails, were customized. They were handwritten by me but made to look as if they might have been somewhat automated, to that we didn’t look like we were absolutely tiny. But when you’ve only got one customer signing up for trial, per day, you can spend your entire day figuring out who is this person and why did they sign up and how did they find us and what are they looking to get out of this. I would just send messages to them, saying, “Hey. I’d love to just jump on a quick call with you and find out what you’re trying to achieve and show you what we have so far, but also get your ideas on how we can improve this.”

So we spent months and months and months just constantly talking to our earliest, earliest users, some of who are actually still with us today, and many of whom actually inspired our early development based on their feedback and what they pointed out we weren’t doing right.

Nathan: I see. And how often…Like, when do you know that there’s enough feedback, that you need to definitely do something? How do you gauge that?

Janna: So when you’re really early stage, oftentimes, the stuff that’ll come through is just blatantly obvious. It’s probably stuff they even thought about, but you ended up scoping out because you couldn’t be bothered to build it, or you didn’t have enough time to build it, which is okay. You shouldn’t try to build everything all in your first go. You should actually try to build really simplified, minimal version of your product to get going. But then you’ll talk to people, and they’ll say, “Hey. This is great, but it seems kind of obvious that I should be able to search.” Right? You’re like, “You’re right. Okay.” Or, “I should be able to tag things,” or, “I should be able to do this, that, and the other.” Some of the stuff will come off as really obvious, and you only need one or two people to point it out that you go, “Yeah. Okay. We should definitely consider this one.”

Other stuff. Particularly as the app evolves, you’ll start getting more and more advanced questions or feedback requests, and you’ll start getting a sense for what is universally useful, versus what is useful for only that one particular user.

Typically there’s no real way of quantifying that because it all comes down to not just the amount of people who are asking for it, but also how does it map with your bigger product vision, how does it sit with your roadmap. Is it going to push other stuff out that is more important? So the product manager has to constantly think about all these different areas in terms of, you know, “If you were to build this, would we then have to support it and sell it and market it properly and fix it when it breaks and all this other stuff?” Versus, you know, working on something simple that is really obvious. There’s always trade-offs that they could be doing.

Nathan: I see. And when it comes to a product roadmap, how does ProdPad help you work that out? And how does it help you…Like, how does that part work?

Janna: So a roadmap is simply a document that communicates the direction you’re gonna be going in order to meet your product vision. So ProdPad actually starts out by asking you to enter your product vision. This is something that any company should have, any product manager should have, any entrepreneur should have, is a vision of what they want to be. Don’t worry. That vision can change as they learn more about it, but just making sure that they’ve sat down, in paper or in ProdPad somewhere, “We want to be the X of Y,” or, you know, “We are going to be doing this in order to change this part of the world.” Whatever it is that that vision is. That way, they know that they are heading in the right direction, and everybody they work with understands that they’re heading in that same direction.

The next step is to then start breaking down what you could be doing along the way. What problems need to be solved in order to meet that product vision? You don’t want to give a list of features that need to happen because, to be honest, the features will get defined as you start talking to customers and start understanding what their actual problems are. But if you start talking to customers, and they say, “Hey. I’ve got a real big problem. I put all this stuff in here, but now I can’t export it. I can’t get it out. I can’t share it.” That becomes almost a theme. You got all these people are saying, “I need export stuff,” or you got all these people saying, “I need search stuff, or I need profiles or whatever else.” They start becoming themes, and you start grouping them together.

Each of these themes, you could classify as something that should happen in current term. You’re working on it pretty much now. You got stuff that is happening in the near term, so whatever is happening after the next few sprints. Then you’ve got stuff that’s being pushed off till the future. So in ProdPad, we call these themes. We call these roadmap cards, and they’re basically blocks that you add to your roadmap, that help you classify. You might have a problem that you want to solve in the future around export options, for example. You might then attach specific features that you think are going to solve that problem or different experiments that you want to run to that particular card. Then you can actually see this high-level look at your roadmap to say, “Okay. So here’s where we are now. This is what we’re working on right now and the different features that are playing in there, but here’s where we’re gonna be going in the near term and in the future.”

One thing we actually recommend with your roadmap is that it’s not just this tool that you work on and then just update once a month to show to your board advisors or whatever else. This is something that your team should be able to see, should have buy-in for, and should even have their input into, as well as showing this to your customers. Now you don’t necessarily have to show the entire roadmap to your customers, including all the features, but giving them an idea as to the big steps you can be taking between now and the future can make a huge difference in terms of the feedback that comes back from them.

You know, for example, if somebody comes to me and says, “Hey. We really need these export options,” I can say to them, “That’s great. We’re definitely considering that. It’s on the roadmap. You can see it here now. But look at all this other stuff that we think is more important than export options, that’s coming up in the roadmap sooner.” They’ll be able to see those and give you a feel for, “Oh, yeah. You’re right. I think that is the right order. This stuff is more important to me, and while you’re at it, I think you could add this to this particular feature. That can give you some insight on other stuff on your roadmap,” or they might say, “You know what? I see your roadmap, but I don’t agree with the order. I think this is the most important thing, and I think you should move this way up in the line versus these other things right here.”

You don’t necessarily go and change it for one customer, but if you start seeing this recurring pattern, every customer saying, “You know, we’ve seen your roadmap. We don’t like it,” or, “Hey. We’ve seen your roadmap. We want to add something else to it.” This is the type of thing that starts informing you, as a product manager or as an entrepreneur, as to what kind of things you should be considering working on and what’s gonna add the most value to your customers.

Nathan: I see. I can see, actually, on your website even. You published your roadmap, and you show what you’re working on.

Janna: We do. Yep. We publish a version of our roadmap, so that anyone can see it. So if you go to prodpad.com/our-roadmap, it will show you what we’re working on now, which is actually a full redesign of ProdPad. It’s been a really exciting and challenging project, as well as what we’re working on in the current time, in the near term, and in the future.

Nathan: Yeah. Wow. Wow. That’s fantastic. You know, I got…I’m really excited to have a play around and implement this in our team because, you know, our biggest focus right now is product, and it’s pretty much me and David just focusing on product. We consider them projects and rolling out a lot more product. Yes, me and my team…I’m really, really excited to use ProdPad and integrate it into what we do because one of the things that we’re working on now is just scaling up product. We have quite a big community, and we need to service them with so many different products. When I say products, I’m talking about online educational video courses.

It’s not as complicated as software, but we do have one product in particular called Founder’s Club, which is constantly evolving. We’re talking about building software now specifically for the club. So we can do all sorts of things, like do these next-level masterminds. We’re talking about it today, and we’re always like, you know…When I think you know…When you talked about the vision, what does the vision look like, the end vision, when I think about that for this product in particular, I have to ask you. I don’t know if it will ever be enough, you know, once we get to like…What do you do around that? Is it ever enough?

Janna: No. A product is never finished, per say. I mean if you’re sitting here and saying, “We’ve got this thing coming up, and I know exactly what it’s gonna look like when it’s done,” and nothing else will happen to it again, that’s a project. That’s a one-off thing that you can get outsourced and have done, and you know when it’s done. You pay for it, and you don’t work on it again.

More often than not, it sounds like, in your case, it sounds like you’re talking about an actual product. You’re gonna build a first version of this thing for your community, and you’re gonna get your community on there, and you’re gonna see what the community says about it. Some things are gonna be great, and some things are gonna be awful, and you’re gonna learn from that and adjust it and work on it until it’s better and better and better.

Now, I mean, you know, this is something that hopefully you’ll still be using in two years’ time. What does your community look like in two years’ time? What kind of needs do they have? Probably completely different needs than what exist today. So your vision that you set today is probably gonna guide you for the next couple of years or so. But as you grow and as you evolve and as the product evolves and as the community members, your customers, essentially, as they mature and they get better at using your product and understanding it, their needs are gonna be more complex. The product is gonna become more complex. You’ll really have to think about how you’re gonna manage this and what you’re gonna build into it next and where you go with it.

Nathan: I see. So this brings me to my next question. User story. What is a user story?

Janna: Yeah.

Nathan: And how do you track someone’s user story? Because this is something I’m thinking about a lot with Founder’s Club, not just the on-boarding. But how are they finding us?

Janna: Yeah.

Nathan: What happens, you know…

Janna: So a user…

Nathan: Yeah, so please go on.

Janna: So a user story…A simple way of putting it is that it’s a way of expressing what a particular feature or product should do, in laymen’s terms. You know? There’s a lot of different ways that you can spec out. By spec out, I mean if you’re saying you want to build a login system, then you should probably make sure that your login system has a login button, and it should have a “reset password” function, and that it should have a “create an account” function as well attached to it. So each one of these could be broken down into a user story. You might say, “As a user, I want to be able to reset my password in case I forget it, so that I can get back into my account.”

Paired with that, you’d probably have what they call “acceptance criteria.” Acceptance criteria is basically you outlining how do you know that this particular thing is done. Well, you know that this thing is done. This “reset password,” for example, is done when the customer gets an email, when they prompt for one, and that if they click on the link in that email, then it prompts them to change their password. Then when they log in again, their password works. You know? So you’ve got all these things that you can basically say, “We know that they were able to reset their password when this happens.”

But the core thing about a user story is that it’s formatted like this. As a user, and by user we mean a type of user, not a particular person, but usually a user persona. I want X, and X is what it is that they want to actually do. Then it follows with, “In order to Y,” and Y is the problem that they are trying to solve. Now the problem isn’t that they want a reset-password link. It’s that they want to get back into their account because they’ve lost their password. So by breaking them down in this way and using these as a way to talk to your developers, it gives you the context as to who’s using it, what is it that they’re supposed to do, and what problem are you actually solving for with them.

If you struggle with coming up with the, “In order to X,” part, then maybe it’s actually not something that’s a valuable piece for this particular user. Maybe it can be scrapped or put off into your backlog somewhere, as opposed to build immediately.

Nathan: I see. So what about the piece where we’re capturing what people are doing, what pathway they go through, from when they find us, to on-boarding, to where are they using? What tools do you recommend to capture that data and work out where people are using across your product? What are they spending their time with? And what particular features are really hitting home? How do you work that out?

Janna: That’s actually a really tough one, and it’s still something that hasn’t been decided or settled yet. There’s no one tool that absolutely wins that game. You know, for comparison, if you have an eCommerce site or a blog or something like that, a public-facing site, then Google Analytics solves pretty much all those problems. It allows you to see where they are and where they’re going through and what things they’ve clicked on and what the conversion rates are and everything like that. It’s a great tool, and it’s incredible that it’s free.

That said, Google Analytics can do some in-product analytics. But to be honest, it’s pretty limited and fiddly to work with, in my experience.

Nathan: Yeah.

Janna: There are other tools out there that will do product analytics. But at the end of the day, at ProdPad, we ended up building our own because none of them quite solved our needs. None of them allowed us to…It came down to things like, “Yes, this one will track their movements, but it’ll slow down the page load,” for example, and we couldn’t be dealing with that. We needed to make sure the app was really responsive. All the ones we weren’t able to customize the way we needed to or pull out data in the way we needed to.

So we’re actually creating…pulling our own data directly from the server and crunching it on our side, using our own sets of tools. That said, I do see more and more tools entering this area. So it’s one that I’m watching myself.

Nathan: If someone wanted to find out some of these answers right now, is there anything that you could comfortably recommend saying, “It’s not the best, but it will help?”

Janna: So one we’re looking at right now and hopefully getting set up with, if all goes well, is a tool called Keen.io, which does in-app product…

Nathan: Keen.io.

Janna: Yeah, it seems pretty cool. The guys there are really cool. It’s a really cool company. They’re very open about giving demos and helping out, and they’ve even got a Slack community that helps…to help them out with everything. We’re just trying to get set up on that to see if we can augment what we’re already doing to get more out of our own data, particularly with visualizing it and making it easier for not just the developers and me and my cofounder, but everybody in the company to access this data. But we haven’t actually finished setting it up yet. So it’s hard to really make a clear recommendation on one versus the other.

Nathan: Yeah, okay. That sounds interesting though. Thank you for that, Janna, because, essentially, what you want, right, is like a Google Analytics funnel, but inside your web app. If you have an eCommerce, you sell a physical product or you have an eCommerce type site, you want to be tracking that. You want to see what people are doing and where they’re dropping off, and then you want to fill those holes.

Janna: The golden thing isn’t just tracking it and seeing it, but it’s actually being able to respond to it, which is where a lot of this stuff kind of falls down. You know? It’s not actionable. We’ve actually just implemented a new version of our own on-boarding, which actually picks up on, in the first 30 seconds, how much of ProdPad did you use. In the first five minutes, how much of it did you use? In the first day, how much of it did you use?

Based on your usage, we’ll actually send you different emails, welcoming you to ProdPad. The first email that you get five minutes after joining is gonna be different if you logged in, clicked twice, and then disappeared, versus the person who logged in and started adding ideas and their products and everything else.

Nathan: Yeah. Wow.

Janna: Which is something that a lot of apps don’t do. They’re just kind of blind to the fact that once you’re in, different, you know, different users are acting differently and should be treated differently. But it’s not an easy one to solve. We’ve been, essentially, hacking apart a series of different tools. We used Drip. Get drip.com for persona-based on-boarding, but even the folks at Drip, who helped support us while we were coming up with this flow, looked at it and went, “Wow. That’s really complicated. I see what you’re doing there, but that was really complicated.”

The end of the day though, we’re really seeing results. We’ve seen a massive uplift in our response rates to those emails and of people getting in touch and saying, “Yeah, you’re right. I didn’t use it, but, you know, I really want to know about the next step now.” So it’s made a big difference for our company, and that’s just something we did in the last month or so.

Nathan: Yeah, behavioral-type stuff is where it’s at, even when it comes to email marketing. People don’t want to be spammed continuously or sent email after email if you don’t even…You’re not even in the next part of the sequence. So you should be able to track if that person opened that email, if they watched this video, how long…how far in the video did they watch, and then send custom-tailored emails depending on, and that will yield the best result. It’s all about relevancy now.

Janna: Yeah, what you were just talking about there is kind of the world of marketing automation, and that’s an area that’s been blowing up over the last five or seven years or so. You’ll see the likes of HubSpot and Marketo leading that one, where it allows you to track as to whether somebody downloaded your white paper and send them followup emails and track as to whether they spent some time on your pricing page or opened your last email or did whatever else. There’s a lot of tools in that world, but they’re still, I would say, not done. You know? When you look at the likes of HubSpot or Marketo or some of those other ones, they’re massive behemoths that are not cheap and are not particularly accessible to startups, particularly if you’re a pre-revenue startup just trying to do the right thing and make sure that you’re not over-egging it with emails.

There are now…I’m seeing more and more and more of these marketing automation tools for startups coming out. So I think time will tell as to which one’s gonna be the best ones out there and, you know, who’s gonna be able to provide the best service for that.

I think the next thing, and this is something that we’re working on here at ProdPad, is product optimization, not just market automation. You know? It’s one thing to make sure that somebody gets all the right emails to sign up for free trial. But once that person signs up for a free trial, shouldn’t you be giving them that same sort of care and attention and making sure they’re getting the right emails from you and the right responses from you. So that’s an interesting challenge that we’re chewing on right now.

Nathan: Yeah, because that’s the thing. Right? Especially when you’re selling on a recurring, like, all of these web apps, they’re all recurring SAS products. You know, it’s one thing to get people purchasing, but it’s another thing to actually keep, and you have to resell every single month. Right?

Janna: Yep.

Nathan: Okay. Well, look. We have to work towards wrapping up, but I have a couple more questions for you, Janna. One around the management of remote workers. There’ll be a lot of people listening that would have a remote team or distributed team. You mentioned Stripe. You mentioned…Sorry. Not Stripe. You mentioned Slack.

Janna: Slack.

Nathan: You mentioned Slack. Don’t know why I said, “Stripe.” There’s too many apps these days.

Janna: Yeah, I know. I know.

Nathan: You mentioned Slack. You mentioned Skype. But I’m curious around just basic management techniques. Do you guys have a weekly catch-up? Do you do stand-ups every day? Tell me about that.

Janna: So because our team is all over the place, it’s pretty nuts. All of us are constantly traveling as well. So we kind of have to update each other on what time zone we have to be in at that point in time. With the developers, we have a weekly catch-up to check how progress is going. But for the most part, we know that they work best when they actually have some peace and quiet in between. So we make sure that we’re queued up and give them the right stuff to work on and are available for questions throughout the week, but we don’t have constant questions going back and forth on that side.

We also have what we call the “Hashtag Daily Standup.” A lot of teams who are in the same office will attempt to do a standup in the morning, talk for 10 minutes about what did you work on yesterday and what are you gonna work on today and what blockers do you have or any questions for anybody else. We know that we are never in the same time zone. So we don’t try to do this at a set time per day, but we just sort of make sure that we update at least once per day in the general channel. “Hashtag Daily Standup.” Here’s what I worked on. Here’s what I’m working on next. You know, progress and whatnot. It just helps keep everybody in line with what’s happening.

But the big thing, in general, it doesn’t matter what tools you’re using. In order to work remotely, you need the right people who are good at working remotely. They’re good at pacing themselves and pushing themselves to deadlines, even though they don’t have a boss or colleagues or anybody else there, even though they might not be working to the same hours of everybody else.

But more than anything, you need trust between the team. So this is why we make sure that we get the core team together to do offsites. So for example, we’ve all flown out, flown everybody out to come to London to work together for a week. We’ve flown everybody out to Dublin or to San Francisco. We’re meeting up in London again next week. So we try to do this once or twice a quarter, every four to six weeks or so, to make sure that we’re all in the same room. We’re all comfortable with each other. So that way, we’ve got that face to the name. We’re not just…You’re not just having to work with this set of colleagues you’ve never met. These are people who you trust and would work with, and it just so happens that you’re not in the same continent.

Nathan: Yeah. No. That’s very key, in-person. How often do you guys do the in-person catch-ups? Every six months? Every 12 months?

Janna: In-person catch-ups, we try to do it every four to six weeks.

Nathan: Oh, wow. So you fly everyone down together every four to six weeks.

Janna: Yeah. We’re lucky because we’re all in Europe right now, most of the time, which means that, you know, you can take an EasyJet flight to London or Dublin or Berlin or somewhere like that. We’ll share an Airbnb and keep costs down and otherwise spend a few days just catching up and getting to know each other.

Nathan: Yeah. Well, that would be fun.

Janna: It is. It is a lot of fun.

Nathan: That’s awesome. All right. Well, look. A couple last questions, Janna. One. You got this epic product. It sounds like you really, really know your stuff, and you’re really onto something here. How do you plan to scale this business? Are you…It sounds like you’re not looking to take outside funding. How do you plan to scale?

Janna: We’re already seeing it scale. We’re seeing our number of leads and our traffic coming in growing. We’re seeing the number of customers constantly growing. We’ve already grown the team. So if you looked at us a year ago, we were three people. This time, this year, we’re now six people.

Nathan: Yeah. Wow.

Janna: With, you know, more than double the customers. So things are already moving up and moving quickly. It was a conscious decision not to take funding. We realized that if we took funding, then it would put us down a particular path that may or may not be the right one for us, based on how we work, our company culture, and what it is that we’re looking to achieve.

Nathan: Awesome. All right. Well, look. That’s it for me. I just…We can wrap there, but I just wanted to say thank you so much. This was a fantastic interview. Where is the best place people want to find you or if they want to access ProdPad?

Janna: Best place to find me or ProdPad is to head to prodpad.com. So that’s P-R-O-D-P-A-D.com. We’ve got a blog  where you can find out what we’ve been writing about and talking about, or hit us up at @ProdPad on Twitter.

Nathan: Awesome. Thank you so much, Janna.

Janna: Absolutely. Thank you for your time. I really had a good time today.