Tick These 4 Boxes Before Bootstrapping Your SaaS with Janna Bastow of Prodpad

I think the reality is that it comes down to how you talk to the customers and how you pull that information out of them.

Getting the information about what the customer's problems are is half the battle, right?

And you've got to have those conversations with them to really understand that pain point. Welcome to SaaS Origin Stories. Tune in to hear authentic conversations with founders as they share stories from the earlier days of their SaaS startups. We'll cover painful challenges, early wins, and actionable takeaways. You'll hear firsthand the do's and don'ts of building and growing a SaaS, as well as inspirational stories to fuel you on your own SaaS journey.

Here is your host, Phil Alves. Today I have Jenna Bassam from ProdPad. We're excited to chat with her and learn a little bit about how she started her SaaS product. Welcome to the show, Jenna.

Hey, thank you so much. Glad to be here, Phil.

First, I would like to ask you about your backstory and how you come up with the idea for ProdPad.

Yeah, sure.

So, I mean, I was a product manager as a junior product manager. I sort of fell into the role accidentally like a lot of other people and didn't really have much in the way of direction or clarity on how to do product management. But I had a sense that there was probably a better way of doing it than when I was doing it.

I mean, I was having to make PRDs and make roadmaps and it was just a lot of inefficiencies in it and, you know, a lot of lack of transparency into how I was working and that sort of thing. So I started sketching out some ideas. I started trying to make my own templates.

I started trying to almost productize the work that I was doing in various ways just by making my own templates and my own sort of little systems to help me do my job as a product manager. This was going way back when I was originally just a junior product manager. And over the years, I improved on these systems. I started sharing them with other product people around me.

And it wasn't until I was a more of a senior product manager and I started sharing my ideas with another fellow product person, Simon Kast, who eventually became my co-founder of ProdPad. And I shared these ideas with him and we spatted around some ideas and it became clear that actually he could build back end and I could build front end.

So we could actually do something with this and turn it into a real product. That's amazing. And I think a lot of products start like that. It's trying to solve your own each and they're developing, you're learning.

So for how many years you were like a product manager before you went to actually build your own product?

Oh, good question. Probably about five or six, depending on how you measure it and how you define when we actually started ProdPad because there were some years there when it was, I guess you could say like a baby product. It was something that we could use internally, but it didn't have a website. You couldn't sign up to it to invite somebody. We would just be adding them to the system.

There was no way to nicely invite people. It was just a tool that we used inside our own systems, our own companies itself. And then eventually we evolved it to the point that it was something that you could actually buy as a SaaS tool. Let's talk more about that because I feel like there's many paths to start a business.

It looks like you started as a little bit of a side project, the entrepreneurial side organization where you were. Walk me through the process a little bit more. Yeah.

I mean, I guess the key thing was that we didn't quit our day jobs. We were product managers. We were both heading up product at a couple of different startups in London at the time. And both were great jobs. Both were opportunities to learn. We were both getting paid. So it was hard to give that up and just quit and go do something that was obviously a big risk.

And it was this complete unknown that we'd be walking into.

And in the meantime, what we really needed at that time was just something to solve the problems we had day to day, something to help us build roadmaps that our team would actually use, help us keep on top of all the specs and all the ideas that we're gathering and needing to write and send over to the dev team, something to help us make sure that we're keeping on track with the objectives that our team was asking us to run towards.

So it was a tool to help manage all that sort of stuff. And so at first, it was actually just something to help with that. We didn't have a name for it. It wasn't a tool that was accessible to anybody else. But over time, we realized that people in the team started finding a lot of value in this thing.

They started coming up to us and saying, hey, this tool that you just added me to, this is really neat. I can see where my idea is gone. I like the roadmap view. I like how I can do this with it. I couldn't find it online, though.

Where did you get this?

And as people started joining this company, both of these companies were startups, scaleups sort of thing. And they were at the point where people were joining the company and didn't realize that I had built this tool. So I didn't tell them. I just wanted to see if anybody could tell that this was a home-based tool. And a lot of people couldn't tell.

I would sort of fake the invite system and make it look as if they'd had a professional invite from an actual SAS tool. And a lot of people couldn't tell. And so it was sort of a smoke test to see if this would fly if we did make an actual invite system and actually turn it into a tool that other product managers would use in their systems, in their companies.

And we realized after a while that this thing that we were building possibly had more value than the companies that we were working for and what we were building was part of our day jobs.

I'm like, oh, that's compelling.

Well, we should maybe get out of here and start go focusing on doing this full time. So you guys are building this nights and weekends. You were a product manager, but you're actually coding the front end of the product. They didn't bring a developer in. And your co-founder is coding the back end of the product. So you're both kind of like technical product managers.

