Convenience Is the Product

Look in your pantry.

A surprising amount of what we buy is something we could have made ourselves.

Cocktail sauce is a good example. The basic idea is remarkably simple: tomato-based sauce, horseradish, vinegar, seasoning. (Heinz) Worcestershire sauce is a much more elaborate fermented condiment, but even it is ultimately a collection of ingredients and processes that could theoretically be reproduced at home.

Brownie mix makes the point even more clearly. A typical boxed mix is largely sugar, flour, cocoa, and a handful of other ingredients. Betty Crocker’s current mixes make the composition almost comically obvious on the label. (Betty Crocker)

Yet we buy these things and we fill our pantries with them.

The interesting part is that we are not really buying the ingredients. We are buying the time someone else spent assembling, measuring, packaging, testing, preserving, distributing, and explaining them.

That is convenience. And convenience is a much more fundamental concept in business than we usually give it credit for.

A business exists, in most cases, because there is something someone needs to do that they would rather not spend their own time doing. Even if you are buying a skill you don’t have, you are actually buying the time to have to learn that skill yourself.

Sometimes the thing takes skill. Sometimes it takes equipment. Sometimes it takes capital. Sometimes it takes experience. Sometimes it is simply annoying. And sometimes it takes five minutes away from what you would rather do. So you pay.

It doesn’t matter if it is software, AI, consulting, manufacturing, or physical labor. The implementation changes, but the underlying transaction is consistent.

This may sound like a shameless plug but it is truly the basis for why I published this in a kids book called Erec Makes a Fire almost 10 years ago. The story is intentionally simple because the underlying idea is simple and it is better to ingrain it in a child than repeat it to all the adults. Erec needs to accomplish something, but accomplishing it requires time and effort. The people around him each have different capabilities, and things they spend time doing.

Someone has a problem they could solve it themselves. You make it take less time and they pay you.

This is one of the reasons I think we sometimes misunderstand innovation.

We tend to imagine a business as creating something that did not exist before. That is certainly one kind of business. In reality 99.9% of the time, it’s a derivative. And for good reason – but not this post’s point.

A business takes something that already exists and make it easier, faster, cheaper, closer, reliable and/or understandable.

More convenient.

The product may look like software, a bottle of sauce, a box of brownie mix, or a person showing up at your house with a toolbox. Underneath, the value proposition is the same.

I will spend my time on this so you can spend yours on something else.

And that is actually a beautiful feature of an economy. We do not each have to become good at everything. We don’t need to astound the world with something never seen before. We don’t need to “innovate” beyond what customers have or need.

We are all simply and constantly buying back pieces of our own time. And that has scaled in layers for thousands of years.

The strange thing is that we often forget this when we talk about technology. We ask what AI can create, what software can automate, or what a new company has invented.

A more useful question is often much simpler:

What does this allow someone to stop spending their time doing?

That is where most of the value lives. The product is not always the thing in the box. Sometimes the product is the five minutes you just got back.

When Determinism Is Better Than AI

AI’s superpower is creating deterministic products.

We have become fascinated with AI’s “human-like” level of non-determinism. “I’ll just let AI handle it” is quickly becoming a default answer to problems we haven’t fully thought through, because if AI will figure it out, why should I?

One can ask a chatbot almost anything and marvel at what comes back. Give it a problem and it can find a path you did not anticipate. That unpredictability is part of what makes AI amazingly intelligent, and in many situations it is exactly what makes it the revolution in technology we dreamed of for decades.

But in some cases, we are using a sledgehammer to tap in a nail, and it is costing us a chance to provide the right solutions.

When delivering software as a product, the majority of products are not trying to surprise their users to provide value. Creativity sounds universally desirable, but humans require a surprising amount of consistency to be productive. We don’t generally ask our employees, engineers, doctors, lawyers, or PhDs to be randomly creative. We give them a mission, constraints, and some expectation of what a good result looks like. We want coffee on Tuesday morning at 9 AM, even though all the data points otherwise. Random human + informed AI + creative decisions = unhappy people.

AI doesn’t escape our expectations simply because it is intelligent.

A system that generates a different answer every time it is asked and is told to respond in certain ways with generalized prompts can aspire to be remarkably capable, but it can also be remarkably difficult to control, test, explain, package, interpret, and trust.

I don’t say this philosophically. I say it after years of wrangling AI to do things I hoped would create uniquely powerful products that didn’t exist. Why are the products we see so bad at converting this powerful tech into a powerful value prop? “SaaS is dead” encapsulates that problem. Copying and pasting your work into ChatGPT is often better than using a packaged product that tries to leverage the same AI to complete expected tasks efficiently or effectively. Chat is a bit messy, but it leans into that via the chat experience. That messiness is at odds with a packaged product.

