The 6 Instruments to Keep Your Product Alive with DevSquad’s Phil Alves

00:00:01:00 - 00:00:23:09

Ben Hillman

Taking to the skies is a sensation unlike any other. The thrill of breaking free from the Earth's grasp and soaring above it all is intoxicating. Yet every pilot knows that while the sky may be limitless, the cockpit is a sanctuary of precision. Flying isn't about casting off all restrictions. It's a delicate dance between freedom and focus. A pilot doesn't just gaze at the horizon.

00:00:23:12 - 00:00:47:19

Ben Hillman

They diligently monitor their instruments, ensuring that while they may tread new paths in the clouds, they remain safely aloft. These instruments don't restrict. They empower, allowing the pilot to push boundaries with the reassurance that they have the data to guide them. This aerial ballet mirrors the world of B2B SaaS. Pioneering in business is exhilarating. But it's not about blind flights of fancy.

00:00:47:23 - 00:01:16:14

Ben Hillman

To truly soar and innovate, one must have a keen sense of direction. Constantly monitoring the critical metrics that signal whether your enterprise is on an upward trajectory or in danger of a nosedive. The scale of success is vast. But just as pilots have their essential instruments, SaaS leaders have their key performance indicators. Enter Phil Alves, a master pilot of the SaaS guys with a perspective shaped by an unyielding commitment to innovation and grounded in data driven insights.

00:01:16:16 - 00:01:41:22

Ben Hillman

Phil understands that while the best don't simply follow, they do have their gauges, their instruments that are non-negotiables to fill. Navigating the turbulent atmosphere of the tech industry is akin to piloting a plane through ever changing conditions. Always ensuring the instruments are in check. In today's episode, we're set to embark on a high flying journey with Phil, who knows a thing or two about flying planes and building products.

00:01:42:00 - 00:02:02:11

Ben Hillman

We'll dive deep into the world of SaaS, exploring the vital instruments every company must monitor to not only stay in the air, but to soar to unprecedented heights. From paddle, it's protect the hustle where we explore the truth behind the strategy and tactics of B2B SaaS growth to make you an outstanding operator. I'm Ben Hillman, and on today's episode, Phil Alves speaks with paddles.

00:02:02:11 - 00:02:22:20

Ben Hillman

Andrew DAVIES about how the best don't follow. They talk about decision making and rule breaking in business learning from SaaS founders through podcasts, The evolution of market strategies, advice for early stage SaaS founders and the six instruments to monitor to keep your product flying. After you finish the episode, check out the show notes for a field guide from today's episode then will you?

00:02:22:21 - 00:02:33:05

Ben Hillman

Leaving a five star review of the podcast to tell us what resonated most about our guests Advice.

00:02:33:07 - 00:02:38:22

Andrew Davies

Oh, fantastic to have you on the hustle. Why don't you just give me a little bit of background about yourself and then also about what you do?

00:02:38:23 - 00:02:57:10

Phil Alves

Lifelong Entrepreneur I'm about 35 years old now and I start when I was 16. I sold a SaaS business when I was very young, buta consulting firm to pretty big size, and I'm also working my own SaaS on the side. Besides work, I love flying your planes Brazilian and so that's my background.

00:02:57:10 - 00:03:15:10

Andrew Davies

I know the the normal startup outages. As you're building a SaaS product, you have to build the airplane while flying it. So let's see if we can mix both of those two skills as we talk through today. I'm looking forward to this conversation. Phil, because you've built SaaS products for hundreds of clients and that's a real skill to be doing that process day in, day out.

00:03:15:11 - 00:03:29:01

Andrew Davies

Most software founders only get to do that once or twice or three times in their career, and yet you've done that a huge number of times. You've got the reps on it. So we're going to dive into some of the learnings from that and then some of the learnings from you then going and building your own SaaS product as well.

00:03:29:04 - 00:03:37:08

Andrew Davies

So tell us a little bit about death squads and then specifically what you've learned by building SaaS products for so many diverse different types of.

00:03:37:08 - 00:03:55:12

Phil Alves

