RACI y DACI son animales muy distintos

No te dejes engañar por el parecido de estos acrónimos:

• RACI: ¿Quién es responsable de completar ciertas tareas?
• DACI: ¿Quién decide sobre un curso de acción para una tarea o función en particular?

El Product Manager empleará una u otra dependiendo de si el problema es de responsabilidad o toma de decisiones.

¿Cómo funciona la matriz RACI?

• Responsible (Responsable/Encargado): ¿Quién es responsable de participar en la realización de una actividad?
• Accountable (Responsable/Aprobador): ¿Quién es responsable de asegurarse de que se complete una actividad?
• Consulted (Consultado): ¿A quién se consulta durante el proceso de realización de una actividad?
• Informed (Informado): ¿Quién debe estar informado sobre el estado de una actividad?

¿Cómo funciona la matriz DACI?

• Driver (Conductor): ¿Quién lleva a cabo la ejecución de una decisión?
• Approver (Aprobador): ¿Quién aprueba una decisión en particular?
• Contributor (Contribuyente): ¿Quién contribuye a una decisión?
• Informed (Informado): ¿Quién es simplemente informado sobre la decisión final?

El modelo DACI funciona de maravilla para aclarar confusiones sobre quién toma las decisiones. Esta matriz muestra claramente quién está al mando. También está muy claro quién puede aprobar, quién puede contribuir con un punto de vista y quién puede detener el proyecto.

Usando RACI y DACI de manera efectiva

El mejor momento para crear matrices RACI y DACI es al comienzo de un proyecto. Lo habitual es que los Program Managers ayuden a definir los detalles junto con el resto de Stakeholders.

Un error muy común (y a veces inevitable) es esperar para crear estos artefactos después de que surja un conflicto sobre quién hace qué y quién manda. A posteriori siempre es más difícil llegar a un acuerdo porque las partes ya tienen sus propias expectativas.

Si tu equipo tiene dificultades para tomar decisiones y adherirse a ellas, organiza una reunión para analizar los problemas y redefinir la DACI. Es posible que necesites un facilitador imparcial. También es importante invitar a alguien de la jerarquía de la empresa que pueda tomar una decisión en nombre de todos (cuenta con que se puedan dar bloqueos de opinión).

Independientemente de si usas RACI o DACI, trata de mantener bajo el número de “A”s.

Una ventaja de estas matrices es que se pueden reutilizar de un producto a otro.

DACI suele ser más apropiada para Product Management

Para la mayoría de organizaciones, una RACI funciona de maravilla. Los Product Managers se enfrentan con más complicaciones: tienen mucha responsabilidad pero poco poder disciplinario. También tratan de avanzar en varios frentes con diferentes departamentos y roles que a menudo tienen intereses diferentes.

Sin una toma de decisiones clara, los proyectos completos pueden estancarse mientras todos se ponen de acuerdo. Esta situación es la razón por la que muchos Product Managers recurren a la matriz DACI.

Es solo una letra, pero el impacto organizacional es dramático cuando todos los niveles de la empresa la adoptan. Por eso, DACI puede ser el salvavidas para muchos productos.

Eso no significa que solamente se pueda utilizar una u otra: ambas pueden usarse en paralelo. Por ejemplo, para definir actividades de Ingeniería y Operaciones, una RACI puede ser más práctica; mientras que una DACI se puede emplear a nivel de dirección.

Aunque sean herramientas diferentes, ambas tienen cierto nivel de intersección. Así que si te decides por utilizar ambas, procura mantener la consistencia entre una y otra.

Redefiniendo DACI en el contexto de Producto

• Driver
  • Limitado a una sola persona (suele ser el PM)
  • Impulsa el proyecto hacia delante
  • Responsabilidades adicionales:
    • Organizar reuniones
    • Reunir feedback
    • Negociar con líderes (tomadores de decisiones)
    • Encontrar soluciones de compromiso
    • Hacer seguimiento con Stakeholders
• Approver
  • Intenta limitarlo a un número lo más reducido posible
  • Tiene la última palabra sobre un aspecto del producto.
  • La persona suele variar de una actividad a otra.
  • No todos los ítems necesitan aprobación (en ese caso puede ser también el PM).
• Contributor
  • Proporciona opiniones expertas
  • No toma decisiones
  • Puede tener diferentes roles en la organización
• Informed
  • Se les actualiza sobre el progreso
  • No toman decisiones
  • Puede ser cualquiera cuyo trabajo pueda ser afectado

Como PM eres responsable de involucrar a todas las personas clave desde el principio (y mantener comprometidas). Esto implica:

• Saber identificar el rol y responsabilidad de todos los miembros del equipo (RACI es una buena herramienta en esta fase).
• Coordinar a todas las partes desde el principio (DACI es una mejor herramienta en esta fase).
• Mantener la comunicación y actualizar a todos los niveles para que nunca decaiga el nivel de compromiso.

La entrada RACI vs DACI: ¿Cuál es mejor para Product Management? se publicó primero en BorrowBits.

El código y el negocio.

El barro y… el otro tipo de barro.

En esta guía rápida comparto los principios más efectivos y que más me han ayudado como Product Owner a la hora de trabajar con Desarrolladores en equipos pequeños y grandes.

No me quedo corto si digo que el 90% de los problemas entre ingenieros y managers suelen ser de Comunicación. Por eso, la mayor parte de mis principios para comunicarme con los ingenieros se apoyan en un compendio de los siguientes:

• transparencia,
• respeto y
• humildad.

El rol del PO suele acotarse como un “representante del negocio”. Pero tu éxito como PO depende mucho más de lo bien que seas capaz de relacionarte con tu equipo.

Esta breve guía está escrita para Product Owners, IT Managers y Project Managers, pero se la dedico de corazón a mi equipo actual de Ströer. Ellos me han enseñado mucho de lo que aquí comparto.

Principio #1: Los desarrolladores no trabajan para ti: tú trabajas para ellos.

Cada vez hay más empresas que se oponen a otorgar el título de “Product Owner” a sus product owners. La palabra “owner” (dueño) ya implica una jerarquía, una autoridad.

Pero nada más lejos de la realidad.

Sin el respaldo de tu equipo no eres nada.

Como PO, tu principal tarea es asegurarte de que se implementa exactamente lo que hay que desarrollar en el momento adecuado, de forma que se entregue valor lo antes posible. En última instancia, es el equipo de desarrollo quien va a implementar tu visión del producto.

Así que no confundas el mapa con el territorio.

Por muy bonitos que sean tus mockups, un PowerPoint no es el producto. El equipo es el que va a transformar tu PowerPoint en algo real.

Aunque exista un Scrum Master o un Agile Coach que proteja al equipo de tu “tiranía”, tú mismo debes tener ese mantra instalado: tú estás al servicio de tu equipo y no al revés.

Y por cierto: el hecho de que haya un Scrum Master para pararte los pies no te da permiso para ser un villano en cuanto éste se descuida. No vayas por ahí dando órdenes arbitrarias o delegando en ellos tareas que no son suyas.

Principio #2: Confía en las recomendaciones de los desarrolladores: ellos son los expertos.

Desde el punto de vista del Product Owner (incluso aunque tengas experiencia técnica) las cosas siempre parecen mucho más fáciles de lo que acaban resultando.

