Peldi Guilizzoni: How To Resist "Feature Creep" + Better Project Management and Prioritization # 154

The following message is brought to you by Balsamiq. Balsamiq have decided to support the SaaS District community by donating their sponsored airtime to some of our listeners. This episode is sponsored by Coffee Pals, a platform that matches people in your organization for weekly coffee through Microsoft Teams. By building personal relationships in your organization through coffee chats, you'll increase engagement, morale, and productivity. They even offer a 30-day free trial to all of their pro plans so you can try it out with your team for your organization. Start new conversations and build deeper relationships to create engagement across your organization by visiting coffeepals.co. If you'd like to receive a promo code for a 90-day trial of Balsamiq, or even just thank the folks at Balsamiq for supporting our community, visit balsamiq.com/go/saas-district today.

Hello, hello everyone. This is your host, Akhil Jobar, and welcome back to another episode of SaaS District.

In today's episode, we're starting our special episodes as part of a mini-series for this month called Inside Balsamiq, where we interview different team members of a SaaS company, in this case Balsamiq, to learn their expertise as part of their overall business strategy.

In today's mini-series of Inside Balsamiq, we're going to talk about how to resist feature creep, and better project management and prioritization.

Today we have our guest, Peldi, from Balsamiq joining us. Peldi is the founder and CEO of Balsamiq, a fully bootstrapped company focused on wireframing and UI/UX.

So Peldi first joined us where he shared his full background and story on episode 18. So if you guys want to check that out, make sure to go back and listen to that episode. Otherwise, welcome, Peldi. Super excited to have you back on the SaaS District show today.

Thank you, Akeel. I'm very excited to be back. Thanks for having us.

So I want to get into, you know, the part of the main core of this episode, which is, you know, a tough challenge in SaaS product management, right? So in terms of how to decide what to prioritize when you have so many features to decide on, what to work on next, how to prioritize what is right. Most of the time it's growth, but I know in your case it's, it's a little bit different. How does Balsamiq choose what to work on? How are you guys keeping track of what you could possibly do and work on next? What's your framework there?

Sure. Well, first of all, let me rejoice in the fact that this is a product management topic and that my dream in life is still to become a product manager. It's my favorite thing to do. So I'm honored that you will ask me these kind of questions. But, you know, I don't have any formal product management training. I just have a lot of industry experience. I've shipped a lot of things in my career. So what I've learned is that How to prioritize? It's an art form. It's super important, but it can be learned. So we have a few techniques that we use. So first of all, we bucket things into 3 different buckets. We have features, bugs, and chores. So obviously, you know what features are and bugs. Chores is work that is invisible to the customer, but that needs to be done. So some refactoring or fixing a security patch or adding monitors on your servers to make sure you get alerted when they're about to go down. So those are the chores. So once you have those 3 categories, Then prioritizing kind of becomes an exercise in— I see these 3 categories as 3 different accelerator pedals, and you can decide what to push at each moment. So sometimes you push more on features, sometimes you push more on bugs, sometimes you push a little bit on all 3. How to decide largely depends on the lifecycle of the product that you're working on. So say it's a new product with zero customers, right? You're just building it. There, it's all features all the time. Obviously, you have to build the thing. You might fix a few bugs that you find yourself, but you don't have any customers to tell you about them. You probably don't have QA team involved so much at this point. So it's all features for however long it takes you, a few months to build the MVP, right? Then when you're about to ship it, you know, you do an alpha, you do a beta, then the number of features kind of dies down a little bit. Maybe you'll finish a few of the features that you really want to have for launch. But in the meantime, it's time to really start focusing on bugs because you don't want to ship a buggy thing because it will make a terrible wrong impression. We go so far into having a gamma after a beta, which is a paid beta, invite-only release where basically people are also paying to be for the product. So that allows you Allows you to build all the payment processing, all the invoicing, and test all that in a nice friendly environment because it's only— it's still considered pre-launch, right?

Mm-hmm.

And so during that gamma, all you want to do is really fix a ton of bugs until all the people in the gamma are happy. And that tells you that you're ready for launch. So At this point, you might also do some chores like making sure you have the continuous integration server set up, you have a staging, a way to create staging environments easily, things that are chores but that you will need once you launch. So then you launch, right? And if you've done the gamma for long enough, You shouldn't have any disaster, but you will still get a bunch of bug reports from customers. So feature work completely dies down at this point for a while, and it's all about bugs. And then if you start scaling fast enough, you gotta work on chores. You gotta make sure that your infrastructure can scale to to keep up with demand, right? So at this point, it's a bunch of chores, a bunch of bugs, and no features whatsoever.

