*La gestión de preferencias es una parte integral de una gran infraestructura de notificación, lo que la convierte en una pieza muy importante del rompecabezas aquí en Courier. Esto también significa que hubo muchas oportunidades de aprendizaje y creación de experiencia para el pasante del proyecto, Denis Tatar. La pasantía de Denis duró solo unos pocos meses, pero pudo tener un impacto enorme como gerente de producto para la función Preferencias de Courier.

Queríamos saber más sobre la experiencia de Denis, así que le preguntamos si estaría dispuesto a trabajar en un artículo para nosotros. ¡Entonces lo que se le ocurrió fue tan bueno que pensamos que sería una buena idea compartirlo con todos ustedes! Esta publicación cubrirá el flujo de trabajo de Denis desde la planificación hasta la ejecución en torno al proyecto de Preferencias, así como su experiencia trabajando específicamente con el equipo de Courier. ¡Dejaremos que Denis se encargue desde aquí!

¿Cual fue el problema?

El problema que experimentamos en Courier fue que ofrecíamos Preferencias (V3) a nuestros clientes, pero la estrategia completa de características del producto no se desarrolló por completo. Creo que V3 fue un gran trampolín para V4, pero fundamentalmente tenía fallas en ciertas partes de su estrategia. Permitir solo la inclusión/exclusión global es un ejemplo de esto. Otro problema fue que V3 no ganó mucha tracción, lo que creo que apunta a la falta de una estrategia completamente pensada.

En mayo, Preferencias (V3) solo permitiría a los usuarios activar y desactivar sus preferencias de elección a nivel mundial. V3 de Preferencias solo permitía a nuestros clientes (y sus clientes) optar por recibir/no recibir notificaciones, y los clientes en todo el mundo también podían decidir si ciertas notificaciones eran necesarias o no. V3 ayudó a brindarles a nuestros clientes la posibilidad de comenzar a jugar con la idea de tener preferencias. Sin embargo, la exclusión voluntaria global es un problema porque restringe las opciones de notificación de los usuarios finales. Era todo o nada, sin término medio. Similar en teoría al dicho Pokémon: "Atrapa uno, atrápalos a todos". Sin embargo, un problema con esto es la inundación de la bandeja de entrada. La suscripción global permitiría el concepto de que las bandejas de entrada de los usuarios finales se inunden con cada notificación de producto, lo cual es problemático porque puede alejar fácilmente a los usuarios de su producto.

La inclusión/exclusión global se resolvió rápidamente al permitir que los usuarios seleccionaran el contenido del que querían recibir notificaciones y los canales que preferían. Esta tendencia general en el mercado es utilizada por miles de empresas (productos B2B y B2C), especialmente en el espacio tecnológico.

La visibilidad se convirtió en un problema serio con V3. Los usuarios finales nunca tuvieron la opción de seleccionar qué tipo de contenido y canal querían. Se preguntaría a los usuarios si estaban interesados en recibir notificaciones en general. No ofrecer opciones es problemático ya que restringe la visibilidad de lo que recibirá a través de las notificaciones. A los usuarios finales tampoco les gustan las sorpresas cuando se trata de notificaciones de productos. Tener claridad es clave porque permite a los usuarios finales tener control sobre sus notificaciones.

Con la V4 solucionamos el problema de la visibilidad, que era el principal “fallo” de la V3. Nuestros clientes y sus usuarios finales ahora tenían la capacidad de controlar el contenido que recibían y los canales que preferían.

V4 fue una buena manera de notificar estratégicamente a los usuarios finales.

Plan

Hubo tres fases que seguimos como equipo al construir Preferencias.

1. Investigación En la fase uno, pasé una buena cantidad de tiempo mirando lo que está actualmente disponible en el mercado en términos de centros de preferencia. Constantemente me hacía las siguientes dos preguntas:

   “¿Cómo administra [insertar el nombre de la empresa] las notificaciones? ¿Cómo es su centro de preferencia?”

   Estas preguntas fueron clave. Me ayudaron a sumergirme en la investigación necesaria que me ayudó a captar muchas tendencias importantes del mercado. Sin embargo, de todas las tendencias encontradas, hubo una que se destacó más.

2. Tendencia: la selección de canales y contenido a través de un diseño de estilo de alternancia/cuadrícula para los centros de preferencia es imprescindible. Esta tendencia se convirtió en la columna vertebral de nuestro proyecto de verano. Era importante ofrecer opciones de preferencia a los usuarios.

