Boring Problems

One of the best product ideas I've had began with an accountant chasing missing monthly documents.

She had a spreadsheet with client names down the left and document types across the top. Every month, she opened the sheet, searched through her inbox, marked cells green or red, and sent reminder emails to whoever was missing something. She did this for dozens of clients. It took most of a morning.

There was nothing glamorous about the problem. No novelty, no spectacle, no language of disruption. Just a repetitive workflow held together by a spreadsheet, an inbox, and sustained manual attention.

So I built Month-Track. It is a small app where you create clients, define which documents are expected each month, track what has arrived, and send reminders. That is the whole product. The most satisfying feature is a button that marks a month as ready, meaning everything is in and the accountant can finally move on. It is not glamorous. It is useful.

I saw the same pattern much closer to home. I grew up around my father's flower shop, and I watched how much of the business ran on memory, notebooks, supplier messages, and spreadsheets that were always a little behind reality. If someone asked what was in stock, the answer was not always obvious. Sometimes it meant walking to the back room, checking the buckets, counting stems, and trying to work out what had arrived, what had been sold, and what was still good enough to use.

I built BloomOps as one place to track products, suppliers, shipments, and orders. A dashboard that shows what is in stock, what is running low, and what has moved recently. Again, nothing revolutionary. Just a better system than counting flowers by hand.

Both problems sit in the background of small businesses everywhere: repetitive operational tasks done with tools that were never really built for the job. They survive not because they are impossible to solve, but because they are too ordinary to attract attention. They do not look like opportunities. They look like admin.

The people dealing with them rarely frame them as software problems. They adapt instead — keeping things in their heads, building routines around the gaps, sticking notes to a monitor. Most of them are not hunting for a SaaS tool because they do not expect one to fit the work closely enough to help.

The only way I know to find these problems is by watching. Not brainstorming. Not “customer discovery” in the abstract. Watching.

I trained as an anthropologist, and one lesson from that training has stayed with me: people are unreliable narrators of their own behaviour. Ask someone what their biggest problem is and they will usually give you a neat, conscious answer. What they often miss are the smaller frictions that have become so familiar they no longer register.

You only see those if you watch the work happen. The tab-switching, the copy-pasting, the brief pause while someone tries to remember whether they already sent that email. The walk to the back room to check what is really there. That is where the product starts.

This is also why generic tools rarely solve these workflows properly. Yes, you can use Notion, Airtable, Trello, or Google Sheets for almost anything. But that still leaves the user to build and maintain the system. Most people do not want a toolkit. They want a tool that already understands the shape of the task. That specificity is exactly what makes the tool useful.

I suspect there are thousands of problems like this. Every trade, every office, every small business seems to have some spreadsheet quietly holding the whole thing together. A dental clinic tracking follow-ups by hand. A construction company managing deliveries on paper. A school running attendance through Google Sheets.

Those problems look small from the outside. That is part of what makes them good.

If someone is running a recurring workflow in a spreadsheet, three things are probably true: the workflow is real, the pain is real, and nobody has built the right tool yet.

I am not arguing that boring problems are better than interesting ones — only that they are overlooked, and overlooked problems make good products for anyone willing to pay close attention.

That attention is the difficult part. Not the code. Not the design. The difficult part is sitting with someone long enough to notice the friction they themselves have stopped seeing.

The software comes later.

First, you have to learn how to look.