Une liste de fonctions peut inclure des comptes, des tableaux de bord, des notifications et des rapports sans expliquer pourquoi quelqu’un reviendrait au produit. Le périmètre se précise lorsqu’il suit le travail depuis un besoin initial jusqu’à un résultat utile. Prenons une idée SaaS illustrative : un outil partagé de suivi des demandes d’intervention pour de petites équipes de maintenance de bâtiments. Son premier objectif est de rendre visibles le responsable et le statut actuel de chaque demande. Cet objectif donne à la version une limite concrète.
Sur cette page
Définissez le premier utilisateur et le résultat
Décrivez le premier public par son travail. Dans l’outil de l’exemple, un coordinateur rassemble aujourd’hui les demandes issues de messages, demande des nouvelles à ses collègues et rend compte de l’avancement manuellement. Le résultat utile est une demande avec suffisamment de contexte, une personne désignée et un statut visible. Identifiez qui saisit les informations, qui agit et qui doit voir le résultat. Cela distingue les besoins du coordinateur de la vue du technicien et évite de considérer tous les clients possibles comme le premier public.
- Quel événement crée le besoin d’ouvrir le produit ?
- Que doit terminer l’utilisateur lors d’une session utile ?
- Quelle information le fait revenir pour poursuivre le travail ?
Cartographiez le premier parcours et tracez sa limite
Dans l’exemple, le coordinateur crée un espace de travail, invite un collègue, enregistre une demande et l’attribue. Le collègue ouvre la demande, met à jour son statut et consigne le résultat ; le coordinateur peut le retrouver ensuite. Ces étapes forment un premier parcours cohérent. Décidez comment traiter une mauvaise attribution ou une demande clôturée par erreur. Les rapports avancés, l’affectation automatique et une place de marché publique de prestataires peuvent rester hors de cette version illustrative. Documentez leur report afin qu’une discussion ultérieure ne les transforme pas implicitement en engagements existants.
- Inclure : accès à l’espace de travail, détails de la demande, attribution, statut et historique de base.
- Inclure : les corrections nécessaires pour maintenir le parcours utilisable.
- Reporter : les processus supplémentaires, sauf s’ils comblent une lacune démontrée du premier parcours.
Délimitez le travail nécessaire à l’exploitation du produit
Précisez la responsabilité des comptes, les invitations, la révocation des accès et les informations que chaque rôle peut voir ou modifier. Si des clients distincts utilisent le service, définissez et vérifiez les limites entre leurs espaces de travail. Donnez au support un moyen d’examiner un problème signalé dans le respect des accès convenus. Planifiez les vérifications de reprise et la responsabilité des enregistrements importants. Si les abonnements sont inclus, décrivez les états de facturation et d’accès retenus ; s’ils sont reportés, consignez comment l’accès sera géré dans la première version. Ce sont des décisions produit au même titre que les écrans, pas des détails à remettre au lancement.
- Qui aide un utilisateur qui perd son accès ?
- Qui peut corriger ou rouvrir une demande ?
- Comment l’équipe publie-t-elle des mises à jour et réagit-elle aux défaillances ?
Décidez ce que la version doit vous apprendre
Notez les hypothèses et la manière dont l’équipe les vérifiera. Pour l’outil de suivi, un coordinateur peut-il créer et attribuer une demande sans aide extérieure ? Le collègue comprend-il ce qu’il doit faire ? Le coordinateur retrouve-t-il ensuite un résultat exploitable ? Observez le parcours entier et relevez les endroits où une assistance est nécessaire. Distinguez un échec du processus convenu d’une demande de nouvelle orientation produit. Réexaminez l’affectation automatique lorsque les éléments montrent que l’attribution représente une difficulté réelle pour le premier public, plutôt que parce que la fonction paraît avancée.