Customer death squad that specialize in helping people build a SaaS product. And so what we do, we give them a team that can help with everything they need. We believe there's a problem because most times when people try to outsource the developers that they hire, they are task level thinking. They don't think in the product level, they don't push back.

00:03:55:12 - 00:04:19:18

Phil Alves

They are not real partners when you're trying to build a product. So that's quite we really tried to position ourselves as consultant, not just people, they write code and that's kind of like what we do in and also one thing, the first thing I learned, it's many times people think they needed that. Co co-founder They, they think they need in-house team and they look at all the big companies are set as best practices or the best way to do like they're setting the rules.

00:04:19:18 - 00:04:39:17

Phil Alves

But I think what I learned is they cannot play Goliath's game by Goliath's rule. You have to change the rules of the game to make it work for you. So our customers are usually bootstrap people, but they are successful business owners that are on their third or fourth venture. And now they're solving a problem very specific for a market that they know.

00:04:39:22 - 00:04:55:11

Phil Alves

For example, someone that owns 50 car washes now is doing a SaaS to run car washes and he just he knows so much better about car washes and he doesn't need to go learn about how to run a development team on a product manager. Is he just want to give us the vision and then he won't be their product.

00:04:55:11 - 00:05:12:21

Phil Alves

And so I learned that there's like many ways to do it. And also sometimes people come to us to do a version of their product and it's we look at the product and it's so horribly designed, but it's making like multiple seven figures. It's because they're really solving a real pain point of an underserved market. Those are some of the lessons I learned.

00:05:13:00 - 00:05:33:21

Phil Alves

There's a lot of money to be made in this. Specifically, I feel like in the SaaS companies that want to make only $10 million, there are so many SaaS companies that can make only $10 million because people really want is like the $100 million business. But there's like so many $10 million companies to be built, and we do the multiple of them with that squad like very a lot, a lot of our clients.

00:05:33:21 - 00:05:44:17

Phil Alves

I would say at least 80% get to seven figures and then a big portion of those customers get to a figures and they do that because it's their first time They do that because actually having to penetrate behind the understand the market.

00:05:44:17 - 00:05:58:23

Andrew Davies

You mentioned bootstrap founders or second or third time founders in other industries as a key kind of customer segment. I know you also work for VC backed startups and for large enterprise is. So how does your approach differ when working with those different type of clients?

00:05:59:00 - 00:06:16:17

Phil Alves

We have to understand like what their goals are and how can we help them to to get to their mission. But also, I believe those companies hire us because of how we think about building products. So like when a big enterprise come to hire us, specifically work with a lot of venture departments, there is only hours because we can move quicker with less resources.

00:06:16:20 - 00:06:46:15

Phil Alves

So they're trying to act scrappy at that bootstrap even though they are not there. That's basically what they're trying to do. How can I simulate that? And so they come and they hire us and we're able to move quicker and with less war ocracy and we're just getting things done quicker and moving along. So that's but one thing that's very different for, for the VC fund companies, it's how fast they have to grow and how if they're not growing very, very fast, they will eventually be called zombie companies.

00:06:46:15 - 00:06:56:17

Phil Alves

So the decisions are a little bit different about speed and then about how we help them. But usually they say, Hey, this in this part of my product, I cannot move forward. Can you move that forward for us?

00:06:56:17 - 00:07:13:16

Andrew Davies

So speed is key. When you've got that money burning a hole in your pocket. Talk to me a little bit about the engagement model here, because I know that lots of our listeners will be hearing about your model here and thinking, is it cash? Is equity is a short term for them. BP is a long term partnership. Like what does a normal project look like?

00:07:13:16 - 00:07:31:23

Phil Alves

On average? People are going to say it was 18 months, but our contracts are month to month and they pay a fixed fee depending on how many resources will be assigned to that. Every team, the base level is going to have at least a product manager akin to developers. And then from there we add more developers, we add designers and the other pieces that they need.

00:07:32:05 - 00:07:52:22

Phil Alves

