Τι Πρέπει — και Τι Δεν Πρέπει — να Περιλαμβάνει το SaaS MVP σας στο Λανσάρισμα

Η λέξη «ελάχιστο» στο minimum viable product είναι το κομμάτι που όλοι αγνοούν. Οι ιδρυτές συμφωνούν με την ιδέα του να ξεκινήσουν μικρά, και μετά παραδίδουν μια προδιαγραφή με σαράντα οθόνες, τρεις ρόλους χρηστών, μια μηχανή χρέωσης, έναν πίνακα αναλυτικών στοιχείων και «α, και πρέπει να ενσωματώνεται με τα πάντα». Αυτό δεν είναι MVP. Αυτό είναι ένα ολοκληρωμένο προϊόν με την αισιοδοξία στο μέγιστο. Και είναι ο πιο συχνός λόγος που τα πρώτα λανσαρίσματα φτάνουν καθυστερημένα, εκτός προϋπολογισμού, και κάπως ακόμα τους λείπει αυτό που πραγματικά ήθελαν οι πελάτες.

Έχω βοηθήσει αρκετές μικρές εταιρείες και ιδρυτές που δουλεύουν μόνοι τους να βγάλουν το πρώτο τους προϊόν λογισμικού. Το τεχνικό κομμάτι σπάνια είναι αυτό που μπερδεύει τους ανθρώπους. Το δύσκολο κομμάτι — κάθε φορά — είναι να αποφασίσεις τι να μην χτίσεις ακόμα. Ένα MVP δεν είναι μια μικρότερη εκδοχή του ονειρεμένου προϊόντος σας με λειτουργίες αφαιρεμένες στην τύχη. Είναι ένα συνειδητό στοίχημα: το μικρότερο πράγμα που μπορείτε να βάλετε μπροστά σε πραγματικούς χρήστες, που αποδεικνύει ότι η βασική ιδέα αξίζει περισσότερα από τα χρήματα και τον χρόνο σας.

Αυτός λοιπόν είναι ο οδηγός που θα ήθελα να διάβαζαν περισσότεροι ιδρυτές πριν γράψουν την προδιαγραφή τους. Χωρίς ορολογία, χωρίς θέατρο «κινήσου γρήγορα και σπάσε πράγματα». Απλώς ένας πρακτικός τρόπος να χαράξετε τη γραμμή ανάμεσα σε αυτό που ανήκει στην πρώτη σας έκδοση και σε αυτό που μπορεί — και πρέπει — να περιμένει.

Τι είναι στ' αλήθεια ένα MVP (και τι δεν είναι)

Ας ξεκαθαρίσουμε τον ορισμό, γιατί από εδώ ξεκινάει η περισσότερη σύγχυση. Ένα MVP είναι η μικρότερη, απλούστερη εκδοχή του προϊόντος σας που επιτρέπει σε έναν πραγματικό άνθρωπο να κάνει το ένα πολύτιμο πράγμα που υπόσχεται το προϊόν σας — και σας επιτρέπει να μάθετε αν θα επιστρέψει για να το ξανακάνει. Αυτό είναι όλο. Είναι ένα εργαλείο μάθησης που τυχαίνει να είναι φτιαγμένο από λειτουργικό λογισμικό, όχι ένα απογυμνωμένο λανσάρισμα του τελειωμένου πράγματος.

Η κρίσιμη λέξη είναι το viable (βιώσιμο). Ένα συνηθισμένο λάθος είναι να διαβάσεις «ελάχιστο» και να κυκλοφορήσεις κάτι τόσο φτωχό που φέρνει αμηχανία στον χρήστη — μια μισή ροή που κρασάρει, μια εγγραφή που οδηγεί σε άδεια οθόνη. Αυτό δεν είναι ελάχιστο-βιώσιμο, είναι ελάχιστο-χαλασμένο. Η άλλη αποτυχία είναι το αντίθετο: ένα προϊόν τόσο «ολοκληρωμένο» που χρειάστηκε έναν χρόνο για να χτιστεί, και μέχρι τότε έχετε ξοδέψει το ταμείο σας αποδεικνύοντας μια υπόθεση που θα μπορούσατε να έχετε δοκιμάσει σε οκτώ εβδομάδες.

Ορίστε το νοητικό τεστ που χρησιμοποιώ. Για κάθε λειτουργία στη λίστα, ρωτήστε: αν την αφαιρούσαμε, θα μπορούσε ο χρήστης να πετύχει το βασικό αποτέλεσμα για το οποίο υπάρχει το προϊόν; Αν η απάντηση είναι ναι, σχεδόν σίγουρα δεν είναι MVP. Αυτή και μόνο η ερώτηση θα κόψει τις περισσότερες προδιαγραφές στη μέση — και το μισό που κόβει είναι αυτό που θα σας έκανε να καθυστερήσετε.