Hmm.

Then, so this is called surviving launch, right? Then after a while, things kind of normalize. The product is solid. You don't have as many bug reports. The servers are humming along nicely. So at this point, you can start thinking about building new features again. By this time, a few months have passed since launch. You know exactly what the rough edges are because your customers have been telling you. And so it's easier to pick what features to add next. So then you gradually add more features, shift your focus to that, and then you enter what I call product, the normal life, the midlife of a product. Which hopefully will last 10 years, likely less in this environment, but certainly a few years. And in this case, you're basically pushing on all 3 accelerators at once. You do some chores, you do some bugs, and you do some features. And every release is a combination of all these things. Another thing that I think is worth mentioning is that, you know, the time between releases gets longer as you progress, right? When you're building features, you release because you're not releasing to anyone. So you release every commit, right? Then in alpha and beta, you release daily or every other day. Then in the gamma, once a week. Then you launch maybe once a week if it's a little buggy. Once it's more stable, you can release every 2 weeks, 3 weeks. And then when you reach the sort of midlife, I think once a month is a good— other than hotfixes, bugs, you know, urgent things. But once a month, I've found, is a good pace for customers to keep up with and for your employees to also not always be in release mode, you know, to be able to work on—

Mm-hmm.

On larger things. So that's sort of the normal proportion. Then if you're sunsetting a product, then obviously you stop building features and you gradually stop fixing bugs and stuff, fixing chores until you kill it. But in general, the majority of the time is sort of this midlife Phase. And in this case, in this phase, we prioritize bugs over chores and features. So we do maybe, I don't know, 40% of our time on bugs. I don't know, 30%, 25% on features and 15% on chores. I don't know, something like that. But we do prioritize bugs first. I think that that's very important because if you have a lot of bugs, your support team is gonna struggle, your development team is gonna struggle, right? Either you hire a bunch of people, but if you have— if you instead you focus on being solid, then you can make do with fewer people and people are happier, et cetera. Of course, you cannot just focus on bugs because some bugs are really not worth fixing. It happens once every year, you know, for one customer. That's not worth the trouble, right? And you can never fix all the bugs because they just keep coming, right?

Mm-hmm.

And it's not really worth your time because if all you do is fix bugs, then the customers might leave because you're not shipping anything new. Right. Right. So, so a good amount of bugs is good. Just, just not, not too much, I guess. So very convoluted answer, but I feel like it does require these different speeds depending on what phase of your, of your product's lifecycle you're in.

No, I love how you kind of break it down and structure that. I think that thinking is good to, you know, how you approach the product cycle and, you know, You mentioned, so when you reach that midlife cycle, I think that's where most of the time you're kind of in more of a stable phase and you're focused on just growing and slow growth of the product. In that first phase, so alpha, beta, gamma, what is the timeframe you generally think is a good time to get to that point? So, you know, like, this is the time you wanna invest in it here. Now you have a good product, 10 years, let's just actually start monetizing this and building a good business here.

Well, let me tell, I can think of, Our latest web app, our latest product that we launched in 2018. So, I mean, I guess it depends on what company you are. If you're Facebook, right, you have thousands of engineers, then you're gonna go faster, of course. But for a small SaaS like ours, we have maybe 15 engineers. Overall, I'd say actually, yeah, maybe maybe ten work on the core product. So for for a smaller company, it takes a while, especially because we don't have investors. So we take our time. We want to do it well. We we don't really have a lot of pressure, competitive pressure, or you know we don't have to. Run, run, run. So in our case, you know, it might take 6 months to get to an alpha, then it takes another 3 months to get to a beta, then maybe another 4 months to get to a gamma. Then we like to run our gamma for a while, at least 6 months. But really, you've already shipped. It's just private. So, um, so that, that can last a long time because you're already making money. Um, so we do 6-8 months of that. Then there's the surviving launch phase, which depending might take, uh, you know, another 6 months probably. And then there's gradually maturity— I mean, uh, middle. I don't want to call it mature because mature means sunsetting, you know, normal stable life. And that can last as long as possible. Probably, you know, our previous web app that lasted 5 years until we decided to rewrite it with a new product.