Tu trabajo como PO es definir “qué” y “cuándo”. El “cómo” es cosa del equipo de desarrollo. Y en cuanto a esto, el equipo técnico suele tener razón.

Sin embargo, siempre existen varias alternativas para un mismo problema. Si no crees en la solución propuesta, pide una explicación (de alto nivel) de los desafíos, pros y contras de cada alternativa. En caso de duda, tomad una decisión conjunta poniendo en equilibrio las prioridades del negocio, la estabilidad y la seguridad de la aplicación, la potencial deuda técnica, etc.

El roadmap no lo es todo. Despreciar el impacto futuro de la deuda técnica es como encerrar un cachorro de león en tu dormitorio y alimentarlo constantemente con carne cruda: en algún momento tú podrías ser parte del menú. Muchos proyectos fracasan por ignorar este fenómeno.

Si al CEO de tu empresa le urge esa funcionalidad y quiere liberarla a toda costa, explícale los riesgos a los que se expone; si es necesario exige una exención de responsabilidad para ti y para tu equipo.

A muchos managers de alto nivel les encanta decir “hazlo en plan MVP”, pero lo que en realidad quieren decir es “haz una chapuza para salir del paso”.

Una cosa que todavía me sorprende es que el equipo técnico siempre se preocupa más que el negocio por la calidad, incluso cuando tiene un impacto directo sobre los clientes.

Principio #3: Comparte la visión del negocio constantemente, aunque nadie te pregunte.

Un minuto de silencio por esas costosas features que al final nadie usa…

Es mejor resultar un pesado, a que se implemente algo que nadie necesita. Lo he comprobado un millar de veces: cuanto mejor entiende un desarrollador lo que hay detrás de una decisión de producto, más acertada será su implementación, más rápida y más libre de errores.

Invierte el tiempo que sea necesario en asegurarte que se comprende la necesidad de negocio que hay detrás, porque será justo eso: una inversión.

Comparte el roadmap de vez en cuando y tus intenciones para release a producción.

Simplifica cuando sea necesario. Algunos Product Owner tendemos a pedir más cosas de las que en realidad hacen falta. Asegúrate de que los requisitos sean desglosados en requerimientos más pequeños, y que estos a su vez sean simplificados y priorizados correctamente (técnica MoSCoW por ejemplo). El equipo de desarrollo tiende naturalmente a desarrollar todo lo que tú le pidas. A veces incluso más de lo que pides. Esto se conoce como Scope Creep, que es el terror de los PO.

Ayuda al equipo a ponerse siempre en el pellejo de los usuarios, y siempre se implementará lo correcto solo hasta donde es necesario.

Principio #4. Sé radicalmente transparente.

No necesitas entender todo lo que los devs hacen, pero ellos sí necesitan entender lo que tú haces. Sé transparente. Al tratar con desarrolladores, no les ocultes los problemas.

Soy consciente de que esto va en contra de la cultura de muchas empresas, sobretodo de las más jerárquicas. También es cierto que hay que proteger al equipo de la presión exterior…

Pero en mi experiencia, si alguna circunstancia les afecta a ellos de forma directa o indirecta, no debes ocultarla. Primero, porque merecen saber lo que se cuece; y segundo, por lo mismo que comentaba en el Principio #3. Si los desarrolladores comparten tu comprensión de la realidad, te ayudarán a solucionar cualquier problema que se ponga por delante.

Aunque eso suponga romper algunas reglas.

Y desde dentro:

Si hay conflictos internos, no los evadas.

Si hay que mantener una conversación difícil, no la postergues.

En otras ocasiones resulta útil abandonar el modo “proxy”, e invitar a los técnicos a las reuniones con ciertos Stakeholders. Asegúrate de que todas las personas involucradas asisten a todas las reuniones. Esto es especialmente importante cuando se trabaja en remoto.

Si recibes halagos de los usuarios, de los clientes o de los stakeholders, transmíteselos al equipo y procura que se sientan dueños de esos triunfos. Si recibes críticas negativas, compártelas también; pero después de que tú hayas asumido la responsabilidad absoluta.

En última instancia y de cara a los clientes/usuarios tú eres responsable del éxito o del fracaso de tu producto. 

Principio #5: Sé exigente.

Espera la excelencia para obtener resultados excelentes (efecto Pigmalión). Pero eso sólo funciona cuando tú mismo persigues la excelencia en lo que haces: es una carretera de doble sentido.

Dale a tu equipo lo mismo que esperas de ellos.

Pon las expectativas bien altas.

Sé claro también con las expectativas individuales de cada uno. Ayúdalos a dar lo mejor de sí. Por tu parte, cúrrate las historias de usuario y el backlog como si se te fuera la reputación en ello. Testea la aplicación concienzudamente y sé despiadado con los resultados.

Si una entrega no cumple tus expectativas, recházalo. No tienes por qué (y no debes) liberar nada de lo que no estés absolutamente convencido.

No se trata de herir sentimientos:

Si no has comunicado bien un requerimiento, asume la responsabilidad. Lo normal es que sea un fallo de comunicación del Product Owner o del Business Analyst. Asegúrate de que el equipo comparte tu definición de “terminado” (Definition of Done). Ése es tu mejor seguro antipatinazos.

Pero si al final algo sale mal, no le eches la culpa al DevOps, ni al Backend, ni al Frontend, ni al QA.

Es culpa tuya y punto.

La próxima vez, asegúrate de que el equipo cubra esa debilidad, y sobretodo de que todos aprendan de esos errores (para eso están las Retrospectivas). Lo único malo de los errores es no aprender de ellos.

Los errores son oportunidades de mejora que nadie debería dejar pasar.

Principio #6: No te entrometas demasiado: el micromanagement es de perdedores.

En la medida de lo posible, no asignes tareas. Permite al equipo decidir quién hace qué. Ellos están más capacitados que tú para ver quién va a ser más eficiente con cierta actividad.

Sin embargo asegúrate de que al final siempre haya un responsable: si todos son responsables, al final nadie lo es. Y la tarea se quedará sin hacer.

Aplica el micromanagement sólo en casos de emergencia extrema, en plan “se está quemando el edificio”.

Por lo demás, deja que el equipo resuelva sus propios problemas de organización, aunque algunos de ellos te lo pidan (los desarrolladores principiantes o inseguros prefieren que el PO les diga lo que tienen que hacer). Incentiva la proactividad y la autonomía.

Dale responsabilidad a tu equipo, y entonces tanto ellos como el producto empezarán a brillar.

No te olvides de que un programador es una persona, no una máquina. A menudo 2 + 2 no es igual a 4, sino a 3. Esto es tanto más cierto cuanto más complejo es el producto. Es un error clásico que cometen muchos managers cuando planifican “recursos”.

Dicho sea de paso: una vez empieza el desarrollo de una tarea, no la detengas para empezar otra más urgente. Los cambios repentinos de contexto exigen un gran esfuerzo mental.

Compréndelo: desarrollar código es un arte. Y todo arte necesita su espacio para prosperar. No presiones. No te metas en los detalles técnicos aunque te guste (especialmente si te gusta).

¡Tú a lo tuyo!

Principio #7: Las estimaciones no son más que eso: estimaciones.