Βρείτε τη μία δουλειά που κάνει το προϊόν σας

Πριν μπορέσετε να αποφασίσετε τι θα χτίσετε, πρέπει να είστε ωμά ξεκάθαροι για τη μία δουλειά που κάνει το προϊόν σας για κάποιον. Όχι το όραμα. Όχι τον οδικό χάρτη. Τη μία επαναλαμβανόμενη ενέργεια που, αν λειτουργήσει, κάνει την ημέρα ενός ανθρώπου καλύτερη και τον κάνει πρόθυμο να πληρώσει. Οι περισσότερες προβληματικές προδιαγραφές είναι αόριστες ακριβώς εδώ — περιγράφουν μια πλατφόρμα, όχι μια δουλειά.

Προσπαθήστε να ολοκληρώσετε αυτή την πρόταση φωναχτά: «Ένας χρήστης έρχεται στο προϊόν μου για να ______, και φεύγει έχοντας ______.» Ένα εργαλείο προγραμματισμού: ένας υπεύθυνος έρχεται να δημοσιεύσει το πρόγραμμα της επόμενης εβδομάδας, και φεύγει με κάθε βάρδια καλυμμένη και την ομάδα ειδοποιημένη. Μια εφαρμογή τιμολόγησης: ένας ελεύθερος επαγγελματίας έρχεται να χρεώσει έναν πελάτη, και φεύγει με ένα σταλμένο, παρακολουθήσιμο τιμολόγιο. Αν δεν μπορείτε να συμπληρώσετε καθαρά αυτή την πρόταση, δεν είστε έτοιμοι να καθορίσετε το εύρος — είστε ακόμα έτοιμοι να σκεφτείτε.

Τι χρειάζεται πραγματικά κάθε SaaS MVP

Κάποια πράγματα είναι αδιαπραγμάτευτα, ακόμα και στην πιο λιτή πρώτη έκδοση — όχι επειδή είναι συναρπαστικά, αλλά επειδή χωρίς αυτά το προϊόν είτε δεν μπορεί να χρησιμοποιηθεί είτε δεν μπορεί να σας μάθει τίποτα. Σκεφτείτε τα ως το δάπεδο, όχι ως την οροφή. Χτίστε τα απλά, αλλά χτίστε τα σωστά.

• Έναν τρόπο σύνδεσης. Ακόμα και μια απλή σύνδεση με email και κωδικό αρκεί — αλλά πραγματική και ασφαλής, γιατί όλα τα υπόλοιπα εξαρτώνται από το να ξέρετε ποιος είναι ο χρήστης.
• Τη βασική ροή εργασίας, από άκρη σε άκρη. Τη μία δουλειά, από το πρώτο κλικ του χρήστη μέχρι τη στιγμή που παίρνει το πολύτιμο αποτέλεσμα — χωρίς αδιέξοδα, χωρίς κουμπιά «έρχεται σύντομα» στην κρίσιμη διαδρομή.
• Κάπου να ζουν πραγματικά τα δεδομένα. Πραγματική αποθήκευση, όχι ένα πρωτότυπο μιας χρήσης, ώστε η δουλειά ενός χρήστη να επιβιώνει από μια ανανέωση και να μπορεί να επιστρέψει αύριο.
• Έναν τρόπο για να βλέπετε τι συμβαίνει. Βασική καταγραφή ή μια απλή προβολή διαχειριστή, ώστε όταν κάτι χαλάει — και θα χαλάσει — να μπορείτε να βρείτε γιατί χωρίς να μαντεύετε.
• Έναν τρόπο για να σας βρίσκουν οι χρήστες. Έστω και ένας σύνδεσμος email. Οι πρώτοι χρήστες θα συναντήσουν άκρες που δεν προβλέψατε· τους θέλετε να σας το λένε, όχι να φεύγουν σιωπηλά.
• Το ελάχιστο ελάχιστο εμπιστοσύνης: μια σημείωση απορρήτου, λογική διαχείριση δεδομένων, και να μην κάνετε τίποτα απερίσκεπτο με τις πληροφορίες των ανθρώπων.

Προσέξτε τι δεν είναι σε αυτή τη λίστα: χρέωση, εντυπωσιακό onboarding, σελίδες ρυθμίσεων, εφαρμογές κινητού, ενσωματώσεις. Θα φτάσουμε στο γιατί σε λίγο. Το νόημα του δαπέδου είναι ότι είναι αρκετά μικρό για να ολοκληρωθεί και αρκετά στέρεο για να μάθετε από αυτό. Μια σύνδεση που λειτουργεί, μία ροή εργασίας που αποδίδει, πραγματικά δεδομένα, και έναν τρόπο να παρακολουθείτε και να μιλάτε στους χρήστες. Αυτό είναι ένα βιώσιμο προϊόν.

