First to Market, but Too Early: Survival Tips
“It’s best to be first to market, but there’s such a thing as too early.”
In which case the first to market entrant has the option to tread water, as inexpensively as possible, allowing them to hold their position, while ideally positioning themselves to succeed for the market opportunity as it manifests, holding copycat competitors at bay.
Of course that’s not what most people do: they feel entitled to a large compensation rewards without having to do the work, which is probably why crypto investments have so much appeal among those who would rather spend four years seeking a “quick payout” than six months of actual work.
The tech industry itself is characterized by expensive people spending other people’s money on things that have little value or merit, which has created a culture of entitlement that ironically recoils from the hard work necessary to bring forth a true innovation.
As a result: this makes the “tech industry” ironically poor at bringing forth actual new innovations, and are more likely to hype re-branded and re-purposed older architectures under new labeling.
For our part we (214 Alpha) chose to “tread water inexpensively” by doing the following ten things:
(1) convert some paying customers into equity owners
What’s needed more than money in the early phases are fellow stewards with as much “skin in the game” as you, willing to go the extra mile.
For our part: those customers who most embody our values are invited to convert payments they’ve made for our products and services, towards a percentage ownership, as fellow stewards, while still receiving the products/services.
These “fellow-stewards” are then consulted in the evolution of our planning, taking care to incorporate their ideas from an authentic spirit of shared attribution.
(2) leverage these early customers-to-co-owners to evolve them into becoming true peers and stewards a number of referenceable customer case studies to support business development
In our case, that includes people like Ruth Glendinning of Future Story Lab, which has significantly enriched the high-context of our market vehicle.
Our eventual go to market will not emphasize our company; it will emphasize the success of our early “customers-to-co-owners,” with us, positioned at their six, ensuring their success.
(3) avoid including those who feel entitled to quick rewards and high compensation
This is why the tech business is so frequently associated with large budgets, by the way, as well as huge losses: a large number of “tech people,” inclusive to tech management, feel entitled to high compensation, which contributes to expensive tastes that are unnecessary, such as wasteful junkets to exotic locales, under the disingenuous claim that these adventures will result in “increased exposure,” whatever that means.
To that end:
(4) avoid traditional forms of marketing
Traditional marketing is expensive and has very little quantitative value, in particular in the tech space, and be advised that there’s such a thing as “successful marketing” in the tech space that results in spectacular and expensive failures.
Traditional tech marketing invents their own quantitative benchmarks, too few of which are actually tied to new business development or return on investment, and the culture itself is too eager to digest “industry media” to inform strategic planning, while being concurrently aware that “the industry” regularly publishes marketing trash of no substance or merit.
And further: if you’re bringing to marketing something new, there’s no such thing as “strategic research” or “analyst data,” because those are actually trailing indicators, not leading indicators.
An analyst brief on a “new market” is leveraging data from the past, and not from the future. Ergo: it’s a trailing indicator, and do you want to calibrate your execution to the footprints others have long ago left in the sand? No.
By bringing to market something authentically new, what you’re doing is different, and there’s a pretty good chance that none of those marketing people have any idea how to actually help, but (as professional liars) they are very good at convincing you otherwise.
To that end:
(5) avoid consultants with little to no applicable experience
There’s plenty of people who will come forward, seeking to coax and manipulate your promising young company out of money that should probably be invested elsewhere, and a lot of these people have zero applicable experience in the first place. Don’t hire them.
If you are bringing a wholly-new product to market, for example, only hire consultants with applicable experience with new product development, and in particular in the domain of “disruptive innovations.”
Here’s a hint: there’s only a few dozen of them on the planet, at most.
Don’t listen to someone “from marketing.” Nine times out of ten, they are lying. They know how to parrot the words, but don’t actually understand their meaning.
If you are face to face with an aspiring consultant that seeks to spend your money, and they claim they know about disruptive innovations, as them to detail their experiences. Betcha a dollar they are lying.
(6) minimize operational investments that are not (yet) necessary
There’s no reason to invest in operational infrastructure if you’ve not solved the more fundamental problem of how to generate revenue. At this early phase, only build what you need, and not a single bit more!
You don’t need to define a staffing and operations plan for a company that has a single unpaid employee with a title of CEO, and absolutely do not need to pay a consultant to define one until you have a meaty plan for getting new business in the door.
When you do cross that bridge, use a methodology that’s proven, low-cost, and can be accomplished in an afternoon.
It’s fine to plan for what you will do “when you cross that bridge,” for example: create a plan that says “define an HR solution when we have figured out how to pay the first three employees,” and then sit on that list until you’ve figured out how to get money in the door.
First things first.
(7) minimize development and maintenance expenses to limit ongoing costs
This is done several ways, for example: if the market’s not ready, then don’t build anything beyond what’s absolutely necessary, which minimizes engineering acquisition expense.
I’m going to repeat this, because if “nine times out of ten, marketing is lying,” then 9.5 times out of ten, engineering is lying as well.
As a rule, engineers want to build new stuff, and it doesn’t matter that the stuff they want to build is not unique, or even a “distinctive competency” (more on this in a moment). Engineers will lie, telling you that the existing solutions are not sufficient, and will lead you down an expensive path of redesigning a wheel that’s been adequately delivered a few hundred times before.
Here’s an example: at last count, there’s 118 chat apps that are available that support “private labeling,” which means you can add their chat app into yours, and present it as your own. This is the bread and butter of the technology world, and it’s how modern software is built.
9.5 times out of ten, your engineers will tell you that none of those 118 existing chat apps are sufficient, and will manipulate you into spending thousands of dollars creating the world’s 119th chat app, and will completely ignore that “chat apps” might not be core to your product’s offering.
This is what I was referring to when I spoke of a “distinctive competency,” which is very much related to your core value proposition. It’s possible that your app might need to periodically support chat, but if chat isn’t your core value prop, then absolutely don’t build another chat app.
And further, if chat is indeed your core value prop, then ask yourself: just precisely what is it that your chat does that makes it distinctive and unique among the existing 118 that are readily available, many of them being developed and maintained for years.
Long story short: engineers lie, and if they don’t get their way, they are prone to “sandbag,” which means they will tell you that the creation of something they don’t want to build will take six years, when it’s actually going to take two weeks. Get rid of those engineers immediately.
Additionally, about 80–90% of software’s total cost of ownership (TCO) is maintenance, and if you skimp on maintenance you’re shooting your long term prospects in the face, because the result is scalability, stability, and security bugs, all of which will hurt your company’s brand value.
This is another area where “engineers lie.” They want to build new stuff, but absolutely hate maintaining it, especially if it’s not something they built.
If you can find an engineer that likes finding and fixing bugs, hold onto that person, because they are as rare as they are valuable.
In our case, we’ve designed and built an architecture that enables the customers to effectively crowd-fund the maintenance of a shared code base, because it’s built as a platform (another significantly-important investment in minimizing capex and opex while ideally-positioning business development to receive ongoing subscription-based sources of revenue).
If your consultant has not done those things, absolutely do not hire them.
Additionally, our company (214 Alpha) have negotiated “local rates” to develop much of our technology for pennies on the US dollar, leveraging a stewardship relationship with some activists I’ve known for decades, most of whom are located outside the US.
Again, most people don’t think to curate and maintain long-term relationships with the development community, which is typically because they only sought “quick wins.”
Normally the kind of engineering work we’ve done would have cost hundreds of thousands of dollars, and yet we did the latest major software update for about $10,000, which was easily collected from a small number of eager “friends” that aspire to become fellow stewards.
Normally one such update of architecture would have required hundreds of thousands of dollars, but we’ve intentionally avoided the pitfalls of hiring people with expensive tastes, and have therefore been able to be nimble while remaining light-weight.
If you’re working with “someone that’s done software development,” ask them if they are still in regular contact with the people they’ve known the longest. It’s revealing if they are not.
(8) management: employ servant leadership vs the “normal model” of management that’s built upon a spirit of attribution theft
We employ an authentic spirit of servant leadership, which invites “fellow stewards” into investing their creativity into ensuring the project succeeds, and with a sustaining level of hard work, grit, and creativity that could never be bought.
The normal management approach features one or two people who claim the work of others as their own. Those people are a dime a dozen, and they should be avoided at all costs.
To that end:
(9) avoid most investors
With very few exceptions, investors want quick returns that only serve to damage trust you have earned the old fashioned way, and further: are prone to add “their guy” to the team, which seemingly always comes with an appetite for a high-expense standard of living that’s damaging to the culture of stewardship, while they extinguish esprit de corps by stealing the credit of other’s hard work (eg: attribution theft).
Additionally, most investors will avoid assisting in your efforts, until they are no longer necessary, and will then push to slap their name upon your hard work at the eleventh hour.
You may have told them of your effort and plan years ago, but there’s a good chance they have avoided assisting until you’ve figured out how to do it without their help.
To that end:
(10) seek a path of self-funding “the old fashioned way”
The “old fashioned way” is almost entirely non-existent in the domain of high tech; it’s a diversified revenue model that covers expenses using revenue from actual paying customers (eg: running in the black), utilizing just enough technology to get the job done, and not a single bit more (thus minimizing expenses).
There’s a lot of benefits to this approach, inclusive to the ability to tell investors “no” if it’s perceived they are not a cultural fit; itself an under-appreciated negotiating position.
Obviously the approach I recommend is not popular; I’d say that it’s indeed an UNPOPULAR approach, for the reasons implied.
Most people feel entitled to quick payouts for as little work as possible; these kinds of people are poison to your successful endeavor, and should be avoided at all costs.
Indeed, much of the “high tech industry” are those who profit from the churn of other people’s losses and failures.