And on the side, you were creating this product and building to a point where you start to see a lot of adoption. And then you got to the turning point of like, OK, it might make sense to us to go full time on this.

At that point, how was the transition?

Do you guys had money saved up?

Do you went and raise money?

So like, how was the transition to say, OK, this is a full time?

And what kind of traction did you have?

Like, did you have any outside customers besides the customers, your own companies where you guys work?

Your own companies where you guys work?

What can you do there?

Yeah. So when we decided to go quit our jobs and go focus on this full time, there were a couple things at play. One was that we also started another thing together. And I think it was a business, but it was another hobby on the side, kind of like Prod Pad started out as. You might be familiar with Mind the Product, which eventually turned into the world's largest community of product people.

But at the time was a meetup around London called Product Tank and was a blog for London based product people to talk about product management. And it just that year, this is 2012, just started getting together to put together the London conference. So it was just at that time that we realized, OK, well, we're just about to start running this London based conference.

We're starting to see people interested in this tool that we've built and the interest that we got. We didn't have any customers. We knew that the companies that we were working for probably weren't going to pay for it. We're happy to give it to our companies for free. But we figured that we could probably get other people to pay for it.

And the way that we tested it was we set up fake landing pages, one of those landing pages that said, we sell product management software, product roadmap tools. Click here to buy now. Add your email address and we'll let you know about when it's ready. And people started clicking. They started trying to buy it. And we're like, OK, that's compelling. We had enough people doing this.

Maybe some of them would actually pay us.

Now, no one actually was paying us. We had nothing in the bank. But we did know that we had this conference coming up with one business. And we did have some interest coming up with this other business, the software side. And we're like, well, let's go focus on this because this is going to start taking up our time.

Now, we didn't have other income. We didn't have a plan with this. What we did have, I mean, I remember counting it up and realizing that if I quit my job and I kept spending my money as I did, I had nine months cash in the bank.

I was like, OK, that's a pretty privileged position to be in to have nine months saved up because I'd sold a house in Canada when I moved over from Canada to London.

I was like, OK, you know what?

I'm going to do this. And I remember being three months in and going, I'm exactly on track. I've got six months left, still have no money. And one of the things that I end up doing was I took on consulting gigs. I took on gigs doing product management consulting. Back when people kind of didn't think product management consulting was a real thing.

So I did some in-house product management a couple of days a week. I did some training, some mentoring, bits and pieces wherever I could that didn't take up my full week but did pay a healthy amount.

And so what I was also doing was I was getting in front of other product management companies and I was using the stuff that I was learning from how other product companies worked and playing that back into what we needed to know about ProdPed. So it worked really well with our ongoing discovery work for ProdPed.

All of a sudden, ProdPed wasn't exposed to just what I knew from the companies I'd worked for and our customers, but also I was working with other clients now. So I had a more well-rounded view. Some of these early clients that I was working with now still today use ProdPed, which is great. But from there, we started sharing it with a wider and wider group.

Our network of product people was growing because as I said, we were growing, the mind of product network and the community with the conference was growing. And in 2012, end of 2012 through to early 2013, we basically got the app ready from where it was as a product. We made a website, we got it ready to launch as a SaaS tool. And that meant a few things.

Like we had to build in a payment processor. We did have a payment processor and this is back before Stripe had launched in the UK. So we built in one, ended up having to take it out because it was terrible and then built in another one. That sucked, but it was time consuming, but we had to do it. We had to build in an onboarding flow because there's no onboarding flow.

There's no wait, there's no dashboard. There's no way where to land when you first landed. We had to build in invite flows. We had to build in onboarding flows for team members. So all this stuff we had to build in. So we spent the next few months building all this stuff up and getting it ready as a SaaS tool and then launched it in early 2013.

So it took a little bit of a year for you to take that to actual SaaS product they could launch as a SaaS tool.

That's how long it took?

About six months, but we did some other work in that period as well. Nice. And then you were bootstrapping out of the way then from what I understood. Out of the way to launch. It was all completely bootstrapped. We were working off of our savings and burning those down while still building up our reserves, doing consulting and stuff.

I think that's really a strategy that other high paid professionals like ourselves can use to take a product to market. Because if you think about your story, you were financially responsible, you had money, but also you can do this consulting gigs on the side.

And did you guys ever raise money or are you guys bootstrapped until today?

We never raised money. One of the things that we laugh about is the fact that we each put £1,500 in to the business to cover the initial server costs and some of the SaaS costs and stuff like that. And that's what we put in as cash to the business to fund it. And that was the sum total of it. And it's basically all run from there.

