Why a software studio wrote a book
On October 16, 2025, in the company of 20 co-authors, I deposited my first book at the BAnQ.
Its title? “Finally: more humane and sustainable workplaces: a collective guide”.
A book full of self-help tools for wellness at work.
Including my own tool, on courage and trust.
I’m not an expert in human resources, mental health or change management. I’ve been building software for 35 years.
So why a book, and above all, why this one?
That’s what I’d like to share with you today.
A history rooted in the marketing of Confides
The story of the guide began when I was running a new campaign around Confides to get into the offices of managers in Quebec companies.
My initial conversations and research had confirmed that the same dynamics that prevent an employee from notifying his boss in a sensitive situation are the same ones that prevent the public from contacting the health organizations that use Confides.
Fear of being identified, judged and penalized.
With an added complication: many managers are not equipped to receive messages reporting sensitive situations within the company.
So I went looking for a solution. Here are the ones I’ve explored.
AI deemed too risky
My first instinct was to imagine a small agent in the Confides interface to help the manager resolve the anonymous conversations received.
Suggest avenues to explore or even draft answers based on industry best practices.
Something we’d planned to develop to support the healthcare professionals of our existing customers. The same professionals who helped me eliminate this idea.
In 2024, when I presented the idea to the sexologists attending the 5th “Sexualités et technologies” conference, the response was unanimous: “yes to an AI that accompanies us, no to an AI that answers or even suggests an answer for me”.
Why is this? The risk of damage is too great.
The situation is easy to imagine: the manager receives a message describing a sensitive situation. The AI suggests a response, and the manager sends it.
Except that neither he nor the AI saw what was missing from the context. And the person on the other end gets an answer that sounds right, but misses the point. This is exactly the kind of damage that can’t be repaired.
The idea of using AI was therefore abandoned.
The fundamental problem remained: how to equip managers when they need it?
The two-sided market trap
My second idea was more promising on the surface. It’s also the one I’ve seen fail dozens of times in the startup ecosystem: A two-sided market. Think eBay, Uber, Meetup.
For Confides, the two-sided market would have consisted of a directory of professionals that the manager could contact when needed. Psychologists, lawyers, mediators, crisis management experts, all accessible directly from the platform, the moment the need arises.
The challenge of the two-sided market is simple: there has to be enough of everything for everyone. Enough potential customers for advertisers. Enough potential suppliers for customers.
For it to work, you need a critical mass on both sides, and that doesn’t happen by magic: you have to start by talking about it, by recruiting people before the platform even exists.
Talking to people is a prototype solution. Cheaper to create, easier to modify, and assumptions that don’t hold up after ten conversations never need to be developed.
So I started talking to people about it. Validating my idea while recruiting potential professionals for the repertoire.
I really hadn’t anticipated what I would discover in the process.
From a repertoire of professionals to a writing collective
Over the course of the conversations, I discovered a common thread.
Whether it’s Nancy Larose as a mediator or Habib Abi Khalil who uses games as a lever for human connection. We’ve all come to the same conclusion: each of us sees several problems to be solved in our work with companies, and holds only a small part of the solution.
From these exchanges arose a question that I began to test: what would happen if we pooled our expertise to equip our respective customers?
But how? How about a book?
The idea germinated slowly, between conversations. Until one day, when Nancy, one of the first professionals I’d spoken to about it, asked me “When are we going to start this project?
From then on, what was a hypothesis to be tested became a project to be delivered, and the conversations I was having to validate an idea became the first conversations of a collective in formation.
Just enough software
If I’d asked people what they wanted, they would have suggested solutions similar to the ones I was considering. It was by listening to them together, letting the conversations intersect, and letting thirty-five years of experience sort it all out, that the right solution eventually emerged.
The trouble is, it’s tempting to create complex solutions just because you can. Just because it’s fun.
Yet I’m constantly reminded of this phrase by St-Exupéry: “Perfection is achieved not when there is nothing left to add, but when there is nothing left to subtract.”
I’ve been trying to think of a name for this for some time. I think it would be something like: just enough software, not one more button. The method that tells us when to build is the same method that sometimes tells us when not to build.
I didn’t start out wanting to write a book. But when the process points to a book, you write a book.
If you’d like to discover the guide, it’s 106 pages long, free and available at de9a5.org.
Going further with Alfred
AI has a reputation for answering. We find it most useful when it questions. For each entry in this blog, we ask Alfred, an AI assistant, to read and generate questions he finds worth digging into. Here are the questions he asked, and the author’s answers.
On the logic of “irreparable harm
Alfred: The logic of “irreparable harm” – the one that made you rule out AI for sensitive conversations – seems to do a lot of work in the text without being named. Is this a criterion you systematically apply to construction decisions at M2i3? And if so, what happens when the failure mode is unknown rather than known-but-irreparable?
Jean-Marc: Yes, it’s a criterion, and it’s even part of our corporate values. Ethical responsibility: our tools must be benevolent and not be open to misuse. Humanism, which requires us to start from people’s concrete realities rather than from what we are capable of building.
We adopt a posture of security & privacy by design, as part of a responsible software engineering approach, to minimize the risk of damage (security, confidentiality, business impact).
My default reflex, when the failure mode is unknown: slow down. Build smaller. Stay close to actual use. Operate the product long enough for failure modes to become known before scaling anything.
On the three roles of conversation
Alfred: You describe conversations as a validation tool, a solution prototype, and a mechanism for discovering a solution other than the one anticipated. Three distinct roles. How do you know, in a given conversation, which of the three is playing out – or do you only find out after the fact?
Jean-Marc: Sometimes I know, more often I realize it after the fact. The hardest thing is to keep having conversations where we let the real answers emerge.
Rob Fitzpatrick’s The Mom Test was my best tool for learning the difference. The book’s rule is simple: don’t ask people what they think of your idea, ask them how they live with their problem today. That takes away the person’s chance to be polite, and yours to fish for validation.
What “software studio” means after a book
Alfred: Thirty-five years of software, and the studio’s most recent contribution is a paper book. Does this shift your relationship to what it means to be a software studio? Or does the book fit seamlessly into your conception of what M2i3 does?
Jean-Marc: It moves him around a bit, yes. But less than you might think. M2i3 has been connecting needs to solutions since 2005. Generally speaking, the solutions already exist. That’s essentially what we’ve done with this book.
The non-software companion as boss
Alfred: Confides + book, that sounds like a software product and its non-software companion. Do you see this as a pattern applicable to your other products? Do Gertrude, La Zoom Zone, Virtuants each have a non-software companion lying dormant somewhere, waiting to be dragged out?
Jean-Marc: Non-software companions already exist. Just think of the website, micro-publications on social media, welcome e-mail sequences and newsletters.
The economics of the studio that chooses not to build
Alfred: When a customer comes to you with a problem for which the best solution is not software, how do you go about it? Do you tell the customer, build anyway, refer elsewhere?
Jean-Marc: When a customer approaches M2i3 with a problem, we first take the time needed to fully understand the situation. And if the solution isn’t software, the customer usually realizes this during the discussion. This was true 20 years ago, and it’s even truer now that our tools include artificial intelligence, which is often used as a pretext to start the conversation.

