- Some of you guys might be like,
"Well, I don't wanna learn this stuff."
Here's the deal.
I'm not asking you to write code,
but I'm asking you to dive in and learn these three things.
(upbeat music)
Hey there, I'm Dan Martell,
serial entrepreneur, investor and creator of SaaS Academy.
In this episode,
I'm gonna share with you how to manage a SaaS,
a technical product as a non-technical founder.
Maybe you're worried that you're gonna spend
all your time and energy building something
that doesn't even work,
that just falls down on the weight of the usage,
it's super buggy,
and you don't have enough technical knowledge
to feel comfortable building a software product.
And maybe you've done the leap already
and you're in it,
and you're worried that the wheels are gonna fly off,
or you're about to make the decision,
but you're scared that you won't find the talent,
or you won't know how to manage them,
or somebody's gonna run away with your idea
and steal your code.
All those things are true.
What I'm gonna share with you today
is the four specific strategies
that if you implement will make this 10 times easier
to allow you to move forward
without worrying about those challenges.
Let's get into it.
So be sure to stay to the end
because I'm gonna tell you how to get access
to my Idea to Exit Mini-Course,
where I talk about how to prototype,
pre-sell,
and hire your dev team
if you're just getting going.
But more important,
I wanna tell you why I feel qualified
to share these ideas with you.
So first off,
I taught myself how to code as a 17 year old.
I didn't go to university.
I'm self-taught.
I thought like many people,
some of you guys have gone through coding boot camps,
that for me to be successful in SaaS,
in technology,
I need to learn how to code.
And I went year after year writing code,
writing code,
probably wrote code for five years
until I realised,
"I'm not the best at this."
When you meet a 10X programme,
or you meet somebody that absolutely loves code,
maybe that's you,
it just certainly wasn't me.
I was more of a ideas guy,
I like to talk to customers,
I wanna figure out where the opportunity is,
maybe sell a little bit,
do some marketing.
And even though I've hired 200 engineers
across all my companies,
I just hired three last week,
I've coached over 700 plus non-technical SaaS founders
to lead successfully and grow their SaaS companies.
And many of them,
I've helped them avoid the pitfalls
which I'm gonna share with you today.
These are the four strategies
that are gonna allow you as a non-technical founder
to play the game at the highest level
in a world of technical people.
So let's get into it.
Number one, how to find talent.
So here's the deal.
Most people ask me,
"Dan, I've got this crazy good idea.
"I wanna hire a programmer.
"Where do I find somebody that can build this for me?"
Here's the reality.
You could look at the college,
you could find your buddy,
you can ask your friends, all those stuff,
the truth is
is for 90% of the founders out there,
I'm talking about products like Basecamp, Jason Fried,
you guys probably know that,
to many others out there,
products you use,
I know their early origin stories
and many of them found developers
in other parts of the world.
The reason why,
if you search on Google,
"cheap developers
"or inexpensive developers in other parts of the world"
you will find the countries.
Today, I want you to Google,
I'm not gonna tell you what they are,
but you could probably guess,
there are certain countries that right now,
even though the world is going through this
increase in salaries,
if you haven't noticed that,
literally all my recruiting friends,
they're seeing 20, 30, 40% increases in salary expectations
across all roles.
And you're seeing this even in certain countries
that used to have really competitive
inexpensive engineering talent
are going up.
Some of them have doubled in the last four months.
So what I would recommend
is to do the Google search
to find the countries today
that have those people,
literally there's countries
where you can hire a developer for $2,000 a month full-time,
I'm talking 160 hours a month.
They're available for $1,200 a month,
$1,500 a month.
It's incredible.
It shifts all the time.
And it doesn't take away from the concern
of being able to manage this person,
and qualifying them, et cetera,
which when I'm gonna talk about,
but I need you to first understand
that most early stage development
needs to be kept on the lower cost level
because there's a good chance
that what you build initially
isn't exactly what you need to build
and you need to give yourself more time and resources
to eventually get there.
Number two is managing the technical talent.
So what I've seen over the years
in many of my coaching clients
is where they have sometimes a technical co-founder,
or at least a technical partner
that's built a lot of the code for them.
And the challenge is they run into a day
where they feel like they're being held hostage.
The person wants a raise.
They want more equity.
The partner wants to double their rates
and the founder is like,
"How do I deal with this?"
Well, I'm gonna give you the three specific tactical
and technical things that you need to do.
And some of you guys might be like,
"Well, I don't wanna learn this stuff."
Here's the deal,
I'm not asking you to write code,
but I'm asking you to dive in
and learn these three things.
It's just like if you open up a restaurant,
I'm not asking you to become a chef,
but I am asking you to be responsible for your kitchen,
meaning you need to understand product,
and food cost and refrigeration,
and safety standards and all those things.
So the three areas is one is source code management.
In your business,
if you can't find out
where your code is being managed and stored at,
you gotta fix that.
So most people are using Git or GitHub.
You can use whatever source code management tool.
You just gotta ask your technical person,
"Hey, what code repository are we using
"for the source code management?"
And get yourself admin access.
So that's number one
is source code management.
Number two is what's called the CICD pipeline.
It's an acronym.
It stands for
Continuous Integration and Continuous Deployment
of your code.
It's a fancy word to explain
the way multiple developers write code.
It merges together,
and then you push it to staging or production,
or even you could build your own
local development environment,
but the CICD pipeline,
which is something you can Google,
and there's diagrams on it
that can show you how to do this
will give you certainty
that at least multiple people working on the code
are doing it in an efficient way.
So if you wanna avoid your code to be you super buggy
or that it's not being built right
because you can't really build a CICD server
if you're not deploying in real time
and you wanna be deploying every day,
ideally every week.
So you can ask your developer,
"Hey, how often are we deploying our code base
"to staging or production?"
If it's only every two weeks per sprint,
that's not a good way to do it.
You wanna build the would be code base
so that it can continuously integrate
continuously deploy.
See why it's called CICD?
And force them to go down that route.
And they might say,
"Oh, it's too much.
"We don't need to do that."
Don't listen to them.
Send them this video.
Hey, if you're saying that to the founder,
stop saying that.
It's not true.
You know what you gotta do.
Deploy it. Check it out.
There's a bunch of great technologies,
I'm not gonna get into it,
but Jenkins is a good one
if you wanna look into that one.
And then the third thing is agile development.
So agile development is the process
of coming up with customer features and stories,
and then building that for the engineering team,
creating the stories for the engineering team.
Most people have the developers write the code
and then the product becomes developer design.
And that is a very bad strategy for doing it.
So you wanna make sure that you use agile.
So if you don't know what agile is,
buy a book,
read the book,
go through the process
become an agile person,
build an agile team.
But those are the three things.
If you said,
"I'm not technical
"and I wanna survive in building my SaaS product,
"What do I need to know?"
I'm saying source code management,
CICD pipeline,
and then agile development.
You do those things,
you will literally save yourself
all the pain that most of my clients have come to me
after they almost lose their code base,
or almost kept hostage,
or have to go through a big rewrite
because their code is spaghetti code
because they didn't have any process.
It's a scary thing.
So that's the area you need to focus on.
Number three, verify talent.
So look, if you've never hired a technical person,
you don't even know what good code looks like.
They might do a test project,
show you the code
and you're like, "This looks good."
Here's my strategy.
It's what I do even with my portfolio companies
at High Speed Ventures
is I hire a technical advisor,
I have a technical advisor.
I'm technical enough,
but I just don't have the time to do it.
So what I do is I hire somebody
that is very talented in development,
maybe works,
well, very likely works for somebody else,
that I can't really hire,
but I admire their knowledge.
So you can hire people on Upwork.
You can find those people in your local city.
But you just wanna find somebody that's really smart
at the code and the infrastructure
and the architecture,
to on a weekly basis,
one hour a week,
come in, look at the code,
look at the infrastructure,
talk to the team,
and then report back to you.
Literally, they act as your kind of
Rosetta Stone of understanding what's going on.
So they might see something and go,
"Hey, Dan, I just want you to know
"it's really weird the fact that
"all of the logins for the database
"is hard coded in the front end code."
And you're like,
"Whoa, yeah, that sounds weird.
"How would you do that?"
"They should put it in a configuration file
"that should be locked down
"and only available to X, Y, and Z person."
"Have you given that feedback to the team?"
"Yeah."
"All right."
"So I just want you to know
"that you need to work with them
"to make sure that gets changed in the next sprint."
"Perfect."
"Thank you very much."
That kind of advice,
you can get it from a coach.
You can hire a technical CTO coach.
My friend, Etienne de Bruin,
has a programme called 7CTOs.
You can check him out.
There are people out there,
coach, mentor,
but an advisor or technical advisor hour, week,
that's to me how we verify the talent
to make sure that not only do we hire the right person
and they can also be involved in recruiting
to do final interviews,
but they also monitor things
and they're just part of the ongoing sanity check.
It's no different than hiring somebody
to do secret shopper at your retail store
or your restaurant,
to come in, order a meal,
do an assessment,
give you the report,
and you take that and talk to your manager and say,
"Hey, this is what I heard from our secret shopper."
That's the same idea.
Number four is protect yourself.
So here's the challenge is
as a non-technical person
trying to build a technical product,
there's just realities to this.
So one, you need to get insurance.
Errors and omission insurance,
make sure you have that.
There are bug bounty services
that you can pay to essentially hack your code,
define vulnerabilities.
But the big idea for protecting yourself
is forcing your team to document the architecture,
to outline how the code works.
Most non-technical founders
don't even know to ask for this,
or to put all the logins into a shared login system
like a one password or a last pass.
But that to me is the fourth step,
which is if you can get documentation
around how the diagramming of the software works,
if you can get some errors and omission insurance
and you can get some bug bounty programmes set up,
that's an 80-20.
You will literally protect yourself from
just low hanging fruit vulnerability and attacks
that other people should find out
to help you protect the asset you invested.
Just like, again, if you owned a restaurant,
you would probably buy some insurance for that restaurant,
same thing.
You need to protect yourself from your technical team.
But those are the big four ideas.
So quick recap.
Number one, find talent in other countries.
Number two, manage that talent
by looking at the source code,
the CIDC pipeline,
the agile development process.
Verify that talent by hiring an advisor.
And four, protect yourself,
insurance,
bug bounties,
and architectural diagrams.
So as I mentioned at the beginning of this episode,
I wanna share with you an exclusive resource
called the "Idea to Exit Mini-Course"
It was a programme I created to help non-technical founders
come up with the right idea,
prototype that idea,
sell it to the market before you write a check to build it
and then use that presale
to go and hire a developer to build it.
You wanna click the link to get access to that.
That is my gift to you.
So click the link below to get access
to the Idea to Exit Mini-Course.
That's my gift for you.
And if you like this episode,
be sure to leave a comment and let me know
what is the number one takeaway?
What's the one thing you hadn't heard before?
Leave a comment below and let me know.
Subscribe to my channel
and be sure to smash the like button
so other people can find the video
because that's how the algorithms work.
And as per usual,
I wanna challenge you to live a bigger life
and a bigger business.
And I'll see you next Monday.
(upbeat music)