He comprobado que los desarrolladores son por naturaleza optimistas.

Cuando un desarrollador te dé una estimación, aplica un buffer de contingencia del 20-30%. Si es junior puedes incluso permitirte un 50%. Nunca culpes a un desarrollador de haber tardado “más de lo estimado”. Anima en cambio a que se comunique lo antes posible una subestimación/sobrestimación.

No preguntes constantemente cuánto falta para acabar.  Si un ticket tarda más de la cuenta en salir, asegúrate de que el desarrollador no se ha topado con algún impedimento.

Un story point nunca es el mismo story point. Cada feature puede ser un mundo. Aunque muchos desarrolladores se oponen a ello (especialmente los más senior), las estimaciones de las historias de usuario son útiles para el negocio: permiten planificar la liberación de software con una mínima sensación de certeza.

A algunos desarrolladores no les gusta estimar tickets por otras razones: puede percibirse como una herramienta de control del desempeño. Pero como Product Owner, nunca deberías usar las estimaciones para medir la velocidad individual.

El desarrollo de Software es un mundo VUCA (volátil, incierto, complejo y ambiguo), y el Product Owner debería sentirse cómodo con dosis elevadas de incertidumbre: he aquí la diferencia fundamental con un Product Manager tradicional.

Tanto tú como el equipo deberías tener claro que:

Una estimación no es una promesa, sino una forma heroica de planificar lo implanificable.

Principio #8: Disfruta del refinamiento de requisitos.

Si tú no te lo pasas bien en los refinements, el equipo tampoco.

Emociónate con los problemas, participa y sigue con atención el debate. Fomenta la discusión constructiva. No te distraigas y mantén tu presencia. Asegúrate que tus requerimientos se pueden dividir en unidades que no duren más de tres a cinco días (o el equivalente en story points, talla, etc). Si son demasiado grandes, pártelo todavía más (siempre se puede partir un poco más).

No fuerces la estimación cuando los requisitos no están claros. Es mejor abortar una sesión en la mitad y decir: “Lo siento, necesito averiguar más detalles sobre esto“.

Nunca supongas: vuelve al mundo real y comprueba.

Así evitarás los infames “change requests”, sobretodo si ocurren de forma constante para una misma feature. Los cambios de requisitos constantes y al vuelo (en los ticket que ya están en progreso) son una fuente de frustración para todo el equipo.

No te aferres nunca al camino feliz (happy path).

Si algo puede salir mal, saldrá.

Murphy nunca se debería perder un refinement.

Valora y premia la detección temprana de posibles “corner cases”. Prepara el material con antelación y exige que los desarrolladores lo lean antes de la sesión: mockups, ejemplos, contexto… Cuanta más información se aporte desde un principio mejor.

Y por el amor de $deity: refinar historias de usuario consume mucha energía, ¡no pongas esas reuniones después del almuerzo!

Principio #9. Siéntete parte del equipo.

Mójate en las retros, bájate del pedestal (si es que crees que estás en alguno).

Comparte tu opinión honesta y ábrete a las críticas de mejora, especialmente si no te gustan.

Nunca te lo tomes como algo personal.

Da igual si eres el dueño del producto: en el día a día formas parte de un equipo. Unas veces serás parte de la problemática y otras veces parte de la solución.

Celebra las victorias con ellos, acompáñalos en las releases difíciles. Trabaja cerca del equipo en el día a día: no te evadas demasiado en el “business”. Intenta estar siempre disponible para el equipo para resolver dudas (sí, sé lo difícil que es esto).

Habla cara a cara siempre que puedas. No olvides tomarte un café con el equipo de vez en cuando.

Eres el puente entre el mundo de las corbatas y el mundo de las camisetas geeks. Y la programación es una actividad intelectual que se parece más al arte que a la mecánica.

Así que trata a los Artistas con el máximo respeto. 

La pregunta “cómo gestionar un equipo de desarrolladores” está mal planteada; en lugar de eso céntrate en cómo tratar con las idiosincrasias de las personas. Más allá de las apariencias y los estereotipos. He visto a otros PO hablar de su equipo con desprecio y autosuficiencia. No seas uno de esos capullos condescendientes.

Y hablando de eso:

No hay nada más condescendiente que un Product Owner regalándole a un Desarrollador un libro sobre cómo programar mejor, o más rápido, o cualquier otra cosa insultante… No hagas ese tipo de cosas. 

Los principios del buen Product Owner: cómo trabajar con desarrolladores

Reflexioné mucho antes de atreverme a publicar este post.

Después de todo, ¿con qué jeta se me ocurre dar consejos cuando yo mismo todavía no los aplico a la perfección?

Creo que no es fácil ser un buen Product Owner.

Requiere la capacidad incesante de encontrar compromisos, a menudo irreconciliables. Es un rol de malabarista solitario que sobrevive en la frontera de varios mundos y submundos. Un PO debe resistir bien la presión sin pasársela al equipo. La palabra más importante de su vocabulario es “No”.

Llegar a ser un buen Product Owner es un work in progress constante, algo así como la aspiración al Nirvana. Un reto casi imposible. Y así con todo, un deber moral.

¿Entonces por qué publico estos principios?

Pues simplemente, porque me habría gustado que alguien me contara cómo trabajar con desarrolladores en mis comienzos. Muchas de estas cosas no las aprenderás en un cursillo de Udemy ni sacándote el PSPO I.

Así que si estás empezando y tienes que quedarte con una sola enseñanza, quédate con ésta: la comunicación es tu herramienta más importante.

Un Product Owner puede llegar a ser tan bueno, como buena sea su comunicación con su equipo. 

Por último, estos principios no están grabados en mármol. Son más bien un borrador perpetuo, y lo iré afinando conforme aprenda nuevas lecciones. De hecho, si tienes otros principios útiles basados en tu experiencia (ya sea como desarrollador o como product owner) que no he tenido en cuenta, escríbeme un comentario

¡Un saludo!

La entrada 9 Principios Efectivos para Trabajar con Desarrolladores. Guía del Product Owner se publicó primero en BorrowBits.

Se trata de un título muy valorado en muchos entornos ágiles, así que tanto si quieres una mejora en tu carrera profesional como Product Manager o porque quieres optar a un puesto en el que se exige tenerla, este artículo puede servirte de ayuda.

Hace relativamente poco pasé el examen de certificación tras unos pocos días de preparación, así que el propósito de este artículo es daros algunos consejos útiles basados en mi experiencia.

¿Cómo es el examen?

• El examen cuesta 200$ y sólo hay un único intento. Si suspendes y quieres intentarlo de nuevo, tendrás que pagar otra vez.
• Para aprobarlo es necesario acertar el 85% de las respuestas.
• Consta de 80 preguntas de tipo:
  • Verdadero/falso
  • Opción múltiple
  • Respuesta múltiple
• El tiempo límite son 60 minutos.
• El único idioma disponible es en Inglés, por tanto es recomendable un buen nivel para entender bien las preguntas.

En comparación con otras certificaciones de la industria puede parecer difícil, tanto por la elevada tasa de aciertos que exige, como por el poco tiempo disponible para cada pregunta. A pesar de todo, el examen resulta muy sencillo una vez se comprende cómo funciona Scrum.

