42 lines
1.2 KiB
Markdown
42 lines
1.2 KiB
Markdown
---
|
|
tags:
|
|
- note/literature
|
|
- to-review
|
|
relates-to:
|
|
---
|
|
# Retention
|
|
Combien de users continuen d'utiliser le produit.
|
|
|
|
## Métriques
|
|
|
|
Au vu des PARAFs ci dessous, une bonne métrique serait la suivante:
|
|
> Des cohortes hebdomadaires devraient donner une bonne idée de la retention de nos users.
|
|
|
|
### Le jammer
|
|
|
|
![[Jammer#PARAF]]
|
|
|
|
### Le long runner
|
|
|
|
![[Long runner#PARAF]]
|
|
|
|
### Tech noob
|
|
|
|
![[Tech noob#PARAF]]
|
|
|
|
## Engagement
|
|
pour favoriser la retention, on pourra:
|
|
- rajouter un dashboard de gestion de projets, un genre de homepage
|
|
- créer un outil de mise en place d'environnement en local pour favoriser l'onboarding, notamment des [[Tech noob]] et des [[Jammer]]
|
|
- faire la promotion d'autres services comme Coder ou Mattermost
|
|
- Laisser les clés de l'infrastructure au bout d'une longue période prédeterminée (voir [[Business model idea]]), faire payer plus cher pour l'avoir plus tot.
|
|
|
|
## Resurrection
|
|
plutôt que de teardown les environnements, on peut simplement les stopper afin de ne pas perdre ses données et son infrasructure.
|
|
|
|
## Growth loops
|
|
- Passer vérifier la fréquence des releases ou les bonnes pratiques de dev
|
|
- notifier les users des modifications possibles
|
|
|
|
---
|
|
# References |