22/12/2025 ☼ product ☼ consulting ☼ AI

tl;dr: This essay is about Boring Tiny Tools—why they’re the way forward for digital transformation. Generative AI coding tools now enable high-utility, highly customised, but narrowly scoped software … but only with a fundamentally different approach to product development that uses meaningmaking to identify problems solvable with off-the-shelf components.

While I was in Japan a couple of months ago, I had coffee with the chief operating officer at a mid-sized manufacturing firm. Let’s call her Yuko. Just over a year into a $3 million digital transformation initiative to roll out an enterprise software platform, Yuko’s team was still manually aggregating supplier insurance certificates into spreadsheets.

The enterprise CRM they’d bought had a vendor management module that could theoretically handle this. But it was designed for much bigger businesses operating across multiple geographies. Yuko’s team needed something simple: extract dates and coverage amounts from documents arriving in different formats, flag gaps, send renewal reminders.

To make the module work properly would either require expensive customisation by sales engineers, or time-consuming pre-processing by Yuko’s team to convert vendor documents to fit into the standard module. It would be so troublesome or expensive that they’d decided to work around it by sticking to the spreadsheets they’d been using for years. She asked: “Why can’t we just have something small that does exactly what we need?” Then she sighed.

It’s a fair question to ask. I’ll answer it by sharing my own digital transformation experience.

Big beautiful transformations don’t work … but boring, tiny ones do

I’ve spent some of the last 6 months engaged in an in-house digital transformation exercise. I’ve been building tiny pieces of extremely narrowly scoped software to improve my tiny consulting company’s internal processes by replacing things I currently do manually without disrupting any other pre-existing workflows and processes.

Here’s one example: I’ve travelled a lot after the lockdowns and need all my travel details (retailers and booking numbers of flights, ground transport, accommodations) aggregated in a form that allows me to interrogate it for duration of travel, cost of travel, who’s paying for the travel, and as is increasingly necessary these days, information about when and for how long I’ve been in/out of a country.

I used to have to go through emails or flip through expired passports. Now I have a script that takes emails, PDFs, and screenshots sent via Telegram, runs them through OCR, extracts the information, confirms it with me via message, then adds it to a queryable spreadsheet. What used to take me hours to do unreliably now takes seconds to do reliably.

The workflow I built is highly specific to how I work. Existing travel tools integrate poorly with my idiosyncratic workflow and require me to change how I work to accommodate them. The reverse is also true: my exact approach would probably feel weird to most other users. I am probably the only user for this very lightweight, rough-around-the-edges piece of software, and it is custom-built to work so that I didn’t have to change any other piece of my workflow when I switched it on.

But a user base of one person is fine because this piece of software took me about 3 hours to build. The tool uses no deep or novel technology—I’m a qualitative sociologist, what do I know about that stuff? Image recognition, text extraction, messaging, data storage are all available off the shelf, needing only good specification. It’ll probably save me 40 or 50 hours over the next two or three years.

Even last year this would have made no sense to build. The commercial proposition is crazy: spend days building something with a tiny userbase. AI-supported coding got much better this year, to the point where the economics of building this tool suddenly made sense.

My little company’s experiment with this kind of unspectacular but actually useful software is the right way to do digital transformation with AI.

If I had to put it in a sentence, it would be “Don’t waste your digital transformation budget on grand AI plans that are intended to disrupt your organisation; instead, build lots of tiny, unsexy pieces of software that fit seamlessly into existing workflows.”

Doing this requires a different approach to thinking about product development

The (former) logic of software

Until this year, most software was expensive to build and support. So software had to be built for enough users to monetise it at scale. Software built under these assumptions generally offers adequate functionality for enormous numbers of users instead of optimal functionality for a tiny number of users.

I spent a few years in product management at Google, watching the company build software like Maps and Ads for enormous scale. This requires imagining markets that don’t yet exist and building speculative products for millions of users. This is what venture capital funds: products with enormous TAMs requiring new technologies—expensive and uncertain to build, but potentially luxurious to operate. The VC mode builds Big Fancy Software.

VC problems are not the problems most organisations need to solve when they’re trying to digitally transform how they work.

Yuko’s situation isn’t one that requires innovation, because her ops team’s needs are well-understood already, even if they’re not yet written down. No new technology needs to be built, because all the required components already exist. The software solution should be designed for Yuko’s small ops team’s highly specific needs, not for a massive market of anonymous users. Yuko’s team’s needs are highly specific because they work within a company with a fully built-up web of business processes that must be preserved.

