Lanzamiento de TranslatePress: del concepto al producto

Cuando lanzas un nuevo proyecto siempre hay un murmullo de emoción, esperanza, alivio, pero también miedo al fracaso y a la decepción.

Esto es algo que he experimentado en todos los proyectos de los que he formado parte en los últimos 9 años, hasta el punto de que espero activamente el primer lanzamiento fallido.

Nada revela más lo anterior que los comentarios que hemos recibido de los usuarios que actualmente utilizan nuestro TranslatePress complemento.

Esperanza: Ya estamos usando su complemento gratuito. Nos gustaría comprarlo más tarde.
Miedo al fracaso: Si funciona con el plugin que gestiona las reservas en nuestro sitio.

Luego está el número abismal de instalaciones activas después de enviar más de 7 mil correos electrónicos a clientes anteriores. Menos de 10 durante las primeras dos semanas.

Pero esta no es la historia de algo que parece el lanzamiento fallido de un producto (más sobre esto más adelante).

En su lugar, voy a remontarme a diciembre de 2016 y empezar a explicar casi todo lo que hemos vivido en los últimos 8 meses con motivo del lanzamiento de TranslatePress, desde el concepto inicial hasta un plugin totalmente nuevo que te permite traducir un Sitio web de WordPress en más idiomas.

Revisaré:

• por qué un nuevo complemento de traducción y cómo se nos ocurrió la idea
• asignar recursos de desarrollo y decidir un plazo
• exceder el plazo en casi 2,5 veces y los motivos de ello
• crear un logotipo y algo que se parezca a una marca rápidamente
• decidiendo cómo se monetizará el complemento
• implementando un sitio completamente nuevo, configurando pagos y licencias
• lanzando la versión beta del plugin y trabajando en una nueva característica
• marketing
• Conclusiones

¡Construyamos un plugin, dijeron! ¡Será divertido, dijeron!

Como cada fin de año, tenemos una reunión con el resto del equipo en Cozmoslabs sobre lo que funcionó en ese año, lo que fracasó por completo y las cosas que esperamos con ilusión el próximo año.

Mi colega Razvan Mocanu quería trabajar en un proyecto completamente nuevo. Un nuevo plugin. Así que tomamos nota mental, nos fuimos de vacaciones de Navidad y regresamos en enero con una única buena idea en la que realmente queríamos trabajar: un plugin de traducción para WordPress que cualquiera pueda usar.

Aunque esto parece algo arbitrario, no lo es realmente:

• como desarrolladores de plugins, hemos tenido que lidiar con plugins de traducción desde el primer día (ahora mismo tenemos compatibilidad con WPML en todo nuestro complementos)
• antes de pasarnos al desarrollo de plugins, éramos una agencia de desarrollo a medida que implementaba WPML para varios clientes (nos funcionaba a nosotros como desarrolladores, casi nunca al cliente final)
• realmente no nos gustaba el flujo de trabajo de traducción de casi todos los plugins de traducción del mercado. (No visual, fuera de contexto, encontrado en múltiples lugares)
• sabíamos que no queríamos hacer un clon de WPML ni trabajar con instalaciones Multisitio

Así que el único otro plugin existente en el mercado que hacía algo diferente era WeGlot. Una implementación de Software como Servicio que ofrece traducción automática y manual. Básicamente, la traducción de su sitio se carga desde sus servidores.

De la combinación de los complementos e ideas anteriores, ideamos un concepto similar a WeGlot, pero bastante diferente en su implementación:

Traduce la página completa. No más cambios entre el editor, las interfaces de traducción de cadenas o plugins mal traducidos. Ahora puedes traducir la página final con total compatibilidad para WooCommerce y creadores de sitios web.

La diferencia principal está en la implementación:

• soporte para cadenas dinámicas ( cadenas de gettext )
• todo almacenado localmente, en tu base de datos (tú eres dueño de tus traducciones)
• un plugin bajo la GPL (acceso al código base en caso de que necesites algo diferente)
• un deseo de hacer que nuestro plugin funcione con cualquier plugin o tema de WordPress y no al revés, donde los desarrolladores necesitan añadir soporte para plugins de traducción

