Fail to Scale — Part 4
You hired the wrong people
This is the 4th and final part of a series on why early-stage tech startups can fail their first few years trying to get into business, due to common and unfortunate circumstances created by their founders, that should, in this day and age, be easily avoided.
In the first, second, and third parts of this series, we explored why domain expertise, the most revered quality of a new startup founder, conspires against a CEO founder, leaving them no choice but to assume control at the top of their company, do all the Sales, and thus stifle innovation below them, all while creating a services company that cannot reach the scale that everyone was hoping for.
In this final part, we are exploring how a non-technical Founder CEO often teams up with an under-qualified technical founder, and then goes on to create an organization and a product that simply can’t and won’t scale in the future — right when they need their business to scale the most.
It all starts at the formation of the startup company…
Don’t’ most new tech startups start out like this picture, on the left?
A CEO + A CTO, and preconceived ideas about a future product?
Not all, but most small ones do.
Behind the scenes, it goes something like this:
- A non-technical business Founder with a brilliant idea seeks out, a technical Founder to partner with to build their tech.
- The CEO canvases their networks for anyone who knows someone technical, and someone is recommended.
- They get together and agree to create a new tech product company. Actually, the tech person, agrees to come on board, is more like how that actually works.
- At some point later (if they survive the first couple of years, and raise some money), they get enough capital to hire other people, and the company begins to grow in size.
Have you ever wondered why it happens like this so frequently? These two people specifically? A CEO + A CTO? A person with an idea for a new business, and a person who can write some code?
How many of you are working for a start-up where it started just like this, I wonder?
The story above is very common and totally understandable, of course. It makes a lot of sense to a lot of people — unfortunately! Especially, to the non-technical founders.
So, what are the problems with this all-too-common story?
Well, before we get into that, let’s look at why this happens so frequently for tech startups. Then, we can examine the problems that crop up because of it, and how things would be better done.
Why a CEO + CTO?
Well, we can safely say that there are “non-technical founders”, and there are “technical founders”. Both have different skill sets and different career paths. Both can be founders, maybe even equal shareholders, and both could be on their first startup journey, or on their next startup journey.
A non-technical founder is generally a founder who has never made anything with software before and comes from an industry outside of tech. Now, they want to get into making some tech. This is not a perfect fit for an accurate description, and there are, of course, exceptions, but I think this is about how it is defined by most people — in general.
Whereas a technical founder is a current or former programmer of some skill level, who once worked or still works in tech somewhere.
A short history of tech founders
So, decades ago (the 1980s-2000s), it was uncommon for non-technical founders to start new tech startup businesses. Making anything technical used to be a giant hurdle, requiring years of skill and practice, because back then, we didn’t have a lot of foundation technology and tools to do many things in the tech space, and those foundational things had to get built first. Sharing knowledge also wasn't that easy. There was no internet. You had to buy physical books and read them end to end to learn the juicy past lessons. Tech founders (think about all the famous ones you know today) had to create organizations to build all the most basic technologies, like: PCs, operating systems, networking, the internet, mobile devices, search engines, social media, the cloud, etc, etc. These are all now in place the platforms we build all tech products on. Only, now, making tech products is a lot easier today than it used to be, and thus, the bar to entry for being a tech founder in the tech world has dropped considerably more recently.
Now that we have many of the tech tools we could pretty much need today, we no longer need uber-geeks (eg. Gates, Jobs, Page & Brin etc) to lead the way in building out the rest of the tech that we are producing these days.
Consequently, we are now seeing non-technical founders enter the scene, from all other industries, without any experience in tech, other than having been past tech “users” themselves — which really isn't any kind of qualification for this job.
Besides this, with most of the richest companies in the world now being tech companies, the promise of great wealth attracts many more people to try their hand at making money from tech themselves. Thus, it seems, it is all within reach of anyone nowadays.
Tech as a commodity
And in this most recent period of time (say, the last ~15–20 years), things have gotten a little crazy in the tech startup world. Tech has somehow become just another “commodity” in non-tech people’s minds.
Can you blame them? There are so many people writing software out there today (I’m not saying they are doing a good job of it), but right now there is no shortage of people programming (and selling their services as programmers), when compared to a few decades ago. That is because the tools and platforms have necessarily evolved to be so much better than they were even ten years ago. And that is because so many more people are spending their money on buying those tools to make their own money in tech.
Thus, non-technical founders now feel that they are able to contribute their skills in this game of making tech. And the side-effect of that is obviously that they feel like the fundamental part of making software that works for their business is not the main thing to worry about anymore.
“Anyone can do it!”
They actually think that it is now a commodity service — in their minds — it’s just cheap labor for hire. You can hire it, you can outsource it, who cares? (they still think).
Thus, since the hard work of making tech is now thought to be a commodity service, they now think that knowing “what to build” is the highest value skill and the most exciting part of a new tech business — and those non-tech founders feel like they can excel past the techies at doing that kind of thing — they know it all.
Non-technical people’s blindspots
However, there is a massive nuance that is being missed with this assumed generalization, being made by these non-technical people.
While I agree that focusing on “what to build” is far more important today than focusing on “how to build it”, I do NOT agree that those doing the building of it, should NOT be the ones deciding what to build, how, and when.
These truths are why those people need to be the ones to do this:
- Knowing “how to build” durable, long-lived, and high-quality products is still not something that just any programmer can do, no sir! Definitely not. It probably won’t be that way for decades. You need highly experienced, highly skilled, experienced, and motivated people to do this. Otherwise, technical debt will rule your future world. And you should be very scared of that outcome destroying your struggling new business.
- Knowing what to try to build first, what is possible to build, how economical that is going to be to build, how far we can get with it built like that, and what it should look and work like. These are again still all exclusively things that only a cohesive/functional tech team can actually know, and pull off. These things can’t be dismissed or second-guessed by non-tech people. Ignoring them is deadly for your struggling new business.
Those building our products (our “makers”), should definitely still be the ones deciding what to build and how and when to build it — informed by the market opportunities, their actual user’s behavior, and actual usage data.
Why is that true?
You simply don’t get any helpful labor efficiencies by dividing those three activities from each other and over-specializing in them.
That’s why all software “product work” is always cross-functional teamwork, unlike software “project work” (and any mass-production work), which is generally not teamwork at all. Attempts to split this work up and over-specialize it always result in expensive, suboptimal outcomes of one form or another. Non-technical founders are not used to this kind of collaborative work, despite all evidence and testimony to the contrary.
Furthermore, only those making the actual technology know how to adapt and use the technology way better than anyone else around them. As Marty Cagan correctly points out, these people (your designers/engineers) are where real tech innovation comes from.
So what should you be doing instead?
You should be giving your Product Managers, Designers, and Engineers customer problems to resolve, and they will innovate solutions, that no customer or executive, or board member could have guessed was even possible with technology today.
But here is the catch. You only get the benefits of this, if those “makers” have the autonomy and the drive to actually do that kind of work.
Otherwise, you just have code monkeys. Which, yes, are a commodity these days (and so is A.I, by the way).
So, while the truth is written above, in reality, the top item on a non-technical founder’s shopping list, when they want to start their new business is always going to be:
TODO:
🔲 #1 Hire a tech person (any developer).
🔲 #2 Figure out what to tell them what to do (my job).
What is worse than this, is that the type of tech people they tend to find to work with, are inexperienced, and are trained to do just that — What they are told to do!
Mirroring The Enterprise
Now, in the startup world, you can see that the first techie person who joins a new non-technical founder’s venture will take some title to reflect the fact that they are the only techie around. Something like “Head of Tech”, “Chief of Tech” or “Lead Tech”, etc, would be appropriate.
Already from day one, the non-tech CEO is unjustifiably dividing their company down lines of knowledge specialization. Just like command and control corporates do.
Business on one side, Tech on the other.
You have the “business brains” on one side of that line. They have all the ideas and the supreme knowledge about what to do, righteously from a strict business lens. On the other side of that line, you have the folks who know how to build it — all the techie people.
This sucks and is totally wrong on so many levels, the least of which is the arrogance of knowledge hierarchy that it implies — don’t get me started!
It has never been this way in any successful tech product company that you have heard of. But, on the flipside, it is how it is commonly always been in all non-tech enterprises — like forever!
Likely, places the very same places where the CEO (or their exec advisors) came from.
In tech product companies, the entire company is all about tech, tech is not a freaking department of the company!
A side-word about Startup Titles
In the startup world, company titles like: CEO , CTO, CMO, CFO etc. serve only one purpose, when comparing them to the purposes served in scaleups or stable businesses.
In startups, those titles are not there to establish a competence hierarchy within the company, since, in the early stages of a startup, you only have a handful of people, who are doing everything together. You’d be lucky if anyone in some startups had any experience at all! Obviously, this varies depending on who starts it up, of course.
So, if you think that at an early stage, those titles make those people highly competent at what they are doing, you are seriously wrong about that.
Think about it for just a minute. How can you have a 22-year university graduate chief of anything? Don’t get me wrong, good on those graduates for taking on a massive challenge like starting your own business. I’m all for supporting them in doing that. Someone has to do it. But seriously, believing that they know what they are doing (with high levels of competency) just from their title — forget about it!
Compare their resumes to an equivalent title of a person in a tech scaleup or in an established product company. Same words, very different implications. There is no way they translate.
Those titles are simply there, in a startup, to declare externally to 3rd parties (investors, partners, etc) that there are people in this company who are taking their commitments seriously enough to say that they have those aspects covered by someone and that those aspects aren’t being neglected. They have the bases covered. Badly, but at least they are thinking about them and acting like adults.
That is it! It is really a bid at some minimal level of credibility, which is important to investors and partners from outside the company, who want to know that those people are committed to making the business a success, for the long haul.
Internally, the skillsets, experience, and maturity of those people with those titles should NOT matter too much, until the company starts to get larger, beyond about ~10–20 people.
So, it should be no surprise to anyone, and there should be no mystery to anyone, that the founding chief “techie person” grabs the majestic title of CTO of the company. No matter what their actual competence level is.
Just like the CEO is the assumed chief “business person” of the company. (Putting aside my disgust of that particular division of labor for a moment).
So, these reasons are why a CEO + CTO are often the first two people in any tech startup. To (incorrectly) model and send the message that their company is:
business + tech
Now let’s investigate what goes wrong with this kind of partnership driven by this kind of legacy mindset: The Business + Tech mindset.
Problems with Business + Tech foundations
In most tech startups, especially where the CEO is young, where capital is low, or where the non-tech founder is unable to identify and qualify experienced technical people, we are likely to end up with a CTO who is inexperienced at product development processes, building teams, or shaping and growing technology organizations.
All the things that need to be growing very early on in the development of a tech product company, ESPECIALLY if capital is scarce!
More than likely (and generously giving them the benefit of the doubt) that CTO is, no doubt, going to be a competent programmer and problem-solver at some skill level. But just as likely as that, they won’t be skilled in much else beyond just programming.
It is also quite likely that the CTO has no experience in building long-lived products either if they've come from a services provider or project background as well.
You can see more about why these details really do matter, for a founding tech leader of a startup, in Developer versus Engineer where I went much deeper on the differences, and consequences of this.
The primary problem with an inexperienced CTO in a startup is going to be thinking that their job (and their entire contribution to the startup business) is going to be; the one who spends their time dedicated to coding up “their baby” — and doing it like a heroic warrior.
The “business” idea may have been the CEO’s “thought child” but by god, what the CTO will be making (the actual product that is sold) will certainly be the CTO’s “baby”
OK then, so it is not much of a stretch to see how immediately the CEO gets busy Marketing and Selling their idea, and CTO gets busy making their technology and delivering its features.
Nothing really wrong with that, if it’s only the CEO and CTO in the company at this stage. Those two things are definitely needed in a startup at a very early stage like this. And someone has to do that work.
At this point, who really cares who does what and when? as long as it all gets done? The real problems begin when the company starts hiring more employees.
Growing the Tech Team
By assuming that the business department and tech department are separate divisions in the early stages of their new startup, and by already establishing a boss over each division (CEO, CTO), when it comes time to add more capability (more people), to do more things, the CEO is naturally going to assume that where the company needs to go faster is in the tech delivery of the product.
Thus, they will simply conclude, that to make things go faster, the company should hire more tech people to speed up the work of the CTO.
The CEO is not going to be thinking that they will need help figuring out what to build and sell. They will assume that they have that aspect covered — in spades!
This is the first grand mistake.
The next grand mistake is how the CTO will react to this.
If you asked the CTO in this company: “who does the company need to hire next?”, and IF they are already maxed out just getting some cobbled together software up and running, just to do something useful for investor demos. Of course, they are going to ask for more hands to do the work of making more stuff faster with them.
Now, here is the major pitfall, that depends on the CTO’s personality and level of humility.
Lack of humility in an inexperienced CTO
The less humble (and thus less experienced) CTOs, in this position, are going to be a big long-term problem here for the startup.
They are going to resist hiring any more programmers, for fear of those new programmers messing up their beautiful creation, “their baby”, which is probably already in a mess to begin with — due to their inexperience at building durable and scalable products.
Furthermore, if they are not good communicators or great teachers of their skills (which is quite unlikely)— then they will resist hiring less experienced engineers than them (who are cheaper to hire). Because they know that this means they will have to spend more of their time helping those new people do their jobs, and less time coding themselves.
BTW: You need to know that “Inexperienced” is the most common status of the vast majority of people writing software today, despite having grandiose titles like CTO.
Furthermore, a CTO like this is certainly going to resist hiring more experienced (and more expensive) engineers than them, since they are holding this grand title of CTO (the “uber-geek”), and they don’t want to hire a new employee who could be showing them up or challenging them on how they are raising their baby — and getting paid more than the CTO to do it!
It is all very complicated. But, nonetheless, the title of CTO is usually bad news all around for the future of a startup company like this.
This is exactly why a startup can’t afford to hire an inexperienced tech leader as a founder, then call them the CTO, and have them decide who should be hired into their team, nor gatekeep what should be done in the product.
Nothing wrong with being inexperienced. But, everything is wrong with using title and positional power to govern who should be hired, and what skills should be introduced.
The humble inexperienced CTO
Now, let’s look at the humble, yet inexperienced CTO. How is that likely to be a problem?
Well, they are going to agree that, YES!, They do indeed need more help, and YES, we should hire more developers next!
Cool. Well, since they are inexperienced, they are likely to hire more “devs” who look just like them. Having the same skillsets as them, and who are a good cultural fit for them. Why? Because coding is their superpower and their primary domain in the startup business, and it's what they know best (probably exclusively), and, thus, all that they can conscientiously sign up to manage and control — on behalf of the company!
It will be more devs, in a group of only devs, led by the CTO dev.
They won’t, for example, feel very comfortable managing and leading Product Managers, Designers, and User Researchers, will they?
What is the outcome of a group of only “devs”?
What Kind of organization have we got now?
Well, let’s extrapolate this forward a few months or years. With the CEO now assuming that they govern what needs to get built, and the CTO with their head down, coding up a storm with more devs under their control.
We now will have an organization that is going to look like and operate like this. Where the Sales department orders the Tech department on what to build and when:
What is wrong with that?
I get it. Some of you are used to this kind of organization structure. Why does this organizational structure feel so natural to most technical and non-technical founders?
Stakeholder delivery
It is because they likely have a services provider background, or they don’t know what good product development companies look like on the inside.
This picture describes how they are used to working within their previous services businesses— only now, their “client” is the CEO at the top of this company that pays their salaries.
But, in a tech product startup, we are not building a product for a CEO stakeholder’s approval!
The CEO is not contracting their own company to build their own pet project, goddammit! We (everyone in the company) are all building a product for an external market! So this model, and the implication of the structure itself, is so, so wrong at so many levels!
The only companies where you actually see this model used internally, are where the Tech department is actually a cost-center (and a separate business unit) to the “real business” of the business. Like in every enterprise, bank, traditional non-tech business that there ever was.
Where most of the startup founders are coming from in their previous careers.
In these non-product companies, the tech people are neatly sheltered in some I.T. department, and their workload is dictated and controlled by other people in the “real business” of the business.
It’s a result of an addiction of business people (higher up in the company) believing that their business domain expertise and their position in the company entitles them to tell less capable people (below them) what to do. Something you can do when you have a predictable business model, but not great when you don’t.
Now, let’s try to erase that ugly image from our minds.
This is not an organizational model that ANY tech startup should be basing its “flow of work” on. No sir!
We know way better than that, like, since 1975 and the all too familiar tarpit of software project work (from the Mythical Man Month).
Tech product companies are in the business of developing new products and services for an external market (a.k.a Product Development). They are not at the service of a parent business. They ARE the farkin business! The whole farkin business!
Correcting the Mental Model
Now, there isn’t anything inherently wrong with the picture on the left in the early days of the company. You do have to start somewhere, and frankly, more than one person is better than “the only person” and when you are less than about five people, everyone has to do everything in the business, whether you like it or not.
The troubles are not there, the troubles start with the domain-expert CEO, when they start to add more employees to their company.
When that happens, we all too often see a non-technical founder who does not understand how tech Research and Product Development actually works, and thinks that all they need (to deliver their new idea to market) is to “tell” some smart techie people what they think will work, and those people will magically deliver that vision perfectly to the market, the first time around!
This is an intoxicating fantasy, a tech startup founder’s dream. This dream is built on an utterly flawed foundation of inappropriate principles for a product development company.
If materializing anything physical is the game that the CEO thinks that they are now playing, then they are naturally going to think that they are going to need more and more techies to make the business go faster. Just like other examples in other physical product industries that they have seen or can relate to — such as the construction industry does, and ironically, just like tech services companies in fact do. When the work needs to go faster on a job, they will think that all you need to do is add more and more people into the mix to do more stuff — this is mass production thinking and linear scaling. It only works for predictable, rote work.
What they don’t know yet about the tech product development industry is that it does not work that way. (viz: the Mythical Man Month). This is product development, not product production. Something non-technical people (and some technical people) really struggle to come around to understanding. Product development work is nothing like mass-production of widgets, nothing like manufacturing, and nothing like how work scales up in tech services companies.
Unfortunately, what a CEO “domain expert” is expecting to work towards, (the mental model they have in their head), is what they may have seen work in their previous corporate companies:
- Techie people in a tech department,
- run by a senior techie CIO,
- doing the bidding of the “real business”
What your business really is
Let’s try to clarify this another way.
A startup founder CEO who is a domain expert in say Law, may really struggle to realize that their tech startup business is not a Law business (like the one they are a domain expert in).
And it is not a Law business that they are now building products inside.
In fact, their business is not Law at all. As CEO, they don’t even have to know Law to build the kind of business they are building now.
They are now building a tech company. Law is simply the domain of the buyers/end-users they might be building the tech for.
They need to get smart about running tech product development businesses, not running Law businesses.
Someone “techie” desperately needs to educate them on that, and fast before it is too late for them.
The trainwreck is Inbound
To be clear, the problem here manifests when the CEO decides to (or permits others to) spend the company’s resources on whatever happens to sell, without having strong technical or strong product leadership on board early in the journey.
Without that perspective and leadership, Sales has no alternative but to dictate the work that needs to be done in this kind of organization. (like it does for services businesses).
Thus, the company will become dangerously Sales-Driven, and a Sales-Driven mindset may lead to the slow formation of a services company down the road — generating more and more bespoke customization work, and associated support and account management costs, that hold back the product business from being able to scale to a mass market.
Death by Sales-Driven software development
Here is what Sales-driven looks like a few years into it.
Revenue and conversion rates are down and way lower than projected, they never were high in the first place. Nobody, in the business, can tell you what existing customers actually find valuable about their product as measured by actual usage of it. Nor can they tell you what is preventing new customers from signing up to it.
Up to now, the only evidence of how they have gotten this far is all opinions and circumstantial luck — anecdotes. Since, up to this point, no one has bothered measuring what actually works and what doesn’t actually work. There is no record beyond the Sales that have landed.
It has all been trial and error up to this point, getting lucky on some things, somewhere, somehow. But that luck rarely sustains itself.
Since there is not a defined “value proposition” of the product that has been empirically proven to work (backed with evidence, being refined by the product team), the Sales people won't know what sells to whom and why, and the market won’t yet understand the product yet either, because the Marketing will be cock-eyed as well.
Sales calls have necessarily become about uncovering any of the new needs every customer has, as those things will seem critically important to winning each and every Sale.
If any prospect has any kind of “buying objection” in the process, and it is considered an important enough blocker to the sale, then the Salespeople will ask what they need, and hypothesize themselves on why that objection is an obstacle to buying. They will then deduce some “logical solution” to that problem themselves — and usually, that will require some new and unique feature or capability that does not yet exist in the product.
They have no idea what that new feature/capability will cost in research and development, nor whether it will fit into the product, at all. (let alone the additional cost of support and maintenance of that feature for who knows how many customers will actually use it)
Nor will they ever have any evidence of whether that new thing will actually work to make this sale, or shore up future sales like this one. It is all just risky guesses, based on gut feels.
Long features lists are thus built and re-prioritized after every sales call by those leading the sales— with ample recency bias thrown in.
Eventually, usually the CEO (or a Project Manager is hired) and calls for daily/weekly/monthly status updates from those pesky techies to find out what is going on precisely, and when things are ready, and why things aren’t moving faster.
The techies, will now considered to be the new bottleneck of the business because they cannot go fast enough to keep up with all the sales that are going on.
The tech department is thus incentivized to, and driven hard to, do whatever it takes, in the best interests of making new Sales, which is then believed to make the actual sales, providing the confirmation biases for sales, and thus naturally (they just assumes) increase conversion rates of the product.
Of course, it does not work like that in practice, but times may have gotten desperate for the startup, money and time are running out, and flogging the “dead horse” seems like the only good option left.
The tech people in this chaotic sales-driven environment, once fully loaded up with work, are going to be doing lots of busy work, and rework, driven to ship more and more features, as fast as they can, whilst wasting their time in detailed planning and status meetings, serving only their managers appetite for creation of certainty. That will in turn create poor quality and production support costs skyrocket.
Quality and empathy for the end-users (from the tech team) will decline rapidly to extinction, and so will the speed at which these people can work effectively. As, they follow onerous planning processes to the n-th degree, just to cover their asses. In the process, applying shortcuts in development disciplines at every step of the way, just to get the next task on the backlog done.
Since this process has now devolved into “a delivery production line” and production lines should not stop, everything is going to get bottlenecked, stressed, over-utilized, and then start breaking - including the product experience itself.
Any snake oil that looks like a silver bullet to the CEO or head of Sales will now be believed to address all of these mounting side effects.
You name it: all-hands meetings, consultants, advisors, etc, etc.
But, any and all of these solutions will just cause more confusion and agitation, and thus, the existing delivery capability is going to struggle to improve at all. Things will be breaking everywhere, customers (buyers and users) will be getting pissed off, and capable, experienced, and intelligent tech people will be flipping tables and leaving this sinking ship.
Unfortunately, that leaves behind those who are now less equipped to cope with this kind of chaos effectively.
A non-technical CEO’s response to all this kind of complex mess will be to start to blame those people who they think are the new bottleneck of the company — the “delivery production line” people.
The [tech] “incompetents” that now remain in the company. That will naturally spurn the CEO to hire more bodies to throw in the mix, as an attempt to try and recover the loss of speed and revenue, that created the chaos in the first place.
I think we’ve all heard this story before. It is the “tar pit” again that Brooke’s warned you about.
Meanwhile, and crucially, while all that chaos and theatre is going on to satisfy the Sales team’s demands. No one is actually taking any responsibility for the product strategy. And for sure, no one is measuring the effectiveness of the built product in the actual marketplace of buyers.
A new Sale or two might be made, but the product is not getting any stronger for the mass market.
In this kind of meat-grinder-of-a-system, no one, no matter how incentivized, is going to be taking responsibility for generating any great buyer or end-user outcomes. They are only going to care about covering their asses (CYA), and doing what they are told from above. Everyone is in chaos.
Since no one has the space or time, willpower, nor positional power (except the CEO) to take care of those more important things. Those responsibilities will also languish. Causing the CEO even more frustration.
A non-technical CEO will simply not be equipped or skilled at resolving this kind of self-perpetuating spiral - and nor should they be doing that kind of remedial work.
It’s a vicious cycle, and the CEO is propelling it, right at its center.
Breaking the Vicious Cycle
So, what should the organization look like? And what should it be focused on doing instead of being Sales-driven?
Well, take a look at the illustration above.
The answer is to organize to focus on the “flow of work” that generates the actual business outcomes.
Separate the running of the startup business (executing the Business Strategy), from the product function of the business (executing the Product Strategy), and trust those who know how to execute that properly. i.e., a strong cross-functional product-focused team.
You won’t need command and control, because control is now distributed, and what needs to be done is already very clear to experienced product people. If you need control, then you don’t have trust in your people, and your startup is simply doomed for the get go.
Tech is important of course, but its part of the product, not the product itself.
Your product team/teams should be:
- Working together cross-functionally (engineers, designers, analysts, researchers, data-scientists, whomever etc), with any domain experts you may have (founders included), and
- They should be directly connected to their customers, producing products that customers have demonstrated that they find useful (using evidence directly from end-users).
- There is no separating what should be done, from doing it. This is the critical difference between product companies and services companies, which makes all the difference, and the only thing that makes product companies sustainable and scalable in the long run.
The product teams should be focused only on making small, incremental, and iterative improvements to the product, that actually move needles on the product-measured in Product Outcomes.
No big pushes or desperate and risky guesses should be assumed to just work because some important person said so (sorry, not sorry, to the CEO, Board, and execs!).
You don't want to produce soldier drones doing manual labor here. You want your smart people to figure out a market, and its behaviors by working in that market. Learning about how people in that market actually work and how things change over time.
They need autonomy and empowerment, not a chain of command, and to be issued orders by supposedly more intelligent, clairvoyant people who are somehow “in the know” reading their crystal balls.
What makes the grass grow green?
At the heart of tech research & product development, it is all about making changes to the product that generate changes in “customer’s usage behavior” that are measured as actual tangible “Product Outcomes”.
Those product outcomes fit a clear product strategy that describes the actual opportunities found in the actual market, that have been uncovered and backed up by real evidence in market.
What do I mean by change in customer behavior? Well, here is a simple example for you. A person who wants to know the weather today. They can look outside through a window, walk outside, or they can use your weather app to find out what they need to know while sitting on their toilet. That’s a change in their behavior! using the weather app, on the toilet.
Then, that person may wonder what the weather is in the town they are visiting today, and they then use the weather app to do that. That’s another change in their behavior.
You get it, right? That’s what we are talking about here. As simple as that.
Then, if they come back to use the weather app, tomorrow, this week, or this month, then they are making a longer-term behavioral change, maybe even building a habit. This is what you want to see happen with your new tech product, and you need to measure it happening. You need to see it happening and count on it happening to more and more people. Not just sit back and assume that it’s happening, just because you built a feature that intended to do that. Because your product probably isn’t good enough for that to be actually happening yet — according to actual measurements taken. And that’s what we want our product teams to be working on improving. Not to be just blindly adding new features that no one actually uses.
So you need to realize that it is only changes in customer usage behaviors (that also solve real customer pain) that ultimately and reliably create the “Business Outcomes”. Of the kind that investors, executives, employees, and founders care the most about. Like: increased acquisition, revenue, retention, etc.
Without which, frankly, there would be no tech business at all, and you could wrap it all up and move on with your life.
You must understand that the Product function of your business creates all the business, not the Sales function of the business!
In Summary
Well, being the last part of this series, we have covered a lot of ground already. Here is the skinny on it all.
Number 1: Don’t be that CEO domain expert who assumes that they know it all! You don’t. Anything you do know is probably working against you as a blind spot due to your own personal biases forged in companies, unlike the one you are building now. Your domain expertise is useful, but you are not selling that anymore. You are finding a product a market wants to buy and use to solve their problems.
This is not a business where you want to create a “smartest person in the room” culture because that will create the kind of command-and-control organization where the “brains” remain at the top of the company, telling people below them what to do. It’s simply not the job of a CEO in a product company to be that person. It is not modeled anywhere in this industry.
These things are the actual job of a startup CEO. Go and read it!
If you hold the title of CEO, and that kind of stuff is not what you want to be doing yourself, then I suggest you hire a new CEO to do that stuff and do whatever it is that you want to be doing in your tech startup. But leave the title behind. No one can take away the fact you founded the company, nor can they take away your shareholding. Park your ego.
If you ignore all this advice and continue to do the kinds of things we have described in this series, you will (after a year or two) grow an organization and culture that will leave you no choice but to have the CEO drive Sales from the top, and that will mandate that Sales will define what product market fit is. It is all interrelated with how creative people work and how they are treated in your company.
Three outcomes are possible for your product business.
- You get extremely lucky, you build a product in less than 6 months, and someone buys your business for squillions. You become an instant billionaire and retire to your yacht in Monaco, advising other startups on why you are such a god at building successful startups.
- You fall into the trap of creating a services company going after one customer at a time with tailored solutions, or
- You create an ineffective tech organization with stifled innovation that churns out ordinary low-quality features that the market won’t be buying for very long, and you will be burying the company years later, after a long and slow death.
That’s the way that goes, I’m afraid.
Innovation should be the #1 top, the non-negotiable superpower of your new tech company, that you need to acquire and grow more of. And that superpower comes from the people in your whole company, not just from the CEO.
Tech innovation is required to delight your market with actual progress that they can see or experience (in the world), demonstrated by your product, which should be squarely aimed at sustaining a change in their daily/monthly behaviors.
Then, at least, and only then, you’ll have a chance to grow your startup into a larger company that can scale your product in the future to more customers.
Thank you for reaching the end of this series on failing to scale startups.
You may have noticed from some of the images, that this series was based on a presentation deck I made, on the same topic, and I wanted to serialize it in a blog of several posts since the content is lengthy. Perhaps I should have done it across 8 or 10 of them to make them shorter, who knows?
It is quite a lot of content, but it has a bunch of really important points for founders to understand.
Not sure if I achieved that here, but that is what I was going for.
Please subscribe to my newsletter content to get more of my content, and Happy 2023!