¿Cuánto tiempo necesito para su preparación?

En mi caso, dediqué menos de 20 horas a lo largo de diez días, si bien ya tenía algunos conocimientos sobre product management. Como suele ocurrir en este tipo de certificaciones, la clave es hacer tests, tests y más tests. Tu probabilidad de aprobar aumentará de forma proporcional a la cantidad de tests que hagas, porque a la postre aparecerán muchas preguntas repetidas.

Con la concentración adecuada y siguiendo los pasos de esta guía, se puede preparar en 2-4 semanas con una dedicación de 1-2 horas al día.

¿Cómo lo preparo? Un sistema basado en la evidencia

Para preparar el examen puedes hacer un curso de pago o estudiártelo por tu cuenta. A diferencia de otras certificaciones, Scrum.org no exige la realización de un curso previo, al menos para PSPO I. Esta guía de estudio está pensada para los que se lo quieren preparar de forma independiente, aunque si ya hiciste un curso puede ayudarte a repasar.

Este sistema consta de varias partes. Es muy importante que no te saltes ningún paso, sobretodo si tienes poca experiencia profesional con Scrum. Considera esta sección como tu “checklist” de estudio:

1. Lee la guía oficial de Scrum con atención al menos 3 veces. Se trata de un texto de apenas 19 páginas, aparentemente sencillo. Pero no te dejes engañar por su longitud, cada frase puede abrir un universo de interpretaciones. Aunque está disponible en muchos idiomas, te recomiendo estudiarla en inglés (ya que el examen y casi todo el material de estudio está en inglés)
2. Además lee TODAS las lecturas imprescindibles que se recomiendan en este artículo, más abajo.
3. Aprueba con un 100% todos los Open Assessments de Scrum, 5 veces cada uno, en menos de 5 minutos por intento: esto te dará una base sólida sobre los principios de Scrum que acabas de estudiar:
   • Product Owner Open => 5 veces con un score 100%
   • Scrum Open => 5 veces con un score 100%
   • Developer Open => 5 veces con un score 100%
   • Nexus Open=> 5 veces con un score 100%
4. Aprueba con un 100% los tests de Mikhail Lapshin en modo real (tiempo límite de 60 minutos) al menos 3 veces cada uno:
   • Professional Scrum Master (PSM I) preparation quiz – learning mode | real mode => 3 veces con un score 100%
   • Professional Scrum Product Owner (PSPO I) preparation quiz – learning mode | real mode => 3 veces con un score 100%
   • Scaled Professional Scrum (SPS aka Nexus) preparation quiz – learning mode => 3 veces con un score 100%

Consejos para el examen y preguntas-trampa

Aunque te salgan bien los “open assessments” no deberías confiarte: algunas preguntas del examen real están plagadas de trampas. Aquí van algunos ejemplos:

• Cuidado con los matices: quizás éste sea el consejo más importante. Lee cada palabra y cada coma con mucha atención. En particular presta atención a las diferencias entre “can”, “should”, “must” y “may”. Un par de ejemplos:
  • The PO (Product Owner) and SM (Scrum Master) may attend the Daily Standup, but they may not participate in the Daily Standup
  • Retrospective improvements must go into the Sprint Backlog, not the Product Backlog.
• Cuidado con las preguntas que contienen una negación. Por ejemplo: ¿Cuáles de las siguientes opciones no es una característica de…?
• Cuidado con la respuesta múltiple (checkbox en vez de radio button) en las que varias podrían ser correctas. También con las de tipo “todas son correctas” o “ninguna es correcta”.
• Respuestas contradictorias: a veces la experiencia del mundo real puede contradecir a las buenas prácticas, ¡incluido a Scrum! En caso de duda, las respuestas “más verdaderas” son las que favorecen el empirismo y la evidencia de los datos (lee sobre “Evidence Based Management” más abajo).
• Cuidado con herramientas específicas que no aparecen en la guía de Scrum: casi todo lo que no aparece en la guía explicitamente, no entra en el examen. Eso significa que a Scrum “le da igual” si utilizas una burn-down chart o una burn-up chart. Tampoco importa si para estimar las historias de usuario utilizas planning poker, la sucesión de Fibonacci o cualquier otra forma que al final de día permita calcular la velocidad de un Sprint…
  • (!)Las excepciones a esta regla se encuentran en las lecturas imprescindibles más abajo (y es por esto que son imprescindibles).

¿Dónde encontrar los exámenes y el resto del material?

Exámenes

La mala noticia es que no esta permitido compartir exámenes reales. Hay muchas páginas y cursos de procedencia sospechosa que prometen acceso a preguntas oficiales, o que ofrecen simuladores del examen real. En mi experiencia, muchas de esas fuentes además de ser de pago ofrecían preguntas incorrectas (con lo cuál podrían confundirte en vez de ayudarte).

Aquí la buena noticia:

Los Open Assessments y los tests de Mikhail Lapshin que mencionábamos antes son una excelente forma de practicar. Son muy parecidos al examen real y además gratuitos.

Lecturas imprescindibles

Además de la guía de Scrum, las siguientes lecturas y artículos son importantes; deberías comprenderlos antes de hacer el examen. Léelos tantas veces como sea necesario:

• Understanding and Applying the Scrum Framework
• Developing People and Teams
• Managing Products with Agility
• Priorización MosCOW
• Glosario de Scrum
• Cono de la incertidumbre
• Evidence-Based Management (EBM) y sus áreas de valor clave: Key Value Areas (KVAs)
• La guía Nexus (cómo escalar con varios equipos Scrum).
• 10 Tips for Product Owners on (Business) Value
• Stances of the Product Owner
• The “new” new Product Owner
• 9 Principios Efectivos para trabajar con equipos de desarrollo (BorrowBITs)

Libros

Aunque no es imprescindible, si tienes tiempo adicional, te recomiendo leer los siguientes libros:

• “Agile Product Management with Scrum”, de Roman Pichler. Son sólo 133 páginas y para mí es uno de los mejores libros sobre agile product management, pues ofrece una visión muy práctica y realista del trabajo de Product Owner. Hay que tener cuidado porque está algo anticuado con respecto a la guía de Scrum, pero desde mi punto de vista ayuda a comprender mejor el papel de Product Owner.
• “The Professional Product Owner: Leveraging Scrum as a Competitive Advantage“, es el libro que recomienda Scrum.org para preparar este examen, y por tanto me veo obligado a recomendarlo (aunque no lo he leído).
• “The Nexus Framework for Scaling Scrum“. Además de ser un excelente “repaso” de Scrum, explica cómo escalar paso a paso éste a varios equipos mediante un caso de estudio de real.
• “Peopleware: Productive Projects and Teams” de Tom DeMarco y Tim Lister. Uno de los mejores libros que he leído sobre organización de equipos IT. No es un libro sobre Scrum, pero ayuda a comprender los valores subyacentes de los equipos ágiles, cross-funcionales y auto-organizados.

¿Cómo aplicar y donde hacerlo?

Solicitar el examen es muy fácil. Sólo tienes que ir a esta página y comprar un “intento” para la certificación Professional Scrum Prouct Owner I, con tarjeta de crédito o Paypal. Tras la compra, recibirás un e-mail con una contraseña para acceder al examen. La contraseña no expira, por lo que podrás comprarla en el momento que quieras y usarla cuando estés preparado/a.