I hear it every week from some aspiring entrepreneur: “Give the AI all your data and let it discover and manage [insert problem here].” It is a magical proposition that is within reach now.

Often it can turn into amazing demos and show unbelievable potential. But getting from a controlled demo to a reliable set of actions and outputs, unmonitored and unaudited by a human, is exceptionally hard. Even big companies with big wallets struggle with the transition. Small amounts of drift compound. Mistakes require review. Sometimes understanding what the AI produced takes nearly as much human effort as doing the work yourself, even if the human would have done the work somewhat worse. And don’t get me started on the cost of answering questions with non-deterministic expectations.

Perhaps we solve this. I hope we do. But in building these systems, I came to appreciate another application of AI that I think we’re underestimating.

Allowing the average person to let AI run their business may be a few years away. Building a business or product with AI tooling is already extraordinarily powerful, and not merely because AI lets us build software faster. It lets us afford complexity we previously couldn’t.

Historically, software has been deliberately simplified.

If a problem had a thousand paths, we rarely implemented a thousand paths. Humans had to anticipate the main cases, write the rules, implement them, test the edge cases, and maintain everything afterward. Eventually the economics would win. We scoped down to three possibilities and ignored the rest so that the software would work well for those cases, slowly building up one case at a time as needed.

AI changes the economics of that equation.

We can now use non-deterministic development tools to explore an enormous possibility space, then turn what we learn into deterministic software. A function that would take an immense level of brainpower to create efficiently, effectively, and robustly was expensive to build, let alone maintain as features were added. Now AI not only helps discover the paths, but can create elegant, hardened functions that deterministically handle all the possibilities you give it. Changing that functionality is no harder.

That distinction is more powerful than it initially sounds.

The power is in the fact that humans don’t typically expect to give or get thousands of outcomes from certain problems. Time and time again, we imagine a waterfall of possibilities when reality only requires an eyedropper’s worth of water.

Because of this tendency to overestimate the useful possibility space, 100 possibilities handled deterministically can feel remarkably intelligent. And with static, scalable, deterministic code, you are paying an infinitely smaller cost to solve these problems. It really is the best of both worlds: scalable software, intelligent-seeming computations, and extraordinarily low complexity to build and manage.

We get much of the richness we associate with AI without requiring an AI to improvise every interaction.

This isn’t an argument against live AI. Some problems genuinely benefit from open-ended answers. Chat obviously does. Search, research, documentation, creative work, and assistance are natural places for a system that can respond to questions nobody anticipated when the product was built. I have five bots running all the time to manage my email, calendar, video creation, socials, and more. They need slapping around now and again and require a lot of guidance, but they are far cheaper than hired help and always running 24 hours a day.

The thing I think nine out of ten people miss when the silver-bullet dream of AI is presented is this: infinite possibility isn’t a requirement for every problem.

Often the customer knows what they are trying to accomplish. Most consumers don’t need an infinite number of possible answers for the mountain of information that surrounds them. They need a sufficiently large number of great ones that consistently provide value.

That is the subtle opportunity I missed when I first started building heavily with AI. I was fascinated by AI’s ability to make software non-deterministic. I now think its ability to make deterministic software vastly more expressive may be just as important.

AI has dramatically lowered the cost of deliberate complexity.

Instead of asking AI to decide what our product should do every time it runs, we can use AI to help us consider far more of what it could do while we build it. We can then deliberately decide which of those possibilities it should handle and save ourselves and the customer more money than they thought possible.

The intelligence moves from improvising the product to constructing it.

And sometimes that is exactly where you want it.

Think in Sprites When You Generate Images with GPT

Here is a useful trick if you are generating a lot of small graphics with GPT.

Not every image you need actually needs to be generated as a standalone image.

A small icon, avatar, button state, game asset, UI decoration, or other graphic may only occupy a tiny amount of your final product. But image generation systems often work at resolutions much larger than the thing you actually need. ChatGPT Images now supports different aspect ratios and resolutions, but you are still generating a relatively large image for a relatively small object. Larger image outputs generally consume more image tokens and can take longer to generate. (OpenAI Help Center)

So think like a game developer from the 1990s. Think in sprites.

A sprite sheet is simply one image containing many smaller graphics. Instead of loading 100 individual images, a game could load one image and tell the graphics system which rectangle of that image contained the sprite it wanted. The browser or game engine would then display only that portion.