We started getting customers in, we started building up our reserves from there and never needed to look back and put more in. Cool. So before we drive into customers, I want to go back in one key word that you say, discovery. Because I think that's super important in product. And I would like to chat with you a little bit more about how the discovery went.

And also, of course, you have a roadmap product.

How now you figure out what goes in the roadmap?

What doesn't go?

And what's the next thing to build?

Let's talk a little bit about the process because that's something that I think is very hard for product managers to do. Sometimes you do too much, sometimes you do too little. Let's chat about your learnings there and how you went about doing discovery. Absolutely.

So one of the first things I can say is that I fell into a trap that I think a lot of people do, particularly people who end up building for what they would consider as themselves if you're scratching your own itch. Looking back, if I could give myself any advice, it's that you are not your user, even if you are your user. We were building for product managers at tech companies.

And I was like, I'm a product manager at a tech company, so I don't need to do that much discovery. I can build it for my use cases. And honestly, I would have saved myself a lot of heartache if I had spent more time in discovery, more time than I imagined.

And instead, I spent more time learning jQuery and trying to hack together the front end of the thing to do what I thought I needed it to do. And it actually took more time to build stuff. And we ended up throwing out more code than we needed to because I didn't do enough discovery. I've learned that lesson now.

And I now know that it's really important to do that discovery and to spend that time talking to the customers, figuring out what problems you really need to solve for them and not assuming that you know what they need, even if you think that you match their exact profile.

How do you strike the balance between talking to your customers, but also knowing what to build?

Because we know customers, they know they're paying, but they don't actually know what they need. And we have to figure out what they need. It's still our job to do that.

I mean, I think the reality is that it comes down to how you talk to the customers and how you pull that information out of them.

I mean, getting the information about what the customer's problems are is half the battle, right?

You've got to have those conversations with them to really understand that pain point and basically use that to play that back to them, to position what it is that you're building for them as something to be really valuable for them.

So an example here is when you're talking to your customers, you don't want to just find something that they're identifying as or something that you've identified as a problem and then have them just validate that problem.

You want to take that step back and sort of cast this wider research net and say, you know, how have you been solving this problem or how have you been tackling this particular job, for example, and allow them to sort of set the stage and talk about problems in that space?

And that will give you a wider area to go solve for. You might discover that you had one particular way of solving it, but the reality is that they're tackling it in a completely different way. They're thinking about it in a completely different way and the right solution isn't what you thought about in the first place.

And so you can tease this information out of them through surveys, through open-ended questions, through discovery questions, through lots of different formats, but also using a mixture of prototypes and, you know, design, you know, co-design work with them to understand as to what sort of things are working and not working.

But like sitting with them to figure out how they're doing jobs, figuring out how they are solving problems and really asking the why's along the way. Let's get a little bit more specific. For example, your product, you're solving the roadmap problem. And so like what kind of like, tell me about your learnings.

I know you create the Now, Next, Later framework and how did that come about?

And tell me a little bit more like how you implement everything they're talking about discovering and how did that work out for your own product?

Yeah, exactly.

I mean, that's a really interesting story about how we came across that Now, Next, Later format in the first place. So taking you back to that period towards mid to end of 2012, we would just quit our jobs to go focus on ProdPad full time. Up until that point, ProdPad's roadmap was a timeline roadmap.

It looked like a colorful Gantt chart that allowed you to take ideas from your backlog and just line them up with the series updates and, you know, publish this roadmap so that other people in your team could see them. And the reason I did it this way is that that's what I was doing in my previous job. This is what worked for me and this is what I thought was best practice.

And you forgive a product manager for thinking that this is best practice because this is how it seemed a lot of other product managers were doing it. And every time I did it this way, I'd get a pat on the head by my boss basically saying, yeah, good job. We like this roadmap format. Now go deliver. And I was never actually able to deliver my roadmap in full.

And I just thought that this was a me problem. I thought I was just not going to deliver it, but the road mapping practices were same because every other product manager I knew of seemed to do it the same sort of way. So fast forward to building ProdPad, I built ProdPad.

I sort of digitized this roadmap into a version of ProdPad that was a version of the roadmap that was allowing you to drag and drop ideas and stretch them out, line them up with dates and do some really cool stuff, all out of some really complex jQuery. And it was a bit of a tangle of code.

It was truly unnecessary work because what we discovered when we started sharing it with customers was they loved it. We put it in front of customers. They're like, yeah, great. I can take this roadmap.

But about a month or so later, they would come back to us and say, OK, I made my roadmap, but I want to take everything that's in this first month or so region and I want to move it over by a month. Now had I just listened to the customers and the problem that they were saying that they wanted to solve, I may have just built a multi-select drag and drop.