Usad los comentarios si tenéis dudas o sugerencias, entre todos nos podemos ayudar.

Si quieres profundizar más sobre Product Management, apúntate a mi newsletter gratuita, The Stoic Product Manager. 

La entrada ¿Cómo aprobar la certificación PSPO I a la primera? (aunque no tengas experiencia como Product Owner) se publicó primero en BorrowBits.

Estoy a punto de decir una obviedad como un piano: la preparación de cualquier negociación es fundamental. ¿Evidente no? Pues con frecuencia, los errores más graves en las negociaciones se producen antes de que ni siquiera empiecen las conversaciones. Y no ya porque la preparación haya sido defectuosa, ¡sino por una total ausencia de ella! Por lo visto, hasta los mejores negociadores resbalan en esto. Yo mismo he pecado de ello unas cuantas veces, y lo he pagado bien caro. Pero a mí no me van a pillar nunca más.

¿Y en qué consiste prepararse una negociación?

Como mínimo, significa reunir la información necesaria para tratar de conseguir el mejor acuerdo posible. Si no sabemos hasta dónde podemos “apretar”, corremos el riesgo de ser demasiado agresivos o lo que es peor, de quedarnos cortos.

Por eso voy a recopilar aquí, a modo de chuleta, los 4 pasos más básicos que he extraído de algunas publicaciones sobre el tema (un buen ejemplo: “El negociador genial“, de Max H. Bazerman y Deepak Malhotra).

Cómo prepararse para negociar en 4 pasos

1) Descubre tu BATNA (Best Alternative To Negotiated Agreement).

El primer paso de cualquier negociación es preguntarse: ¿Qué haré si la actual negociación no llega a ninguna parte? En otras palabras: ¿qué es lo peor que podría pasar? ¿cuál sería mi plan B(ATNA)? Para ello, identifica todas y cada una de las alternativas disponibles y calcula el valor asociado a cada una de ellas. De entre todas, la alternativa de más valor es tu BATNA.

2) Calcula tu Valor de Reserva

Ahora estamos en condiciones de hacernos la siguiente pregunta: ¿cuál es el acuerdo mínimo que soy capaz de aceptar? ¿A partir de qué punto estoy dispuesto a negociar? O también: ¿por debajo de qué punto giraría sobre mis talones sin dignarme a seguir hablando?

Pues ese punto de inflexión constituye tu Valor de Reserva, el punto exacto en el cual te sería indiferente quedarte con tu BATNA o continuar la negociación. Es, por tanto, el valor asociado a tu BATNA.

3) Descubre el Valor de Reserva de la otra parte

Ahora que ya sabes cuál es la oferta más baja que puedes aceptar, es momento de averiguar cuál es la oferta más alta que podrías llegar a negociar. En este paso se trata de encontrar el BATNA y el Valor de Reserva de la otra parte. Lo que hacemos es responder a esta pregunta: ¿qué haría la otra parte si la negociación acabara en un punto muerto? ¿Cuál es el valor de reserva que la otra parte asociaría a su BATNA?

Este es el paso más difícil y delicado- por no decir el más importante – ya que la otra parte hará lo posible para no mostrarte sus cartas.

Algunos trucos para disolver parte de la incertidumbre:

• Agota todas las fuentes de información a tu alcance: recurre a Internet, publicaciones del sector, estudios estadísticos, amigos y conocidos que sepan algo del tema…
• Identifica tus supuestos y duda de ellos: haz una lista de las cosas que “sabes” y otra de las cosas que “supones”. En la medida de lo posible, trata de resolver la incertidumbre sobre cada uno de los ítem de la segunda lista.
• Esboza un contrato de contingencias para protegerte de las cosas que supones o de las que no estás del todo seguro. La reacción de la otra parte a las cláusulas de dicho contrato te ayudarán a confirmar o descartar dichas suposiciones durante la negociación.

4) Evalúa la Zona de Posibles Acuerdos (ZOPA)

¡Felicidades!

Ahora ya eres capaz de evaluar todos los posibles acuerdos que hay entre tu valor de reserva y el de la otra parte. Este intervalo se conoce como la ZOPA, o Zona de Posibles Acuerdos.

En la negociación, tu trabajo no sólo conseguirá en conseguir un trato, sino de alcanzar el mejor acuerdo posible, maximizando la ZOPA. En definitiva: quedarte con la parte más grande del pastel (cuidado con no caer en la trampa del pastel de tamaño fijo).

Un par de consejos finales

Pásate de la raya

Si vas a negociar desde una posición fuerte o crees que has calculado la BATNA/Valor de Reserva de la otra parte con precisión, está en condiciones de ser tú quien lance la primera oferta (¿recuerdas?). Al lanzarla, ve un poco más allá de su valor de reserva, lo cual permitirá crear un anclaje más cerca de su Valor de Reserva que del tuyo, acaparando así la ZOPA al máximo.

Revalúa la ZOPA durante la negociación

A pesar de las cábalas que hayas realizado sobre el papel antes de la negociación, es importantísimo que recalibres la ZOPA con la información que te vaya dando la otra parte (sin caer en las trampas de influencia, ya hablaremos de ello). Cuídate de no ser rígido: no te ciñas demasiado a los resultados de tu investigación preparatoria y escucha atentamente.

No olvides, pues, aquel refrán popular: “Tetas y ZOPA no caben en la boca”

La entrada Estos 4 pasos podrían marcar la diferencia antes de una Negociación se publicó primero en BorrowBits.

En los últimos años, hemos visto asistido a cómo muchos mercados tradicionales han sufrido una disrupción por la cual los protagonistas han cambiado considerablemente y en la cual las nuevas empresas protagonizadoras han pasado de no existir a ser valoradas en cantidades ingentes de dinero y continuar creciendo a ritmos vertiginosos. Este fenómeno fue perfectamente analizado por Tom Goodwin en su artículo en TechCrunch llamado “The battle is all for the customer interface” y el cual contiene una cita (traducido al español):

Uber, la mayor compañía de taxis del mundo, no posee vehículos. Facebook, el propietario de los contenidos más populares del mundo, no crea ningún contenido. Alibaba, el minorista con una valoración más alta, no tiene inventario. Y Airbnb, el mayor proveedor de alojamiento, no tiene propiedades. Algo interesante está sucediendo

Esta disrupción tan clara en estos mercados será extensible a más y más mercados en un futuro próximo. Ese dicho de personas mediocres y conformistas tal “Todo está inventado” es claramente una gran mentira considerando que estas empresas cuentan en el caso de mayor antigüedad con apenas 10 años de vida. Viendo este pasado reciente podemos soñar con un futuro lleno de oportunidades esperando ser descubiertas.

La entrada El boom de los negocios disruptivos se publicó primero en BorrowBits.

Hoy tenemos en BBits una entrevista. El elegido ha sido Alberto López, un ingeniero de Telecomunicación que, al contrario que la mayoría de los egresados, decidió apostar por su propia empresa y tras terminar sus estudios cofundó Idintel. Estamos convencidos de que esta entrevista será muy útil para conocer los entresijos del día a día del emprendedor y de que nos hagamos una idea de las dificultades y satisfacciones que conlleva. Pasamos a la acción, comenzamos con las preguntas:

1. ¿En qué consiste vuestra startup? ¿Cuántas personas hay detrás del proyecto?
Actualmente, Idintel se dedica fundamentalmente al desarrollo integral de aplicaciones móviles, desde el análisis previo, la consultoría, y la conceptualización, pasando por el diseño y desarrollo, hasta la publicación en los diferentes markets, seguimiento y mantenimiento. Sin embargo, pretende ser una empresa con unos servicios mucho más ambiciosos, pues está dando el salto al Internet de las Cosas (IoT), que nos permitirá abarcar proyectos más completos, que incluyen software y hardware, siempre bajo el prisma de la tecnología móvil.
Detrás de Idintel, están los cofundadores, José Luis Montesinos y yo, Alberto López Agrela, ingenieros de informática y telecomunicación, respectivamente, de la Universidad de Granada.

2. ¿El tema de emprender y poseer vuestra propia empresa es algo que tenéis en mente desde hace mucho tiempo o es algo que surgió en base a que visteis una gran oportunidad desarrollando apps para dispositivos móviles?
Creo que primero siempre viene la idea, el interés por algo, en este caso una tecnología, y, si tienes un carácter emprendedor innato, enseguida planteas cómo sacarle una oportunidad de negocio.
En nuestro caso, en los primeros años de carrera, allá por 2007 y 2008, comienza a aparecer en escena el smartphone, y es ahí cuando comienza nuestro interés por este mundo tecnológico que cabe en el bolsillo. Y es en el último curso de carrera, en 2011 y 2012, cuando comenzamos a plantearnos la idea de emprender, a partir de la inclinación por autoemplearnos y obtener partido de nuestro ocio y conocimientos de la tecnología móvil.
En ese momento, iniciamos una pequeña investigación de mercado, y, para nuestra sorpresa, concluimos que las condiciones y números de este negocio son ventajosas, a pesar del contexto de crisis económica.

3. ¿Cómo surgió la idea? ¿Cómo fueron los comienzos? ¿Cómo es vuestra jornada de trabajo típica?
Tras terminar la carrera, y examinar las condiciones para emprender, comenzamos a elaborar nuestro plan de negocio. En él esbozamos nuestra visión de lo que pretende ser Idintel, una empresa que proyecte y sea referencia de la nueva revolución tecnológica basada en lo inalámbrico, en lo móvil, y en lo conectado a Internet, a la nube, donde el elemento clave es el dispositivo móvil.
Al principio, el optimismo es la sensación mayoritaria: conoces bien tu servicio y tu producto, ¿por qué no iba a funcionar el negocio? Sin embargo, en el inicio te das cuenta que existen multitud de factores que debes gestionar: clientes, marketing, branding de la empresa, contactos, etc. Todo un mundo empresarial con el que nunca has lidiado y que es esencial para que el proyecto tenga éxito. No queda más remedio que aprender a toda prisa todo aquello que, en otro caso, tardas años. Por ello, las jornadas comienzan siendo extensas, pues tienes que, además de la actividad principal de la empresa, trabajar en todos estos aspectos, que son complementarias y a la vez fundamentales para el desarrollo de la empresa.
Poco a poco, las jornadas van convergiendo, conforme el comienzo tiene éxito y la empresa se va estabilizando. Actualmente, nuestras jornadas no superan las 8 ó 9 horas, aunque es cierto que luego en casa aprovechamos algún momento más.

4. Contáis con vuestra sede en Málaga en el edificio BIC Euronova en el PTA. ¿Cómo os han apoyado desde BIC? ¿Animaríais a otros jóvenes emprendedores a que se ubiquen en Málaga? ¿Qué destacaríais del Parque Tecnológico de Málaga? ¿Habéis contado con el apoyo de inversores privados?
Idintel fue fundada en Granada, pero, desde el principio, nuestro objetivo era ubicarnos en una localización más adecuada para nuestro negocio. En ese sentido, Málaga tiene un tejido empresarial fuerte y maduro, y el Parque Tecnológico de Andalucía (PTA), donde existen fuertes sinergias entre grandes y pequeñas empresas, y una red empresarial fuerte, es el ejemplo de ello.
Trasladarnos al PTA y que BIC Euronova nos aprobara nuestro plan de negocio, ha sido clave para Idintel.
Desde que nos instalamos en BIC Euronova, hemos recibido un gran apoyo y promoción, dos de los elementos fundamentales que necesita un emprendedor. Gracias a esta incubadora, hemos podido formar una gran red de contactos, asistir a eventos, e incluso obtener conocimientos empresariales, de marketing y estratégicos, de la mano de sus consultores.
De momento, no contamos con la necesidad de recibir financiación privada. A partir de las ganancias en nuestros propios proyectos, hemos ido obteniendo los recursos para invertir en instalaciones y material, los cuales hemos ampliado poco a poco. El resultado de optar por esta estrategia, es que hoy en día no tenemos ninguna deuda externa.

5. En este primer año de vida de Idintel y dado vuestro perfil técnico, ¿cómo habéis solventado los aspectos en los que no contáis con formación especializada en vuestro equipo como marketing, finanzas, legislación entre otros? ¿Qué es lo que os ha resultado más complejo?
Tal y como comentaba antes, al principio no queda más remedio que proceder a un aprendizaje urgente de materias que apenas conocías. Existe todo un mundo de conocimientos en todos estos aspectos empresariales (marketing, finanzas, etc.), por lo que debes buscar lo que realmente necesitas para tu negocio, seleccionarlo, analizarlo y adaptarlo a tu empresa. Tienes que limitarte a lo que realmente necesitas.
Saber vender tu servicio o producto en el mercado, darlo a conocer, y encontrar clientes y fidelizarlos, fue lo que más se nos antojó complicado. Además de las numerosas fuentes de información a las que uno puede recurrir, y de todo el conocimiento y material existente sobre este ámbito, en cursos, libros, etc., para nosotros fueron esenciales las pequeñas reuniones y encuentros organizados por BIC Euronova con emprendedores de más años de experiencia y empresas ya consolidadas.

6. Contáis con una gran cartera de servicios orientados a empresas pero ¿tenéis en mente lanzar algún producto/servicio destinado al mercado de masas?
Nuestro principal y actual objetivo es consolidar a la empresa en los servicios de proyectos de tecnología móvil, tanto en el desarrollo integral de aplicaciones móviles, como en proyectos de sistemas dentro del concepto del Internet de las Cosas.
Creemos que una de las principales características que debe tener una startup y empresa de base tecnológica, es poder adaptarse rápidamente al contexto, e incluso anticipar los cambios tecnológicos.
De momento, esbozamos posibles productos, pero pretendemos primero lograr nuestros objetivos a corto y medio plazo.