The same idea works surprisingly well with AI image generation.

1. Generate a grid instead of individual images

Suppose you need 20 tiny cartoon avatars for an application.

You could ask GPT to generate 20 images. That means 20 generation jobs, 20 waits, and potentially 20 times the generation overhead.

Instead, ask it for a grid:

Create a 10×10 grid containing 100 unique cartoon avatars. Each avatar should occupy exactly one cell. Keep the visual style consistent, but make every character distinct. [what you want the images of – in the case below clubhouse dressed, 2d, comic style, animals]

You now have one generated image.

Then split the image into its cells yourself. This is trivial with an image editor, a tiny script, or even a second AI-assisted step in your agentic environment.

The important part is that the generated image is now the container, not the final asset.

You can do the same thing for icons, illustrations, characters, graphics, UI elements, or almost anything where each individual asset is smaller than the generation system’s useful output size.

Here is an example of one I iterated on for a hobby project at http://www.skillbase.club where we made the theme country club based on the domain we could get.

That’s 100 avatars for the same time and token cost as a single oversized image.

2. Use grids for drafts, too

This is arguably the more useful trick.

Maybe you don’t need 20 images. Maybe you are trying to decide which version of one image you actually want. Instead of generating four separate versions, ask GPT for a 2×2 grid:

Create four variations of the same clubhouse in a 2×2 grid. Keep the subject identical, but make each cell explore a different composition. [or name each composition like Lichtenstein-esque or paper cut out]

Now you can compare four directions in a single generation.

Once you pick the winner, generate that one properly.

This changes the economics of experimentation. You are using the expensive, slow part of image generation to explore a space of possibilities, rather than paying the full cost to explore each possibility independently.

And there is a broader lesson here.

We spent decades learning to optimize graphics by separating the asset from the container used to transport it. AI image generation makes it easy to forget that distinction.

If you need something small, generate a sheet. If you need alternatives, generate a grid. Then cut out what you actually need.

You can’t build a vision

Great visionaries know better than to try.

Founders are encouraged to think bigger, dream bigger, and change the world. Investors ask about the ten-year roadmap before the company has ten customers. Every pitch deck ends with an enormous market and an even larger ambition.

Ironically, none of history’s great companies were built by executing their original vision.

Many founders have misunderstood what a vision is. They believe it is the product they should build. In reality, it is a vague direction they want to travel.

This seems backwards until you realize that a vision is not a blueprint. It is a compass.

A blueprint describes something that can be built today. A vision describes a future that cannot. Trying to build the destination first is one of the fastest ways to build something nobody wants.

Instead, great founders ask a different question.

“What is the current established working system that I can make a derivative of that points in the right direction”

The distinction sounds subtle, but it changes everything.

SpaceX did not begin by building a city on Mars. It started by trying to build a rocket (in fact buying existing rockets) that could reliably reach orbit and eventually be reused. “Making humanity multiplanetary” was never the first product. It was the reason for building the first product.

Amazon did not launch as the everything store. It sold books because books were one of the easiest retail categories to digitize. Only after mastering logistics, fulfillment, warehousing, recommendations, and customer trust could it expand into everything else. Patience is Bezos’ super power.

Uber did not replace transportation. It simply made hailing a ride easier. The broader transformation of urban mobility emerged from years of iteration after customers had already adopted the first step. And transportation is far from replaced.

Even Apple followed this pattern repeatedly. The Macintosh was not Steve Jobs’ ultimate vision for personal computing. In fact Lisa was a visionary product that failed terribly. The iPod was hardly the invention of portable music. In many respects it was an exceptionally well-executed digital Walkman. Yet it became the foundation for the iPhone, which became the foundation for an ecosystem that Jobs could never have shipped on day one.

There is an uncomfortable lesson hidden inside all of these stories.

Visionaries don’t build their vision.

They build the first stepping stone that reality will allow. They don’t fight the world to manifest their vision to life against all odds. They fight their ego to build what’s possible today. They hope the two will meet one day.

Many founders resist this because it feels like compromise. They worry that solving a smaller problem somehow means thinking smaller. They want to standout and be impressive.

The opposite is true. I am impressed by the success of the unimpressive.

Reducing an ambitious future into something customers will actually buy is one of the hardest acts of product design. It requires sacrificing elegance for momentum, completeness for usefulness, and pride for learning.

Almost anyone can imagine a better future. Make claims of what the future will look like and sell that.

The rare skill is translating that future into something almost disappointingly ordinary, shipping it, learning from reality, and repeating the process until the original vision slowly emerges.

History suggests that this is not the exception.

It is the process.