Estimaciones de desarrollo

En enero, mi compañero Madalin Ungureanu comentó que había probado el núcleo del plugin, una clase de analizador DOM de PHP, para ver si podíamos trabajar con ella. Funcionó bastante bien: podíamos realizar búsquedas y sustituciones de cadenas en la base de datos sin ralentizar el sitio de pruebas, así que decidimos seguir adelante con el proyecto. Razvan iba a ser el desarrollador principal y se encargaría de entregar las versiones alfa y beta, momento en el que destinaríamos más recursos al proyecto. Aunque no era lo ideal, era lo único que podíamos hacer sin contratar a más gente.

3 meses. Tengamos una versión alfa/beta en abril. En julio empezamos las pruebas internas e impulsamos un lanzamiento beta. El 31 de julio pusimos la beta disponible para descarga. El lanzamiento final fue el 4 de septiembre, más de 5 meses por encima de nuestra estimación.

También he llegado a esperar que las tareas de desarrollo de software tarden más de lo esperado

Al igual que con el lanzamiento lento, también he llegado a esperar que las tareas de desarrollo de software tarden más de lo esperado.

Hay algunas excepciones a la regla, pero eso suele ser al final de un ciclo de desarrollo, cuando el problema ya estaba bien definido y comprendido, no requería más investigación y todo lo que quedaba era escribir el código.

Entonces, ¿por qué tomó más tiempo del estimado?

• Obviamente hemos subestimado el tiempo necesario. De verdad no sabíamos cuánto iba a tomar.
• El plazo de 3 meses se impuso más por razones prácticas. No empujes el proyecto hacia la temporada de vacaciones de verano. (lo hicimos)
• Razvan sigue siendo un desarrollador junior y este fue su primer gran proyecto en la empresa. Si bien hubo bastantes discusiones sobre la dirección del desarrollo y la implementación, el código real escrito por cualquier otra persona del equipo en las primeras etapas del proyecto fue muy escaso. Por lo tanto, el progreso fue lento.
• una vez que comencé a probar el plugin en junio, nada funcionó. En mi instalación al menos. Si bien Razvan intentó generalizar lo más posible el problema (reemplazo rápido de cadenas), rápidamente nos quedó claro que había muchos más casos límite de los que habíamos previsto y presupuestado.

Diseño de logotipos rápido

Mientras se desarrollaba el plugin, concentré mi atención en el diseño de un nuevo logotipo y combinación de colores para nuestro futuro sitio web.

De ningún modo soy diseñador gráfico, pero me defiendo moviendo píxeles en Photoshop. Conozco mis límites y no me importa combinar cuadrados, rectángulos y círculos para conseguir algo aceptable. No brillante, pero aceptable. Así que destiné unas pocas horas y se me ocurrieron 4 propuestas (que van desde infantiles hasta más o menos aceptables) que les he mostrado al resto del equipo.

Nos decidimos por la última y seguimos adelante con la diseño del sitio.

En total, probablemente había 3 a 4 días de trabajo reales distribuidos en un par de meses para obtener todos los gráficos y el diseño que necesitábamos para el lanzamiento. El tema era un clon del mismo tema personalizado que hemos estado usando en www.cozmoslabs.com Así que hemos dedicado el menor tiempo posible a sacar esto adelante.

Aunque el diseño es muy importante, sacarlo adelante con una inversión mínima lo era aún más. El diseño de Cozmoslabs fue el resultado de 4 meses de trabajo con un diseñador (con muchos tira y afloja) y otros dos meses implementándolo en su totalidad. Simplemente no podíamos permitirnos hacer esto en esta etapa. Así que hicimos algo bien y seguimos adelante.

Monetización