So I was sort of just thinking about, you know, that's the feature that they're asking for. Let's move it over. I asked the five why's. I asked why they wanted to move things over and I asked why the things had to be moved over in the first place. And I asked why everything, nothing got built in that first month. And I asked why we had a timeline in the first place.

And I realized that actually having a timeline at the top of the roadmap was detrimental. I realized that no one was delivering the roadmap. It wasn't just a me problem. It was in every product manager, product managers with lots more experience and hugely capable people were not delivering the roadmap.

Everyone was taking everything they put on the roadmap in that first month and moving it over because no one was delivering on a timeline roadmap.

And so we sort of looked at it and went, well, if this is the state of road mapping, why is it that we are trying to build a timeline roadmap that's just going to have people having to move it over?

So we sat down and we threw out our assumptions of what roadmaps looked like and came up with these three buckets. And myself and Simon sat in a coffee shop in Wandsworth, which was about equidistant between our two places in London at that time, and sketched out what became the first version of a three column time horizon roadmap with the columns current near term future at the top.

And we decided to prototype that in the app, put to side the old version, put in the new version and see how people like that. And people loved it even more. So we were able to just sort of try something new and see how people reacted to that.

And it got us even further because it gave people permission to step away from their old way of road mapping and try this new way of road mapping that was more flexible and more freeing and meant that they didn't have to constantly shift things around every week or every month when delivery dates inevitably weren't hit. That's amazing.

I want to dive deeper, but I feel like this is such a great example of discovery well done because before we were talking about the theory of discovery, but when you go and you tell the story, it makes clear how discovery should be done.

You went, you talked to your customers, but you went deeper. You tried to understand the problem. You didn't give the customer what they were asking. You solved the problem that they had. And you still had to, as a product person, and I think that's all you have to realize, you still had to call a shot and you still have to make a bet. Your bet was, we need the three Collins.

This is how we're going to go about it. But of course, your bet was an informed bet. You reduce your odds of being a bet that was just something out of your head because you understood and you were looking about your surrounds.

Again, I think that's just an amazing example.

But I want to understand more about this now, next, later, because you removed the concept of timeline, is there any concept of timeline?

How does that actually work and how you get people that are very used, like think about the stakeholders, that they're very used to have a date that we know is not going to get there, but somehow that make people feel good about it.

Oh yeah, we're going to have this at this date. And that's not how it usually goes.

But yeah, talk to me about a little bit more how this works. Right. Yeah. So that's one of the biggest misconceptions about the now, next, later roadmap is that it doesn't have dates on it. All we've done is removed the timeline from the top.

Having the timeline at the top means that everything you put on that roadmap, just by the format of that roadmap, naturally has a due dates and duration assigned to it. Because it's a little bit like a math chart where you've got the time creating a timeline along the X axis and the Y axis is all the things to do. And everything you plot underneath it is the stuff to do.

And it's naturally plotted as to where it's going to be done and when. And that creates a problem because it means everything has a due date. And that's not how product teams naturally work. Some things might have due dates and some things might not. The reality is, you know, you might have the occasional regulatory due dates.

You might have the occasional strategic due date, something that, you know, if you don't get something done by a particular date, it's going to cause problems for the rest of your company. And so you have to put a date on it. And if that's the case, then do so. You can add dates to individual cards or initiatives on your now, next, later roadmap without imposing dates on everything on your roadmap.

So as injured people, don't penalize yourself by adding dates to everything. Don't penalize yourself by having a timeline roadmap when you can have a flexible roadmap. But you can still communicate when there are dates or dependencies.

You know, sometimes dates are hard dates, like we have to have this done by here because if we don't, then we're breaking the law. Or sometimes it's like, well, we would like to have this out by this time because that's when the conference is. We'd like to be able to show this off. But we're not breaking the law if we don't have it done by then.

And sometimes things are like flexible dates. We should have this done by the spring semester or whatever else. Right. So you can add this level of context to the now, next, later roadmap that you just can't get with a solid timeline roadmap, which doesn't really give you that level of detail. I think at the end of the day, product management is about prioritization.

And basically what you create, it's a tool that you can prioritize things in a different way instead of like you say, penalize yourself adding a date for everything. If you have to, if something needs a date, you prioritize that. And if not, why would you do that when it's just, and then at the day two, you don't want to create, you have to manage expectations.

You create expectations that you can met in the new, yourself are not happy about it and the team, the stakeholders are not happy about it. So it looks like it's a better tool to manage expectations. That's why you're doing now, next, later. But walk me through like, what you put in each of the categories, like how you decide what's now, what's next and what's later.

Like tell me a little bit more about that. Yeah.

I mean, it depends on the company, but typically speaking, the things that are in the now are things that are keeping your team busy right now. They're the things that are being developed and being worked on actively as we speak. And so they are generally not set in stone, but generally much less flexible. The things that are in the next are lined up to be worked on next. These have more flexibility.

