Aumentar el valor del software: el poder de la integración de datos externos

No todos los productos son iguales. Algunos productos están «rellenos»: integrar datos externos en el producto es un requisito previo para ofrecer valor al usuario. Si bien esto puede suponer un gran reto inicial para el equipo de desarrollo de software —y ciclos de desarrollo más largos—, puede generar un gran valor para los usuarios finales y barreras de entrada significativas para los operadores tradicionales. Al ser un producto relleno, folk estos retos típicos. Desde el primer día, nos integramos con las fuentes de comunicación e importamos las interacciones de los usuarios (correos electrónicos, eventos del calendario). A los 5000 pilotos en lista de espera, gracias por su paciencia, estamos añadiendo valor día a día. La espera merecerá la pena.

El objetivo de cualquier equipo de producto es crear valor para sus usuarios finales. Los equipos tienen esto presente en cada etapa del proceso de desarrollo. Sin embargo, cada proceso es diferente dependiendo de cómo el producto consolidará los datos y el contenido. Surgen dos familias de productos:

Acerca de los productos vacíos

Estos productos funcionan de forma independiente. Su valor reside en la forma en que el usuario crea contenido en el producto. No hay una integración inicial que condicione la experiencia del usuario. Estos productos existen para contener datos. Se aplica a varias categorías de productos:

• Aplicaciones para tomar notas, por ejemplo, Notion, Slite.

• Aplicaciones de gestión de productos/proyectos, por ejemplo, Asana, Trello, Cycle, Jira.

• Herramientas de presentación, por ejemplo, Pitch.

• Gestores de tareas, por ejemplo, Todoist, Wunderlist, Kairn.

• Herramientas de comunicación, por ejemplo, Slack, Aircall.

Acerca de los productos rellenos

Estos productos solo adquieren valor tras importar, agregar y consolidar datos externos procedentes de otros productos o API. En ese sentido, las integraciones son una piedra angular de la experiencia del usuario y uno de los primeros objetivos de los equipos de desarrollo de productos. Estos productos heredan contenido ya existente e incluyen diversos programas de software para clientes:

• Clientes de comunicación y mensajería, por ejemplo, Front, Superhuman.

• Clientes de calendario, por ejemplo, Sunrise (RIP), Cron.

• Contactar con clientes de gestión, por ejemplo, folk.

• Herramientas de visualización de datos, por ejemplo, Tableau, Data Studio, Forest Admin.

Tras los primeros años de iteraciones de productos, la diferencia entre productos vacíos y llenos tiende a difuminarse, lo que es especialmente cierto en el caso de los productos exitosos. En nuestra economía API emergente, todos los equipos exitosos acabarán desarrollando integraciones.

Sin embargo, en los primeros días, incluso antes de que el producto se adapte al mercado, esta distinción es significativa e impone retos adicionales al equipo de desarrollo.

No todos los productos son iguales: el peligroso camino hacia los productos rellenos

No todos los productos son iguales. Los grandes equipos de producto lo saben. Las desigualdades son diversas y se dan en la complejidad de las características necesarias, la complejidad de la tecnología del producto o la solidez de los productos ya existentes.

El desarrollo de un producto relleno añade obstáculos al proceso inicial de desarrollo de software. Los productos rellenos integran datos de entrada procedentes de diversas fuentes, por lo que, en ese sentido, son clientes. Depender de datos externos plantea tres tipos de retos:

Administración y asuntos legales

Todo comienza con la obtención de los datos. Los datos de entrada no existen en el vacío. Están alojados en una empresa matriz que debería haber desarrollado una API. Para obtener acceso, normalmente hay que pasar por largos procedimientos administrativos y legales antes de cerrar un acuerdo. Tomemos como ejemplo la API de Gmail. Exigen que los productos se sometan a una evaluación de seguridad realizada por terceros que puede costar entre 15 000 y 75 000 dólares. Las soluciones suelen reducirse a invertir tiempo y/o dinero para close asociación. Eso es lo que hicimos con Gmail for folk.