Desde el principio decidimos que habría una versión gratuita y Versiones Pro. Tanto nuestras propias experiencias anteriores como las de otros desarrolladores de plugins de la comunidad de WordPress nos dejaron claro que ese era el camino a seguir.

Lo que no estaba tan claro es cómo debíamos diferenciar las versiones. Las cosas que consideramos que debían formar parte de las versiones Pro fueron:

• traducción de tipos de contenido personalizado;
• varios idiomas;
• API Google Translate;
• Módulo de SEO (traducción de slug, título de página y descripción).

Al final decidimos incluir el Módulo SEO y Varios Idiomas en las versiones Pro, además de una diferenciación basada en el número de instalaciones activas.

Además de esto:

• cada nivel de precios es por 1 año, con renovación automática;
• Las versiones Pro solo incluyen los complementos avanzados. Por lo tanto, siempre será necesaria la versión gratuita.

Lanzamiento de TranslatePress: nueva página web, configuración de pagos y licencias

Para poder vender nuestro nuevo complemento, hemos intentado que sea lo más sencillo posible, por lo que hemos utilizado Easy Digital Downloads y Digital Licenses para EDD.

Desafortunadamente, para que nuestra configuración funcione necesitábamos trabajo personalizado:

• nuestra pasarela de pago Avangate (programada a medida porque la API de Avangate es un poco rara)
• renovaciones automáticas de Avangate (no podemos utilizar EDD para esto, sino una solución programada a medida)
• licencias digitales para un producto de tipo “paquete”, de modo que una sola licencia sea válida para todos los complementos del “paquete” (esto no funciona con EDD)

Queríamos utilizar el complemento «All Access Pass» para EDD, que resolvía el problema de las licencias digitales para los paquetes, pero no nos funcionó porque:

• Si tienes un Pase de Acceso Total, no puedes comprar otro, solo ampliar el período de licencia.
• Esto provocó que dejaran de funcionar nuestras renovaciones automáticas personalizadas (debido a la forma en que Avangate gestiona las renovaciones automáticas)
• también rompió las actualizaciones porque, de nuevo, las actualizaciones son personalizadas debido a Avangate.

Así que terminamos programando a medida un complemento para EDD que funciona más o menos como All Access Pass (el código está básicamente tomado del complemento), pero sin la parte de All Access 🙂

Aparte de eso, el tema fue reciclado de Cozmoslabs como se mencionó antes y nosotros usamos el nuestro Profile Builder Pro plugin para la funcionalidad de inicio de sesión, edición de perfil y restablecimiento de contraseña.

Lanzamiento beta

Una forma de generar expectación en torno a un producto es lanzar una versión beta. Aunque hay otras razones para lanzar una versión beta (como la notificación de errores), lo que he observado con otros complementos en el pasado es que El principal beneficio es la posibilidad de hablar de tu producto incluso si todavía no funciona. 🙂

Aunque su enfoque es un poco superficial, no deja de ser otra herramienta de marketing que se puede utilizar. Y, como ventaja adicional, también hemos recibido un par de informes de errores y sugerencias de funciones que nos han dejado claro que nos faltaba algo fundamental en la versión beta: no había compatibilidad con los campos gettext.

El soporte para campos gettext era una de las grandes funciones que queríamos introducir DESPUÉS del lanzamiento. Sin embargo, al jugar cada vez más con el complemento y escuchar lo que nuestros usuarios beta tenían que decir al respecto, asumimos el riesgo y comenzamos a trabajar en esta función justo después del lanzamiento de la versión beta del complemento.

Este es uno de los mayores errores que podríamos haber cometido desde el punto de vista del desarrollo y una de las razones por las que tardamos tanto en lanzar la versión 1.0. Retrasamos el soporte para gettext porque era difícil de implementar.

Una historia divertida sobre cómo empezamos es que, tras el lanzamiento de la beta, tuvimos un corte de energía de una hora en la oficina. Mientras esperaba a que volviera la luz, empecé a limpiar mi teclado. De todos modos no había nada mejor que hacer, así que le saqué una foto al teclado, quité todas las teclas y procedí a limpiarlas una por una con un poco de alcohol isopropílico y un trapo.