They're being discovered, right?

This is the stuff that you are testing and saying, Hey, we think this is what's up next, but you know, it could be flipped with the other thing or it could be taken off entirely if we discover that it's actually not the right thing to be done.

And then the thing that's in the later, these are more of the, the high level problems to be solved or the opportunities that you spot on the horizon that you're saying, we know that we want to head towards these things. We want people to know about them, but we probably haven't started breaking them down into discrete problems or started into discrete ideas or experiments.

You know, maybe we have some ideas as to how we're going to tackle these, but it's okay if we don't because they're so far off that we'll tackle them when we get closer to them. Makes sense. Makes sense.

So, so if you're thinking about like the dual track agile, now it's, it's the things that actually in development and the next is this, whatever's in discovery and later is the things that we, we might not have the resources. We can't tackle that right now, but you want that to be somewhere we can see.

And eventually we might get to that problem just so we know, okay, this is a problem we're going to get to.

Is that correct?

Yeah, exactly. And some alt titles that I've seen people use and you can change the titles of your roadmap columns in ProdPad. We've seen doing discovering dreaming and also ice water steam. I like it. I like it a lot. So let's move on to, to customer.

Like you kind of touched on that, how you attract and retain customers to your product and what has worked for guys over the years?

Oh, well, I mean, for the most part, it's just been talking about good product management.

I mean, 99% of our customers have come through organic means as in they have looked up problems that we can solve. They've been looking for, you know, how to do a roadmap or how to do specs, you know, how to, how to put together, how to collect customer feedback, how to do personas, you know, all things that we solve for. We have tons of information on how to do this stuff.

And then we point out there's a tool that makes it that much easier. So you know, over the years, myself and my co-founder and now my teammates have done lots of talks, lots of articles, just lots of educational material. We like to give our knowledge back to the world and just builds up tons of credibility, tons of SEO juice.

And what we find is people find us, people come to us and say, yeah, this is a tool that seems to know what they're doing.

And so, you know, I'll trust it to hold on to my product strategy and to help me figure out how to tackle these next steps. Is it fair to say like that basically it's a founder's brand, you guys as the founders build the brand for yourself as an expert on the problem of product management.

And you went to conferences, you create your own community about which is the biggest community for product people today. So you just say that maybe that's the strategy that you guys use, it's just like a strong founder brand behind the company.

And today, maybe people buy more from people than faceless companies.

Do you agree with that statement?

Yeah, absolutely. Having a really strong personal brand as a founder has made a real difference because people know who I am and the fact that I speak about this sort of thing, know that we're the creators of the Nounix leader. And we'll talk to us about how they make the most out of it. And know that this is the tool that's going to support them on best practices.

It goes in line with product pads mission. This is a tool that actively helps you become a better product manager. There's a lot of tools out there that you can add your ideas to Jira or to a spreadsheet or to Notion or Confluence or to a lot of other places. But there's no other tool out there that's going to actively help you become a product manager.

It's partly a coach system and partly a product management tool. It's actively going to help you ask the best questions and actively going to help you prioritize at the problem level. It's going to make it difficult to fall back into the traps that a lot of teams do when it comes to the bad product management. It makes it difficult to make a feature-filled, date-driven roadmap.

It makes it difficult to build ideas that have no business case and no reason for being built. Right.

So let's talk a little bit about you mentioned the big guys play in the space, right?

Jira, Atlassian, Confluence. So how you when you're positioning your product on the market, you're like, I'm replacing those guys. I'm helping you use those tools better because that's another thing that sometimes when someone is building a SaaS product and there's like a very, very big established companies that people are using, you have to make the decision how I'm going to position myself.

Am I a replacement?

Am I a neighbor software to help people do it?

How did you do that?

Yeah.

I mean, we never set ourselves out to replace Jira or anything like that. We sit really well alongside of it. So put it this way, if somebody is using Jira, almost certainly they have a problem that product can solve.

I mean, talk to any team who's using Jira. They all hate Jira.

I mean, Jira is a great tool. Don't get me wrong. It's a great tool for what it is good at, which is development management. And when people use it for just that, they're really happy with it. It's really great. You can configure it to do all sorts of different ways of handling development management, but it's not good for managing your strategy, your discovery side of things.

It's not good for following up and learning and iterating. It's good for that slice of product work, which is the actual delivery and doing. So what ProdPad does, it connects to your Jira and says, well, here's a big pile of stuff to do. Let's pull out the interesting things, the things that you might do and make sure that those don't mess up your Jira.

Because now in Jira, you have only approved ready to go tickets that have enough detail that any developer could pick them up and start working on them and know that they're working on the right stuff.