Datos

• Datos heterogéneos: los datos ya están disponibles. Pueden proceder de diversas fuentes. Su estructura varía en función de la fuente. Tomemos como ejemplo a Front, que tuvo que integrar correos electrónicos enviados, mensajes de Twitter, mensajes de WhatsApp, etc. Los equipos de datos deberán asegurarse de que todos los puntos de datos recopilados estén uniformizados.

• Datos duplicados: la existencia de múltiples fuentes de datos también puede dar lugar a duplicados. Según nuestra experiencia, los duplicados generan redundancia. Por lo tanto, es necesario eliminar los duplicados para que cada dato corresponda a una sola ocurrencia.

• Datos inexactos: los datos introducidos también pueden contener errores. Limpiar los datos externos eliminando los puntos de datos inexactos es un requisito previo para ofrecer una buena experiencia.

• Datos irrelevantes: tras integrar estos datos externos, heterogéneos y potencialmente duplicados, es necesario tratarlos de forma que resulten relevantes para el usuario. En los productos vacíos, los datos son generados por los usuarios, por lo que no hay que preocuparse por la relevancia del contenido. Sin embargo, en los productos rellenos, el reto consiste en hacer que sean relevantes.

Para hacer frente a estos retos, será necesario crear un equipo de datos —con conocimientos de ingeniería de datos— y una infraestructura de datos (incluido un lago de datos) para recopilar, alojar y tratar los datos recibidos. Esto también supone un coste adicional que hay que tener en cuenta.

👉🏼 Prueba folk para unificar y deduplicar los contactos del correo electrónico y el calendario, de modo que tu CRM se mantenga limpio y fiable.

Experiencia del usuario

• Confianza: generar confianza entre los usuarios es un proceso tedioso, especialmente en el caso de los productos Filled. Los usuarios están familiarizados con sus propios datos, por lo que hay poco margen para el error cuando se sincronizan con el software. Cualquier pérdida o alteración de datos será fatal para la ya frágil confianza que estás tratando de generar e inevitablemente provocará la pérdida de clientes. La confianza es difícil de generar y fácil de perder.

• Rendimiento: es posible que el producto reciba grandes cantidades de datos. Los equipos de productos completos deberán asegurarse de que la infraestructura pueda soportar la carga que supone importar datos externos, manteniendo al mismo tiempo el rendimiento al más alto nivel.

• Facilidad de búsqueda: con la gran cantidad de datos importados, cada punto de datos debe poder encontrarse fácilmente. Esto crea la necesidad de funciones adicionales, como la categorización y la búsqueda. La facilidad de búsqueda de datos no es un problema para el software cuyo contenido es generado por los usuarios.

Para conquistar sin peligro, triunfamos sin gloria.

Aunque la mayoría de los equipos de desarrollo coinciden en que el camino hacia un producto completo estará plagado de retos, los usuarios finales no son necesariamente conscientes de ello. Sus expectativas respecto al producto no serán menores. Por lo tanto, la calidad general del producto (diseño, velocidad y características) debe mantenerse al más alto nivel para satisfacer a sus clientes.

Teniendo en cuenta todos estos obstáculos, probablemente te preguntarás: ¿por qué demonios lanzamos entonces un producto Filled?

Sí, es una gran empresa. Pero tiene un valor significativo para los usuarios, ya que supone un cambio revolucionario en el producto:

• Menor tiempo de valorización: cuando finaliza la incorporación, el usuario ya tiene todos sus datos en el producto. Los usuarios pueden estar completamente operativos desde el momento en que comienzan a utilizar el producto, a diferencia de los productos vacíos, en los que los usuarios deben introducir contenido progresivamente. En Superhuman, puedes empezar a utilizar el software inmediatamente después de la incorporación, ya que todos tus datos de correo electrónico ya están introducidos.