We like to think in the plans and themes of Borchers. I believe all cars are the best way to to like understand where we're trying to go meet with our clients every 90 days. The ones they're looking at states you actually ask them to fly to Utah. We have office in Utah and then we spend a whole day doing old care planning on road map and in We love also the now Amex later the way of doing road map.

00:07:52:22 - 00:08:06:10

Phil Alves

And so we do that and then we work with our customers in 90 days increments. So on average, we're going to say we've lost 18 months. Usually they will leave when they race a big series A or series B, And but like companies that want to stay bootstrapped, we have customers that have been with us for three or four years.

00:08:06:11 - 00:08:23:03

Phil Alves

They're like, I just want a development team at all. But most of our customers are like, We want to come, go to market, keep developing, keep evolving, but eventually we will bring our own team. And so that's how I call the engagement. Looks like our cocktail. In terms of numbers too, I think that's important. People listening how much does it cost to hire a consulting firm like the squad?

00:08:23:03 - 00:08:42:11

Phil Alves

People are spending anywhere between 200 and a half a million dollars away from us when building their product and keeping working. So. So it's not cheap. But again, it's not the first or second time founders that followed. It has some money. It's not super rich, but he does have some money and then he comes to us to reduce risks because at this point he's very busy and time.

00:08:42:11 - 00:08:58:09

Phil Alves

It's a scarce resource and money is not so much, you know, so so those are the people that we will work with for that squad. And it's the same way with big companies like, for example, like if a venture firm wants to launch a new product, like we work with ADP, get a brand new product for them, they came to us and they're like, He's the product, he's the vision, go build it for us.

00:08:58:12 - 00:09:01:03

Phil Alves

And then they talk over after like a year and a half over.

00:09:01:03 - 00:09:15:22

Andrew Davies

100 SaaS products built, you must have decent pattern recognition on, you know, the kind of traits of those of the founding team and the traits of the business, the idea of the market, what things have to be true in order for one of these products to work and to grow to that seven or eight figure revenue.

00:09:15:22 - 00:09:34:07

Phil Alves

Mark B to B is usually the first thing like they should. They have to be in the B2B space, need to be able to charge these $100 a month for for their subscription. They see cheaper products having a very hard time. The knowledge of the founder of like the market knowing the market very well, I would say 80% of the time they're doing something that they need themselves.

00:09:34:07 - 00:09:58:09

Phil Alves

20% of the time. They really went in, study and understood the market very, very, very well. So that makes the whole difference. Just the capability of the go to market strategy that the founder has to put in place because the first million is very heavily dependent on the father experience in enrolling know product to market. I think what we do, honestly, the 3%, what we build is 3% of the equation, like it's how we solving a problem that people actually have.

00:09:58:09 - 00:10:19:00

Phil Alves

And how do you know that is usually if you are like the user of that problem and can you sell that product? I believe like building B2B SaaS product has zero technology risk. That's why you outsource because there's zero technology risk. There's like hundreds of products that have been built. There's a bunch of technology out there. So if you're not like building the next open A.I., there's no technology risk.

00:10:19:00 - 00:10:30:09

Phil Alves

And so if there's no technology risk that can be outsourced, that's not very important. And then you go work on go to market strategy, solving an actual problem that people have, and it comes out to the founder knowledge of that problem.

00:10:30:09 - 00:10:40:16

Andrew Davies

You've also got a lot of experience on managing dev teams and the dev process. Talk to me about the learnings and the best practice of how you manage and measure a high performing dev team. What does it look like?

00:10:40:16 - 00:10:59:21

Phil Alves

Even I build my own product around that. I have a broader it's called dev starts. And the first thing was like, how can it benchmark? What is the starting point to know if my team is doing well or not? Because like with working and building 20 to 30 products at once, I wanted to know how well each team that we gave to our customers were.

00:10:59:21 - 00:11:20:21

Phil Alves

And since the beginning, we, our marketing things, we did your high performing development teams and I'm like, okay, what does that mean? How can we actually give people high performing development team? I went back and I figure out some PA data numbers that are true across most of high performance development teams. I didn't make those up. They'll come from as from the metrics is space metrics.

00:11:20:21 - 00:11:37:09