So your development team can now work autonomously and don't have to stop and check as to whether they're working on the right ticket or not, or don't have to pick up a ticket and go, this doesn't have enough detail.

Why is this in my backlog?

So they're burned down charts, they're velocity. They're doing great work in the development side. Whereas ProdPad now becomes this place where you can see all the things you could do. It's your opportunity backlog. It's a list of all the stuff you could do. And it's not your job as a product manager to do all the things.

ProdPad gives you lots of ways of looking at this backlog to figure out of all the things you could do, which ones should you do. You can see which ones have been sent to Jira. We've got a two-way sync there. You can see which ones need more detail.

Here's a bunch that haven't been looked at for a while or that don't have a business case yet or are waiting for design work or is waiting for discovery work to happen. Here's a bunch of ideas that have been put on the roadmap but are stalled by something. Or here's a bunch of ideas that we think should be put on the roadmap. It has AI matching and deduplication.

So it cleans up your roadmap for you. So it's a tool that sits upstream from Jira to make sure that you can find the stuff. And then when you're ready, you press a button and it goes to Jira. And then once something's actually done in Jira, the developers say it's done. It syncs that all back with ProdPad so you can see what's happening.

But just because the developers say it's done does not mean it's done, done. There's always stuff that happens after that.

So you can continue the story in ProdPad to say, well, developers say it's done, but has it met the acceptance criteria?

Do we need to put it through a beta phase?

Do we need to contact customers and train the salespeople and write support documentation and write a press release and do all the stuff afterwards, like measure that there's actually successful?

So you've got all the stuff that happens after Jira as well. That's all product management. And so many teams just don't have a tool to do this stuff. It happens. Sometimes it gets crammed into Jira and the stuff gets lost. Sometimes it just sort of happens by accident, like in a mixture of different tools. And more often than not, it just doesn't happen.

Teams sort of know that this stuff should happen, but they don't do it all.

Yeah, for sure.

I really like how you explained it and I can see the business case for, but also for other people listening to the show that they're not maybe building the specific product that you were building, but the insight that I get from it's you can go in the market where there is a big player and you can build something that you can see what is the blind spots, because that's what you did.

What are the blind spots that these two have?

And then you solve for the blind spot. You allow that to do what they're best at and that's how you grow your company. Instead of being like, I'm going to fully replace them because there are some things that they're very good at. And then it's a harder sell to because, oh, now I have to go and I have to stop using out of this.

You're like, no, what you're using is fine for X and Y, but you also need this, this and this. And this is how I'm going to solve those blind spots.

And again, I think that's insight that any founder can have as they're creating their own SaaS products.

So are the blind spots that are there in the market from the main tools that you can solve for?

My next question for you, it's one of my favorite questions, it's what's the first old shit moment that comes to mind from the early days of your company?

I mean, there was the time that we had to rewrite our entire payment system. We had rewritten it in one and then realized it was a pile of junk. And so I had to rewrite the whole thing. We only had one paying customer on it because it was super, super early days.

And the one paying customer was actually one of our early, early competitors who's now they didn't stick around in that space. And this person is now a friend of ours and now knows this story. But when doing the transfer over from the one payment provider to the next payment provider, something went wrong.

And there was like this system email that went out to technically all the customers this by all the customers, literally the one customer. And it said something like, you know, your prod pad thing has been canceled.

And this person got back in touch with us and said, have I done something wrong?

And we're like, oh, I'm really sorry.

No, you're welcome to re-sign up. You have to go through the flow again. So we had no way of transferring it over because the system that we'd chosen was terrible. And since I think shut their shut the doors was not recommended at all. We moved to a better payment system after that. But I mean, if you think about it, like we would have lost all of our customers.

Fortunately, it was just the one and it was not somebody who was buying for any real reason except for that they were scoping us out as a competitor. This was we don't even count them as our first customer. It was just somebody who's scoping us out.

But yeah, that was a real oh shit moment realizing, OK, now we've got people using this. We've got the world watching. We've really got to think about how we care for customer payment stuff, you know, how we make sure this doesn't happen again, make sure we choose good quality services so we don't have to make decisions like this again. I have been in similar situations even with more customers.

I remember building this one software and that was a problem. And we send 2000 text messages for each customer. I think we had about 100 customers and they all got 2000 text messages each and you're like, oh man, and then like really trying to mitigate it. And then we just send a gift card for everyone saying sorry.

Yeah, I mean, that's good mitigation.

I mean, once you press that button.

Yeah, I mean, been there, done that, not on the product side, but as a product manager in a previous company, we once was one customer, but we did send something like 5000 emails and they were very mad.

