Coleman McCormick

Archive of posts with tag 'Low-code'

The Low-Code IKEA Effect

March 22, 2021 • #

I linked a few days ago to Packy McCormick’s piece Excel Never Dies, which went deep on Microsoft Excel, the springboard for a thousand internet businesses over the last 30 years. “Low-code” techniques in software have become ubiquitous at this point, and Excel was the proto-low-code environment — one of the first that stepped toward empowering regular people to create their own software. In the mid-80s, if you wanted to make your own software tools, you were in C, BASIC, or Pascal. Excel and its siblings (Lotus 1-2-3, VisiCalc) gave users a visual workspace, an abstraction layer lending power without the need to learn languages.

Today in the low-code ecosystem you have hundreds of products for all sorts of use cases leaning on similar building principles — Bubble and Webflow for websites, Make.com and Zapier for integrations, Notion and Coda for team collaboration, even Figma for designs. The strategy goes hand-in-hand with product-led growth: start with simple use cases, be inviting to new users, and gradually empower them to build their own products.

Low-code IKEA effect

Excel has benefited from this model since the 80s: give people some building blocks, a canvas, and some guardrails and let them go build. Start out with simple formulas, create multiple sheets, cross-link data, and eventually learn enough to build your own complete custom programs.

What is it about low-code that makes such effective software businesses? Sure, there’s the flexibility it affords to unforeseen use cases, and the adaptability to apply a tool to a thousand different jobs. But there’s psychology at play here that makes it particularly compelling for many types of software.

There’s a cognitive phenomenon called the “IKEA effect”, which says:

Consumers are likely to place a disproportionately high value on products they partially created

IKEA is famous for its modular furniture, which customers take home and partially assemble themselves. In a 2011 paper, Michael Norton, Daniel Mochon, and Dan Ariely identified this effect, studying how consumers valued products that they personally took part in creating, from IKEA furniture, to origami figures, to LEGO sets. Other studies of effort justification go way back to the 1950s, so it’s a principle that’s been understood, even if only implicitly, by product creators for decades.

Low-code tools harness this effect, too. Customers are very willing to participate in the creation process if they get something in return. In the case of IKEA it’s more portable, affordable furniture products. In low-code software it’s a solution tailored to their personal, specific business need. Paradoxically, the additional effort a customer puts into a product through self-service, assembly, or customization generates a greater perception of value than consumer being handed an assembled, completed product.

SaaS companies should embrace this idea. Letting the customer take over for the “last mile” creates wins all around for everyone. Mutual benefits accrue to both creator and consumer:

  • Customers have a sense of ownership when they play a role in building their own solution.
  • The result can be personalized. In business environments, companies want to differentiate themselves from competitors. They don’t want commodities that any other player can simply buy and install. Certainly not for their unique business practices.
  • Production costs are reduced. The product creator builds the toolbox (or parts list, instructions, and tool kit) and lets the consumer take it from there. Don’t have to spend time understanding the nuances of hundreds of different use cases. You provide building blocks and let recombination generate thousands of unique solutions.
  • Increased retention! Studies showed that consumers consistently rated products they helped assemble higher in value than already-assembled ones. This valuation bias manifests in retention dynamics for your product: if customers are committed enough and build their own solution, they’ll more likely imbue it with greater value.

The challenge for product creators is to strike a balance — a “just-right” level of customer participation. Too much abstraction in your product, requiring too much building of primitives, and the customer is confused and unlikely to have the patience to work through it. Likewise, when you buy an IKEA table, you don’t want to be sanding, painting, or drilling, but snapping, locking, and bolting are fine. Success is a key criteria to get the positive upside. From the Wikipedia page:

To be sure, “labor leads to love only when labor results in successful completion of tasks; when participants built and then destroyed their creations, or failed to complete them, the IKEA effect dissipated.” The researchers also concluded “that labor increases valuation for both ‘do-it-yourselfers’ and novices.”

Participation in the process creates a feedback loop: the tool adapts to the unique circumstances of the consumer, functions as a built-in reward, and the consumer learns more about their workflow in the process.

Low-code as a software strategy allows for a personalization on-ramp. Its IKEA effect gives customers the power to participate in building their own solution, tailoring it to their specific tastes along the way.

Weekend Reading: American-Dream-as-a-Service, Content Marketing, the Fifth Column Reading List, and More

March 20, 2021 • #

👨‍🎓 The American-Dream-as-a-Service

Antonio Garcia-Martinez interviews Austen Allred, founder of Lambda School. Lambda charges no tuition and builds its program on the ISA (income sharing agreement), in which you only pay when you get a salaried position in your field of study.

The cool thing about the incentive alignment is that we’re not going to train you to be a sociologist, because it just doesn’t work. A common critique of the ISA model is: oh, now people aren’t going to study poetry anymore. And my response to that is: yeah, we’re not a university, we’re a trade school. The university has 18 million things that it does for you, and we cut cut off a tiny sliver of that, which is: we’re going to help you get a better job, we’re going to help you improve your state in life. That’s all we do.

There are actually more high-paying jobs available than there are people to fill those roles. And that’s true all over the place. I think about it as an optimization problem. You’ve got all this latent human potential, and it’s just kind of bouncing around. Sometimes it goes to school, and it picks stuff at random to study, and you know what you know because of who you’re surrounded by.