Phil Alves

And the main thing is that for me makes a huge difference. It's cycle time, which is how fast the team goes from started to code to like things in production. Plenty across. How can the team plan like if I say, oh, the this, how much of what I say I was able to do code size code review size.

00:11:37:09 - 00:12:03:09

Phil Alves

So like how is mouse the code review? I believe code review is the most important ceremony that happens in tougher development. We think daily sprint planning get out that the most important thing is software development is code review is where the developers are learning, is where we're getting to the quality of the product. And so the metric that we have to look there is what's the size of the the pull request that's been sent of the code that's being reviewed.

00:12:03:11 - 00:12:21:21

Phil Alves

And if it's too small, it means that the team is like being able to move in as well increments. The real review is being done on that code base and we look at deploy frequency, how frequently we actually deploy and we look change. If I rate how high or everything the I move to production, how much of my breaking like will move fast and break things by Facebook.

00:12:22:02 - 00:12:44:00

Phil Alves

I am moving too fast and breaking it too many things, but I understand fingers going to break. That being said, I feel like the foundation doesn't start at the numbers. The foundation is the culture, and the culture of the team is a team that has open communication, is the team doesn't have insecurities because when I'm doing that code review, like if in some I'll find a problem and someone has a suggestion and they're maybe they're less senior than me.

00:12:44:04 - 00:13:04:00

Phil Alves

So the foundation is culture, the whole thing like culture, it's a strategy for breakfast. I believe in that, and I think the best teams is the teams that have the best culture. If open communication safety, where people can say what they mean and where people are afraid of looking at hard beat it like most teams are like, we're not going to look at numbers.

00:13:04:00 - 00:13:14:18

Phil Alves

I'm like, Why? Why are you afraid of the numbers? If you look at any professional sports, we know how well the basketball player is doing, how many of the shots they're missing. So that's kind like what I think it defines a high performing development team, planning.

00:13:14:18 - 00:13:27:15

Andrew Davies

Accuracy, a rate change cycle time deployment frequency code quality review and rework rate. Those all feel like quantum things we can measure. How do you measure a culture? How do you measure insecurity? Is it open communications.

00:13:27:15 - 00:13:44:12

Phil Alves

That's very, very hard to measure and we are working very hard on that. The ENP is it's a good start, which is kind of like NPS above core employees. So you can kind of see how people are. It comes down to what's in the ground, understand the I think that's the thing about building products. We want it to be all about data.

00:13:44:12 - 00:13:58:21

Phil Alves

But at the end of the day, it's still evolving. Everything that we do, it's like this really go how people feel around your company. And I mean, I can look at the Glassdoor for the company. I can look at other things like that. It's very hard to measure culture. That's why it's the hardest. It's the super easy to MuleSoft.

00:13:58:21 - 00:14:07:04

Phil Alves

I like that stats that give you a numbers, but if you don't have a good culture, dev statistics are this for you or any other product. Similar dev stats and a developer metrics software.

00:14:07:06 - 00:14:24:03

Andrew Davies

Could we take a couple of minutes and just think about each one of those six? Because I find this fascinating. I think our audience will too. So can you take each one of those six and just give me, you know, whether it's a target you would be aiming for or a comment on how you measure it so that every one of our listeners can have a thought of what they'd do next with each one of those six.

00:14:24:03 - 00:14:24:15

Phil Alves

Sure.

00:14:24:15 - 00:14:30:23

Andrew Davies

So let's start with planning accuracy. So how do you measure planning? How do you measure the accuracy of your planning and what's your target there?

00:14:30:23 - 00:14:56:21

Phil Alves

So our target, it's 80%. Why? It's 80% because if you want your team to be 100% all the time, you're not leaving any room for mistakes. And people going to start to like really not push the boundaries they will starts to like, what are you going for? The layups if we're going for sport analogies. So you want to give your team some room to to be wrong and to be like, okay, to be optimist because developers are usually optimist.

00:14:56:23 - 00:15:17:01

Phil Alves