Y durante las siguientes 2 horas, limpié mi teclado y creé un mapa mental de la implementación de gettext en WordPress, cómo nuestro plugin traducía cadenas y cómo podríamos combinar ambos sin entrar en problemas de rendimiento más adelante.

Después de eso, tuve una breve discusión con Madalin sobre gettext, decidimos que deberíamos hacerlo ahora, antes del lanzamiento de la versión 1.0 y él se puso a trabajar en ello.

Hay un par de conclusiones que se pueden extraer de esta historia:

• es una mala idea retrasar funciones complicadas sin una buena razón. Sabíamos que iba a ser complicado, por eso lo retrasamos tanto tiempo;
• si bien las 2 horas pensando en gettext no hicieron absolutamente nada en términos de tiempo de desarrollo real (a Madalin le tomó 1 mes de trabajo hacerlo funcionar y ahora está en su segundo mes lidiando con wp_ajax y gettext), fue infinitamente mejor que no pensar en ello en absoluto. Era lo que necesitábamos para decidir y salir del bloqueo.

Para promocionar la versión beta, nosotros:

• escribió un artículo beta que también está optimizado para SEO para “WordPress en Más Idiomas”(no tiene sentido escribir más de 2000 palabras sin esperar en el futuro un poco de tráfico SEO).;
• envió un boletín informativo a nuestros clientes actuales en Cozmoslabs sobre el nuevo complemento;
• contaba con formularios adecuados de “Inscripción en la beta” en la página web de TranslatePress;
• dos semanas después del lanzamiento de la beta, pedimos comentarios a las 100 personas que se inscribieron en la beta (para esto usamos Mailchimp);
• durante otras dos semanas, publicamos anuncios en Facebook que aumentaron nuestros evaluadores beta a 160.

Versión 1.0

Nos llevó un mes de desarrollar → prueba → arreglar ciclos para hacer que la implementación de gettext funcione para cadenas renderizadas por PHP (plantillas de páginas normales).

Todavía no teníamos compatibilidad con gettext para las llamadas wp_ajax, pero Era importante lanzarlo ahora y no más tarde:

• Si hubiéramos retrasado la finalización de todo, habríamos perdido tiempo para la comercialización (o al menos para ver qué funciona y qué no). Si no hay producto, no podemos hablar del producto;
• podríamos haber perdido la oportunidad de patrocinar WordCamp Bucarest eso ocurre en octubre;
• una vez que el sitio web, la pasarela de pagos, las licencias, el soporte y la documentación estén listos, lo único que nos queda es trabajar EN el producto.

Marketing

Desde el lanzamiento de la beta, empezamos a pensar en comercializar el complemento.

Un modelo de negocio freemium significa que dependemos de un gran número de usuarios gratuitos e instalaciones activas.

Con un nuevo plugin, eso es mucho más difícil de lo que podrías pensar, particularmente con el nuevo directorio de WordPress que tiene en cuenta las instalaciones activas, las reseñas, el número de preguntas respondidas en los foros y otros elementos cuantitativos sobre los cuales no tenemos control.

Por lo tanto, nuestros esfuerzos se dirigieron a ponernos en contacto con tantos administradores de WordPress como fuera posible: 

• Hemos añadido promoción cruzada en nuestros otros complementos (TranslatePress puede traducir nuestros otros complementos, por lo que lo hemos incluido en nuestra sección de complementos recomendados);
• añadimos la descarga gratuita a la página de la cuenta de todos nuestros clientes en Cozmoslabs;
• se puso en contacto con ThemeIsle Añadir TranslatePress a la lista de plugins recomendados, ya que funciona muy bien para traducir sus temas complejos (estamos utilizando Hestia para nuestro sitio de demostración);
• patrocinar WordCamp Bucarest y poder hablar con usuarios potenciales cara a cara.