Durante esta fase, leí muchos estudios de casos. Me sorprendió ver cuántos existían sobre este tema. Cada uno me ayudó a iluminarme con soluciones para el problema que estábamos abordando. Aprendí a través de los errores de otras personas, absorbiendo lecciones valiosas.

Hablar con los clientes fue de gran ayuda en esta fase. Pude participar en numerosas llamadas con nuestros clientes y escuchar sus perspectivas sobre este problema. Haría preguntas y mostraría ejemplos de lo que teníamos en mente para una solución. Esto ayudó a adaptar un POC. Cuanto mejor entendamos las perspectivas de nuestros clientes, más fácil será comenzar a diseñar algo que usarían.

3. Diseñando un POC Disfruté mucho esta fase. Ver la investigación convertirse en un POC real fue increíble y muy divertido. Tomamos todos los comentarios que había recopilado y luego creamos varias iteraciones de diseños.

Una vez que creamos un POC, era esencial volver a nuestros clientes y asegurarnos de que fuera algo que imaginaron para Preferencias. Nuestros clientes también eran personas encantadoras con las que trabajar, siempre allí para brindar sus comentarios tan necesarios.

A menudo, tenía una buena cantidad de sesiones de intercambio de ideas con Ian. Veríamos nuestra investigación y lo que nuestros clientes tenían que decir, y combinaríamos estas fuentes en un POC. Fue un proceso perspicaz del que formar parte.

Esta fase duró varias semanas hasta que finalmente aterrizamos en un POC que satisfizo a todos los clientes con los que habíamos hablado desde mayo de 2022.

4. Construyendo un MVP Una vez que tuvimos un POC y diseños completos, comenzamos a construir la característica de nuestro producto. Esta fase me enseñó dos lecciones vitales...

   
   

Ser organizado es extremadamente importante.

y...

Como gerente de producto, debe estar una semana por delante de su equipo.

Mientras trabajaba en Courier y delegaba tareas, noté que cuanto más organizado estaba, más fácil era trabajar con otros. Mis habilidades organizativas afectarían la claridad con la que nuestros diseñadores e ingenieros entendieron nuestros objetivos y tareas delegadas individualmente. Cuanto más organizados estábamos, más rápido y eficientemente trabajábamos. Describir las tareas que nuestro equipo necesitaba completar y expresar por qué estas tareas eran necesarias ayudó mucho. Trajo claridad a todos, incluyéndome a mí.

La segunda lección aquí me la dio nuestro CEO, Troy. Me enseñó lo importante que era pensar en la semana actual y la siguiente. Troy mencionó esto porque, como gerente de producto, desea mantener a su equipo informado sobre qué proyectos y tareas están en trámite. Un gerente de producto que no tiene esta mentalidad puede convertirse rápidamente en un obstáculo para su equipo. Asumir esta mentalidad trajo claridad y me hizo sentir menos estresado por nuestro proyecto. Pasaría tiempo planificando cada semana y estimando dónde debería estar el equipo al final de cada semana (ciclo).

Estas dos lecciones ayudaron cuando estábamos construyendo un MVP. Progresamos cada semana como equipo, con las tareas de cada semana descritas, junto con las metas semanales que necesitábamos alcanzar. Trabajar con el equipo de Courier fue increíble, todos fueron comprensivos y absolutamente brillantes. Lo que más me gustó fue que todos tenían una opinión. Los ingenieros y diseñadores preguntaban si las tareas específicas eran prioritarias antes de construirlas, lo que nos permitió construir el MVP y ponerlo en funcionamiento rápidamente. Estas preguntas ayudaron a orientar las prioridades y la toma de decisiones.

Ejecución: Lo que hice exactamente

A lo largo de esta pasantía, cada día fue diferente. Mi semana implicaría hablar con los clientes, delegar tareas a nuestros ingenieros y diseñadores, y tomarme el tiempo para pensar en el futuro, dos o tres semanas antes de la semana actual. También trabajé de cerca con ingenieros y diseñadores, asegurando una gran sinergia entre ambos equipos.

Había cuatro responsabilidades principales que encarné a lo largo de mi pasantía de gerente de producto en Courier:

Ser el experto interno en lo que el mercado (clientes y prospectos) quiere dentro de mi ámbito de enfoque.

Ser el experto interno en lo que ya proporciona la función de mi producto (y, por lo tanto, el delta de la responsabilidad principal anterior). La capacidad de priorizar la ruta que lleva a Courier de nuestro estado actual a nuestro estado deseado.