Hmm.

So that's kind of the timeframe. I'd say a couple of years, From zero to midlife and then 5 years or 10 years if you're lucky for the long phase.

Got it. No, that's super helpful. And one thing we see a lot of founders, maybe your product managers thinking about is all around features, right? I think that's what they— for some reason, that's the main focus because it seems like new and exciting and more and more rather than fixing what's There. It just seems to sound better for users. Like, look at this new thing, we got a new shiny object, right? Why prioritize bugs over these other stuff, features, UI, new design, and all these fancy stuff?

Yeah, I think having too many features is a mistake. When I see our competitors shipping features furiously, I get a little smile because I know that they're basically shooting their own foot. If you have too many features, your product becomes too complicated. So you got to raise your price, you got to have more tutorials, webinars. You know, it's a completely— it changes. It doesn't, you know, unless that's your strategy, right? You want to start with something simple, but then you want to move upmarket or whatever, making an enterprise something which is impossible to use.

Right.

But it doesn't matter because it's the CIO that buys it and forces the whole company to use it. Right. Then that's one thing. But if you, if you have a vision for a product that is kind of complete, that does one thing and does it well, adding too many features actually hurts. Because it just loses its soul. It becomes much more complicated than before. So, you know, I kid that we have a newsletter and I always want to say, hey, guess what? No new features this month. You know, like, you don't have to learn anything new. We are not changing anything. You can just do your work in peace, you know. Because people are pissed off when you add a new feature and change things. People don't like change.

That's right.

They just want to get in and do their work. When they come in a new SaaS especially, and it's all different, they're just— they have a meeting in an hour, just, you know, like, let me work. I don't want to learn your new thing.

Exactly.

So we're very careful in adding features. We always try to put them as hidden as possible. We don't bring attention to them in the UI because recent doesn't mean more important necessarily, you know.

Hmm.

So, you know, we're overall, I think, you know, I'm pretty proud of the fact that on first glance, our UI hasn't really changed over the years. Although we've added, I don't know, 100 features to it, but they're small and considerate and only there for those people who actually need them. You know, the power user features are very hidden. They're there, but they're very hidden, especially in our case where we tried to build a product for beginners. It's really hard to resist the temptation of building pro-level features. Because we do have people who live in our app all day, every day. And of course they have some demands. But we, we try to really stay focused on being everyone's first user experience tool. And so that takes a lot of discipline, I guess. And it takes a lack of ambition because, because we could Make it a pro tool, charge more, go enterprise, get VCs, right? But then who's going to serve all the people that we serve right now?

Right.

Right. And we don't want to have 2 different products because it sort of confuses the message and we don't want to go through that accelerated growth. We're happy the way we are. So because of that, we're able to say no to a lot of features that don't really fit with the vision.

So I think that's a super important point, right? Which is that self-discipline which you talked about. So there's one side of being ambitious and wanting to go down that path, so understand that. But in the case where it's just about avoiding feature creep, do you have any maybe suggestions or frameworks or tips you give to maybe founders who come to you and say, look, I have a product team, I have all this vision, I want to build this and build this out. And you tell them like, hold on, you should focus on this. What do you typically tell them? How does that conversation look like?

Well, I think it just takes being burnt a few times before you really learn. I've shipped things in the past where now we're stuck with it and nobody likes it and it doesn't really fit with the rest of the product. But taking it away is nearly impossible, right? So once, once that happens to you a couple of times, then you become better at learning how to say no to things that don't really fit. It's hard to explain. It's kind of a feeling of, you know, you're crafting something and does, and does this new idea fit in a corner of it? You know, without really taking us down a path that maybe long term we don't want to— we don't want to go down. I don't really, you know, other than having a lot of experience, I don't really know how to— how to give advice because everybody says, oh, you have to say no all the time. Well, it's true, but sometimes you don't have to say no. So how do you decide when not to say no? In my mind, it's the more I understand my customers, the easier it is to understand what product they want, right? So we don't do any analytics. We talk to customers all the time. We have one person that does, you know, 5 interviews a week all the time. We have a support team that's constantly talking to customers. We try to really foster a very tight feedback loop. We have a Slack community and, you know, we know what our customers want to do and what they want from us very clearly. And so we're driven by that, but to a point.