Yeah, so for sure. And from that day, now we have all kinds of fail safe to not send about a bunch of messages for people.

Yeah, that's definitely. And I think also super cool that the first customer like, hey, I want to use it.

Why are you cutting me off?

Yeah, no, exactly. That's awesome. Exactly. Yeah.

So what is kind of like a very smart decision that you made in the early days?

Oh, we played around with our onboarding. We made the decision to like always think about onboarding and iterate on our onboarding early days. And so one of the things we pioneered really was the idea of giving additional trial time for your actions that you take in onboarding. So where this came from was we could see that people were using the app.

We initially started off with a 30 day free trial because everyone give a 30 day free trial. That was just the way of Sass. And so we're like, OK, well, that seems OK. But we could see that people were making their mind up within a couple of weeks or so. We could see which ones are going to buy or not based on their activity.

Like, OK, well, that's interesting. We can also see which activities they were doing. There's a certain set of things people were adding their first product, adding some ideas, adding some feedback from customers, adding colleagues and those colleagues making comments. So stuff like that. We're like, OK, that's interesting to see.

Well, how do we encourage people to do that stuff?

Because if we encourage people to do that stuff, we bet that more people are going to then want to buy the app. But we wanted to encourage them to do those actions.

But also, we realized that a lot of people were like, they had 30 days, but they knew when they were going to buy or not within like 14 days. So we cut the trial time down in half to see if that would encourage people to make use of the app more readily. And it did. People did start using the app more readily. It increased the trial conversion rate.

But the number one support request became, quite predictably, people asked for more trial time.

So some people were ready to buy, but other people were saying, hey, could I get more trial time?

So what we decided to do was link the two. So now when you sign up for a ProdPad trial, you get a certain number of days. You get seven days free trial. But as you add things to the app, you get little check marks throughout the app. And you say, OK, we'll add a first product. And you get a day free.

Add an idea, maybe one that's been sitting around on a Post-it note, stuck to your monitor. Take an idea and add that to your ProdPad backlog. Great. You get two days free. You set up an integration or invite a colleague. Get a few days there. So based on the actions that you did, you'd be learning how to do these actions. You get little tutorials for each one.

But also, you would be unlocking additional time. So you'd be getting the extra time that people would be asking for. And so ultimately, you'd be able to get more time. But we would be getting people signing up more readily on this. So you're able to quadruple the conversion rate from where we were to where we ended up using this model. That's amazing. I'm totally stealing that. I'm doing my own SaaS.

And you know what?

We started seeing it all over the place. We started seeing it all over the place. And the thing is, no idea is original. We got the idea from Dropbox and Slack. So Dropbox had the idea of you would get additional storage space by doing actions. So if you invited a friend and if you did things like added the downloadable version, if you downloaded it, you would get additional storage space.

Like, that's cool, but we don't have storage space as a vector in PropPad. And then Slack has the concept of credits. So if you do certain things in Slack, you get credits. We're like, that's cool, but we don't have credits.

What do people want?

Well, people wanted trial time. We have trial time. We can create a vector for that. And so we did so. And it really worked. It's a great insight. And I think it goes down to also the time to value. We can't just decide my trial is going to be 30 days because everyone else is 30 days. And I think that was the first thing that you learn.

What's the time to value?

You reduce how many days were.

But then you were thinking, OK, what else can I do so these people get to the value?

And you kind of made a gamification. I know they're going to get value if they create a card. I know they're going to get value if they add team members. And so you kind of walk through.

If not, if they wouldn't like by themselves get to the value, you were able to create a gamification of time to value.

And how about a suboptimal decision that you made, a decision that wasn't a great one?

Could you share one?

Yeah. So we probably stuck with our original pricing for too long. So when we first bought, sorry, when we first launched Propad, we just chose pricing out of thin air. We didn't do much. And I think a lot of people do this. We didn't do much in the way of discovery around it. We didn't ask people how much they wanted to pay.

We just chose a price because other companies that were similar size to us or similar sort of feel to us were like that. So we looked at Basecamp. We're like, well, they're $25. So we probably charged $20. And there weren't other product management tools out there. So we had nothing to really compare to. So we just made up a price and went from there.

And while we have done a good job of iterating our pricing over the years, we probably see stuck with the original pricing model for too long. So when we first launched Propad, we had two prices and then we made three prices. We had the good, better, best pricing. And we just sort of stuck with that and added more and more to it.

But we realized in the last year or so that actually we'd be much better off with something that aligned a little bit better to usage based pricing. And so instead of charging for packages per company that had a set of users and a set of functionality, it meant that some people were paying over the odds because if you only needed a subset of it, you ended up paying more.