La capacidad de educar al resto de la empresa sobre el producto actual, el producto que se está construyendo y nuestra visión final del producto para que todos puedan estar en la misma página sin ser expertos.

Como el pegamento que asegura que el equipo esté trabajando en conjunto en lo correcto por las razones correctas, su éxito está limitado en última instancia por mi efectividad en uno y dos. No puedo educar con precisión a mis compañeros de equipo sobre lo que yo mismo no entiendo profundamente.

Troy fue un mentor fantástico durante todo mi tiempo en Courier. Me llamó la atención sobre estas cuatro responsabilidades principales, que se convirtieron en una parte integral de mi pasantía. Lo que más resonó conmigo fue ser el pegamento entre todos los equipos. Al principio, miré este concepto y me intimidó. Pero me divertí mucho al convertirme en esta figura pegajosa entre equipos. Definitivamente no fue algo fácil de lograr, pero disfruté el desafío. ¡También logré hacer muchos buenos amigos en el camino!

¿Qué compensaciones experimenté?

Hubo muchas compensaciones a lo largo de toda mi pasantía. Los principales que experimenté estaban relacionados con el siguiente concepto "hacer que funcione -> hacerlo bien -> hacerlo rápido", que escuché a menudo durante mi pasantía. Hubo muchas ocasiones en que las pequeñas características que podían hacer que nuestra UI/UX se destacaran en realidad ralentizaban al equipo.

Concesiones como estas eran necesarias. Me hicieron preguntarme si nos enfocamos en los detalles esenciales o dejamos de lado la función y nos enfocamos en hacer un producto que funcione y haga el trabajo. La última parte de esa pregunta a menudo se eligió como nuestra estrategia. Es difícil hacer estas llamadas porque sabe que el equipo puede desarrollar una compilación de producto sobresaliente con componentes de UI/UX fenomenales, pero nuestra compilación debe lograr lo que debe hacer en primer lugar.

El objetivo principal era lanzar nuestro MVP, asegurarnos de recibir comentarios de los clientes, mejorar las funciones principales y luego centrarnos en prioridades menores que afectan la UI/UX de este producto.

¿Cómo fue trabajar con el equipo?

Me divertí mucho trabajando con el equipo de Lifecycle en Preferencias. Todos fueron muy amables y ofrecieron comentarios fantásticos. He mencionado esto numerosas veces en la oficina y en llamadas con compañeros de trabajo. Trabajar en Courier no se sentía como un trabajo; me sentí como si estuviera trabajando en un proyecto paralelo con amigos cercanos. Realmente creo que es por eso que pude producir el trabajo que hice en Courier, debido al medio ambiente. Courier es tranquilo, extremadamente amigable y orientado a los resultados.

Otra cosa que realmente me encantó del equipo fue que siempre pensaron en mí. Si hubiera tareas que los ingenieros o diseñadores harían y que se consideraran una "norma" para ellos, me preguntarían si me gustaría intentarlo para ver cómo es. Tengo tres ejemplos de esto.

Al diseñar una información sobre herramientas específica para una parte del proyecto Preferencias, Ian (Diseñador sénior) durante una de nuestras llamadas, me preguntó si quería intentar diseñar una información sobre herramientas. Esto implicó trabajar con Frames en Figma, un concepto con el que nunca trabajé. Realmente disfruté creando esa información sobre herramientas. Me hizo sentir incluida.

Cada semana, el equipo tendría nuestras reuniones de planificación del ciclo de vida del equipo. Hablaríamos de boletos y los escribiríamos. Fue al principio de mi pasantía cuando Suhas (Ingeniero sénior) me preguntó si quería intentar redactar varios boletos en Linear. Sabía que esto era algo que la mayoría de los PM harían normalmente, pero tenía mucho respeto por Suhas por mencionarlo y estaba dispuesto a enseñarme cómo crear boletos correctamente en Linear.

Una vez que el equipo tenía algo solidificado para las Preferencias, comencé a preguntar internamente para saber si había alguna empresa que estuviera interesada en conocer mi proyecto. Nathan (ejecutivo de cuentas) se puso en contacto conmigo para informarme sobre un cliente interesado en esta característica del producto. Nathan me animó MUCHO cuando se trataba de comunicarme con este cliente. Pude salir de mi zona de confort gracias al estímulo de Nathan. Nunca antes había podido hablar con un cliente en ninguna de mis experiencias de pasantía anteriores, y aprendí mucho sobre los clientes y la forma en que perciben a Courier.