Todo este esfuerzo es especialmente importante al principio para ganar un poco de visibilidad y que TranslatePress aparezca en los resultados de búsqueda de WordPress.org.

Intentamos ser lo menos intrusivos posible, si es que eso existe. No usamos avisos que aparecen en todas las páginas del panel de control ni enviamos boletín tras boletín a nuestros clientes existentes (solo dos para la beta y el lanzamiento de la Versión 1.0).

Futuros planes de marketing:

• planeamos crear tutoriales para muchos temas populares y cómo traducirlos (gracias Ionut);
• continuar con nuestros esfuerzos de divulgación hacia los desarrolladores de complementos y temas. Queremos añadir soporte para plugins, no que los plugins tengan que añadir soporte para nosotros;
• El marketing de contenidos para varios idiomas es difícil porque no apareceremos en los primeros puestos de los motores de búsqueda. Al menos no al principio. Así que, aunque estaremos activos en este frente, no es muy importante para nosotros ahora.

Conclusiones del lanzamiento de nuestro programa TranslatePress

Lo principal que quiero destacar de este proceso de 8 meses, es que no es el final del camino. La falta de interés al principio es normal. Pocas o ninguna descarga es normal. Poco o ningún comentario es normal.

En lugar de preocuparme por todo esto, he llegado a ver los lanzamientos iniciales por lo que realmente son: estructura sobre la cual la empresa pueda construir el producto y comercializarlo en el futuro.

El éxito o fracaso real llega en un mucho más tarde.

Incluso me ha parecido cómico ver lo malos que son los lanzamientos iniciales y hacer apuestas con el resto del equipo que casi siempre son mucho más optimistas 🙂

Por último, aquí tenéis una lista de lo que hemos aprendido sobre el lanzamiento de nuestro TranslatePress en estos últimos ocho meses:

• lanzamientos como la construcción de la estructura del proyecto. Una vez fuera, puedes trabajar en el marketing y en la mejora del producto;
• no demores en pensar en las partes complicadas del proyecto. Puedes elegir incluirlos o no en la Versión 1.0, pero nunca, jamás dejes de pensar en ellos;
• pedir comentarios a otras personas de la comunidad. He tenido discusiones muy interesantes con la comunidad de PostStatus (técnicas), con personas locales de WordPress que implementan sitios web multilingües (sobre características), con usuarios reales (les encantó la interfaz fácil de usar, ojalá el plugin funcionara para todas las cadenas 🙂 ), con otros profesionales de productos de WordPress (marketing). Las características futuras, las decisiones técnicas y el marketing están influenciados por estos comentarios;
• Dedica el tiempo necesario a las funciones importantes. Hemos dedicado mucho tiempo a la implementación de gettext y seguimos haciéndolo. Es lo que hace que todo el plugin sea tan versátil, por lo que tiene que funcionar;
• a menos que estés vendiendo trabajo de diseño real, no pases mucho tiempo en el diseño del sitio web. Concéntrate en cambio en hacer que el contenido sea claro, sin palabras elegantes, y estructurado para que no sea demasiado complicado para alguien que no es técnico. Si no estás seguro de por dónde empezar, simplemente ve a AffiliateWP y robar su estructura de contenido. Nadie lo notará;
• Todo lo que puedas configurar y olvidarte de ello debería hacerse desde el principio. Si no puedes utilizar herramientas ya existentes para vender tu plugin, crea un código a medida ahora mismo si sabes cómo hacerlo. Con la infraestructura ya establecida, podremos centrarnos al 100 % en el plugin durante el próximo año o más, sin tener que preocuparnos por cambiar la estructura de precios, las renovaciones, las cuentas, etc.

Así que este es el principio de nuestra aventura TranslatePress.

Si lograste leer todo esto, ¡gracias por tu tiempo! E inténtalo TranslatePress, aunque sea solo para jugar con él. ¡Es genial así!

[NOTA]: Este artículo sobre el lanzamiento del TranslatePress se publicó originalmente en el Estado de la publicación boletín informativo.