Gran pregunta: probablemente podrías escribir un libro completo sobre esto. De hecho, he tenido el privilegio de administrar no solo productos de software empaquetados / locales y SaaS, sino también ofertas en medio de una transición de paquetes a SaaS. Permítanme centrar mi respuesta en las diferencias, ya que esas son a menudo las que tienden a disparar a los PM que están en transición de uno a otro.
Desarrollo de productos:
1. Ritmo de desarrollo:
Sin lugar a dudas, el ritmo de desarrollo en SaaS siempre parece mucho más alto que para el software empaquetado. En el caso de software empaquetado, los clientes a menudo tienden a alinear recursos, presupuestos, etc. para prepararse para una actualización de la versión, por lo que existe un entendimiento no escrito de que cualquier implementación de nuevas funciones o corrección de defectos (a menos que sea crítica) no funcionará vive de inmediato Incluso si el software empaquetado se puede actualizar sobre la marcha mediante mecanismos de actualización en vivo / actualización automática, siempre existen problemas específicos del entorno del cliente que les impiden aprovechar al máximo estas capacidades y aceptar parches / correcciones de inmediato. Esto es muy diferente en el caso de SaaS, ya que la función / corrección se puede implementar rápidamente a través de los procesos de CI / CD del proveedor y las dependencias en el entorno del cliente tienden a ser mucho menores (siempre hay excepciones, especialmente en casos en que hay importantes integración entre el SaaS y la infraestructura del cliente).
2. Complejidad del desarrollo:
La mayoría de los software empaquetados que tienen una huella significativa en la empresa a lo largo del tiempo terminarán admitiendo múltiples plataformas de servidor (Windows, Linux, Unix). El soporte de todas estas plataformas a menudo puede ser una tarea desafiante para el desarrollo, control de calidad, soporte, etc. y agregar riesgos y esfuerzos sustanciales al proceso de desarrollo. Esta complejidad puede afectar la definición de su producto (qué plataformas admitir, por ejemplo), así como su capacidad de ejecución como PM.
- Si tuviera un presupuesto mensual de marketing de $ 25K para gastar en la adquisición de 100 clientes de pago para su aplicación SaaS, ¿en qué lo gastaría?
- Cómo construir una empresa de software SAAS desde cero sin habilidades de codificación
- Si una parte interesada en una posible empresa de SaaS empresarial (que probablemente firme) le pide que reduzca su tarifa de instalación y aumente la tarifa mensual para compensar, ¿cómo debe manejar esto?
- Cómo dar cuenta de los clientes que pagan por adelantado por SaaS
- ¿Qué piensan los desarrolladores del programa $ rev de Box?
Operaciones de producto:
1. Conjuntos de habilidades de Ops:
Hay un conjunto de habilidades críticas que la mayoría de las compañías SaaS necesitarán desde un punto de vista operativo, que las compañías de software empaquetadas no han visto una necesidad generalizada de DevOps. Los ingenieros de DevOps, en términos muy crudos, poseen la doble habilidad de ser desarrolladores fuertes, así como ingenieros de sistemas. Este rol, que a menudo no se requiere en el grupo de ingeniería de una compañía de software empaquetada convencional, es indispensable para un equipo de ingeniería / operaciones de SaaS.
2. Soporte del producto:
Esto es similar al ritmo del punto de desarrollo que mencioné anteriormente: las correcciones y parches en SaaS a menudo se pueden implementar de inmediato, lo que agrega una urgencia sustancial a su organización de soporte de productos y obliga a una mayor / mejor comunicación entre ingeniería y soporte.
3. Metodología de implementación:
Como primer ministro, es posible que necesite conocer y tomar decisiones (con el apoyo del arquitecto) sobre los tipos de implementaciones de SaaS que debe considerar (por ejemplo, Canary vs. Blue-Green) ya que pueden tener un impacto significativo en su capacidad y costo para servir a los clientes.
Ir al mercado:
Precios:
Para el software empaquetado, el costo marginal de una unidad adicional de software (basado en cualquier métrica) a menudo tiende a ser mucho más bajo, y en su mayoría comprende su costo para soportar esa unidad adicional. Por otro lado, para SaaS, hay un costo marginal real significativo (costo de servicio) por cada unidad adicional de licencia SaaS vendida. En consecuencia, en mi observación, el comportamiento de descuento para el software empaquetado tiende a ser mucho más agresivo que para SaaS. Además, aunque el software empaquetado siempre se puede vender por suscripción, he visto que se vende principalmente con una licencia perpetua + mantenimiento anual. Como consecuencia, hay un enfoque enorme en conceptos como “tiempo para valorar” cuando se trata de SaaS.
Estrategias de integración de socios:
Por lo general, la mayoría del software empaquetado / local en el pasado (que está cambiando) ha tenido “ecosistemas cerrados” donde una forma estándar para que los socios se integren con ellos sería a través de la integración de la capa de datos, ya que los almacenes de datos tienden a ser locales . El impulso para crear API para permitir la integración de socios tiende a ser menor. Sin embargo, para SaaS, la única forma real en la que puede integrarse es a través de API. Como consecuencia, las estrategias de integración de socios requieren la construcción de una estrategia API.
De ninguna manera es una respuesta exhaustiva, pero estos son algunos puntos que pueden servir como punto de partida para pensar en paquetes vs. SaaS. Dicho esto, lo que Cliff Gilley dice a continuación es en gran medida cierto, ya que la mayoría de los proveedores de software empaquetado de la actualidad aprovechan SaaS de alguna manera (características de actualización automática, licencias y medición, etc.). Espero que esto ayude.