Tenga en cuenta que estos son solo tres ejemplos de las muchas oportunidades como esta a lo largo de mi pasantía. Quiero dar un gran saludo a Ian, Suhas y Nathan. Les agradezco que me den oportunidades para aprender y crecer, significa mucho para mí.

¿Cómo trabajé con los diseñadores?

Disfruté trabajar con Ian (Diseñador Senior). Tendríamos reuniones improvisadas a través de la función 'Huddle' de Slack (que se renombró internamente a 'Huggle' debido a un error tipográfico que cometí una vez que se atascó). Estas reuniones fueron realmente geniales para la lluvia de ideas y el diseño de productos. A veces, Ian y yo teníamos llamadas más tarde en la noche porque era más fácil tener ideas más creativas. Teníamos sesiones de una o dos horas y obtuvimos una UI/UX realmente increíble para Preferencias. . Esto es algo que nunca olvidaré.

Al trabajar con Ian, intentaría hacerlo lo más fácil posible. Crearía una lista de tareas pendientes a través de Google docs o Slack, para que tanto Ian como yo estuviéramos al tanto de lo que debía completarse cada semana.

Durante nuestras llamadas, Ian y yo también hablábamos sobre muchos temas diferentes que no siempre estaban directamente relacionados con el trabajo, lo cual fue genial. Esto realmente ayudó a construir nuestra amistad, haciendo que sea mucho más fácil colaborar y crear una UI/UX limpia para Preferencias. A menudo hago una cantidad decente de diseño de productos fuera de las horas de trabajo, ¡e Ian siempre me daba consejos fenomenales sobre el diseño de productos y sobre Figma!

¿Cómo trabajé con los ingenieros?

Mencioné esto brevemente, pero cuando trabajaba con ingenieros, ayudaba a crear boletos y organizaba cómo sería cada semana. Ayudé a nuestros ingenieros cada vez que estaban confundidos acerca de cualquier cosa relacionada con las Preferencias y les explicaba cómo se me ocurrieron nombres específicos, por qué Ian y yo diseñaríamos ciertas partes de nuestro producto y los objetivos detrás de estos diseños. Muchas de estas respuestas provienen de mi extenso proceso de investigación con clientes que estaban interesados en Preferencias.

Mientras trabajaba con ingenieros, aprendí mucho sobre cómo desglosar correctamente los tickets (eipcs) dentro de Linear. Pensé que tenía una comprensión firme antes de trabajar en Courier, pero aprendí mucho más después de trabajar con el equipo de Lifecycle. La clave para desglosar los tickets es poder pensar en cada detalle junto con los ingenieros. Estar en un grupo pequeño mientras se hacía esto fue muy importante porque cada individuo ayudó a traer una perspectiva muy importante sobre cómo desglosar los boletos.

Durante mi pasantía, Seth (Director de tecnología), Suhas (Ingeniero de software sénior) y Christian (Ingeniero de software) me alentaron a hablar con el equipo de experiencia del desarrollador en Courier y mostrarles nuestro proyecto. El objetivo principal detrás de esto era probar si la UI/UX de Preferencias era intuitiva, si el diseño tenía sentido y si el equipo de experiencia del desarrollador entendió el objetivo detrás de esta característica del producto. Preparé una presentación de diapositivas explicando nuestro proyecto en su totalidad. Esta fue una gran experiencia porque me ayudó a prepararme para vender Preferencias a nuestros clientes. Dar presentaciones perspicaces sobre productos y "vender" su producto a los clientes es una habilidad tan importante que se pasa por alto para los gerentes de producto . Hablar con la gente internamente también me ayudó a practicar y refinar esta habilidad.

¿Cómo resolví el problema?

Antes de V4 Preferences, a los clientes no se les daba la opción de elegir qué contenido les gustaría escuchar y cómo les gustaría escucharlo. Con las preferencias de V4, los usuarios ahora pueden expresar sus opiniones sobre estos dos asuntos. Esta nueva característica del producto hace posible que los clientes elijan lo que les gusta y lo que quieren escuchar. Específicamente a través de su preferencia de canales.

Atrás quedaron los días en que la bandeja de entrada estaba abarrotada y los clientes se irritaban con la cantidad de notificaciones que recibían. Las preferencias minimizan la frustración que experimentan los usuarios finales con sus notificaciones.

¿Quiere postularse para un puesto en Courier? Echa un vistazo a nuestra página de carreras . Para ver lo que Denis ayudó a construir en acción, solicite una demostración aquí y pida ver la función Preferencias.