Insinöörivetoiset organisaatiot lähtevät rakentamaa monimutkaisia rakenteita ohjelmistoihin. Syntyy moduuleja, ominaisuusryhmiä ja rakenteita joilla ominaisuuksia pannan päälle tai pois. Eli kohtuuttoman raskaita tapoja yrityksen alkuvaiheeseen, kun ei oikeasti vielä tiedetä paljoakaan todellisesta asiakastarpeesta tai siitä mihin suuntaan tuote lopulta kehittyy.  Tehdään hallintaa ominaisuuksille, jotka ovat myöhemmin turhia (tai lasketaan rahoja, jotka eivät ole tilillä).

Helpoin tapa tuotteistaa monta tuoteversiota onkin täysin toisenlainen. Vaihtoehtoisia tapoja, joita voi käyttää rinnakkain on kaksi ja ne ovat kapasiteettiperusteinen ja kokonaistuoteperusteinen tuotteistaminen. Ne eivät vaadi riviäkään koodia ja molemmilla tavoilla saa luotua tuoteversioita monille eri kohderyhmille ja eri suuruisiin käyttötarpeisiin.

Kapasiteettiin perustuva SaaS-tuotteistus

Kapasiteettiperusteisessa tuotteistamisessa asiakkailla on täysin sama sovellus käytössä, mutta sopimus määrää miten tuotetta voi käyttää. Tämä sopii hyvin SaaS-tuotteisiin, joissa kapasiteetit tai integraatiot ovat isossa osassa.  Yhtiö yksinkertaisesti kertoo, että Tuote A sisältää 100 yksikköä ja tuote B sisältää 500 yksikköä ja jos haluaa yli 100 yksikköä käyttöön, pitää päivittää A:sta B:hen. Asiaa sitten seurataan vaikka kuukausitasolla jollain yksinkertaisella menetelmällä.

Kokonaistuotteeseen perustuva SaaS-tuotteistus

Kuten olemme aikaisemmin kertoneet, toimiva kokonaistuotteistus on hyvä lähtökohta SaaS-liiketoiminnalle. Se tarkoittaa, että asiakkaalle myydään (tai tarjotaan) ydintuotteen lisäksi osana kokonaisuutta laajempi paketti asioita joita asiakas tarvitsee. Näitä ovat mm. käyttöönotto, koulutus ja tukipalvelut. Tässä vaihtoehdossa yhtiö differoi tuoteversiot lisäpalveluiden kautta. Perustuote on siis kaikille sama, mutta tuoteversioissa on erilaiset tai eriarvoiset lisukkeet.

Edelliset voi myös yhdistää ja yhdistämisen ei missään nimessä tarvitse tai pidä olla säännönmukainen, eli jokaisessa portaassa kaikkien asioiden ei tarvitse parantua. Porrastukset pitää toki miettiä huolella ja versiot, skaalautuvat ominaisuudet ja palvelut pitää porrastaa niin, että tuoteversio osuu kohderyhmään ja täyttää sen tarpeet.

Tämä tapa tuotteistaa eri versiot yhdestä ja samasta tuotteesta toimii lähes kaikille SaaS-sovelluksille. Se ei ota kantaa itse tuotteeseen tai sen ominaisuuksiin (tai ainakaan kovin vahvasti). Yleinen vastaväite on, että esimerkiksi käyttäjätilien määrän valvonta pitää koodata tuotteeseen, jotta se olisi automaattista. No toki voi koodata, mutta ei siitä suoraan hyötyä ole, koska ei se asiakkaalle arvoa tuota. Antaa asiakkaiden luoda tilejä, sopimuksessa sitten lukee, että versio muuttuu jos tilien määrä ylittyy (tai laskutus kasvaa).  Eli mieluummin tuotteistuksessa kevyesti liikkeelle ja kehitysfokus tuotteen arvoa luoviin ominaisuuksiin.