Serial founders do not brainstorm. They maintain an always-on radar for problems in their own workflow. Here is what that looks like in practice.
19 April 20268 min read
There is a persistent myth about where product ideas come from. According to the myth, founders sit down with a whiteboard, a facilitator, and a problem statement, and generate ideas through structured creativity sessions until something good surfaces. This describes how consultants run workshops. It does not describe how serial founders actually find things worth building.
The research on serial innovators is consistent on this point. The process starts with observation: not much talking, just watching, looking for compensating behaviour, for the gap between what people do and what the available tools ask them to do. The idea is not invented. It is noticed. It was already there, embedded in a friction that the founder encountered, tolerated, worked around, and eventually stopped tolerating.
The difference between a first-time founder and a serial founder is largely that the serial founder has learned to take their own friction seriously. They know the gap between "this is annoying" and "this is something worth building" narrows with experience.
What a pattern surface is
A pattern surface is any tool, system, or routine that puts a founder in regular contact with a specific category of problem. It is not a research methodology. It is a working environment that generates signal over time.
A developer who builds tools for a living and uses those tools every day is sitting on a pattern surface. Every time they work around a limitation, that workaround is data. Every time they switch tools to fill a gap a single tool should cover, that context switch is data. Every time they explain the same limitation to a colleague for the third time in a month, that repetition is data.
The signal accumulates slowly. Most of it is noise. Occasionally something surfaces that is specific enough, painful enough, and recurring enough that it stops looking like a complaint and starts looking like a product.
Sant Tabs: the tab manager that did not exist
Sant Tabs came from a personal frustration with the available options. The Chrome and Chromium tab manager ecosystem splits into two categories. On one side are tools that are too large and too feature-heavy, built for enterprise use cases with more configurability than any individual developer needs. On the other side are tools that are too simple, offering basic grouping or saving without the developer-oriented features that make the tool genuinely useful in a technical workflow.
The middle ground did not exist. A tab manager that handled the core developer use cases without becoming an application in its own right, that kept saved collections accessible without turning the browser into a second workspace, that had the controls a developer would actually reach for without burying them under ones they would never use.
The idea did not come from a market research exercise. It came from repeatedly reaching for a tool that was not there, and eventually deciding to build it rather than continue working around its absence.
That is the pattern surface at work. The same irritation, experienced enough times by someone who knows how to build, eventually tips into a product decision.
Sant Chat: the plugin that came from client conversations
Sant Chat AI started from a different kind of observation. Not a gap in available tools but a pattern in client requests.
Two years of working as head of studio in a digital agency context produced a recurring category of question. Clients with substantial knowledge bases, non-profits, healthcare organisations, professional services firms, wanted to make that knowledge accessible to visitors by voice and by text, in ways that went beyond simple frequently-asked-question lookups. A visitor describing a symptom and receiving information drawn from the organisation's official clinical guides. A member asking about eligibility and getting an answer sourced from the organisation's own policy documents. Not a chatbot that answers "What are your opening hours?" but a system that genuinely surfaces institutional knowledge in response to specific, sometimes complex questions.
The tools available for this in a WordPress context were thin. The category of product that would sit on a WordPress site, read the site's own content before answering questions, and handle lead capture, voice, and theme controls within the one plugin, did not exist at the right quality level.
The observation accumulated across enough conversations over enough time that it stopped being a recurring client request and started being a product specification. Sant Chat is the result of that accumulation.
The gap between observation and the right observation
Not every friction is a product. The test that separates a real observation from a complaint is specificity and recurrence.
Specificity: can the problem be described in terms of what someone is trying to do, what the available tools ask them to do instead, and what the gap between those two things costs in time, effort, or accuracy? Vague frustration is not a product. A specific, nameable friction with a specific, nameable cost is a candidate.
Recurrence: has this friction surfaced more than once, across more than one context, over more than a short period of time? A single bad experience with a tool is not a pattern. The same gap appearing in the same form across months and across different situations is a pattern.
The tab manager gap met both tests. The client request for AI-driven knowledge base access met both tests. Most frictions encountered in daily work do not meet both tests, which is why most frictions do not become products.
Serial founders maintain an always-on radar for problems, workflow friction, and unfair advantages, collecting raw signals from complaints, workflow analysis, and platform changes. The radar does not run when they decide to look for ideas. It runs continuously, because the environment they work in generates signal continuously. The decision is not to look for ideas. The decision is to pay attention to the signal that is already arriving.
Building a pattern surface deliberately
If the signal comes from working environments that put a founder in regular contact with specific categories of problem, the practical implication is that the environment matters. A founder who wants to find ideas worth building needs to be in environments that generate the right kind of friction.
For technical founders, this usually means building their own tools, using their own products, and paying attention to where the tools break down or where a workflow requires a compensating behaviour that should not be necessary.
For non-technical founders, it means staying close to the operations of the businesses they serve, not just the strategy layer. The friction lives in the daily work, not in the quarterly review.
The tab manager for a technical founder. The plugin that a head of studio needed. The compliance checker that Sant built because the WordPress submission process had no good tooling around it. Each of these came from sustained proximity to a specific problem, not from a dedicated ideation session.
Turning observation into a build
Once a real observation exists, the next question is whether the observation is accurate. This is the validation step, and it is different from the ideation step.
The fastest version of this validation is building the smallest possible working system and putting it in front of the people who have the problem. Not a prototype, not a survey, not a deck. A working thing that does the one job the observation pointed to.
Build in a Day is the delivery model Sant uses for exactly this stage. The scope is defined before the day begins, the decisions are made upfront, and the output is a working system that exists and can be tested rather than a concept that needs further investment before anything is learned.
The observation identifies the problem. The validation build tests whether the observation is accurate. If it is, there is a product. If it is not, the cost of finding out was one day rather than three months.
That sequence, observation, specificity test, validation build, is closer to how serial founders actually work than any structured ideation process. The idea was already in the friction. The work is in paying attention long enough to find it.
Frequently asked questions
How do serial founders know which frictions are worth building on. The test is specificity and recurrence. A friction worth building on can be described precisely: what someone is trying to do, what the available tools require instead, and what that gap costs. It surfaces repeatedly, across different contexts, over an extended period. Most daily frictions do not meet both conditions. The ones that do are worth taking seriously.
Do you need to be the user of your own product for this approach to work. Not always, but being the user removes the distance between the observation and the builder. Sant Tabs and Sant Chat AI both came from direct personal or professional experience of the friction. That proximity accelerated the clarity of the product specification. Founders who are building for a category of user they are not themselves need a sustained and honest relationship with that category, not just research into it.
How does Build in a Day fit into this process.Build in a Day is the validation step after the observation has been made. The observation identifies a real problem. The build tests whether the identified solution is right. The scope is tight because the goal of that first build is learning, not completeness. A working thing that tests the core assumption is more valuable than a comprehensive thing that takes three months to reach a user.
Is this approach only useful for software products. No. The observation pattern applies to any domain where a founder has sustained proximity to a specific category of problem and the competence to act on what they observe. The products that result from this process can be software, services, physical products, or process innovations. The mechanism is the same.
Closing
The brainstorming session does not produce the idea. The idea surfaces from the environment a founder inhabits, from the recurring friction they have tolerated long enough that they know exactly what shape it takes and exactly what it costs. The session is too short and too clean to generate that kind of signal.
The practical alternative is simpler and harder at the same time: stay in environments that generate the right friction, pay attention to what recurs, apply the specificity test, and build the smallest thing that tests whether the observation is accurate. The idea was probably already there. The question is whether enough attention was paid to notice it.