Mm-hmm.

You know, our main, one of our top requested features is rotation, the ability to rotate any UI control that you use in Balsamiq. It's the number one feature. I'm never going to do it.

Why is that?

Number one feature request. I'm never going to do it. Never.

Okay. Okay.

Right. Because it just doesn't fit. Because then it's a simple thing, but it completely changes the nature of the product. Then we become much more a generic drawing tool. And now we got to compete with a million other generic drawing tools. And also, sure, it might look nice to you to put a button at an angle, But your developer is going to hate you because that's not easy to implement, right? I don't want you to be able to use my product to make crappy UIs. I mean, I'm sure you can still, but I'm not going to make it easy for you to do crappy work, right? So, and then there's some other things that, you know, maybe 2 people ask for, but they are brilliant for a beginner, which is where our core customer base is, and we'll do them immediately, right?

Interesting.

So I think it's all about knowing your customer as well as possible.

So it's not really about the kind of 80/20 rule of like, okay, 80% of our users are asking for this feature, even though it might be it, or we ignore the 20%. But it could be just those 1 or 2 people who are like the perfect fit at the right phase, and it's just something they pointed out that nobody ever else did.

Right.

And that's the game changer right there.

Yeah. So I think that it's all about having a strong vision, meaning that you protect that vision over time, resisting the sirens, the mermaids, you know, of the, of new stuff to stay focused. And I think that that's powerful. That's, I think, one of the reasons of our, of our success.

And I just want to touch that maybe as a last question before we get into kind of the personal rapid fire, which is You know, how you stuck to your, your, you know, core vision from what it was from the beginning to where it is today. And you didn't get tempted by, you know, what the norm is by, you know, typically in SaaS companies, meaning you're bootstrapped, you're profitable, you're happy to grow, you know, single digits a year. You're not focused on high growth. Like, you know, I talked to your team, you know, KPIs and OKRs. Well, I mean, a little bit, but, you know, growth targets and, you know, marketing as a track, like, you know, that just Blows my mind. Um, but you're okay with that? What's, what's the thought around that? And, you know, maybe why'd you decide to go that route? You know, then there's no right— there's no right or wrong answer. Um, it works for you.

You know, uh, we've always made more money than we needed, and so this has allowed us to focus on, uh, creating a company that we want to work, uh, work at and a company that other people might want to work with, you know, and focusing on the product, focusing on the customers and their needs rather than investors and their needs, you know. And so as long as we do that and have a good time doing it, we're happy. More money means more risk, more, you know, bigger company, which means harder to manage. I don't know. It's more stress. Definitely more stress. We're making plenty to go around for all of us, and we give back a ton to charities. And so— We're happy in our little corner of the internet.

No, no, I love it. And I mean, I think that is the challenge of knowing when is enough versus that you always think you need more, right? And when you're like, okay, no, we're actually okay. Just looking at it like, we're actually okay, we don't need more. And that's the tough—

I mean, we're making plenty. We're a 33-person company. This year revenue should be around $7.7 million. You know, it's, it's a good, uh, it's a good company. We're totally happy.

Yeah. Well, good, good, good, uh, good job. And I'm proud that you've been able to stick to it.

I guess, you know, a word of caution, which is we're lucky that we're building a tool, um, because tools are, you know, how many brands of screwdrivers are there? Hundreds. They all do the same thing, but the market can digest many, many brands building the same tool, right?

Right.

So tools are like that where there's not a winner takes all. Even on the internet, there's a lot of graphic design tools, there's a lot of marketing tools. You know, people will use the tool that they like best. So in our case, we don't have to grow. to survive. We can, we can stay at our size and people kind of leave us alone. But not everybody has that luxury. If you're building a marketplace, you have to be the one, or, you know, there can be one or two, uh, winners, but that's very expensive. You have to get everybody to know your brand. You have to do TV ads, you know. Um, and so in that case, You have to make a lot of money or you're not gonna last, right?

Right, right. Yeah, no, that makes perfect sense. Shifting kind of gears here, Peldi, moving to the funner rapid-fire questions. This has been great, obviously super helpful for people listening in. Let's start off with, what's your favorite hobby outside of work that you say gets you into flow state? Maybe other than planting those beautiful plants behind you.

Oh yeah, well, I do a little bit of plants, but I think woodworking is my favorite. I'm showing my bowls that I made.

