(5 minute read / 43 minutes front to back)
Short On Time And Already Convinced You Absolutely Need An Advisor?
Skip the “why” and read Part III – Finding Your First Advisor to learn how to recruit, retain and get the most out of your first technical advisor.
The crux of the issue stems from three concerns:
Put these three things together and it means someone has to help you who doesn’t make a living building your software – from the day you start to the day you exit.
Here’s a simple non-technical example:
This Founder Lost $80,000 and 9 Months – Don’t Let It Happen to You
A young founder named Billy approached me after a conference panel and told me that he liked what I had to say. He hadn’t built his prototype yet, but he wanted me to review it once it was ready.
“Ok, sure,” I said. At the time, I didn’t think much of it. After all, founders present prototypes to users, investors and advisors for review all the time, right?
9 months later, Billy hired me to review his product.
I listened in horror as he told me about the mobile app he had slowly built to make his vision real. Billy’s app allowed users to capture and share media with other users – but, not regularly like Spotify or Instagram – only once in awhile. And, the media his app was sharing was stuff that was readily found online, not pictures or videos captured on a phone.
I was troubled by something very fundamental. There was no out-of-app experience. New users had to download the app before knowing if they cared about what was being shared.
Why does this matter?
As a five time founder, I can tell you that customer acquisition is the most important aspect of any business. When I asked Billy if he was more likely to click on a link to view a random website or download a random app, his response was: “Uh oh…”
His out-of-app experience mattered more for attracting new users than his in-app experience. In fact, he didn’t need an in-app experience at all. The app would eventually be a nice-to-have for his power users… but the need for that was two, maybe three, years down the road.
He needed links to a website embedded in social media, highly visible and easy to navigate to.
The problem with people that build software (firms, developers, architects, CTOs and product managers) – is that they are trained to build software – not build businesses.
I designed a new prototype for Billy, one that didn’t rely on an app – and only cost him $2,000 to have built by a new team of developers I helped him find.
As an independent party who didn’t stand to make money building the solutions I recommended, I wasn’t biased towards a specific product direction or technology. My incentive and expertise was in helping Billy operate in the most efficient way possible. The firm he worked with had incentives and expertise in creating the app placed in front of them.
I simply showed him the best path, one entrepreneur to another.
To summarize, Billy lost 9 months and $80,000 because the people who designed his product were the same people who built it.
Readers familiar with the MVP methodology would say that Billy failed to test his assumptions early and often; and while this is true, there is more to the story.
Key Concept – The Underlying Problem Was
That Everyone On Billy’s Team Was
Financially Motivated To Prevent Him
From Understanding How To Spend Less Money
The simplest prototype that Billy was able to envision required a lot of time and money to test, and nobody in his circle of influence was in a position to show him simpler, faster, and cheaper paths.
If this can happen to Billy, imagine how it impacts your ability to manage the myriad of decisions that are made on a daily basis about the structure of your code – something you will never be able to touch, see, or feel.
Frightening? It should be.
Remember that software developers, CTOs, and development firms can’t remain objective all the time because they all earn a living building software.
Academically, the problem is known as the “Principal Agent Problem”, and this quote from wikipedia sums it up well:
“[The problem] occurs when one person or entity (the “agent”) is able to make decisions on behalf of, or that impact, another person or entity: the “principal”… where the two parties have different interests and asymmetric information (the agent having more information), such that the principal cannot directly ensure that the agent is always acting in their (the principal’s) best interest.”
Pause for a moment and really consider this.
It should be fairly obvious that you’ll never understand code at the same level as your development partners, and you never want to.
But, if you don’t understand code, how can you ensure that you aren’t overpaying for what you are getting, digging yourself into a hole with poorly implemented solutions, or wasting resources building unnecessary products?
Do you honestly expect your team to recommend not building software when doing so means they have to find another gig?
Key Concept – Even Well-Aligned, Equity-Based
Partners Have Severe Limitations
And, everyone you work with is limited by their own experiences and perspectives.
Even highly seasoned CTOs need help from time to time with the things they aren’t familiar with.
As severe as the Principal Agent Problem is, it’s only a part of a larger picture.
The other important problem is that the cost of technical mistakes compounds with each day that passes; unlike sales, digital marketing, operations or finance.
This is what makes software development so dangerous.
Key Concept – It’s Already Too Late To Put Out
The Fires By The Time You See The Smoke
Think of code like a ball of rubber bands.
Each band that is added to the ball increases the difficulty of accessing the center because every band must be unwound and then rewound again. This means mistakes made early on, at the core of the ball, are the most expensive to fix.
In terms of software, what non-technical leaders need to understand is that software developers need to access the core all the time. This means every line of code makes every line of code that came before more expensive to work with.
In turn, this means that you won’t be able to just hire a new team when things get bad like you can with most other things. You’ll either have to start over or spend years fixing the mistakes made before hiring your newest team.
I’m not exaggerating here, it often takes years to fix technical problems because of the intricacies involved.
It comes down to this – software development is too important and costly to learn how to manage as you go.
Think of it like Super Bowl ads, international war, and other high risk activities where you have to invest heavily up-front before having any idea if your effort will pay off – and then have to deal with high maintenance costs to proceed forward with whatever jumbled mess you end up with.
Readers that are familiar with the MVP methodology know that the approach helps to combat this problem; but it isn’t enough.
The only way to manage high-risk activities is to hire people who don’t stand to gain substantially from the recommendations they make in order to inspect and manage everyone else on the team.
Key Concept – The Only Way To Manage
Something You Can’t Inspect Is To Put Multiple
People In A Room To Question And Challenge
Each Other’s Recommendations
Someone who doesn’t stand to gain substantially from the recommendations they make has to help you inspect and manage your development partners, and this person needs to be incentivised to give you quality feedback.
Remember that there is a very good reason why the President of the United States has a Cabinet of Advisors.
Learning how to work with your advisors is the key to your success.
The #1 mistake founders make is waiting to go looking for a Technical Advisor until they have established traction, and the #2 mistake founders make is wasting time trying to motivate high profile people to work for free (cough “equity”).
Most founders assume that advisors:
And, while most these assumptions might hold true in general, they all are incorrect when it comes to Technical Advisors.
Part III – Finding Your First Advisor will begin to explain the differences between the many kinds of advisors that are available, and work with each best.
Never put all your faith in just one person… or firm.
It’s rarely a good idea to rely on a single person in any area of business but it just so happens that software development is the first endeavor that many entrepreneurs face which is expensive, complex, and difficult to repair.
You can’t manage everything yourself, you can’t expect anyone responsible for building your software to guide you, and you can’t wait to deal with everything down the road.
You have to establish checks and balances to build software quickly and cheaply.