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.

This is one of the biggest mistakes we could have done from a development point of view and one of the reasons why it took us so long to ship version 1.0. We delayed support for gettext because it was hard to implement.

A funny story about how we got started is that after the beta launch, we had a 1-hour power failure at the office. While I waited for the power to come back on, I started cleaning my keyboard. There was nothing better to do anyway, so I took a picture of the keyboard, removed all keycaps, and proceed to clean them one by one with a little bit of rubbing alcohol and a rag.

And for the next 2 hours, cleaned my keyboard and created a mental mindmap of the gettext implementation in WordPress, how our plugin was translating strings and how we could combine the two, without getting into performance issues further down the line.

After that, I had a quick discussion with Madalin about gettext, decided we should do it now, before version 1.0 launch and HE got to work on it.

There are a couple of takeaways from this story:

• it’s a bad idea to delay complicated features without a good reason. We knew it was going to be complicated, that’s why we delayed it for so long;
• while the 2 hours thinking about gettext did absolutely nothing in terms of actual development time (it took Madalin 1 month of work to get it working and he’s now in his second month dealing with wp_ajax and gettext), it was infinitely better than not thinking about it at all. It was what we needed to decide and get unstuck.

For promoting the beta we:

• wrote a beta article that’s also SEO optimized for “WordPress en Más Idiomas” (no point in writing 2000+ words without hoping in the future for a bit of seo traffic.);
• sent a newsletter to our existing clients at Cozmoslabs about the new plugin;
• had proper “Signup for beta” forms on the TranslatePress website;
• two weeks into the beta we asked the 100 people who signed up for the beta for feedback (we used Mailchimp for this);
• for another two weeks, we ran Facebook ads that increased our beta testers to 160.

Version 1.0

It took us a month of develop → test → fix cycles to get the gettext implementation working for strings rendered by PHP (normal page templates).

We still didn’t have gettext support for wp_ajax calls, but it was important to launch now and not later:

• if we would have delayed getting everything done, we would have lost time for marketing (or at least see what works and what doesn’t). If there is no product we can’t talk about the product;
• we could have lost the opportunity to sponsor WordCamp Bucharest that’s happening in October;
• once the website, payment gateway, licenses, support, and documentation are all set up, all we’re left with is working ON the product.

Marketing

Ever since the beta launch, we started thinking about marketing the plugin.

A freemium business model means we’re dependent on a large number of free users and active installs.

With a new plugin that’s a lot harder than you might think, particularly with the new WordPress directory that takes into account active installs, reviews, number of responded questions on the forums, and other quantitative elements that we don’t have control over.

So our efforts were directed towards getting in front of as many WordPress admins as possible: 

• we added cross-promotion in our other plugins (TranslatePress can translate our other plugins, so we’ve listed it in our recommended plugins section);
• added the free download to the account page of all our clients over at Cozmoslabs;
• got in touch with ThemeIsle to add TranslatePress to a recommended plugin list as it works great to translate their complex themes (we’re using Hestia for our sitio de demostración);
• sponsoring WordCamp Bucharest and getting to talk to potential users face to face.

All this effort is particularly important at the beginning to get a bit of traction so TranslatePress appears in the WordPress.org search results.

We tried to be as less spammy as possible, if that’s even a thing. We didn’t use notices that appear on all backend pages or send newsletter after newsletter to our existing clients ( just two for beta and Version 1.0 launch).

Future marketing plans:

• we plan to create tutorials for a lot of popular themes and how to translate them (thanks Ionut);
• continue our outreach efforts towards plugin and theme developers. We want to add support for plugins, not for plugins to have to add support for us;
• content marketing for multilingual is hard because we won’t rank high in search engines. Not at first anyway. So while we’ll be active on this front, it’s not highly important for us now.

Conclusions from our TranslatePress launch

The main thing I want to highlight about this 8 month process, is that it’s not the end of the line. Lack of interest at the beginning is normal. Little to no downloads are normal. Little to no feedback is normal.

Instead of worrying about all this, I’ve come to see initial launches for what they really are: structure on which the company can build the product and market it in the future.

The real success  or failure comes at a much later time.

It’s even been comical for me to see how bad initial launches are and to make bets with the rest of the team that are almost always way more optimistic 🙂

Finally, here’s a list of the things we’ve learned about our TranslatePress launch in this past 8 months:

• launches as building up the structure of the project. Once out you can work on marketing and improving the product;
• don’t delay thinking about complicated parts of the project. You can choose to include them or not in Version 1.0, but never, ever NOT think about them;
• ask feedback from other people from the community. I’ve had some really interesting discussions with the PostStatus community (technical), with local WordPress people who implement multilingual websites (about features), with actual users (they loved the easy-to-use interface, if only the plugin worked for all strings 🙂  ), with other WordPress product people (marketing). Future features, technical decisions, and marketing are influenced by this feedback;
• spend the needed amount of time on important features. We’ve spent a lot of time on the gettext implementation and continue to do so. It’s the one thing that makes the entire plugin so versatile, so it has to work;
• unless you’re selling actual design work, don’t spend a lot of time on the website design. Focus instead on making the content clear, without fancy words, and structured so it’s not overly complicated for someone non-technical. If you’re not sure where to start, just go over to AffiliateWP and steal their content structure. No one will notice;
• everything you can set up and forget should be done early on. If you can’t use off-the-shelf tools to sell your plugin, custom code them now if you know how to. With the infrastructure in place, we can 100% focus on the plugin for the next year or more, without worrying about changing the pricing structure, renewals, accounts, etc.

So this is the beginning of our TranslatePress adventure.

If you managed to read all of this, thank you for your time! And try TranslatePress, even if it’s just to play with it. It’s cool like that!

[NOTE]: This article about the TranslatePress launch was Originally published in the PostStatus newsletter.