Get the flexibility to change your business model in the initial period — right when you need it the most.
It’s hard to overstate the obvious – that when you first launch you’ll inevitable need to pivot, that is to say, a chang in strategy without a change in vision. In his book, The Little Black Book of Innovation, Scott D. Anthony delves into the work of great innovators, and succintly summarizes this concept in the following quote:
"Your first idea is almost always wrong. And you can't figure out precisely how it is wrong through analysis alone. You have to, actually do something."
But changing can be hard. Particularly when that means accepting our previous decisions were not entirely spot-on. We humans have a knack for being overconfident in our own predictions, and there’s plenty of evidence of this out there tu support this, summarized by some of the decision making biases that science has identified. For example, you have confirmation bias, or, our ability to cherry-pick the evidence that supports our beliefs, while discarding information that stands out against them. For instance, which type of feedback about our product, into which we have invested heavily, do you expect we would pay attention the most, positive or negative?
An another effect that’s significantly relevant to this point is what is called “The IKEA effect”: we tend to place a disproportionately high value on objects that we partially assembled ourselves (such as furniture from IKEA) regardless of the quality of the end product.
Dan Ariely nailed capturing this phenomenom with a clever experiment in which amateur origami builders ended up valuing their own creations at a similar price as those made by expert builders. What gives?
Third parties, however, gave these amateurs a reality check, and appraised their creations at around 1/6th of the value of the experts’ work, which seems about right. In entrepreneurship, these biases may end up working heavily against a startup’s founder, who must make decisions to adjust his or her value proposition, feature set and strategy in order to reach product-market fit (PMF).
Often, this means doing away with features that have already been completed.
But if, on average, we humans perceive that the more work we put into something, the more intrinsic value it has, regardless of how other people such as actual customers might think of it, how will we ever change what is needed to increase the odds of achieving PMF? This problem hops right off the pages from the book of another cognitive bias, the sunk-cost fallacy:
…a greater tendency to continue an endeavor once an investment in money, effort, or time has been made. This is the sunk cost fallacy, and such behavior may be described as “throwing good money after bad, while refusing to succumb to what may be described as “cutting one’s losses” (from its Wikipedia entry).
So when building a digital product on whose success you and many others are betting heavily on, you’d think founders would take valuable new feedback into consideration and adjust the sails, right? But according to behavioral economics, often times it is easier to write-off adverse feedback and dodge a healthy pivot due to the fact that, psychologically and emotionally, we can’t avoid developing too much of a strong connection with our own creations and past decisions.
It’s kind of the Monty Hall problem, all over again.
However, succumbing to these biases need not be our destiny. Can we humans breakout from these effects entirely? Most probably, not. Surely, some people may have the emotional ability to do it more succintly than others, but admitedly, we can’t escape our human condition altogether. So how about what about lowering the amount of time & work we put into building a product to reduce the emotional dependency and effects of these biases? Wouldn’t that help out everyone involved in adopting a different strategy in the light of new feedback? An interesting idea, indeed.
Enter the low-code app development movement
A 100 years ago, marked the beginning of a new technology era. Not for digital apps or the internet, of course, but in automotive technology.
Early in the century, most cars were still started with a hand-crank system. You’ve seen it in those old movies, with the handle in front of the vehicle which by rotating manually makes the pistons move enough for the engine to start.
Harold Lloyd on 1926 “For Heaven’s Sake” (Paramount)
This practice was not only cumbersome, but also dangerous as cars were getting bigger and engines could sometimes kick-back.
Cadillac’s campaign for its 1912 350 Model.
By 1912, the first Cadillac that featured an electric ignition system came out to the market. By 1920, Ford’s Model T had also followed suit. Eventually by the end of that decade, cranking up your engine was a thing of the past.
OK. We get the picture. So nobody starts their cars this way anymore. Now, what has that anything to do with launching a digital app in the 2020’s?
Low-code software development, sometimes lumped together with no-code development, is a relatively recent trend, but one that is here to stay. It’s been touted as the onset of the citizen developer wave, and in many ways represents an analogy of the no-crank automotive innovation of a century ago. It is an easier way to get to the same spot.
The Pushback
While in retrospect we might suppose that there was no resistance to adopt the new technology back then, you can be sure that people whose job it was to crank-start the car for women, elderly adults or others without the strenght or will to do it on their own, were not thrilled in seeing that part of their job disappear as new models rolled out of the factory. Would they keep their jobs?
Today, software developers whose position depends on systems being complex, project budgets multi-year, and massive tech teams the norm, may not necessarily be thrilled with the availability of an alternative means of going to market. While they may be the expert builders here, they are judge and jury when it comes to selecting a tech stack for a new venture – a strategic decision in most cases.
More than once, I’ve heard technologist rate low-code options in a way akin to showing up to an F1 race riding a Little Tikes Cozy Coupé. Somehow due to their knowledge, many lead devs see these options as below professional grade.
But from what angle is this coming from? I’ve seen startups fail in the long run due to starting out with a tech stack that was chosen for how well it fared at 10,000 concurrent sessions. But after launch the startup never made it to 100 users because they could not create or change the features their actual users requested quickly enough and surpass a huge churn rate. What good was that high-performance rating anyway?
When starting out you need to be able to change quickly. And to surmount our inherent human bias which opposes change, you need a flexible set of tools to get you to product-market fit. They may not be the fanciest. They may not be the latest. But they certainly allow even the most experienced software developer to align his or her abilities with the startup’s strategy and walk the talk of Lean Startup principles.
All things considered, the benefits of low-code are numerous and only continue to get better. In fact, Gartner estimates that by 2024, as much as 65% of all app development functions will be available from technology within this category. Through graphical user interfaces, drag-and-drop solutions and mostly tweaking configuration screens instead of hand-coding apps from scratch, low-code solutions offer a new realm of possibilities for all types of business goals out there.
Many CTOs or project managers in charge of selecting a tech stack, though, are not keen on betting on the chances of innovating themselves out of a job. And for this reason, low-code development is still an uncommon sighting in both the corporate and the startup world.
However, CTOs with a longer-term vision will definitely see the benefits of creating more value with less resources, and their organizations will reap the benefits of this decision.
Robust, dependable infrastructure will always be needed to offer surface-level development spaces to less-technical collaborators within an organization, so there will always be a need for saavy technologists. And as enterprise software market surpasses the US$500 billion-a-year mark, and grows hastily at a rate of almost 11%, this piece of the puzzle is more relevant than ever.
The bigger picture in innovation and entrepreneurship
Together with Design Thinking (explore the problem) and Lean (do the right thing), Agile (do the thing right) software development has taken us to a new and exiting place in history. This triad presents a robust philosophy for going about in launching new products out into the market with improved odds of success.
However, employing this philosophy does not curtail a great part of the risk associated with it when it presupposes that software development is inevitably complex, and that it’s for that reason that the Agile part is needed.
Back in my experience as portfolio manager for a global corporate venture team, I kept hearing very intelligent people saying very funny things. For instance, they might say: “we’ll be launching an MVP super quick. Like in 10 months.”
Meaning of “Agile” circa 2020.
There are plenty of reasons to believe these best intentions come from a truly sincere place. Specially the more senior executives who for decades have seen the not-so-funny rerun of enterprise software projects going over budget and performing below expectations. For them, there seems to be some kind of emotional damage alerting them whenever they encounter new IT development projects.
Same goes for non-technical founders whose vision to launch their digital product lies seemingly out of reach due to the fact that they can’t afford a massive tech development team in order to go to market. The idea of developing an MVP within weeks would sound like a pipedream that, surely, in their view, must result in poor quality.
Low-code is not the silver-bullet, but it does come from a place where quality assurance is exponentially more robust than newly minted code. Since thousands, if not millions of user-developers across organizations are QA’ing a the same features, there is less wiggle room for bugs to make their way into production.
To be fair, there are various levels of MVP we could talk about, such as mock-ups, but what I’m talking about here is a working digital product. One that has, admitedly, a limited feature set, but that still somehow allows you to test your hypotheses early-on with real-world customers. And it’s not just a simple landing page, but fully funtional application with inputs and outputs, data processing and visualizations. All of this designed and developed with a progressively blurred line between hand-coding and creating digital products intuitively.
Now, rocket science, sophisticated biotech or complex AI most definitely work outside the context I am describing. But through my experience in VC, a majority of the early-stage startups walking through the door came along with digital tools, within the realm of low-code development possibilities.
Marketplaces, project management, team communication tools and other relevant innovations are within the reach of low-code solutions. Though simple, apps like these are so useful that they are light years from paper or even e-mail based management practices, which are still prevalent in many contexts. Many of today’s unicorns started out with MVPs as simple as the ones we’re describing here. And in this day and age, we’re really standing in the shoulders of giants when it comes to the thoroughly tested building blocks of leading low-code solutions, as opposed to newly written pieces of code you’ll be QA’ing for the first time with a more manual, start-from-scratch approach.
Goals when considering low-code software development for your startup or enterprise application
One powerful quote directly from Agile’s 12 principles embraces low-code solutions:
Simplicity–the art of maximizing the amount of work not done–is essential.
It’s useful to have this in mind when considering a tech stack for launching your venture. An in our view, the maxim represents a a type of efficiency and sustainability, values that are core to successful entrepreneurial practices.
Another core value that helps us decide which way to go is extensibility. One may argue that any low-code architecture out there will run into potential limits in terms of advanced functionality. However, a competent tech stacks will use industry-standard features such as APIs to connect relevant endpoints to external services that might boost the sophistication of an app. This may mean you could exporting data from a simple marketplace, community management or dating app with potent machine learning servers to perform much more complicated data analytics and predictive modeling. But on Day 1, you want to make sure you can quickly launch and app that manages the basic features you require to bring people onboard with a basic value prop that you can eventually grow as needed.
It’s also good to consider your product and tech stacks portability. Unlike other low-code solutions, our view is that a startup’s code should not be land-locked into any type of arrangement, either legally, financially or technically to any supplier and applies for issues regarding software licencing, IP ownership, choice of hosting, user quotas (either developers or customers), among others. Some suppliers out there like are making an amazing job in popularizing low-code web development solutions. However, if as app owner you want to transfer your website and run it in your own server, that’s simply not possible.
Final thoughts
The current environment for developing with low-code is amazing, considering the capacity and variety of available solutions out there. One of the greatest advantages this movement brings about is the flexibility to pivot a product’s feature set with amazing speed. This ability is key for startups to increase the odds of making it to product-market fit, as well as for corporate applications to improve their chances of success.
As increased functionality becomes the norm and the advantages of this technology becomes evident, a new wave of digital products and services will become more prevalent. And as the line between developer and entrepreneur becomes more blurred, even more people will be in a position tho achieve their business goals.