7. De los servicios ofrecidos tenemos especial curiosidad por conocer más detalles sobre vuestra posición en el desarrollo de servicios basados en redes de sensores, una tecnología que dará mucho que hablar en los próximos tiempos. ¿Qué podéis contarnos?
El Internet de las Cosas (IoT) es un potente y novedoso concepto que se perfila como la próxima revolución tecnológica, pese a que lleva ya años presente en nuestra sociedad, pero a un nivel mucho más bajo con respecto a lo que pretende ser. Permitirá que cualquier objeto, como coches, lavadoras y frigoríficos estén conectados a Internet, de modo que puedan ser gestionados de forma remota desde cualquier dispositivo con conexión, como los smartphones.
En este sentido, las redes de sensores ocupan un lugar destacado, pues permitirán extraer información del medio en estos objetos conectados, y enviarlas hacia la nube para procesar los datos. De este modo, serán posibles numerosas aplicaciones en diferentes ámbitos clave como las ‘smart cities’ y las tecnologías de la accesibilidad y movilidad, así como en sectores como el sanitario, industrial y medioambiental.

8. ¿Qué consejos le daríais a alguien que quiere emprender?
Creo que es vital para el proyecto, que el negocio se base en la explotación de un concepto, idea, tecnología, producto, etc. del que el emprendedor tenga unos amplios conocimientos y manifieste un principal interés. Es decir, que su trabajo, que por supuesto no hay que negar que va a ser duro en muchas ocasiones, represente ocio e interés. Si no nos gusta lo que hacemos, difícilmente el proyecto tendrá éxito.
Por otro lado, situarse en la localización correcta es fundamental. En nuestro caso, pasar de estar aislados en Granada, a instalarnos en el Parque Tecnológico de Andalucía, el núcleo de un tejido productivo muy importante, y entrar en contacto con otras compañías y emprendedores fue clave.
Tampoco hay que subestimar la paciencia. Los resultados tardan mucho en llegar, y estabilizar una empresa de reciente creación es complejo, gradual y lento. Sin embargo, cuando comienzan a aparecer estos resultados y los hitos, y a lograr los primeros objetivos, es cuando la satisfacción obtenida compensa todo lo anterior y te da la energía necesaria para continuar.

Muchas gracias a Alberto por compartir con nosotros su tiempo y acercar Idintel a los lectores de BBits. ¡Mucha suerte!

La entrada Emprender desde cero con un perfil técnico, entrevista a Alberto López de Idintel se publicó primero en BorrowBits.

La mente humana está acostumbrada a tomar atajos que, aunque a veces son útiles para tomar una decisión rápidamente, también pueden provocar un resultado desastroso para ambas partes. Son los llamados sesgos psicológicos, y uno de los más comunes es el sesgo del pastel de tamaño fijo.

¿En qué consiste este sesgo?

Básicamente, consiste en la creencia errónea de que los recursos a negociar son un pastel de tamaño fijo que sólo podemos cortar en pedazos para tratar de hacernos con el de mayor tamaño.

Esta mentalidad no sólo dificulta la creación de valor (la posibilidad de hacer el pastel más grande), sino que también puede llevar a una devaluación reactiva: la tendencia a despreciar las concesiones de la otra parte, simplemente porque quien las ofrece es un adversario. El sesgo del pastel de tamaño fijo nos lleva a asumir que cualquier cosa que sea buena para ellos es mala para nosotros.

¿Cómo solucionar este problema?

En primer lugar debemos ser conscientes de que nuestra reacción inicial a una propuesta puede estar producida por nuestro piloto automático. Debemos preguntarnos: ¿estoy dejándome influir por este sesgo?

A continuación debemos cambiar nuestra mentalidad a un modo cooperativo: tratar de buscar zonas de acuerdos que puedan crear valor y hacer el pastel lo más grande posible antes de trocearlo.

Es mejor suponer que podemos agrandarlo y más tarde descubrir que estamos equivocados, a dar por sentado que su tamaño es fijo y llevar a cabo una mala negociación para ambas partes.

Si te ha gustado este artículo sobre psicología de la negociación, échale un ojo a éste: ¿deberías ser tú quien haga la primera oferta?

La entrada Psicología de la negociación: el pastel de tamaño fijo se publicó primero en BorrowBits.

Una cuestión muy debatida en las escuelas de negocios es quién debería abrir una negociación. ¿Quién debe hacer la primera oferta? ¿Qué actitud nos proporciona mayores ventajas? No olvidemos que negociar consiste en hacer cábalas, no tanto con la información que se conoce de la otra parte, sino con la que NO se conoce.

Diferencia de opiniones

Por un lado hay quienes opinan que NUNCA se debe hacer la primera oferta. Afirman que se debe dejar a la otra parte tomar la iniciativa, ya que esto nos proporciona información muy valiosa. El principal beneficio es que se establece un anclaje, es decir, una cifra que centra la atención a lo largo de toda la negociación, así como las expectativas de la otra parte. Según ciertos estudios, este anclaje determina en gran medida el resultado final.

Por el contrario, hay quienes opinan que somos nosotros quienes SIEMPRE debemos abrir la negociación. Esto nos permitiría tomar el control del diálogo y negociamos según nuestros propios términos. ¿El beneficio de esta actitud? Precisamente se trata del poder que proporciona el anclaje de la oferta inicial sobre el resultado de la negociación: si realizamos una primera oferta escandalosamente baja (o alta), el resultado final negociado tenderá también a ser mucho más bajo (o alto).

Está claro que hacer una primera oferta agresiva puede ser muy ventajoso. Entonces, ¿por qué a veces es mejor dejar al otro mover ficha primero?

La solución

La respuesta correcta es que DEPENDE. Depende de cuánta información dispongamos sobre los intereses y expectativas de la otra parte. Existen trucos para averiguar esta información (aunque eso lo dejaremos para otro artículo).

Si no tenemos idea de qué expectativas, alternativas e intereses contempla la otra parte, puede que nuestra primera oferta “agresiva” sea en realidad muy blanda. Imaginemos que esperamos cerrar un trato por 50.000 euros. Ese es nuestro objetivo. Así que lanzamos una primera oferta agresiva: 70.000 euros. Pero, ¿cómo sabes que la otra parte no estaba dispuesta a pagar 80.000? El poder del anclaje, así como unas expectativas erróneas, te han hecho perder más de 10.000 euros.

En resumidas cuentas…

Si tienes suficiente información sobre la ZOPA (Zona de Posible Acuerdo) puede que sea sensato hacer una oferta inicial agresiva. Si no es así, conviene dejar a la otra parte hacer la primera oferta. Sí, es cierto que perderías el poder del anclaje, pero también evitarías crear un anclaje erróneo (tanto por exceso como por defecto).

La entrada En una negociación, ¿deberías hacer tú la primera oferta? se publicó primero en BorrowBits.

En todo proyecto, lo primero es diseñar tu modelo de negocio. Algunos de vosotros no habréis oído hablar de esto en vuestra vida. No os sintáis raros, yo hasta más bien poco no había diseñado ninguno y ahora me dispongo a hablaros de él ya que con la experiencia me he dado cuenta de que es imprescindible.

No voy a reescribir la definición de modelo de negocio y las fases que implica, hay cientos de entradas al alcance de un clic que lo explican muy bien. Lo que sí trataré es de simplificaros la elaboración de vuestro primer modelo de negocio incluyendo las dos plantillas más importantes y que facilitan enormemente la elaboración del mismo.