Wow, did that take a while?

Yeah, little wooden bowls. I love the lathe. It's super relaxing. It's like surfing on a piece of wood. So I do a bunch of woodworking. That's really where I lose track of time, just like coding.

Love it. Beautiful. What's something people usually learn only after it's too late?

Ah, I was not prepared for this one.

Uh, yeah, just something.

I mean, we mentioned one example, right? That too many features is bad. More features is not always good.

Yeah, no, that's a fantastic one.

Uh, to back up your photos.

That is very good. Yes, you just never know. Back up, back up, back up. Get that extra hard drive.

Once it happens, then you learn.

Yes, yeah, that's a good one. Um, so obviously you've had some, some great success. I mean, you're happy with where you are. You built a solid team, um, and continuing to grow. What motivates you to keep working hard after, after so much success in these years?

Uh, the same thing that motivated me to start this company, which is learning. Uh, there's so many learning opportunities. There's— I haven't had a job like this where, uh, you have to learn so many different things. I decided to be a solo founder because I wanted to see what does it take to really do everything from idea to support to legal to pricing to coding to server side, etc., etc., right? Marketing. And you have to really continuously roll up your sleeves and you're always faced with new challenges. And then as the team grows, you have to learn how to become a manager. People issues, giving feedback, delegating. It just, it never ends. And it's been 14 and a half years and I'm still learning so much that I'm never bored.

Learning, education. Yeah, that's what keeps it interesting. So you have a dog here named Lucy, right? So a couple things. What's her name? Is that her name?

That's Lucy.

There she is.

Yeah, yeah.

Oh, there she is in the background.

She's sleeping.

She's taking a nap. What's her favorite meal? And why did you name her Lucy?

The name came from our son. He picked the name when he was— we got her when he was 10, so we let him pick the name. And I don't know how he chose it, but Lucy unfortunately has to eat a very specific diet because she had bladder stones. She had to get emergency surgery at some point for it. And so she has to eat the specific food for dogs that have bladder stones, and she has to drink bottled water. We don't even drink bottled water, but she has— we buy bottled water for her.

Dogs are not cheap, eh? They can get very expensive very quickly. So I like this question because it's not like, what's the best trick that you taught Lucy? It's what's the best trick Lucy has taught you? Is that right?

Oh, that's a good question.

Yeah.

Well, dogs are great because they really live in the moment. It's amazing to see, and it's a constant reminder of how great it is to really live in the moment. And then I like that she needs her walks every day. It kind of reminds me to work out. You know, it's part of her body.

She—

her body needs to move. And so my body doesn't remind me as much, but the fact that I have to walk her makes me want to work out as well.

Nice, nice. That's awesome. Yeah, I have 2 dogs myself, and I know they force me to, you know, do the walks every day at least 2, 3 times. Yeah, they're ready to go. So final question, Peldi, before we wrap this up. If you were to start a business from scratch today, that could be— it doesn't have to be a SaaS, it could be anything. What would it be? What would get you interested and excited?

Well, that's interesting because I just started another business a few months ago, and it's a luxury Airbnb in the countryside in Italy.

Okay.

So completely not software related, but I feel like tourism is really growing and, and we had this opportunity to build this house in the country and it came out nice. So now we want to rent it too.

Beautiful. I can imagine that's more of like the product, you know, you had a vision around it and now the customer experience is all tied in together of the—

It's pretty interesting. I'm using a lot of lessons from Balsamiq in this new business, even though it has basically nothing to do with software.

No, that's all right. I mean, that's not always about software. Awesome. Thank you. Thank you so much, Peldi. Anything else you want to add before we wrap this up?

No, thanks a lot. I like this idea of doing a series of interviews with the same company and I'm looking forward to Listening to whoever you pick next.

Awesome, awesome. Thank you. I'm enjoying it as well. Thank you, Peldi.

Thank you, Akhil.

Cheers.

Thank you all for watching this episode and joining SaaS District today. Don't forget to like, subscribe, and hit the bell for future episodes where we interview top leaders in the SaaS industry. If you're a SaaS company looking to grow and unlock the true value of your business, Get in touch with us at Horizon Capital and myself or one of our consultants will provide a free assessment to help you get there and hit your goals. If you have any feedback or suggestions for this podcast, please comment down below and help us improve our content for you all. Thanks again and see you on the next one.

Thank you.