I believe the target above 80%, you are in a good place, actually, even 65 to 79, you're not so bad. Anything below 65. We have to figure out like we're being too optimistic what's going on or our fingers being able to spread and how we measure is very simple. We look what we put in. They spread. So we put like 20 cards in this breadth.

00:15:17:01 - 00:15:36:22

Phil Alves

And while we finish all everything that we thought we would finishing this, so we finish six of 20. But usually what happens is like things change along the way and cards get added and then we have to measure that to like measure the process. How, how true are we to our processes? Are we able to actually close the sprint and do the things that we thought we would do in that time?

00:15:36:22 - 00:15:56:11

Phil Alves

And MuleSoft was all about estimation and like making educated guess we have to get better at those guess as time move along. And I think that's a super important metric because maybe our team is doing very, very, very well and they're like super, super good, but you're communicating wrong and speculation management is that one of the main things that you have to do to keep everyone happy?

00:15:56:11 - 00:16:15:19

Phil Alves

Your team might be delivering more than 99% of the team, but you are plenty access. It's 50% and you're getting everyone mad at you because you cannot communicate. What could we actually do? Even though we have seen that all the other metrics are amazing that they play every day, the cycle time is 24 hours. The team is actually kicking butt, but they're super bad, they're communicating.

00:16:15:20 - 00:16:20:23

Phil Alves

And so that's causing everyone to be mad at our team. So that's why planning access is a metric that's very important.

00:16:20:23 - 00:16:24:04

Andrew Davies

Let's get to the next one then. Cycle time. How do you measure cycle time? What's a good time?

00:16:24:09 - 00:16:44:23

Phil Alves

There's two kinds of cycle time. There's cycle time. The poor request select one. The developers start a branch, work on their breast when they get merge. And there's the issue cycle time, which is we have like this whole feature plan. So when that feature starting progressed to when their future got to that. So we measured at looking at a GitHub data and a jury data and then we have those two numbers.

00:16:44:23 - 00:17:05:00

Phil Alves

And that's very important because you start to see, for example, where things getting stuck are, things are stuck in code review. They're waiting like base to code two for us to do code, review our finger in stacking or and also we start see if it's too big, like are we biting more than we can chew? So the cycle time we support or we are spending base coding but then like later is hard to do.

00:17:05:00 - 00:17:22:07

Phil Alves

The code review is hard for a cookie. That's why I believe cycle time is the most important metric of any development team, and the shorter you can make that the best. And then let's talk about where the benchmarks are. I think you need to be below five days with the issue cycle time. So everything that you put in your board, a song goes to progress.

00:17:22:07 - 00:17:37:03

Phil Alves

I want to be done in less than five days and with the PR cycle time I track being hours and I think good number is like less than 42 hours. You have to be finishing your peers. And then the way that works, if you sign up and look at my product, we give you the whole benchmark right away.

00:17:37:03 - 00:17:41:00

Phil Alves

You log in and you can see where you stand in each of those six items, as.

00:17:41:00 - 00:17:44:04

Andrew Davies

Could you do the other ones then. So code quality review, how do you measure that?

00:17:44:09 - 00:18:02:10

Phil Alves

Actually the metric scored review size because we just measure the number of lines of code for review that we are doing and then we go deeper a little bit. We measure how many shoes we got, how many reviews, how many comments we wrote, because sometimes people are doing code review or just clicking the green button. If you're not catching any shoes, what code review is actually being done?

00:18:02:10 - 00:18:10:11

Phil Alves

So those are the things that are measuring when it comes to to code review. And the smaller it is, the better you want it to be under 200 lines of code to be in a good place.

00:18:10:11 - 00:18:11:22

Andrew Davies

And then failure rate change.

00:18:12:01 - 00:18:27:12

Phil Alves

How many times you actually have to do a hotfix, something that broke in production and you had to submit a hotfix I what's the percent of the time of other deploys that you do there are hotfix the number we want it to be under 15% again I think is going to happen if your team is moving quick enough, things are going to break in production.

00:18:27:12 - 00:18:44:15

Phil Alves