This is the inverse of VC-mode product development, requiring a fundamentally different approach.

Boring Tiny Tools

The alternative approach is to focus on building Boring Tiny Tools instead of Big Fancy Software. Boring Tiny Tools, or BTTs, are narrow-scoped software with exactly the functionality needed and nothing more. Each is specifically designed to integrate seamlessly with existing business processes. To build Boring Tiny Tools takes some counterintuitive thinking:

1. Build software that limits itself to replacing only parts of work that require no discretion or judgment calls, leaving judgment calls to humans. (This is what I call the meaningmaking lens on AI.) Routine tasks like extracting booking references, dates, and cities from documents are ideal for BTTs.
2. Design BTTs around how work actually happens, not how organisational charts or process documents say it should happen. The insurance certificate problem has company-specific detail: this vendor sends PDFs, that vendor send sends photos from her cellphone, those vendors send faxed certificates. The tool needs to handle the particularities of current reality without requiring dependencies to change.
3. Scope each BTT as narrowly as possible, limiting it to what its actual users want. If this means fewer people want to use it, that’s okay. Test early versions with actual users to ensure the scope is narrow enough to be immediately useful.
4. Build the BTT with only off-the-shelf components. If the narrowly scoped BTT requires building brand new technology (or worse, “deep tech”) … consider working on a different BTT instead.

The contrast is fundamentally conceptual, not technical:

non-VC mode (Boring Tiny Tools)	VC mode (Fancy Big Software)
Build software that limits itself to replacing only parts of work that require no discretion or judgment calls	Try and build software that tries to replace all human work
Aim to serve tiny userbase, the smaller the better	Aim to serve enormous userbase, the bigger the better
Avoid developing new technology	Try to innovate on technology to create a moat
Try to solve an existing, tightly-scoped problem without disrupting any of the problem’s upstream/downstream dependencies	Try to solve a new, preferably enormous problem that fundamentally disrupts markets

This is a product mindset problem, not a technical problem. The technical part—actually writing the code—is relatively straightforward because the scopes are small and the components already exist. What’s hard is having the mindset that is able to choose the “right” software to build, and figuring out how to do it without breaking the things that are already working.

Organisations I’ve worked with struggle with focusing on Boring Tiny Tools because it isn’t fashionable to think about software development in this apparently unambitious way.

The people who understand the workflows and business processes (always people in operational roles close to the ground) aren’t trained to specify requirements for Boring Tiny Tools. The people who build software (IT departments, external vendors) are trained and incentivised to push for huge enterprise software deployments or complex from-scratch builds — expensive Big Fancy Software that gets the leadership excited.

What’s missing is someone to bridge that gap. Someone who can help articulate workflow needs in ways that can be rapidly prototyped, who can evaluate where a Boring Tiny Tool would make sense, and who can help grow an internal organisational culture for doing this systemically.

This requires an unusual combination: understanding of product strategy, enough technical fluency to evaluate what’s feasible, and deep appreciation for how work actually happens versus how organisations think it happens. It also requires not having a vested interest in any particular technical solution.

The goal is to find small problems to solve in the most direct way possible, not to sell a platform or justify a large development team. If you’re successful, your organisation will have a profusion of Boring Tiny Tools, not Big Fancy Software. Each BTT represents a small optimisation that is more likely to be used, less likely to break things, and therefore more probably transformational.

(If the concept of incredibly useful but Boring Tiny Tools resonates, you might also be interested in what I wrote last year on why effective strategy needs to be deeply embedded in how things work.)

---

For the last few years, I’ve been wrestling with the practical challenges of meaning-making in our increasingly AI-saturated world, developing frameworks for how humans can work effectively alongside these powerful tools while preserving the meaning-making work that is the irreplaceably human part of the reasoning we do. I’ve published this as a short series of essays on meaning-making as a valuable but overlooked lens for understanding and using AI tools

I’ve also been working on turning discomfort into something productive. idk is the first of these tools for productive discomfort.

And I’ve spent the last 15 years investigating how organisations can succeed in uncertain times. The Uncertainty Mindset is my book about how to design organisations that thrive in uncertainty and can clearly distinguish it from risk.