On 22 October 2026, Product Meetup SXB #23 trained its participants in atomic research, a method for sorting your evidence before you decide. Two problem owners then brought their products to the tables: a knife shop and a file-sharing app. The training slides are available as a PDF download.
Strasbourg, Thursday 22 October 2026, pitch time. Antoine (the owners’ names have been changed) presents his online knife shop: a huge catalogue, blades of every shape, and a single sale in several years of trading. A little later, Hugo, a designer, presents the app he built to send files to his clients without paying for a service. He has no idea whether anyone else will want it.
Both the knife shop and the app already exist. Yet both owners face the same open question: who, exactly, is this for.
An hour earlier, the training had covered a way to find answers that hold up.
The training: sort your evidence before you decide
I devoted this month’s training module to atomic research, a way of organizing research into small units, each tied to its evidence, so that answers hold up. The problem is familiar: interviews, tickets and traffic figures are stored somewhere, nobody finds them when it is time to decide, and decisions fall back on gut feeling. The evidence exists. It sleeps.
The method grew from two places at once. In 2017, Tomer Sharon at WeWork created Polaris, a system for storing research findings built on nuggets: small, tagged items that are easy to find again. At the same time, Daniel Pidcock proposed organizing research into experiments, facts, insights and recommendations.
Both drew on atomic design, a designers’ method that breaks an interface into reusable components, such as a button or an input field.
So during the session, I kept the word nugget, the research version of those reusable components: a brick of knowledge tied to where it came from. A nugget reads on its own, without the report it was pulled from, turns up six months later from a single keyword, and combines with other nuggets, like a Lego piece, to say more than it could alone.
Then I followed a running example: a fictional online shop whose customers take too long to pay. Everything starts from an objective and its key results, the numbers that will show whether the objective is met: cut the time between adding to cart and paying from 9 to 3 minutes, and raise the share of paid carts from 32 to 45 %. These figures are invented for the exercise. The course is set.
Next, each key result produces questions, written with a question mark so they stay questions. For each one, before searching, the team sets the criteria an answer must meet to be accepted. The team thus forbids itself from moving the bar once the results are in.
The nature of the question steers the method. The session relied on the seven types of product tests, need, opportunity, desirability, usability, feasibility, viability and ethics, each with its own methods. So an unknown cause calls for interviews or observation; a lead to check, a prototype; a solution to measure, an A/B test, which compares two versions with two groups of users.
Then answers arrive through collections: a study run on purpose, such as a series of interviews; a continuous stream, such as analytics or tickets; a document read once, such as a market study; and each collection brings back raw data, an export or a note, and facts: what was said, observed or measured, dated and sourced.
Raw data is never evidence. A fact becomes evidence when an interpretation rests on it. In the running example, three facts from three collections support the same interpretation: customers want to know the total cost before they commit. The first is an interview quote, the second an observation of customers hunting for shipping costs, the third a measurement showing that 6 customers in 10 leave the site at account creation. Apart, these facts describe behaviors. Together, they point to a cause.
Not all evidence weighs the same. In the atomic research app I demoed during the training, each fact gets a confidence score out of 5. It depends on its nature, on the reliability of its collection, on the legitimacy of the person speaking on that specific question, and on its validation by another team member. A quote weighs 2, because it reports what a person believes they do; an observation 4, because it shows what they do; a measurement 5, because it counts what all customers do. The gap is deliberate.
Legitimacy is judged question by question. A sales director carries weight in the company, but no particular knowledge of the purchase journey. On this question, his word carries no weight.
So whatever weight each piece of evidence carries, as long as it falls short of the criteria, an interpretation stays a hypothesis. Once the evidence meets them, by default three pieces from at least two methods, including one observed or measured fact, it becomes a learning. A learning is not declared. It is established. One piece of evidence at a time.
At the top, the decision states what it rests on. It is informed when all its nuggets are learnings, owned when one of them is a conviction backed by a person who knows the subject, and a bet when it rests on a hypothesis. Bets are allowed. They are simply flagged. In the running example, the shop decides to allow checkout without an account, and that decision immediately opens a new question to check.
Finally, participants worked with the method for 13 minutes, in pairs, in a working version of the app, from the objective all the way to the decision. The app is not finished: screens will change, and the evening’s feedback will shape what comes next. To try it, open the Impact Factories applications page, click + Nouveau (New), choose Nouvelle expérimentation (New experiment), then the Atomic Research app.
The session fits in four sentences. An objective is decided. A fact is checked. An interpretation is proven. A decision states what it rests on.
The workshop: one owner, one table, one action plan
After a short break, the workshop took over, with separate registration. Its goal fits on one line: the owner of a problem leaves with the biases that brought them where they are, hypotheses to test quickly, and an action plan they can start the next day. Not a ready-made answer. At the end, the owner scores the plan from 0 to 5, depending on whether they really intend to use it. The target is 3 or more.
Each owner pitches in 60 to 90 seconds: their context, their problem, what they have already tried, their constraints, their role and their goal for the evening. Tables then form around the pitches, with three to five people each and a facilitator, a product manager or product designer, whose job is to keep the group on the problem instead of letting it drift toward solutions.
The work then runs in three stages: fifteen minutes to map the context, forty minutes to dig deeper, twenty minutes to build the action plan. The first stage always opens with the same six-point questionnaire:
- How old is your product?
- What problem does it solve?
- How does it solve it?
- How is the team organized, and what is your role?
- What problem do you want to solve tonight?
- What are the consequences, and how often?
The questionnaire serves the contributors first. It lets them put themselves in the shoes of the person about to lay out their problem, in that person’s own context, not the one they imagine.
Four rules frame the table, and facilitators enforce them. You challenge the method, never the idea or the person. No solution is offered before minute twenty. You put forward a hypothesis rather than a judgment. And the owner leaves as the decision-maker: the group coaches, it does not decide for them. In my experience, rule two is the one everyone forgets.
This framework is not new: the write-up of the twenty-second edition shows it at work on two other products. On 22 October, it served Antoine and Hugo.
Case 1: a knife catalogue with no soul
Back to Antoine, who has been selling knives online for several years. His catalogue is huge: shapes, sizes and uses for every taste. Yet the site has recorded a single sale. Just one.
The table quickly put its finger on what was missing. The site displays products, but nothing that makes you want to buy them. Unless you are looking for one precise knife and already trust the site, because Antoine convinced you in person, a visitor has no reason to place an order. The catalogue has no soul.
A catalogue full of choice draws people to a site, but abundance alone does not sell. In an experiment published in 2000, psychologists Sheena Iyengar and Mark Lepper had set up a jam-tasting booth in an upscale grocery store in California. With 24 flavors, 60 % of passing shoppers stopped, against 40 % with 6 flavors. But among those who stopped, nearly 30 % bought a jar when facing 6 flavors, and only 3 % when facing 24. Ten times fewer.
Yet the effect does not hold everywhere. In 2010, a meta-analysis of 50 experiments found a mean effect of virtually zero, with wide variation from one study to the next.
So the number of knives probably does not, on its own, explain the missing sales. The table’s hypothesis lay elsewhere: the lack of guidance. The hiker, the cook or the collector who lands on a huge catalogue with no theme, no advice and no story does not know where to start, and often ends up closing the tab. They leave with nothing.
The table’s first recommendation was to choose an audience and themes, such as hiking or cooking, rather than show the same catalogue to everyone without saying who it is for or what it is for. April Dunford, a positioning specialist, calls best-fit customers the customers who really care about what makes a product unique.
Clayton Christensen sheds light on the same choice from another angle, with jobs to be done, the progress a person is trying to make in a given situation. According to the institute that carries his theory, people do not simply buy a product: they pull it into their lives to make progress.
The hiker who wants a lighter pack and the cook who wants a blade that holds its edge are not looking for the same knife. Nor for the same reason.
The catalogue’s variety then becomes an asset. It gives Antoine the image of a knife expert, which he can strengthen by guiding the choice: each product page starts from the customer’s problem and explains why this knife rather than another, and blog articles tell the stories of how they are used.
For Antoine, this guidance also feeds the site’s visibility, because SEO, search engine optimization, rewards what Google calls people-first content: content created primarily for people, not to manipulate rankings. GEO, for generative engine optimization, applies the same logic to generative engines, the AI assistants that answer with a text, and researchers coined the term in 2023 for the craft of improving a piece of content’s visibility in those answers.
A product page that explains why a given knife suits a given use hands both kinds of engines an answer to quote. The themed stories do one last job, because they segment customers by use: the hiker arrives through an article on hiking, and Antoine knows, from the first visit, what to offer.
All of this must rest on a clear vision of what the company stands for, its values and its mission, carried through all of its communication. Simon Sinek sums up the idea with his Golden Circle, which invites you to start everything you do with a simple question: why. His best-known line fits in one sentence: people don’t buy what you do, they buy why you do it.
The soul the catalogue was missing is that why.
Case 2: a file-sharing app looking for a market
The second table welcomed Hugo, a designer. To send files to his clients, he built his own on-premise solution, meaning installed on a machine he controls, at home or with the host of his choice, rather than on a provider’s service.
It comes as two apps that work together, one on his server and one on his computer, to upload files to the server and generate a download link to send to the client. Hugo built for a need of his own. He does not want to hand his data to just anyone: with his solution, he chooses his host precisely, even if that means running a server at home with a public IP address, the one that makes a machine reachable from anywhere on the internet. He also avoids the subscription that file-transfer services charge. No middleman, no monthly bill.
His question for the table fit on one line: would anyone besides him be interested. Nobody knew.
Building for himself before anyone else is interested is still a good start. Paul Graham, cofounder of the Y Combinator accelerator, notes that the best startup ideas often share this trait: they are things the founders themselves want. He adds that a product no competitor offers, which a subset of users urgently needs, gives you a beachhead. Yet on-premise solutions already exist: Nextcloud, for example, can be deployed on your own servers, in the cloud or in hybrid mode.
Hugo is therefore not facing a blank market. He still has to find the subset of users for whom his solution beats the ones that already exist.
The table listed possible audiences, then chose to start with freelancers who, like Hugo, regularly share files with their clients and want to do it securely. First action: find the events where these freelancers meet, and go talk to them. Without selling them anything.
The instruction fits in one sentence: do not talk about the solution. Rob Fitzpatrick made it the core rule of The Mom Test: focus on the customer’s life rather than your idea, and probe specific past behavior rather than future promises.
So the interview moves from the customer’s need to their effort, up to the domain name, the readable address of a site such as impactfactories.com, and access to a server, in this order:
- Do you need to transfer data between you and your clients?
- Do you pay for a file-sharing solution?
- Would removing the cost of your file-sharing solution interest you?
- Do you have a domain name?
- Do you know your server credentials, and can you access it easily?
The first two questions describe the freelancer’s life, what they already do and already pay for, while the next three measure the effort they would have to make to adopt a solution like Hugo’s. The domain name serves here as a rough, imperfect gauge of technical maturity, and the fifth question assumes the freelancer has a server. A freelancer with no domain name, or who cannot reach their server, will struggle to install an on-premise app, even if they say they are interested.
Beyond saying they are interested, The Mom Test tells you to look for commitments: time, money or reputation.
I add one caution about the third question: it asks about a future intention, and costs no time, money or reputation. A polite yes proves nothing. A freelancer who leaves their contact details to try the solution is worth more than ten enthusiastic answers.
These answers will be declared facts, the kind that weigh least in the method from the training, but cross-checked across several freelancers and compared with what they actually do, they can become a learning.
Building before knowing who for
Antoine and Hugo both built before knowing who for. The first filled a catalogue, the second wrote an app. Neither lacks a product. What they lack is named customers, people you could call tomorrow, described by their use and what they already pay for, and evidence that those reasons hold.
That is exactly what the training taught people to sort, an hour earlier: an objective, questions, sourced facts, and decisions that state what they rest on. Hugo’s interviews with freelancers will be his first nuggets. Each theme Antoine tests, with its visits and its sales, will become a piece of evidence.
Finally, thank you to the owners, the facilitators and every participant. The next edition takes place on Thursday 26 November 2026. Registration is on Meetup, and a review left on the event page helps other people find the community.