• Producto basado en datos: desde el primer día, un producto Filled contiene grandes cantidades de datos. Es un terreno muy fértil para crear funciones inteligentes basadas en el análisis de datos. En folk, desde el día en que te registras, podremos detectar tus duplicados, identificar contactos irrelevantes y puntuar las relaciones que tienes con tus contactos en función de tus interacciones con ellos. La incorporación de estas funciones inteligentes causará una gran impresión incluso a tus primeros usuarios. La culminación de un producto basado en datos es la creación de una base de datos «canónica», es decir, aprovechar los mismos puntos de datos utilizados por varios usuarios para proporcionar un efecto de red. Se trata de un proceso complejo, pero que ayudará a crear una ventaja competitiva.

• Única fuente de información veraz: el producto Filled centraliza un conjunto específico de datos (contactos, correos electrónicos, etc.) y se convierte en su principal fuente de información veraz. Cualquier actualización de otros puntos de datos se propagará en el producto Filled. Ahora los usuarios disponen de un software de referencia para realizar una tarea determinada. Por ejemplo, independientemente del canal de comunicación (Twitter, correos electrónicos, Whatsapp, etc.), yo utilizo Front para interactuar con todos mis clientes.

👉🏼 Prueba folk para sincronizar correos electrónicos, eventos del calendario y contactos en una única fuente de información veraz y ponlo en práctica desde el primer día.

Está bastante claro por qué los productos Filled son tan buenos. Los usuarios comprenden rápidamente su valor (¡mejor conversión!) y los adoptarán durante más tiempo, ya que se benefician de una ventaja única en cuanto a datos y de una única fuente de información veraz (¡por lo que se reduce la pérdida de clientes!).

Lo difícil de las cosas difíciles

De los 25 proyectos de startups que hemos lanzado en eFounders, solo unos pocos son productos «completos» por diseño: Mention, Front, Forest Admin y Upflow.

Folk la última incorporación a esta familia. Y al igual que nuestros otros productos «Filled», el desarrollo Folk sus propios retos. Sabiendo que habría obstáculos que superar, decidimos desde el principio mantener los más altos estándares de desarrollo y no comprometer nunca la calidad del producto. Las dificultades pueden haber retrasado nuestro lanzamiento, pero estos esfuerzos no han sido en vano. Si se ejecutan correctamente, las primeras integraciones impulsarán la adopción y crearán un valor de producto revolucionario. Nuestro objetivo es la perfección. Prometemos que la espera merecerá la pena.

Los productos rellenos son difíciles, sí, pero son geniales. El camino puede estar lleno de dificultades, pero ¿no es eso lo difícil de las cosas difíciles?

Preguntas frecuentes

¿Qué es un producto lleno frente a un producto vacío?

Un producto completo aporta valor tras importar y consolidar datos externos mediante integraciones; un producto vacío crea valor a partir del contenido que añaden directamente los usuarios, sin necesidad de integraciones previas.

¿Por qué son importantes las integraciones para los productos envasados?

Desbloquean el valor fundamental del producto importando datos de correos electrónicos, calendarios y otras herramientas. Los equipos deben gestionar el acceso y el cumplimiento normativo, normalizar y deduplicar los datos, y mantener un alto rendimiento para ganarse la confianza de los usuarios.

¿Cómo reducen los productos rellenos el tiempo de amortización en un CRM?

Al sincronizar los contactos, correos electrónicos y eventos existentes durante la incorporación, los usuarios pueden actuar de inmediato. Funciones como la deduplicación, la puntuación y la búsqueda permiten utilizar los datos rápidamente. Un CRM como folk las relaciones y ahora admite la automatización del correo electrónico a través del Asistente de flujo de trabajo, lo que le permite enviar comunicaciones personalizadas y automatizadas activadas por cambios en sus datos.

¿Cuáles son los 4 tipos de API?

API abiertas (públicas) para desarrolladores externos, API de socios compartidas con socios específicos, API internas (privadas) para uso interno y API compuestas que agrupan varias solicitudes en una sola llamada.