It's just the nature of building moving quickly. I've never have a problem production, you know, moving to slow. If you're having 20, 30, 50% of issues of change of rate, they will be too quick. Then you have to take a step back and look at how can we move maybe a little bit slower where things are breaking the process.

00:18:44:15 - 00:18:51:13

Phil Alves

So yeah, so the change, the failure rate, it's a very important metric to know like of how well your team is moving and how many times things are actually breaking.

00:18:51:13 - 00:18:52:15

Andrew Davies

So rework rate.

00:18:52:19 - 00:19:11:13

Phil Alves

We work rate know whether that won't work. That's like how there's rework in there is refactor refactor is good rework it's bad refactor it's things changes that to the code that you wrote that it's like less than 20 days old. So you just wrote it, you got to work on it. Awesome. Left me refactor moving the zero here just it's always more organized for the next person.

00:19:11:15 - 00:19:32:23

Phil Alves

Rework is code that you did and after 20 days or 30 days you have to go and do it again. And that usually means that was something wrong in product. There really means that we didn't know what we actually supposed to build because you're just changing things that we already built. That's where our reward rate is. It's important to to track is also none of those metrics alone should mean that your team is doing bad because you have to understand the big picture.

00:19:33:04 - 00:19:45:02

Phil Alves

And real work I think is the biggest one about sometimes you do a big pivot or sometimes for early on in the process, and so it's okay to have a bunch of rework in certain stages, but it's also a metric that's good to to be looking at.

00:19:45:02 - 00:19:47:14

Andrew Davies

Bring US Home is the only one we've missed deployment frequency.

00:19:47:17 - 00:20:05:18

Phil Alves

Yes, planning frequencies. That's very high performing teams like GitHub, they deploy every single day. So how how often are you deploying new things to perfection? Of course, that depends also on the size of your team and in the mature of your team with a mature of your tools. I believe feasible metric for any SaaS product if at least once a week we are in a strong position.

00:20:05:18 - 00:20:20:09

Phil Alves

If we can deploy new things at least once a week, you're a very strong position. If we can deploy like once every day or multiple times a day deploy, it's so important because that's the actual value they deliver in your customers. How many times I'm actually giving new value to the customer. So that's a metric that I really like.

00:20:20:10 - 00:20:37:06

Andrew Davies

I appreciate you diving into those. So I think it's really helpful for both engineering leaders or experience, but also for founders who perhaps haven't worked with engineering teams much before because those metrics are things that you can know, understand and measure. So really, really helpful. Maybe if we just back right out again now and think about some of the trends you're seeing.

00:20:37:06 - 00:20:48:23

Andrew Davies

So you've been doing this for a while now. What are the changes you have seen in the SaaS industry, in the B-to-B SaaS products you're building? What are you seeing coming around the corner over the next over the next couple of years? How have things changed from when you started to.

00:20:48:23 - 00:21:04:08

Phil Alves

Know building SaaS product is getting easier and easier? The tools that we have to build SaaS products allow us to move quicker and we don't have to solve the problems that we're ready to solve for us. Years ago, like for example, payment could be a problem or log in or so building a SaaS products getting easier and easier.

00:21:04:08 - 00:21:22:02

Phil Alves

And I see that what happens to customers expect more and more the whole thing of, hey, they're going to lose broken product. All of this market is very, very underserved where they'll see so many underserved markets anymore. So I feel like the level of quality of products they have to build is also high. And that's like some of the changes that I see.

00:21:22:02 - 00:21:40:00

Phil Alves

I also see more and more companies experiment on. We've product lead, which is amazing. I love it. But there's also a lot of risks that come in for there. You have to be so much better onboarding, you have to be so much better delivering value, and that's like was one of the hardest things for me, building my SaaS product because I wanted people to log in and get value.

00:21:40:01 - 00:21:52:15

Phil Alves

That was the whole thing with like putting out this benchmark. They're going to log in, you're going to connect, they're going to give you a benchmark. From there you're going to go deeper. But I see more and more companies going public at and I see I think that's going to keep me in attendance in the years to come.

00:21:52:15 - 00:21:53:01

Phil Alves