Τι να αφήσετε σκόπιμα έξω από την v1

Αυτή είναι η ενότητα στην οποία αντιστέκονται οι ιδρυτές, οπότε ας είμαι ξεκάθαρος: τα περισσότερα από τα πράγματα που μοιάζουν απαραίτητα για το πρώτο σας λανσάρισμα δεν είναι. Μοιάζουν απαραίτητα επειδή ένα «πραγματικό προϊόν» τα έχει — αλλά δεν χτίζετε ακόμα ένα πραγματικό προϊόν, χτίζετε μια ερώτηση. Το να τα αφήσετε έξω δεν είναι κόψιμο γωνιών. Είναι ολόκληρη η πειθαρχία ενός MVP.

Αυτοματοποιημένη χρέωση και περίπλοκη τιμολόγηση

Σχεδόν σίγουρα δεν χρειάζεστε μια μηχανή αυτοεξυπηρετούμενης χρέωσης, κλιμακωτά πακέτα, αναλογική χρέωση και λογική dunning στην πρώτη έκδοση. Αν οι πρώτοι χρήστες θέλουν να πληρώσουν, μπορείτε να πάρετε τα χρήματά τους χειροκίνητα — ένα τιμολόγιο, έναν σύνδεσμο πληρωμής, ένα γρήγορο τηλεφώνημα. Η χειροκίνητη χρέωση για τους πρώτους δέκα πελάτες σας λέει κάτι που η αυτοματοποιημένη χρέωση δεν μπορεί: αν θα πληρώσει κανείς καθόλου. Χτίστε τη μηχανή αφού αποδείξετε ότι υπάρχουν χρήματα να μαζέψετε.

Περίπλοκοι ρόλοι και δικαιώματα

Τα συστήματα δικαιωμάτων πολλαπλών ρόλων — διαχειριστές, υπεύθυνοι, θεατές, λεπτομερείς κανόνες πρόσβασης — είναι ένας πραγματικός μηχανικός βάλτος, και πολλαπλασιάζουν τεράστια την επιφάνεια ελέγχου. Για μια πρώτη έκδοση, ένα είδος χρήστη είναι σχεδόν πάντα αρκετό. Θα μάθετε τις πραγματικές ανάγκες δικαιωμάτων παρακολουθώντας πραγματικές ομάδες να χρησιμοποιούν το πράγμα, και αυτές οι ανάγκες σπάνια είναι αυτό που θα μαντεύατε στα χαρτιά.

Ενσωματώσεις, εγγενείς εφαρμογές κινητού, και ο πίνακας ελέγχου

«Πρέπει να ενσωματώνεται με τα πάντα» είναι η φράση που αθόρυβα διπλασιάζει τα χρονοδιαγράμματα. Διαλέξτε το πολύ μία ενσωμάτωση, και μόνο αν είναι μέρος της βασικής δουλειάς. Οι εγγενείς εφαρμογές iOS και Android μπορούν σχεδόν πάντα να περιμένουν — μια responsive web εφαρμογή λειτουργεί σε ένα κινητό σήμερα. Και ο πίνακας αναλυτικών στοιχείων που θέλουν όλοι; Οι χρήστες δεν μπορούν να αναλύσουν δεδομένα που δεν έχουν δημιουργήσει ακόμα. Κυκλοφορήστε πρώτα το πράγμα που δημιουργεί τα δεδομένα· οπτικοποιήστε τα μόλις υπάρχει κάτι να δείξετε.

Μια απλή μέθοδος για να χαράξετε τη γραμμή

Το να γνωρίζεις την αρχή είναι ένα πράγμα· το να την εφαρμόσεις στη δική σου προδιαγραφή, όπου κάθε λειτουργία μοιάζει με το παιδί σου, είναι πιο δύσκολο. Ορίστε μια μέθοδος που λειτουργεί επειδή επιβάλλει μια απόφαση για κάθε στοιχείο αντί να αφήνει τα πάντα να ξεγλιστρούν στο «απαραίτητο».

1. 1
   Καταγράψτε κάθε λειτουργία που έχετε φανταστεί

   Ξεχύστε τα όλα — χωρίς φιλτράρισμα ακόμα. Βάλτε όλη τη λίστα ευχών στο τραπέζι, ώστε τίποτα να μην παραμονεύει ανείπωτο και να επανεμφανιστεί μέσα στο χτίσιμο ως έκπληξη.
2. 2
   Σημειώστε κάθε μία απέναντι στη βασική δουλειά

   Για κάθε λειτουργία, ρωτήστε: χρειάζεται ο χρήστης αυτό για να ολοκληρώσει τη μία βασική δουλειά, από άκρη σε άκρη; Σημειώστε την «βασική», «χρήσιμη» ή «κάποτε». Να είστε ειλικρινείς — οι περισσότερες πέφτουν στις δύο τελευταίες.
