Décision avant le code
Une décision avant toute ligne de code.
Pour un nouveau produit qui s’y prête : poursuivre, remodeler ou refuser — par écrit, motivée, sous 48 heures (jours ouvrés). Avant toute ligne de code.
Notre CEO, Mark Prais, la prend. Elle n’est pas vendue et ce n’est pas un rapport : c’est notre décision de prendre ou non votre produit, prise avant que l’un de nous n’engage de l’argent.
La lettre
Une lettre, signée par notre CEO.
48 heures (jours ouvrés)après le premier échange
La décision, les principales raisons et la suite, sur une page. La recherche reste chez nous.
IdéeRéservation et paiement pour cabinets de kinésithérapie indépendants
Notre décision
Notre décision: Remodeler
Les principales raisons
- MarchéLes cabinets paient déjà un logiciel de réservation. L’encaissement et les rendez-vous manqués se gèrent encore à la main.
- ProduitLa première version veut tout faire d’un coup. Les cabinets paieraient d’abord pour l’encaissement et les rappels.
- ArgentUn remplacement complet du logiciel de réservation se vend lentement. Un module qui fonctionne à côté se rentabilise plus vite.
Ce qui changerait la réponse
Une première version avec paiement et rappels, qui fonctionne à côté du logiciel de réservation déjà en place, dans un seul pays.
La suite
Envoyez-nous le périmètre remodelé. Nous répondons sous 48 heures (jours ouvrés) ; si nous poursuivons, un responsable vient avec une offre écrite.
Ce que nous vérifions avant de décider de construire ou non.
Pour un produit qui s’y prête, cela inclut une analyse de marché mondiale menée en interne.
Les huit points que nous examinons
| # | Ce que nous vérifions | Les questions que nous posons |
|---|---|---|
| 01 | Qui est l’utilisateur | Qui a le problème ? Comment le gère-t-il aujourd’hui ? |
| 02 | Qui paie | L’acheteur est-il aussi l’utilisateur ? Que paie-t-il aujourd’hui ? |
| 03 | Quel problème est résolu | Que se passe-t-il pour l’utilisateur si rien ne change ? |
| 04 | Quelles alternatives existent | Que font les gens à la place, y compris utiliser un tableur ou ne rien faire ? |
| 05 | Comment le produit peut acquérir des utilisateurs | Quel canal permet de les toucher, et combien coûte chaque utilisateur touché ? |
| 06 | Si la monétisation peut fonctionner | Le prix, le modèle de paiement et le seuil à partir duquel les chiffres tiennent |
| 07 | Quelle première version a du sens | Quelle est la plus petite version qui teste l’hypothèse la plus risquée ? |
| 08 | Si nous devons le prendre en charge | Sommes-nous prêts à le construire et à l’exploiter avec vous après le lancement ? |
Ce que vous nous envoyez. Un pitch deck ou une note d’une page, le lien vers un prototype s’il en existe un, et tout élément concret sur les utilisateurs ou le marché. Rien de confidentiel.
Pourquoi nous dirions non
Si nous poursuivons, nous investissons notre propre développement dans le produit en échange d’une participation de 30 %, et le groupe l’exploite après le lancement. Un oui que nous ne pourrions pas assumer nous coûterait cher pendant des années. Nous acceptons jusqu’à dix nouveaux Product Partnerships par an.
Pour qui
Les fondateurs et les entreprises qui ont un nouveau produit numérique autonome — une idée, un prototype ou une première version — dès qu’un premier échange montre qu’il peut convenir. Une entreprise existante passe par Annual Product Operations ; un produit en ligne, par Existing Product Review.
Ce que vous recevez, et quand
01
Premier échange
Trente minutes sur votre situation. Un responsable répond à votre demande sous un jour ouvré, en général avec une invitation Google Meet.
02
Évaluation, 48 heures au plus (jours ouvrés)
Nous examinons en interne le marché, le produit et la logique commerciale : qui est l’utilisateur, qui paie, quelles sont les alternatives et si la monétisation peut fonctionner.
03
La décision avant le code, par écrit
Poursuivre, remodeler ou refuser, avec les principales raisons. La recherche reste interne.
Ce qui se passe après chaque issue
Poursuivre
Un responsable vient à une réunion préparée pour votre produit, avec une offre écrite : périmètre, rôles, budget, PI, jalons et structure commerciale.
Remodeler
Nous vous disons ce qui devrait changer — le périmètre, le modèle ou la première version — et pourquoi.
Refuser
Vous l’apprenez avant de dépenser quoi que ce soit en développement, avec les principales raisons. Un « non » avant le développement est la bonne décision la moins chère qui soit.
Ce qu’elle n’est pas
Pas une prestation vendue
C’est notre décision de prendre ou non votre produit, prise avant que l’un de nous n’engage de l’argent.
Pas un rapport
La recherche reste interne ; vous recevez la décision et ses principales raisons.
Pas un développement automatique
Le travail ne commence que selon des conditions écrites, convenues lors de la réunion préparée pour votre produit.
Pas l’avis d’un comité
Une personne nommée la prend : notre CEO, Mark Prais.
Les questions à poser à tout partenaire produit — et nos réponses
Dites-nous sur quoi vous travaillez.
Nouveau produit, processus métier, produit en ligne, subvention ou mise en relation : quelques lignes suffisent pour trouver la suite.
Anton répond sous un jour ouvré. Le formulaire s’ouvre avec ce parcours déjà sélectionné.