So I find.

00:21:53:01 - 00:22:07:17

Andrew Davies

It fascinating that you've been building SaaS products for other people and then have now launched your own one. And there's that old Spanish proverb that says the cobbler's children have no shoes. So did you follow all of your own best practice when you launched Devsecops and what differed?

00:22:07:19 - 00:22:28:14

Phil Alves

I did not. Before I talk about the best practices I didn't follow, I think best practices the wrong name for best practice because the best really don't follow best practice. Think about investing. People tell you, Hey, buy index funds both above or by single stock, and that's how you got rich or like I like racing cars. Everyone tells you, hey, keeps with the racing line and that's going to go fast.

00:22:28:14 - 00:22:53:11

Phil Alves

But then you go look at Louis Remington and he does everything different. He doesn't follow any race line or everyone talks about customer research and the Steve Jobs did zero customer research. So I believe best practices are a great foundation for you to be in a safe place. And you really have to understand and deeply. And so the best practices I told my customers to follow, I understood them deeply, but I decide to not follow some of them because I could understand the trade offs that I was doing.

00:22:53:11 - 00:23:10:20

Phil Alves

By doing that, I feel like I put my product in the different position. One thing that now every single customer that's been a tool before with the platform, let's go to market quick and let's start getting paid as soon as we can. And that's normal advice for anyone building a product like every single. Investors tell you that when I decide to build my product, the different I build the whole product.

00:23:10:20 - 00:23:26:18

Phil Alves

Before I was in the rush, I took me two years to get the first paying customer. But why I did that, it's because I understood the reason why you move very fast because you likely going to run out of money now if very consulting firm, a very, very successful consulting firm over here, I knew I would not run out of money.

00:23:26:20 - 00:23:44:20

Phil Alves

I wanted to go to the market with a product that was more established. And other thing I also told my customers, do not be a better tester, use well-established technologies. There's a lot of risk in using a technology that's new, that's now established. They might die and it never be the product for our customer of us with any new technology.

00:23:44:20 - 00:24:00:10

Phil Alves

When I went to build my own product where a big part of the Laravel kind of like ecosystem and there was a new product coming out, which was Livewire Laravel Livewire, and it was a powerful product that allow you to build like a monolithic application and not having to use any of the other JavaScript framework and in this how to use that product.

00:24:00:10 - 00:24:20:13

Phil Alves

And that was a big risk. The product could, could stop being produced and a lot of other things could happen. But I just look at it and if I understand software and I think this is going the right direction, but most times people, they're like following trends, don't have enough knowledge to realize if that trend is going to stay there or not, or what kind of provider that's going to add to just follow trends because that's what's hot.

00:24:20:13 - 00:24:37:06

Phil Alves

And so that's why the best practice of not following trends is going to definitely protect you. But I was like, Hey, this is technology and I want to go and version three just come out and it's powerful and we're going to, you know, allow us to move super quick. And it was a good decision. I also tell people, stick with one market and my product is available in Brazil.

00:24:37:06 - 00:24:51:06

Phil Alves

And as a way of United States, again, understand both markets work well. And I decided I'll go with both market Yeah. So those are some of the rules that I was like I tell everyone to follow and I'm like, okay, I'm not going to follow them, but because I understand the best practices, it's not just I'm going to follow because, you know.

00:24:51:10 - 00:25:08:10

Andrew Davies

So the best don't follow best practice. I like it. You also run a podcast, right? You know, I think it's the SaaS Origin Stories podcast. Every SaaS hero has an origin story. So I love the process of interviewing people like where we're speaking here and what I can learn from it is you must have learned a bunch from this as far as you've been interviewing.

00:25:08:10 - 00:25:14:02

Andrew Davies

What are some of those common themes or insights you've uncovered while interviewing SaaS founders on your podcast?

00:25:14:04 - 00:25:36:09

Phil Alves

The main thing that comes to mind, it's like what you hear usually when you are reading like the most popular websites and they speak with people actually doing it's what word two years, three years ago. The market is very quickly changing. So if the podcast I was able to interview the SaaS founders, but I also get like strategy as it was working today and his strategies that were making sense.