And some people ended up laughing because they ended up with these big packages that covered all their needs and actually weren't spending all that much on Propad. It was a lot cheaper than a lot of other competitors. We were leaving money on the table, which wasn't good for us.

So we realized that if we split it up and said, actually, you know what?

Pay for the module that you need and pay for the number of users who need that module. So now today, Propad, you can buy in individual modules. So roadmapping, idea management, and feedback management. And you can choose as to how many people you have using this. So if you just need roadmaps for one person, 25 bucks.

Really simple, nice, easy starting point as opposed to where the pricing had got to, which was a couple hundred. And so I think we made that decision too slow. And we probably could have changed that pricing four or five years ago to make a bigger impact on the business. I see that quite often. Pricing strategy is a very complex topic. The SaaS founders is going to look at really as afterthought.

It's not easy, super, super complex. And there's a lot of consulting firms that specialize just on that because it is a very complex.

So how did you learn about the pricing strategy?

Did you bring a consulting group to help you?

Did you took the time to really study and understand everything about pricing strategy because it is a complex, very complex topic?

We spent a lot of time studying up on it. We didn't bring in any external consultants, but I did spend a lot of time talking to people who are experts in the matter. We spent a lot of time talking to our customers and figuring out how they buy.

So one of the really interesting things that we did over the last couple of years was talking to people who had bought and people who hadn't bought.

Some people who had heard of us and hadn't bought, people who hadn't even heard of us and just talked about how they bought software in general and just figured out that in general, people who buy software, B2B software, they don't buy these all in one packages. They'd like to have people just go in and experiment.

And so, you know, tools where it's like, yeah, you can just put $20 on their credit card and expense it. That stuff just gets under the radar and then they expand from there. And that's exactly what we found is people like to be able to start with something small that they can just solve their immediate problem with.

So people just come in, solve the road mapping problems for a couple of months within ProdPad and then they start sharing it with the rest of their colleagues and the usage expands from there. And then they change the credit card out for the company credit card or, you know, that sort of thing.

And, you know, it makes a lot more sense that way to grow rather than trying to sell them on our big package right out of the gate.

Yeah, and I think another big insight here again, like as a founder, because that's so complex, we might postpone that. I don't want to deal with that. I don't know what's going to happen. I can make it worse by changing my pricing. And so the lesson here for other founders, you probably should think about that as early as possible.

So how is the company doing today and what does the future look like for the company?

Yeah, great question.

I mean, we've been growing our team this year, which is great and just growing in general. So really excited about some of the stuff that's been going on. We update the product, we do releases every week. So there's constantly new stuff going on in the product. We've got some really exciting stuff coming out in the new year. You'll have probably seen some stuff around like AI things that you can do.

So we're actually taking some of that and using that to power insights, power what we're calling signals. So basically, if you've got lots and lots of feedback from your customers, pile that into ProdPad and what we call dot bot. Dot bots are our AI powered friend within ProdPad is going to basically tell you what sort of things it's seeing your customers talk about and bubble up the signals from within there.

So we've got that in beta right now, but in the new year, there's going to be some new releases and we're going to be taking that out of beta.

And yeah, just constantly moving and shaking and creating some new more value in the going forwards. That's exciting.

And like my final question, what book do you recommend for every SaaS founder?

Oh, such a good question.

What book do I recommend?

You know what, I'm going to say, Obviously Awesome by April Dunford. It's the book on product positioning. I think every SaaS founder is going to find value in this because I think more than anything, it's not necessarily about what you build, but it's about making sure that you have positioned what you're building to the right people in the market to get the most out of it.

I'm actually having a conversation with April Dunford next week. I'm doing a webinar with her. That's amazing.

So if people want to see the webinar, how they can sign up for?

I'll drop you the link, but it's also prodbed.com slash webinars.

Okay, that's great. Thank you for your time here today. I enjoyed learning about your story and about the company.

And if people want to follow you, learn more about you, what's the best way to do?

So reach out to me. I'm on LinkedIn. I'm Jana Basto there. So easy to find me. I'd be happy to connect with you and let me know where you've heard me. Find me on Twitter. I'm simply Basto on Twitter. Reach out to me by email if you like. I'm jana at prodped.com and happy to hear from you. I'd love to chat to you some more. Awesome.

Jana, thank you very much for your time today. I think there was a lot of insights here for all this news. SaaS Origin Stories is brought to you by Dev Squad. To find out more about how we help entrepreneurs launch new products and help larger businesses plug in a ready to go development team, visit devsquad.com.

Add us to your rotation by searching for SaaS Origin Stories in Apple Podcasts, Google Podcasts, Spotify, or anywhere else podcasts are found. Make sure to click follow so you don't miss any future episodes. Thanks for listening and remember, every SaaS hero has an Origin Story.