3. 3
   Κρατήστε μόνο τις «βασικές» για την v1

   Το MVP σας είναι ο σωρός των «βασικών» και τίποτα άλλο. Οι σωροί «χρήσιμη» και «κάποτε» δεν απορρίπτονται — είναι ο οδικός σας χάρτης, παρκαρισμένος εκεί που ανήκει.
4. 4
   Ελέγξτε τη λογική του κοψίματος

   Δείτε τι έμεινε και ρωτήστε: μπορεί ένας πραγματικός χρήστης να πάρει πραγματική αξία μόνο από αυτό; Αν ναι, έχετε καθορίσει το εύρος ενός MVP. Αν κάτι πραγματικά σπάει τη βασική ροή, τραβήξτε πίσω μόνο αυτό το ένα στοιχείο — και τίποτα άλλο.

Η πειθαρχία βρίσκεται στο τέταρτο βήμα. Υπάρχει πάντα ο πειρασμός να «τραβήξεις πίσω άλλο ένα πράγμα», και μετά άλλο, μέχρι να έχεις αθόρυβα ξαναχτίσει το ολοκληρωμένο προϊόν. Επιτρέψτε στον εαυτό σας να διασώσει μόνο στοιχεία που πραγματικά σπάνε τη βασική ροή — όχι στοιχεία που απλώς θα την έκαναν πιο όμορφη. Το πιο όμορφο είναι για τη δεύτερη έκδοση.

Το βιώσιμο σημαίνει ότι πρέπει να μοιάζει αληθινό

Υπάρχει ένας τρόπος αποτυχίας στην άλλη πλευρά της γραμμής, και αξίζει να τον ονομάσουμε. Στη βιασύνη να κυκλοφορήσουν κάτι μικρό, κάποιοι ιδρυτές κυκλοφορούν κάτι πρόχειρο — και το ονομάζουν MVP. Μια βασική ροή που χάνει τη δουλειά σας, μια εγγραφή που δίνει 404, κείμενο γεμάτο placeholder. Αυτό δεν δοκιμάζει δίκαια την ιδέα σας· δοκιμάζει αν οι χρήστες θα ανεχτούν μια χαλασμένη εμπειρία, και η απάντηση είναι πάντα όχι. Θα συμπεράνετε ότι απέτυχε η ιδέα ενώ στην πραγματικότητα απέτυχε η εκτέλεση.

Το «ελάχιστο» αφορά το εύρος, ποτέ την ποιότητα του κομματιού που κρατάτε. Λιγότερες λειτουργίες, καθεμία στέρεη. Η μία ροή εργασίας που κυκλοφορείτε πρέπει να μοιάζει τελειωμένη — γρήγορη, καθαρή και αξιόπιστη — ακόμα κι αν είναι το μόνο πράγμα που κάνει το προϊόν. Ένα στενό προϊόν καλοφτιαγμένο νικάει ένα ευρύ προϊόν κακοφτιαγμένο κάθε φορά, ειδικά όταν ζητάτε από αγνώστους να σας εμπιστευτούν τη δουλειά τους.

Το MVP δεν είναι η γραμμή τερματισμού — είναι η πρώτη ένδειξη

Ορίστε το κομμάτι που αλλάζει την οπτική των πάντων: το λανσάρισμα δεν είναι ο στόχος. Ο στόχος είναι αυτό που μαθαίνετε τις εβδομάδες μετά. Ένα MVP που κυκλοφορεί και σας λέει «οι χρήστες λατρεύουν το βασικό αλλά συνεχίζουν να ζητούν το Χ» είναι μια τεράστια επιτυχία — ακόμα κι αν το Χ σημαίνει έναν μήνα ακόμα δουλειάς. Ένα MVP που κυκλοφορεί στη σιωπή, χωρίς κανέναν να επιστρέφει, έχει επίσης κάνει τη δουλειά του: σας έσωσε από το να χτίσετε τις άλλες τριάντα λειτουργίες πάνω σε ένα θεμέλιο που δεν ήθελε κανείς.

Σχεδιάστε λοιπόν τις πρώτες εβδομάδες τόσο σκόπιμα όσο και το χτίσιμο. Παρακολουθήστε τι κάνουν πραγματικά οι άνθρωποι, όχι τι λένε στις έρευνες. Μιλήστε με αυτούς που επέστρεψαν και με αυτούς που δεν επέστρεψαν. Αφήστε την πραγματική χρήση — όχι την αρχική σας προδιαγραφή — να αποφασίσει τι θα μπει στη δεύτερη έκδοση. Ο οδικός χάρτης που παρκάρατε νωρίτερα δεν είναι υπόσχεση· είναι μια υπόθεση, και οι χρήστες σας είναι έτοιμοι να τη βαθμολογήσουν.

Συχνές ερωτήσεις