• Business model Canvas es la plantilla más usada y como no podía ser de otra manera se encuentra encabezando esta lista. La gran ventaja de ella es que de un vistazo visualizas todos los puntos fundamentales de tu modelo de negocio. En este enlace os dejo un artículo interesante en el que explica brevemente cada uno de las secciones del mismo. En este enlace disponemos de la plantilla en español
• Lean Canvas es una herramienta que nos proporciona un lienzo para el modelo de negocio adaptado a una startup y que está basado en el libro “Lean Startup” de Eric Ries La diferencia con respecto al lienzo tradicional es que éste es más adecuado para startups mientras que el otro sería más apropiado para empresas consolidadas. En este artículo compara ambos lienzos y describe detalladamente el orden que debemos seguir a la hora de rellenar el Lean Canvas.

Recordad, el modelo de negocio es la primera piedra que tenéis que colocar para llegar a construir vuestro proyecto. A un click tenemos muchísimas herramientas que os permitirán validar si vuestro mercado existe y de las que hablamos recientemente en el blog. Validad vuestras hipótesis y el futuro será un poco menos impredecible.

¿Vosotros como planteáis vuestros modelos de negocio? ¿Conocíais estas herramientas? Espero que con este artículo os haya ayudado y que sea el inicio del proyecto de vuestros sueños.

La entrada ¿Tienes una idea? Primero diseña tu modelo de negocio se publicó primero en BorrowBits.

• ¿Cómo surgió la idea?

Fue en un viaje que hicimos Alejandro y yo a Londres. Nos dimos cuenta que si queríamos encontrar un buen restaurante en la zona debíamos llamar a nuestros amigos de Bilbao. No existía una herramienta que te permitiera preguntar a la gente local de forma fácil y gratuita. Ahí empezó todo.

•  ¿Cuál fue vuestro primer medio de financiación?

Nuestra primera ronda de financiación fue de amigos y familiares. Poco tiempo después tuvimos la suerte de contactar con Olli Pekka Kallasvuo, ex CEO y Presidente de Nokia a quien le encantó el proyecto y decidió unirse a la aventura.

•  ¿Qué ofrece Spotbros a un usuario de aplicaciones de mensajería instantánea que no le pueda ofrecer otras aplicaciones?

Spotbros es diferente a todas ellas, de hecho diría que en lo único que se parece al resto de apps es que puedes hablar en privado con tus contactos. A pesar de que nos comparen con ellas, Spotbros es algo totalmente nuevo. En Spotbros nuestros usuarios descubren grupos de chat públicos temáticos (Spots), donde comparten con otros usuarios información sobre los temas que les interesan. Spotbros es un lugar donde descubrir Spots, compartir información y quién sabe, conocer gente nueva con tus mismos intereses. Y eso es algo único que no ofrecen el resto de apps.

Existen miles de Spots creados sobre todas las temáticas que te puedas imaginar; cine, deporte, equipos de fútbol, club de fans, gastronomía… Los usuarios encuentran Spots de los temas que les interesa, se unen y comparten información de sus hobbies vía mensajería instantánea.

Además somos una app de mensajería instantánea que respeta la privacidad y seguridad del usuario. Nos tomamos muy en serio a nuestros clientes y por eso no almacenamos la información de usuario, eliminamos cada un máximo de 30 días la información de los servidores y además ciframos las conversaciones para que nadie pueda acceder a ellas.

•  De momento contáis con versiones de la aplicación para teléfonos con iOS y Android ¿tenéis en mente extenderos a otros sistemas como Windows Phone o Blackberry? ¿Y una versión de escritorio para PCs?

Ahora mismo estamos centrados en mejorar la app para Android y Iphone y convertirla en un lugar donde es más fácil descubrir y compartir contenido. Más adelante analizaremos que nuevas plataformas empezar a desarrollar.

•  Contáis con más de un millón de usuarios. ¿cuál es vuestra próxima meta?

Metas tenemos muchas pero principalmente nuestro objetivo es llegar a los cinco millones de usuarios en 2014.

• ¿Cómo pretendéis lograr la extensión de uso de vuestra aplicación en otros mercados como países de habla no española?

El primer paso es afianzarnos en España y una vez hecho esto expandirnos internacionalmente. Habrá que adaptar la app a los distintos idiomas y trabajar para conseguir presencia en los medios acompañada de distintas acciones de marketing.

• Ahora que WhatsApp está convirtiéndose en una aplicación de pago ¿esperáis un fuerte crecimiento de nuevos usuarios?

De hecho ya lo hemos notado. No todo el mundo esta dispuesto a pagar anualmente por WhatsApp y prefiere probar otras alternativas más completas y seguras que las hay.

•  ¿Qué opináis sobre Google Hangout? ¿Será un rival a la altura de WhatsApp?

El sector de la mensajería instantánea es una auténtica revolución en donde compiten grandes empresas. En este entorno nosotros tenemos que encontrar nuestro hueco e innovar. Diferenciarnos. Como he explicado antes, Soptbros no es una app de mensajería más, es una app donde descubrir contenido en función de tus intereses. Unirte a Spots con miles de personas y acceder a información y compartirla a través del chat, algo que no puedes hacer con el resto de aplicaciones de esos gigantes.

• En cuanto a vuestro modelo de negocio, ¿Cómo es posible rentabilizar una aplicación como Spotbros gratuita y sin publicidad?

Serán las empresas las que, a futuro, pagarán por ofrecer un servicio de calidad a sus clientes en Spotbros. Ya sea información, atención al cliente, resolución de incidencias… todo a través del Chat.

•  ¿Pensáis en implementar en un futuro un sistema de financiación como por ejemplo micropagos o con la inclusión de publicidad?

No, la aplicación será siempre gratuita para los usuarios.

•  ¿Veremos alguna opción de llamadas por VoIP en vuestra aplicación?

Es una opción pero no en el corto plazo, actualmente las llamadas por VoIP no funcionan bien si no estás con una buena conexión Wi-Fi. Además de que las apps que incluyen esta opción suelen tener un consumo de batería excesivo. Creemos que es una funcionalidad buena pero con unos efectos colaterales demasiado importantes para el usuario.

• ¿Tenéis en mente futuros proyectos relacionados o no con Spotbros?

De momento estamos 100% centrados en nuestra pasión, ver crecer Spotbros.

• ¿Qué consejo le daríais a aquellos emprendedores que como vosotros tienen una idea y quieren desarrollarla?

Que deje de pensar. Que se lance. Ahora bien, tiene que saber que el camino no es fácil. Que emprender no es de color de rosa. Que va a tener que respirar su proyecto, vivir por él, soñar con él. Que habrá momentos buenos y momentos muy malos. Y sobre todo, que se rodee de un buen equipo, de los mejores que sea capaz de encontrar. Que les haga sentir el proyecto como propio y ponerse manos a la obra.

Nuestro primer prototipo lo lanzamos al mercado con un coste cero (sin contar las horas invertidas). ¡Haz un prototipo rápido y lánzalo! No esperes a que esté perfecto, no hay tiempo. Y además, cuando lo lances, verás cómo lo usan los usuarios y te darás cuenta de que tienes mil cosas que cambiar. Tras 20 versiones tu aplicación no se parecerá en nada a la primera versión, y si se parece, probablemente algo estés haciendo mal.

La entrada [Entrevista] Conocemos al equipo de Spotbros se publicó primero en BorrowBits.