📝 Content-Driven Growth

Lenny Rachitsky gets into different types of content marketing by startup, plotted on two dimensions: user-generated to editorial, and vitality-driven to SEO-driven. Useful structure here for thinking about where you want to be and what types of content and tactics fit.

🌍 Earth at a Cute Angle

Some great examples of oblique satellite imagery. Love the shots of the Tour’s mountain passes — Col du Galibier and Tourmalet.

📖 Fifth Column Podcast Reading List

Someone in the Fifth Column podcast community put together an archive of all the books mentioned on the show over the years. This’ll greatly extend the reading list, nice mix of classics and modern stuff.

💻 Microsoft Power Fx

Microsoft has open-sourced its simplistic formula language based on Excel.

A Nomenclature for Low-Code Users

July 7, 2020 • #

The low-code “market” isn’t really a market. Rather, I see it as an attribute of a software product, an implementation factor in how a product works. A product providing low-code capability says nothing about its intended value — it could be a product for sending emails, building automation rules, connecting APIs, or designing mobile forms.

What are termed “LCAP” (low-code application platform) software are often better described as “tools to build your own apps, without having to write all the code yourself.”

This post isn’t really about low-code as a marketplace descriptor, but about refining the nomenclature for how we talk about users we have in mind when designing low-code tools. Who are we building them for? Who needs them the most?

As Aron Korenblit wrote a few months back, low-code as a term isn’t really about code, per se, but often things like process modeling, workflows, data flows, data cleanliness, speed of prototyping, and low cost trial and error:

If what we’re trying communicate is that no-code helps get things done faster, we should elevate that fact in how we name ourselves instead of objecting to code itself.

For many years, all sorts of tools from Mailchimp or Webflow to Fulcrum or Airtable provide layers of capabilities for a continuum of user types, moving from the non-technical through to full developers. The non-tech space wants templates and WYSIWIG tools, the devs want an API, JavaScript customization, and full HTML/CSS editing suites. I think a two-type dichotomy isn’t descriptive enough, though. We need a third “semi-technical” user in the middle.

The spectrum of users could look something like this — we analogize these to an Microsoft Excel user equivalent (parenthesized):

Users of low-code software
  • Novice — anything that looks like code is totally opaque to novices. They’re scared off by it and afraid to change anything for fear of breaking something (Can enter data in Excel, and maybe do some sorting, filtering, or data manipulation)
  • Tinkerer — can parse through code examples and pre-existing scripts to roughly understand, uses trial and error and small adjustments to modify or piece together snippets for their own use case; often also can work with data and data tools like database applications and SQL (Can use formulas, pivot tables, lookups, and more with Excel, comfortable slicing and dicing data)
  • Developer — fluent in programming languages; excited about the prospect of writing their own code from scratch, just wants to be pointed to the API docs (Can write VBScripts and macros in Excel, but mostly wants to escape its confines to build their own software)

Of course empowering the Novices is one of the primary goals with low-code approaches, as they’re the least prepared to put together their own solutions. They need turn-key software.

And we can help Developers with low-code, too. If we can bootstrap common patterns and functionality through pre-existing building blocks, they can avoid repetitive work. Much of tool-building involves rebuilding 50-75% of the same parts you built for the last job, so low-code approaches can speed these folks up.

But the largest gap is that middle bunch of Tinkerers. Not only do they stand to gain the most from low-code tools. From my observations, that group is also the fastest-growing category. Every day as more tech-native people enter the workforce, or are compelled to dive into technical tools, people are graduating from Novice to Tinkerer status, realizing that many modern tools are resilient to experimentation and forgiving of user error. The tight feedback loops you can get from low-code affordances provide a cushion to try things, to tweak, modify, and customize gradually until you zero in on something useful. In many cases what a user decides is a “complete” solution is variable — there’s latitude to work with and not an extremely rigid set of hard requirements to be met. By providing building blocks, examples, and snippets, Tinkerers can home in on a solution that works for them.

Those same low-code tactics in user experience also give Novices and Tinkerers the prototyping scaffolds to build partial that can be further refined by a Developer. Sometimes the prototyping stage is plenty to get the job done, but even for more complex endeavors can greatly reduce cost.

Weekend Reading: Honeycode, Imagery for Utilities, and BigQuery in Google Sheets

July 4, 2020 • #

🍯 Amazon Honeycode

AWS is making its entrance into the low-code app platform space.

🌲 Using satellite imagery to prioritize vegetation management for utilities

Geoff Zeiss on combining satellite imagery and spatial analysis to identify tree encroachment in utilities:

Transmission line inspections are essential in ensuring grid reliability and resilience. They are generally performed by manned helicopters often together with a ground crew. There are serious safety issues when inspections are conducted by helicopter. Data may be collected with cameras and analyzed to detect a variety of conditions including corrosion, evidence of flash over, cracks in cross arms, and right-of-way issues such as vegetation encroachment. in North America annual inspections are mandated by NERC and are not optional. With over 200,000 miles of high-voltage transmission lines and 5.5 million miles of distribution lines in the United States, improving the efficiency and reducing the risk of inspections would have a major impact on the reliability of the power grid.

🔌 Connected Sheets

Google Sheets now supports using BigQuery data inside of Google Sheets features like pivot tables and formulas, which means orders-of-magnitude increase in data limits.