00:25:36:09 - 00:25:54:08

Phil Alves

And so was it because of my podcast that also I decided to take so longer, so much longer to build the version one of my product because I interview multiple people that did that. And then I start, Why didn't you do that? Oh yeah, that was my third, fourth company I knew I could support. I did because of I was just changing the rules of the games.

00:25:54:14 - 00:26:08:09

Phil Alves

So like it's cool with my SaaS Sparkasse to see how different founders follow a very different way to build. There's not like one single. This is the best way to do stuff, you know? So that's the main thing I learned interviewing under SaaSol. There's a learning about our origin stories.

00:26:08:09 - 00:26:25:17

Andrew Davies

We've got an audience of thousands of SaaS founders and go to market leaders. A whole bunch of them will be very early stage. They may be a bootstrapped and a building, their first or maybe the second second SaaS product. Let's close out with some advice for them. So you're now their consultant sitting in front of them. They're kind of planning their MVP.

00:26:25:17 - 00:26:35:22

Andrew Davies

What are your cautionary words of advice and words of wisdom for them as they plan the next few months and maybe, you know, hire their first engineer and think about how they build this MVP and take it to market.

00:26:35:23 - 00:26:51:13

Phil Alves

The number one thing that I help a lot of people in consulting is to come out of their big picture vision to what is the tactical things that we have to do to take to get to our first million. And they might be very different because founders like this are not going to go to 10 to 100. Oh, that's awesome.

00:26:51:19 - 00:27:13:04

Phil Alves

But we need to come down like, Wow, what is that? What's going to work for us? To make the first million? You have to think a little bit more short term. And I think a lot of fathers sometimes understand that, and the things that you do at this stage of your business is very, very different. That's the whole reason for my podcast is because like we look at what big companies are doing today and you want to emulate that, that's a bad idea.

00:27:13:04 - 00:27:28:22

Phil Alves

You need to look at what they did when they were smaller and maybe emulate that and so my whole thing is like asking about the origin stories because you can see what people did when they had to be scrappy or like in the very, very early days. What we do in the early days is very different than what you do when you're bigger.

00:27:28:22 - 00:27:41:17

Phil Alves

And I'll just tell fathers there's you have to realize that. And going back to that concept and we also cannot fight Goliath following his rules. You can always lose, you know, you have to create your own rules.

00:27:41:19 - 00:27:51:20

Andrew Davies

And there's been so much in this conversation for we're going to be able to pull out a whole bunch of insight for our for our audience here. Are there any final thoughts before we close this you would like to leave with. I don't.

00:27:51:20 - 00:27:52:04

Phil Alves

Think so.

00:27:52:04 - 00:27:59:03

Andrew Davies

So that's great. We've covered so much. This is super helpful and I love the ability you've got just to go straight into the answers.

00:27:59:03 - 00:28:19:16

Phil Alves

Actually, maybe it is okay if there is like a call to action to my product, like, right. I'd like to invite everybody to go benchmark our development team, go to dev stats dot com, sign up and connect your repository or JIRA and you're going to be able to in less than 30 minutes benchmark your product. We're not going to ask the red car upfront or anything and and you're going to see where you stand.

00:28:19:18 - 00:28:24:21

Phil Alves

So I just would like to invite everyone listen to the show, too, to do just that and let me know what you think about the product.

00:28:24:21 - 00:28:29:08

Andrew Davies

Fantastic. Thank you so much, fellow.

00:28:29:10 - 00:28:49:02

Ben Hillman

Shout out to Phil for being on the show today. We talked about decision making and rule breaking in business learning from SaaS founders through podcasting, the evolution of market strategies, advice for early stage SaaS founders and the six instruments to monitor to keep your product flying. Make sure to give Protect the Hustle a five star review and tell us what lesson from today's episode was your favorite.

00:28:49:04 - 00:28:56:19

Ben Hillman

Thanks for listening. Subscribe to and tell your friends about Protect the Hustle, a podcast from Paddle Studios dedicated to helping you build better SaaS.