Inovação tem a ver com o momento e o quanto diminuímos riscos e incertezas.

Em inovação, o importante não é medir se você está dentro do budget, escopo ou tempo. Em inovação e principalmente no momento da busca de inovação, é importante que você tenha em mente como diminuir riscos e incertezas de novas ideias de negócio antes de investir grande em escala. E isso não é fácil de se fazer.

Eu trabalho na Sympla que é uma empresa da Movile. Na Movile, temos um conceito que tenta trazer esse espírito de experimentação para produtos e projetos. Chamamos essas iniciativas de Jetskis. O Fabrício (fundador da Movile e agora CEO do iFood) falou um pouco sobre isso esses dias. Essa ideia não é totalmente nova, mas consegue materializar bastante bem a dinâmica de criação e validação de hipóteses de uma maneira bem rápida.

Tipos e inovação

Assim como estratégia, inovação é algo difícil de definir. Existem diversas definições pelo mercado. E é difícil de definir porque não existe um tipo só de inovação. Inovação está mais ligada a fases ou momentos do negócio do que algo que pode ser materializado ou seguido passo a passo. Isso não acontece porque as empresas são diferentes e atuam de formas diferentes, mesmo que os mercados sejam os mesmos.

Eu gosto bastante dessa Matriz que o Greg Satell montou para organizar um pouco melhor os tipos/momentos de inovação de uma empresa:

Diferentes tipos de inovações necessitam de diferentes tipos de skills, recursos, investimentos e especialidades. Além disso, algumas inovações, para darem certo, requerem que alguns times e partes da empresa trabalhem de maneira mais solta, flexível, sem grandes pressões por resultados.

Ainda seguindo este mote de dividir inovação em momentos, eu adoro a forma como o Clayton Christensen divide a inovação em três tipos:

• Transformative é a inovação mais difícil de acontecer, pois envolve explorar oportunidades e hipóteses fora da área de atuação core da empresa. Para tentar esse tipo de inovação, a empresa precisa investir não apenas em times e novas áreas da empresa, mas também em uma nova lógica de pensamento de operar e principalmente em uma mudança de modelo de negócio. Contudo, esse tipo de inovação direciona a empresa para uma posição de visão de mais longo prazo;
• Sustaining é a inovação que explora oportunidades em mercados e oportunidades adjacentes à atuação core da empresa, com o intuito de fortalecer o modelo de negócio já existente, talvez criando produtos ou serviços novos para servir problemas ainda não solucionados em mercados no qual a empresa já atua e conhece. Aqui entra também, por exemplo, planejamentos para expansão internacional, explorar novos canais de distribuição e assim por diante;
• Efficiency é aquela inovação que explora oportunidades que melhoram o modelo operacional de negócio core da empresa, em cima de mercados que já atuamos, usando, na maioria das vezes, produtos e serviços que já temos. Dessa maneira não mudamos o modelo já existente da empresa de forma muito substancial, mas de forma sutil, o suficiente para atendermos melhor os segmentos já existentes. Aqui melhoramos muito operações, processos, distribuição, marca etc;

Em cada um dos tipos de inovação, os riscos também mudam. No modelo onde atacamos mais eficiência, o risco é quase nulo e quase não há incertezas, exatamente porque já atuamos e somos bem sucedidos nesse mercado. Mas a desvantagem é que ficamos cada vez mais próximos da disrupção, principalmente quando surge um novo entrante no mercado, com ideias mais frescas e processos mais leves.

Existe um framework que divide a inovação em dois momentos. Vou usar os nomes desses momentos em inglês, porque eles têm a mesma tradução no português. Os momentos são Explore e Exploit.

É importante notar que Explore tem muito a ver com procurar, descobrir, encontrar o modelo ou a hipótese que poderá ter sucesso, ou seja, que consiga ter o menor risco de inovação e maior retorno esperado. Já o Exploit procura crescimento, growth. Na fase de Exploit, nós procuramos aumentar e manter o retorno que o modelo já está trazendo para empresa e diminuir o risco de disrupção que poderá vir do mercado ou até mesmo por falta de capacidade de sustentação do negócio.

Explore

Esse momento envolve descoberta no sentido de diminuir incertezas e entender quais os riscos de disrupção desse modelo de negócio ou hipótese que queremos implementar no negócio.

É um momento onde iremos analisar o mercado para encontrar soluções similares que validem de alguma forma nossa ideia, nos ajudando a diminuir o risco e as incertezas.

Aqui também entra toda uma análise de retorno econômico. Se você estiver em um mercado onde não há nenhuma empresa que seja de capital aberto, fica difícil ter números para servir de base, então, o estudo deverá ser inferido de alguma forma que materialize melhor esses números.

É aqui que devemos analisar os famosos 4 tipos de riscos de inovação:

• Desejável: será que o cliente quer/precisa/deseja/tem interesse no que você está construindo? O mercado pode ser pequeno demais, com poucos clientes interessados que não compensa o esforço/investimento. Não tem escala nem agora, nem no futuro;
• Viável: será que a empresa pode investir tempo e dinheiro nessa hipótese? Será que a empresa consegue arcar? O risco é que o negócio não tenha dinheiro para investir, não apenas para montar times de desenvolvimento, mas algumas estratégias precisam de marketing, vendas, compra de maquinário ou qualquer outro tipo de investimento que explode o budget antes mesmo da gente implementar a ideia;
• Possível: será que nós conseguimos construir e entregar em um período de tempo factível? Legal, nós podemos até ter time suficiente, mas será que dá tempo? Temos também o risco da empresa não conseguir ter acesso à recursos chave, nem consegue criar especialidades importantes que viabilizam de verdade a execução/implementação da ideia;
• Adaptável: será que fatores externos são favoráveis para receber essa ideia? Será que o momento econômico é favorável? Existe alguma regulamentação tramitando que poderá inviabilizar o produto no futuro? Esse é o risco do negócio não conseguir se adaptar ao ambiente competitivo, legal, tecnológico, social ou até jurídico;

Algumas perguntas interessantes para se fazer nesse momento:

• Quanto você conseguiu diminuir de risco ou incerteza dessa ideia? Quais riscos ainda permanecem e que deverão só ser diminuídos em um estado avançado de implementação?
• Quanto essa ideia é grande no sentido de retorno financeiro? O quanto ela pode escalar? Quantas oportunidades de novas linhas de receita ela cria no futuro?
• Quanto tempo gastamos até agora com essa ideia? O que realmente temos certeza que aprendemos nesse tempo?
• Quanto tempo já gastamos ou iremos gastar para testar essa ideia? Quanto custou para testar ou quanto custará para testar essa ideia?

Exploit

Esse momento é o momento de escala. É o momento de mitigar mais ainda o risco de disrupção ou até morte do modelo aplicado, além de impactar ainda mais o retorno financeiro. Aqui você pode medir esse retorno como lucro, receita, aumento de receita, controle de margem ou qualquer outro indicador financeiro que sua empresa prefira (EBITDA, estou olhando pra você). É importante que seja um indicador no qual sua empresa consiga avaliar o sucesso desse modelo e que, unido com a diminuição do risco de disrupção, traga certeza de que o modelo realmente foi validado.

Aqui a hipótese já não é mais uma hipótese, mas um modelo funcional de negócio, já sendo usado pelo mercado e gerando, mesmo que pouco, algum retorno financeiro para a empresa e entregando valor para os clientes.

É interessante que há algumas fases aqui:

• Escala: fazer o modelo realmente decolar, sair do chão e ter taxas de crescimento relevantes para que entendamos que o negócio realmente vale a pena ser mantido por mais tempo, apontando que há growth saudável;
• Impulsionar: impulsionar o modelo para um nível que ele possa se tornar um modelo confiável e sustentável. Nessa fase, que podemos até apontar como sendo aquela fase de platô/declínio da vida de um negócio/produto, é importante que continuemos a entregar mudanças/atualizações relevantes para o negócio continuar crescendo de forma saudável;
• Proteger: momento de focar em manter uma posição forte no mercado e perante a concorrência, protegendo o negócio de novos entrantes ou reações de concorrentes já estabelecidos. Nesse caso, o terceiro tipo de inovação do Christensen, Efficiency, é essencial, porque o negócio vai precisar penetrar mais no mercado em que já atua, criar moats para defesas e fortalecer a relação com os clientes já existentes;

Algumas perguntas:

• Será que ainda temos espaço ou elasticidade de mercado para escalar o nosso produto antes de pular para um mercado totalmente novo?
• Será que estamos gerando mais repetição de negócio do que criação de base engajada? Os clientes realmente estão percebendo valor por meio desse modelo?
• Qual o esforço (financeiro, de processos, ferramentas ou de pessoas) que precisamos fazer para conseguir manter o negócio crescendo de forma relevante?
• Quando sabemos que chegamos no platô e agora está na hora de proteger o nosso posicionamento? Nossos concorrentes estão crescendo ainda ou eles estão se posicionando de uma maneira defensiva?

Esse momento e Exploit é importante para que o modelo se estabeleça de maneira que a empresa consiga dedicar mais tempo para novos negócios ou produtos e serviços que tragam mais inovação no médio/longo prazo.

Concluindo

É importante que o time de produto saiba em quais dessas fases a empresa está, pois isso indica a fase que o produto deve estar. Se a empresa estiver em um momento de growth, o produto precisa se mexer rápido, não dá para passar longos períodos pesquisando, é necessário ser mais orgânico aprendendo rápido. Se o negócio está numa fase mais de Efficiency, não se frustre por tudo estar muito parado, essa é a fase do negócio e você precisa se adaptar de acordo.

O timing do produto deve ser o mesmo timing do negócio.

Referências

• There Is No One True Path To Innovation | Digital Tonto
• 3 Types of Innovation You Should Know | HBS Online
• Fresh Insights From Clayton Christensen On Disruptive Innovation
• Disruptive Innovation Theory: 4 Key Concepts | HBS Online

TODOS os líderes, diretores, CEOs deveriam ler esse livro, e nem precisa ser o livro inteiro, mas pelo menos o segundo capítulo. Reinventando as Organizações de Frederic Laloux é sem dúvida um livro para guardar na cabeceira como referência sobre estruturação de times, cultura corporativa e gestão de pessoas.

Percebi com esse livro que tudo o que eu sei e tento executar sobre gestão baseada em empoderamento nas pontas, autonomia e alinhamento são apenas fragmentos. Esse livro me ajudou a criar um racional mais linear, coerente e claro sobre gestão flat. Pra falar a verdade, eu ainda não acredito muito em formatos de gestão sem hierarquia, não porque eu ache que não funciona, mas por que aqui no Brasil, ainda, não temos maturidade pra isso. E a maturidade não existe em nenhum dos níveis da empresa, começando pelos funcionários e indo direto para os altos escalões.

Esse tipo de gestão orgânica, é uma resposta criadas contra exatamente ao modelo atual de gestão popular altamente hierarquizada, que gera diversos conflitos de interesse e é totalmente te descompassado com as emoções, psicologia e comportamento humano. O livro do Frederic Laloux simplesmente juntou em apenas um livro tudo o que eu tento praticar no dia a dia com times locais, em doses homeopáticas. E precisa ser em doses controladas, por que as pessoas não estão preparadas e nem sempre há autonomia necessária. Por isso é algo que não precisa ser feito 100%, mas você já consegue ver resultados positivos misturando os modelos: mantenha a hierarquia, mas delegue as decisões aos poucos para as pontas, até que todos aprenderam a usar autonomia e tenham segurança para praticar.

Estamos presos no modelo tradicional

O tipo de gestão que é aplicado hoje nas empresas, inclusive nas startups de tecnologia que se dizem com times autônomos auto-organizados com pessoas empoderados, me parece ser bastante inconveniente, colocado ali apenas por que faz parte desse tipo de cultura “moderno descolado”. Todos tentam fazer só por que o manual manda e não para resolver realmente a forma que as pessoas se relacionam com o trabalho e consequentemente com os resultados da empresa. Eu sei que essa crítica pode ser bastante mal interpretado, mas eu nunca vi nenhuma empresa realmente tentar, de verdade, aplicar um tipo de gestão onde não houvesse um controle velado de uma hierarquia que nunca se desfez de verdade. E isso não é errado de forma alguma. Só se torna errado quando você diz que a cultura de gestão é uma, mas executa outra. Sou sortudo por ter trabalhado em empresas que tentavam mesclar uma gestão mais flexível, embora hierarquizada, onde todos tem alguma autonomia.

Quando definimos para nossa vida metas desconectadas da nossa individualidade mais profunda e quando vestimos os rostos de outras pessoas, não permanecemos na potência do nosso ser. Inevitavelmente, nos sentimos incapazes e investimos muita energia tentando superar nossas fraquezas ou culpando outros e nós mesmos por não sermos quem pensamos que deveríamos ser. — Laloux, Frederic. Reinventando as Organizações

O alto escalão de TODAS as empresas deveriam ler esse livro. Não para revolucionarem suas empresas atuais de forma imediata, mas pra mudarem (ou reforçarem) suas formas de gestão e então imbuirem seus negócios com uma cultura que realmente cause impacto nas pessoas ligadas às empresas.

Eu conhecia alguns dos cases mencionados no livro, como a Valve, por exemplo, mas os exemplos que começam a ser citados a partir do capítulo 2 explodiram minha cabeça. O livro não explica no detalhe como essas empresas se organizaram ou os passos táticos que os gestores e alta liderança trilharam para realizar os feitos. Acho que essa é uma enorme oportunidade pra autores como o Frederic Laloux.

Mudar é difícil por causa da forte influência da cultura tradicional, principalmente na vida pessoal

Manter e organizar empresas ou times no formato proposto e exemplificado no livro é difícil. Embora exista momentos em que o autor disse que é possível, a coisa não é fácil, sobretudo quando você tenta aplicar algumas práticas de auto-gestão em empresas que tem uma estrutura hierárquica tradicional forte. Por sorte, trabalho hoje em uma empresa que permite aplicar algumas das premissas e da pra ver que o desconhecimento e a desconfiança das pessoas afeta bastante o processo. Escrevi um artigo chamado Sobre receber e dar autonomia, que mostra como é difícil alguém aprender a usar e a receber autonomia da sua liderança. As pessoas estão tão acostumadas a uma estrutura de comando e controle que elas se perdem com tanto poder (no sentido de poder realizar algo). E isso não acontece apenas na sua profissional, mas também na pessoal: igreja, família, amigos, Colegio… em todos esses pontos da vida, há uma hierarquia, com regras exclusivas e rígidas que precisam ser seguidas sob o olhar de alguém acima de você.

Tudo baseado na confiança

Acho que a confiança é quesito mais importante para criar organizações baseadas nos princípios de auto-gestão.

Você precisa delegar não só algumas, mas todas as decisões para todas as pessoas. O CEO não toma decisão alguma sobre qualquer coisa. Obviamente há restrições a seguir: ninguém pode simplesmente tomar uma decisão, sem antes se aconselhar com todas as partes impactadas. Veja bem:

• Se a ideia for boa, todas as partes irão aceitar e seguir a ideia sem problemas algum, por viram valor maquilou;
• Se a ideia for ruim, as partes irão dissuadir a pessoa de não aplicar a ideia, por que ainda há pontos a resolver ou discutir;
• Se mesmo assim a pessoa (ou grupo) decidir aplicar a ideia sem consultar ou tentando forçar uma adoção, as partes podem simplesmente não adotar a proposta e a ideia morre por inanição;

Você tem o direito de tentar sugerir e aplicar qualquer coisa que queira, e o grupo tem o direito de ajudá-lo ou não.

quanto mais complexa nossa visão de mundo e nossa cognição, maior é a efetividade para lidarmos com os problemas que se apresentam. — Laloux, Frederic. Reinventando as Organizações

Um exemplo no livro de uma empresa de peças industriais, sobretudo automotivas, chamada FAVI, onde um dos integrantes dos time, chamado Frank, entendeu que a empresa poderia ser mais inovadora se eles explorassem novas máquinas, processos e novos materiais. Então, ele queria assumir a responsabilidade de sair pelo mundo procurando novas tecnologias e processos para melhorar a fabricação. Ele falou (pediu conselho) para o CEO, Zobrist, que achou que ele tinha um ótimo perfil pra isso e motivou a fazê-lo.

Atrás da fachada e da bravata, a vida de um líder corporativo poderoso também é um sofrimento silencioso. Sua atividade frenética é muitas vezes a cobertura perversa de um profundo senso de vazio interior. — Laloux, Frederic. Reinventando as Organizações

Contudo, nesse caso, não era Zobrist que decidiria sobre o papel dele, então Frank deveria provar que esse papel tem valor pra empresa e para os times. Então ele começou a viajar o mundo procurando o que a fábrica pudesse usar e melhorar seus processos. Uma sexta-feira por mês, Frank fazia uma apresentação, aberta, para quem quisesse assistir. Ele informava o assunto que seria abordado na descrição do compromisso e então áreas e pessoas que estivessem interessadas estavam livres para comparecer. Como funcionaria:

• Se os colegas vissem valor nessa responsabilidade e comparecesse nas reuniões, haveria um indicativo de que essa responsabilidade estava entregando valor para o time.
• Se as pessoas aplicassem as ideias trazidas e realizassem mudanças sugeridas, sua responsabilidade de solitária poderia se tornar um time, aumentando a potência do trabalho já feito (um time de Research e Inovação, por exemplo).
• Se as pessoas não comparecessem, provavelmente ninguém estaria vendo valor naquilo, e ele deveria encontrar uma nova responsabilidade ou iniciativa na fábrica.

Foi um sucesso! Frank tem viajado o mundo, procurando novas tecnologias e novos fornecedores. Ele trabalha sem um orçamento e sem alvos, como todos os outros na FAVI. Ele é confiável para ser sensato em suas despesas de viagem e hotel. Cerca de uma vez por mês, ele volta à fábrica numa manhã de sexta-feira e realiza uma conferência para compartilhar suas descobertas. O tema determina quem dentre os operadores ou engenheiros aparece na conferência. Se as pessoas escolherem participar da reunião e captar suas ideias é prova de que seu papel é valioso. Se, em algum momento, os colegas pararem de ir às reuniões das manhãs de sexta-feira, seu papel naturalmente deixará de existir. Nesse caso, Frank precisaria encontrar um novo papel para si próprio, possivelmente juntando-se a uma equipe como operador de máquina.

Página 100, Reinventando Organizações

Esse tipo de confiança deve ser construída. Como eu disse antes: estamos tão acostumados a sermos direcionados, a não lidarmos com autonomia, a não tomarmos decisões difíceis na empresa por medo ou receio das consequências que cenários de alta liberdade como o exemplo acima estão totalmente fora do nosso radar.

Concluindo

Achei o início do livro muito “esotérico”. Ele se refere a empresas que tem uma gestão flat, onde as pessoas tem um altíssimo poder de decisão nas pontas, onde não há hierarquia quase nenhuma e os funcionários não tem um cargo específico, como empresas que contribuem para uma nova consciência humana. Achei muito mítico e utópico a forma como ele aborda o assunto. Parece que o autor tira a carga técnica que vemos em livros comuns de gestão e negócios e coloca no lugar um sentimento mais espiritual pra coisa.

Contudo, ignorando o “esoterismo” e se apegando ao foco de gestão e estruturas organizacionais, o livro é ótimo. Eu realmente quero começar a aplicar ideias e atitudes de auto-gestão em meus times e fundamentar mais a minha atitude de dar mais autonomia e alinhamento para os times tomarem decisões. Eu mesmo tenho muito a aprender nesse quesito de “direcionar” sem ser “diretivo”. Sutilezas que mudam tudo.

Referências:

• REINVENTING ORGANIZATIONS — Home
• Reinventing Organizations — YouTube
• FAVI: How Zobrist Broke Down FAVI’s Command-and-Control Structures
• http://www.favi.com/management/
• Holacracy — Evolve Your Organization
• Holacracia Brasil | Holocracia | Holacracy

Originally published at https://diegoeis.com.

Existem uma série de métodos e workflows de produtividade disponíveis por aí. Mas eu não uso nenhuma de forma completa e íntegra. O que eu fiz foi tentar adaptar hábitos e um ou outro workflow para o minha rotina e tem funcionado muito.

Eu não tenho uma disciplina correta de olhar minha lista de tarefas todos os dias de manha, por exemplo. Eu uso muito o Todoist para organizar as tarefas importantes que precisam ser feitas, mas geralmente, essas tarefas importantes já estão no meu radar (memória) e raramente perco elas de vista. Tanto, que no final do dia, geralmente, só marco todas elas como feitas. Contudo, tem algumas tarefas que deverão ser feitas dali uns dias, então, o Todoist serve para me lembrar delas e melhorar meu planejamento de médio/longo prazo.

Nunca escrevi sobre isso aqui, então, provavelmente pode ser que não faça sentido pra você, mas isso nem importa muito, por que na verdade, suas práticas pessoais de produtividade, tem que fazer sentido pra você. Contudo, é legal saber quais as práticas de outras pessoas para saber se há algum hack que você pode importar e adaptar para sua rotina pessoal.

Priorização: Eisenhower Matrix

Uso a própria ferramenta de prioridades do Todoist para escolher a importância das tarefas. Contudo, uso um esquema simples pra facilitar o processo chamado Matriz de Eisenhower.

Não crio uma matriz bonita e tudo mais. Eu faço o mais simples possível, que é até explicado nesse artigo da própria Todoist:

Levando em consideração a categoria de priorização citada a cima, eu tento me focar mais nos níveis P1 e P2. Entre esses dois níveis, tento sempre me focar nas tarefas que estão em P2. O nível P3 eu evito com todas as forças e P4 eu nem categorizo. Na verdade, eu não deveria fazer nenhuma tarefas que não seja importante ou não seja urgente, então, ou está no Todoist só como lembrete para não esquecer (o que é mais correto estar em um app de anotação, como o Bear) ou nem devo perder tempo cadastrando.

De tempos em tempos faço uma varredura nas tarefas para procurar as tarefas P1 (tarefas urgentes e importantes) que não foram feitas ainda ou aquelas que não tem data pra terminar. Não deveria ter uma P1 esquecida, pois se ela é Urgente e Importante, ela não deveria estar dando sopa por aí durante muito tempo. Então, se eu vejo uma tarefa P1 que está demorando pra ser feita, tento descobrir se ela depende de mim, se depender só de mim, eu “ como o sapo”, caso contrário, se ela estiver fora do meu controle total, eu tento diminuir a prioridade (e fico cobrando a pessoa/área para agilizar), até que um dia ela seja feita ou perca importância até chegar no P4.

Coloco data para (quase) tudo

Outro hack que uso é que todas, ou pelo menos a grande maioria das tarefas, devem ter uma data. Oras bolas: se você tem uma tarefa, ela precisa ser feita em algum momento, logo, precisa de uma data para ser feita.

Eu sempre mantenho as datas nas tarefas para que elas fiquem sempre no meu radar. A funcionalidade postpone me ajuda a procrastinar tarefas que podem estar muito cedo para serem feitas ou que eu estimei errado a data de conclusão. Se eu uso muito a funcionalidade de postpone, quer dizer que:

1. Tenho um problema que está me impedindo de executar essa tarefa. Pode ser desde desleixo ou até outras tarefas bloqueando a execução;
2. Verifico se a tarefa ainda precisa ainda ser feita ou perdeu prioridade por conta de alguma circunstância;

Tarefas que não tem data, somem na minha lista. Tento não ter tarefas sem data. Se não tem data para fazer, não é importante e vira só uma anotação.

Labels

A invenção de labels (ou tags) é tão importante quanto a luz elétrica. É uma forma fácil de categorizar e organizar coisas. Não tenho um padrão legal para labels. Contudo, uso a regra padrão universão de uso de labels: uso nome de labels de forma genérica, permitindo que elas possam ser usadas em projetos de assuntos e contextos diferentes.

As minhas labels são:

O padrão aí é o tipo de trabalho. A tarefa pode ser um hábito, de cunho pessoal, uma compra, ou assistir algo, etc. Tem espaço pra melhorar aí. Label é uma das features mais flexíveis de taxonomia que existem e está presente em diversos serviços que precisam facilitar a organização, sobretudo textual. Você pode usar labels em formato de verbo. A Todoist tem umas regrinhas legais aqui.

Crie o seu workflow ou pegue um disponível da prateleira e adapte

Como eu disse no início, eu não sigo um workflow “de mercado”. Eu simplesmente customizei meu fluxo de acordo com a minha rotina. Contudo, há uma série de workflows que podem funcionar muito bem para você. Alguns:

• Getting things done
• Time blocking
• Eat the frog
• The Pomodoro Technique
• The Eisenhower Matrix
• Systemist
• The Medium Method
• Objectives & Key Results
• The Weekly Review
• The Commitment Inventory

A Todoist fez um quiz incrível que te ajuda a descobrir qual é o workflow certo pra você. O meu é o Eat the Frog. ;-)

Conclusão

Produtividade é algo pessoal. Acredito que todos já temos uma parte da rotina diária que é executada de forma bastante natural. A outra parte é aquela porcentagem “forçada” das tarefas e da rotina, que precisa ser empurrada para ser executada. A ideia é que você execute suas tarefas da maneira mais limpa, rápida e indolor possível. A produtividade, como já disse em outros momentos, tem mais a ver com a qualidade e com os resultados obtidos do que com a quantidade de coisas que são executadas. Com certeza em alguns momentos será necessário adaptar um pouco alguns dos seus hábitos para encaixar fluxos que tornarão seus dias mais produtivos, contudo, se tornar mais produtivo não quer dizer aumento da qualidade de vida. A graça é entender qual é essa moderação.

Originally published at https://diegoeis.com.

Esse texto foi publicado muito antes na PM Letter. A Newsletter feita para PMs e pessoas que trabalham com produtos digitais. Assine e entre para um grupo de mais de 1550 pessoas. Eu adoro anotar coisas: reuniões, palestras e ideias. É um jeito de me conectar com o assunto e iniciar conexões com outros assuntos que conheço. Esse texto é uma dessas anotações. Você vai perceber que ele não está muito bem estruturado. Por isso, releve problemas com continuidade, typos, parágrafos com possíveis finalizações bruscas. Saiu direto do meu Bear, para a PM Letter.

Geralmente falamos muito sobre as empresas estruturarem vantagens competitivas para chegarem à uma posição estratégica e confortável no seu mercado, setor e indústria. Essas vantagens, pelo menos para mim, sempre se apresentam como “ataques” ou “ações pró-ativas” de empresas para chegarem mais rápido enquanto, de alguma forma, dificultam a jornada dos seus adversários. Contudo, pouco é falado sobre o que deve ser feito quando as empresas já chegaram num lugar privilegiado no mercado, tendo vantagens perante seus adversários. Como ela pode se manter naquela posição? Como ela pode criar dificultar a possibilidade de novos entrantes ou até mesmo neutralizar ações da concorrência a fim de defender sua posição atual?

As defesas ajudam a empresa a preservar as suas vantagens e seu posicionamento estratégico, além de dar tempo para planejar os próximos passos do negócio para ampliar sua vantagem. Algumas defesas mais usadas são:

• Acesso à matéria prima;
• Localização geográfica;
• Relacionamento com players do mercado;
• Relacionamento com o governo e/ou reguladores;
• Patentes e licensas;

São defesas importantes para empresas que estão em um ambiente bastante competitivo, onde adversários são do mesmo tamanho ou maiores que ela mesma. Nesse caso, ter controle sobre a maior quantidade de matéria prima é essencial para diminuir o avanço do adversário. Criar alianças e parcerias com outros players que ajudem a empresa a aumentar o valor da sua plataforma, também ajuda a diminuir as opções de escolha dos adversários e principalmente de novos entrantes.

Saber se relacionar com governo e reguladores ajuda prevenir quebras de leis, se mantendo dentro das restrições e criando oportunidades e vantagens para mitigar custos. O Uber usa muito essa abordagem. Como ele quebra um paradigma muito grande de comportamento da sociedade e do sistema de transporte, estar perto do governo é uma alternativa para influenciar afrouxamento das restrições e de criação de novas regulamentos mais flexíveis.

Defesas importantes para empresas de tecnologia

Existem 4 outros tipos de defesas, mais abrangentes e provavelmente mais difíceis de serem dominadas, que impactam diretamente todas as empresas, inclusive as empresas de tecnologia que tem seus serviços baseados no mundo digital.

Essas defesas também impactam forma com que o negócio se comporta, explorando profundamente a desvantagem dos competidores ao mesmo tempo que cria um ambiente defensivo praticamente permanente para as empresas:

• Marca: Gillete. Bombril. Maizena. São apenas algumas das marcas que se tornaram sinônimos de produto. A marca ajuda as pessoas a se lembrarem do que resolve o problema delas. A marca ajuda as pessoas a terem empatia com a sua empresa. A marca expressa as propostas de valor que a empresa oferece para as pessoas e para o mercado. A marca ajuda as empresas a criarem barreiras psicológicas de qualidade, de performance/desempenho e de resultado;
• Integração Operacional (Embedding): SAP, Oracle, TOTVS, Microsoft. São exemplos de empresas que tem produtos e serviços que se integram nos processos operacionais das empresas, se tornando parte do seu dia a dia. Quando seu serviço se torna parte do processo, as empresas podem perder muito dinheiro, tempo e esforço se trocarem para outro tipo de solução. Isso se aplica bastante a organizações, mas há serviços que se focam em pessoas como Todoist, Bear, Notion, Miro, que ajudam nos processos diários de organização, criativos e pessoais de pessoas comuns;
• Escala: Amazon, Google, Apple. Quando você ganha escala, você ganha de presente uma série de vantagens. Maior volume significa diminuição de custos. Mais pessoas usando seu produto, significa poder de barganha, poder de negociação, poder de relacionamento e principalmente impacto social e financeiro. Os governos de países podem fazer concessões para que a empresa permaneça com seus negócios ali. Quando se é muito grande, a matemática está do seu lado;
• Efeito de Rede: Twitter, Facebook, Mercado Livre. Talvez o mais barato e mais efetivo de todas as defesas: quanto mais pessoas ou empresas usam seu serviço, mais valor é gerado. Quanto mais se gera valor, mais pessoas se interessam em usar seu serviço. Quanto mais as pessoas usam seu produto e se beneficiam do valor que ele entrega, menos interesse as pessoas tem de usar os competidores. Quanto mais uso, mais se percebe valor e menos necessidade as pessoas tem de procurar um outro serviço;

Dessas, o Efeito de Rede é a defesa mais acessível para conseguir criar, monitorar e manter. Se você quiser se aprofundar de verdade nesse assunto de efeito de rede, sugiro que procure ler mais sobre Sistemas Dinâmicos.

O conceito de Sistemas Dinâmicos foi criado no meio dos anos 1950 por Jay Forrester no MIT. É uma abordagem para entender comportamentos não lineares de sistemas complexos (outro assunto que merece estudo).

Imagem: Keynes’s trade cycle: A system dynamics model — Scientific Figure on ResearchGate. Available from: https://www.researchgate.net/figure/System-dynamics-model-of-Keynes-theory-of-the-business-cycle-and-crisis_fig1_270245395 [accessed 16 Sep, 2020]

Outras defesas para qualquer tipo de empresa

Obviamente essas não são as únicas defesas existentes. Existem defesas mais operacionais e táticas, que podem ser moldadas praticamente em qualquer tamanho de empresa. Exemplos:

• Controle do processo de entrega do serviço;
• Entrar em negócios secundários estratégicos que tenham integração com o principal negócio da empresa;
• Contratação de especialistas e profissionais;
• Contratos de exclusividade;
• Proteções regulatórias;
• Investimento em pequenas empresas potenciais competidores;
• Investimento em empresas com inteligência, tecnologia, patentes;

Existe uma conceito usado por algumas empresas que se destacam da maré turbulenta de crescimento a qualquer custo. É um conceito cunhado pelo Jim Collins, chamado Marcha das 20 Milhas. A Marcha de 20 Milhas diz que as empresas precisam moderar, controlar e planejar sua velocidade de crescimento, independente do que o mercado, investidores e consumidores achem que ela deveria acelerar crescimento mais rápido que a concorrência. O que importa nesse conceito é entregar resultados positivos de forma constante, com um foco de geração positiva de resultados de médio e longo prazo.

Posso explicar esse conceito em outro post, mas por enquanto, quero destacar que esse conceito pode fazer parte da estratégia de defesa das empresas: manter um ritmo constante de crescimento, que seja saudável, possibilitando a economia de energia, dinheiro e tempo, possibilitando dar passos mais fundamentados e firmes, se protegendo de impactos imprevisíveis do mercado, adversidades internas ou posicionamentos agressivos da concorrência. A palavra resiliência se encaixaria aqui. Um caso interessante é a da Southwest. Leia mais depois.

Referências:

• What Makes a Business Defensible?
• Paper: Keynes’s trade cycle: A system dynamics model
• Defensibility x Scalability = The Marketplace Matrix
• How do I evaluate a startup’s competitive advantage and defensibility?
• Marketing strategy of Amazon — Amazon marketing strategy
• How Network Structure Shapes Defensibility and Scalability

Originally published at https://diegoeis.com.

Defesas competitivas — Blog do Diego Eis was originally published in productoversee on Medium, where people are continuing the conversation by highlighting and responding to this story.

Engajamento e retenção são dois dos fundamentos mais importantes na construção e manutenção de produtos e serviços digitais. É muito fácil confundir o significado dos dois e principalmente definir quais usuários são engajados e quais são retidos.

Neste texto quero me focar em Engajamento e em um momento posterior, podemos falar melhor sobre Retenção.

Artigo publicado muito antes na PM Letter. A Newsletter feita para PMs e pessoas que trabalham com produtos digitais. Assine e entre para um grupo de mais de 1650 pessoas.

Antes de falar de engajamento, precisamos falar um pouco sobre entrega de valor

Engajamento e retenção são importantes pois é como você consegue construir um nível de lealdade e geração de hábito dos usuários em relação ao seu serviço/produto. A criação desse loop de lealdade e hábito se dá quando estimulamos:

• Percepção de valor no momento da experiência de uso;
• Retorno recorrente do produto, seguido de uso recorrente;

Falamos muito sobre entrega de valor por meio do nosso produto. Mas, na minha opinião, temos um erro de interpretação aí:

1. Valor só é percebido quando o usuário usa o produto/serviço. Antes disso, o usuário só tem suposições de que o seu produto ou serviço vai trazer um determinado benefício para ele. Benefício significa, dentre outras coisas, resolução de problemas, saciedade de desejo e/ou necessidade ou aumento de desempenho/produtividade;
2. Nós não entregamos valor, nós facilitamos a percepção de valor por meio da experiência de uso. Todas as funcionalidades, a construção da jornada, a forma com que o produto é desenhado e também a forma com que ele é construído, tem apenas um objetivo: facilitar e adiantar a percepção de valor. Nós falhamos se a pessoa demora para perceber como o produto pode ajudá-la a se tornar alguém melhor. Falhamos também se a pessoa encontra dificuldades para chegar no core do produto, que é onde ela realmente irá perceber o valor.

Na minha opinião, nosso serviço ou produto serve apenas para diminuir a distância que existe entre o problema do usuário e a solução para esse problema.

Sobre engajamento

Podemos definir engajamento como extensão de uso do produto pelas pessoas.

Nesse sentido, engajamento tem tudo a ver com o comportamento que a pessoa tem dentro do produto, que geralmente se resume em interações e cumprimentos de tasks/jobs, desde cliques, comentários, compartilhamentos até execuções de tarefas que são core no produto, que ajudam o usuário a cumprir seu objetivo. Isso significa que é necessário entender, no modo mais granular, o que afeta o comportamento.

Usuários engajados são importantes por que:

• Eles têm maior probabilidade de ficarem mais tempo na plataforma;
• Eles cuidam e mantém suas contas por mais tempo;
• Eles geralmente são early adopters de novas funcionalidades;
• Eles compartilham seu produto pra outras pessoas;
• Eles sabem extrair e usar o seu produto para extrair o máximo de valor possível; Saber o que afeta o comportamento do usuário, ajuda a entender como é possível maximizar e estimular o aumento do uso, além de saber se o serviço realmente facilitando o valor que as pessoas esperam.

Definindo o que é um usuário engajado no seu produto

Todas as definições que falaremos aqui vão depender muito da empresa, produto e serviço que você está envolvido, além do setor e da forma que as pessoas usam o produto. Contudo, não iremos nos focar em métricas ou indicadores de growth.

O engajamento pode ser definido pela execução das core tasks do produto. Diferente da retenção, que tem a ver com a período de retorno ao produto, quando o usuário está fora do sistema.

Diferença entre usuário engajado e usuário ativo

As pessoas usam o tempo inteiro o termo usuário engajado como um sinônimo de usuário ativo. Acho que isso é um erro, por que embora os dois estejam relacionados, eles são coisas diferentes.

Eu não consegui pensar em uma analogia melhor, espero que você, depois desse meu exemplo tosco, consiga pensar em algo mais legal. Mas pense que o seu produto seja uma festa. Tem uma pessoa que interage com as outras pessoas, que come, que se diverte e canta no karaokê. Agora tem uma outra pessoa, um pouco mais low profile, que também está ali na festa, mas prefere fazer apenas uma coisa que a festa oferece de melhor: comer.

A primeira pessoa do meu exemplo é o usuário engajado: ela usou todos os recursos oferecidos pela festa enquanto ela estava lá. Já a segunda pessoa do exemplo é apenas um usuário ativo. Ela não usa todos os recursos do sistema, mas ela ainda está no sistema, fazendo uso de uma ou duas features que provavelmente a fazem alcançar seus objetivos.

Para ficar mais palpável, vou utilizar como exemplo uma empresa fictícia que tem um serviço de streaming de música. A missão dessa empresa é ser o principal local para ouvir músicas online em qualquer plataforma digital existente. Lembrando que a missão é algo para ser alcançado em longo prazo.

Eu não crio mais tantas playlists como antes, nem busco muitas músicas, nem compartilho ou favorito músicas o tempo inteiro no Deezer. Entretanto, eu ouço músicas todos os dias durante horas, pelas playlists que eu criei lá no início ou de playlists já prontas do Deezer. Embora eu não esteja engajando (usando várias features do produto ou executando jobs e core tasks), eu posso ser considerado um usuário ativo.

O problema é que usuários ativos podem se camuflar de usuários que serão potenciais churns no futuro. Do mesmo jeito que podem existir pessoas que são clientes há muito tempo do serviço, mas que usam apenas as tasks principais, há usuários que acabaram de chegar ou que não estão satisfeitos com o produto, que também tem um comportamento de pouco uso. Contudo, há como diferenciar:

• Entendendo a frequência de retorno. Pessoas que são ativas no sistema, costumam retornar mais. Pessoas não ativas/engajadas, quase não retornam sem estímulos externos;
• Entendendo a execução de tarefas que não são jobs importantes. No nosso exemplo de streaming de música: precisamos investigar usuários que não ouvem música;
• Investigar visita em seções de saída. Monitorar visitas e ações em áreas como histórico de pagamentos, troca de forma de pagamento, botões de cancelar, sign out, etc;

Existem muitas interpretações sobre o que são usuários retidos, engajados e ativos… Isso vai depender muito do setor da indústria em que o produto está inserido ou da forma com que sua empresa e time definem esses perfis, além do que os dados do seu produto diz. As definições acima, são as que eu uso no meu racional de gestão de produto. Até agora, tem feito sentido.

Uma coisa em comum entre usuários ativos, engajados e retidos é a execução de core tasks do produto. Se eles executam essas tasks/jobs, o produto ajuda a empresa a chegar mais próximo do posicionamento estratégico pretendido, além de gerar valor para o negócio. Então, como encontramos e definimos as core tasks do nosso produto?

Definindo as core tasks

Core Tasks são aquelas tarefas que o usuário precisa executar para alcançar um determinado objetivo. As pessoas têm objetivos diferentes em momentos diferentes e por motivos diferentes ao utilizar seu produto. É exatamente por isso, que eu atrelo as Core Tasks à execução de um grupo de tarefas. Essas tarefas são executadas por meio das funcionalidades e serviços existentes no seu produto.

Para descobrir essas tarefas e quais os problemas e os benefícios que os usuários esperam resolver ao usar seu produto, você pode simplesmente consultar o Value Proposition Canvas do seu produto. Se você ainda não fez um VPC do seu produto/serviço, sugiro que você faça o mais rápido possível.

Abaixo, segue o exemplo de Value Proposition Canvas dessa nossa empresa fictícia de streaming de música:

Nós podemos usar várias outras formas para definir o que são core tasks, mas eu vou usar aqui os CUSTOMER JOBS do Value Proposition Canvas, que dá uma boa ideia do que o usuário precisa fazer (muito bem) em nosso produto. O Customer Jobs são as tarefas e a rotina que o usuário precisa executar para alcançar um objetivo ou resolver um problema em um determinado contexto. Esses jobs não estão necessariamente ligados ao seu produto, eles estão ligados ao contexto de obtenção de um objetivo.

Então, quais são os jobs ou rotinas que alguém pode executar relacionados ao ouvir música?

Esses jobs não estão ligados a nenhuma funcionalidade específica do produto e podem ter várias funcionalidade que facilitam a execução desses jobs no nosso produto.

Eu agrupei essas tarefas em temas macro, para conseguirmos entender o contexto que cada job.

O como as pessoas irão executar esses jobs, serão nossas tasks mais importante no sistema, por um motivo: por meio dessas tasks, nós iremos impactamos esse jobs, que são os objetivos que os usuários procuram resolver seus problemas/objetivos.

Vou usar o exemplo de descoberta. Para descobrir músicas, os usuários precisam encontrar novas músicas no sistema e encontrar músicas em momentos diferentes do seu dia.

As tarefas abaixo, se executadas com frequência (essa definição de frequência vai depender do seu mercado, do seu produto e da sua empresa) podem ajudar a indicar que o usuário é engajado. Principalmente se elas forem interligadas com as tasks de outros jobs.

A rotina de a pessoa procurar uma nova música, adicionar uma música na playlist, compartilhar essa playlist com amigos e depois ouvir a música, pode ser uma rotina de engajamento.

• Pessoas que criam playlists ouvem mais música?
• Pessoas que compartilham músicas com amigos, ouvem mais música?
• Pessoas que usam a buscam, ouvem mais música?
• Pessoas que interagem mais com as playlists temáticas, ouvem mais música?
• Quando há um recomendação pelo algoritmo, a pessoa ouve mais? Engaja mais?

Concluindo

Nós podemos fazer uma ligação muito clara com indicadores importantes do produto e é daí que eu acho que os indicadores deveriam ser organizados e estruturados, exatamente por que você tem uma conexão clara com o comportamento do usuário. Acho que uma hierarquia boa seria assim:

Eu tenho uma visão de que tudo no produto precisa estar completamente interconectado, desde o nível mais tático até o nível mais estratégico. Veja bem, a missão do Spotify é “ Our mission is to unlock the potential of human creativity-by giving a million creative artists the opportunity to live off their art and billions of fans the opportunity to enjoy and be inspired by it. “. O contexto de DESCOBERTA está totalmente interligado com essa missão. A missão, por sua vez é algo que será atingido no longo prazo.

Dessa forma, qualquer linha de código, qualquer design, qualquer planejamento de produto, qualquer decisão em qualquer nível, deve deixar a empresa mais perto da sua missão. Quando essa missão for cumprida ou a empresa se sentir satisfeita com o posicionamento, uma nova missão deve ser encontrada ou a missão atual deve ser renovada.

Referências:

• https://medium.com/@tsharon/measuring-user-engagement-86d10ae24c0a
• How to Increase User Engagement in 2020 4 Strategies | Intercom
• 7 Examples of User Engagement — Simplicable
• https://medium.com/engagement-marketing-smiles/four-steps-for-creating-a-user-engagement-score-for-your-product-a2c6e1d66930
• https://medium.com/boundlessai/user-retention-or-engagement-c3a1dae99c17

Originally published at https://diegoeis.com.

Sobre engajamento em Produtos Digitais — Blog do Diego Eis was originally published in productoversee on Medium, where people are continuing the conversation by highlighting and responding to this story.

Eu prefiro pensar que produtividade tem mais a ver em fazer as coisas certas, do que fazer uma grande quantidade de coisas em um período de tempo. Por isso, acho que é melhor entender onde colocar o foco e esforço para conseguir alcançar o impacto desejado.

A maior parte do meu dia eu estou envolvido em reuniões e conversando com pessoas por meio de diversos canais. É um fluxo insano de informações e mudanças constantes de contexto. Já cansei de colocar a culpa dessa rotina maluca na empresa, no mercado, nas pessoas, em mim e tudo mais. Até que eu entendi que é muito mais fácil eu mudar minha forma de lidar com isso, do que tentar mudar outras variáveis. É natural conviver nesse tipo de ambiente no mundo de hoje, principalmente se você trabalha com qualquer tipo de gestão.

Basicamente uso dois tipos de ferramentas de produtividade: umas ferramentas servem para para me manter produtivo, outras para monitorar minha produtividade. Hoje quero falar sobre duas ferramentas que poderão aparecer muito em futuros artigos, principalmente quando falarmos um pouco mais de hacks.

O Todoist e o Bear são duas ferramentas essenciais que uso na minha rotina para potencializar o meu fluxo produtivo. Com eles eu:

• 📋 Organizo e defino minhas prioridades;
• 🧠 Faço de forma livre o dump de informações que estão no meu cérebro;
• 📬 Mantenho visível e acessível as threads que estou envolvido e resolvendo no meio do caos diário;
• 📆 Planejo os próximos dias;

Eu diria que estás são minhas ferramentas táticas, que eu uso pra executar meus hacks de produtividade. Também uso outras ferramentas para monitorar a produtividade, mas aí é outra história.

Todoist

Em dias muito agitados no trabalho, é comum se perder no improviso. São requisições, problemas, necessidades, urgências que aparecem o tempo todo, preenchendo seu dia com tarefas etéreas, que se dissolvem durante a rotina e que dão aquela sensação de “o que eu fiz o dia inteiro”? Mesmo sabendo você trabalhou sem parar, fica difícil conseguir mensurar o resultado no final do dia. Mas embora esse fluxo de informação e mudanças de contexto seja natural web determinadas responsabilidades, você pode minimizar muito os efeitos da ansiedade, senso exacerbado de urgência e aquele sentimento de improdutividade. Fiz isso usando o Todoist.

O Todoist é uma ferramenta de gerenciamento listas de tarefas. Simples assim. Você cria uma tarefa e quando termina, marca que ela foi feita. Pronto. Nada demais. Contudo, ao mesmo tempo que você pode usar o Todoist assim, de uma maneira simples, você consegue expandir seu uso para potencializar ainda mais sua produtividade. Uma ferramenta de produtividade é boa quando ela não te faz perder tempo com ela.

Por exemplo, pra cadastrar uma tarefa, simplesmente entro no todoist, aperto a tecla de atalho q (Quick Add Task) e digito:

Escrever artigo sobre ferramentas de produtividade. #writing 15/07 @blog

Aperto enter e pronto. O Todoist me cria uma tarefa com o título Escrever artigo sobre ferramentas de produtividade., dentro do projeto writing com o deadline pro dia , com a label blog. Eu nem preciso usar o mouse.

O Todoist é um daqueles serviços que a superfície já executa o que se propõe, mas que se o usuário quiser se aprofundar, ele vai encontrar uma série de funcionalidades que entregam ainda mais valor.

Não quero escrever hoje como eu organizo minhas coisas ou quais as features do Todoist. Mas sugiro que você dê uma olhada aqui.

Tchau, Keep. Olá, Bear!

Nem só de tarefas uma pessoa vive. Como eu disse, eu entro e saio de várias reuniões e converso com muita gente sobre assuntos diferentes. Além disso, eu tenho uma série de outros projetos pessoais que me fazem escrever. Para não perder nenhuma informação e conseguir revisar todos os assuntos posteriormente, eu tenho o costume de sempre fazer anotações (principalmente de palestras… quem me conhece, sabe que eu sou o maluco das anotações das palestras).

Até hoje eu guardava todas as minhas anotações no Google Keep. Ele é MUITO simples, perfeito para anotar coisas rápidas, categorizar com tags e pronto. A visualização em formato de cards é perfeita. Eu mantinha ele aberto o tempo em uma aba para usá-lo durante todo o dia.

Contudo, o que me incomodava muito era que algumas vezes eu precisava do mínimo de formatação: Frisar uma frase, fazer um título, criar uma lista, separar pensamentos em uma mesma nota, etc… Eu sempre escrevo tudo em Markdown, e seria ótimo se o Keep suportasse markdown, mas não suporta.

Foi aí que recebi a indicação do Bear. O Bear é um serviço de anotações para mac. O serviço aceita markdown como formatação e permite usar tags encadeadas para organizar/categorizar suas notas. A interface é simples, a experiência é bem fluída. Consegui importar as mais de 350 notas do Keep (depois explico o processo que foi semi automático) para Bear.

Eu sei que todo mundo tem um conceito pessoal sobre anotações. A minha é: anotação é aquilo que você faria se tivesse um caderninho de anotações. No caderninho de anotações, você não escreveria um artigo inteiro. Você escreveria pequenos pedaços de pensamentos com informações importantes para conseguir aprofundar e relembrar daquele assunto posteriormente, para aí sim, decidir como quer avançar. Um exemplo do que eu costumo anotar:

• Ideias;
• Um ou dois parágrafos de um possível artigo;
• Links e referências;
• Listas;
• Anotações de reuniões, palestras, conversas;
• Pequenos textos;

Muito por isso, eu não gosto de usar aplicativos e serviços como o Notion pra fazer anotações. Ferramentas desse tipo são ótimas para organizar e diagramar grandes pedaços de textos onde outras pessoas poderão acessar, como um time, por exemplo. Se você quer estudar, fazendo análises e produzindo conteúdo mais denso, aí sim, o Notion e qualquer outro serviço desse tipo é mais apropriado. Mas aí, nesse caso, eu costumo usar o Miro.

Concluindo

Dado que consegui descrever um pouco das minhas duas minhas ferramentas prediletas de produtividade, agora podemos falar mais sobre os meus hacks pessoais de produtividade. Já adiantando, não uso nenhum método específico como GTD ou P.A.R.A.

Qual ferramenta de produtividade você usa no seu dia a dia?

Originally published at https://diegoeis.com.

MVP serve para testar a execução da ideia, não a ideia em si — Blog do Diego Eis

Você já deve ter visto essa imagem no Linkedin, grupos de WhatsApp ou blogs sobre produtos digitais por aí. Se não, segue aí embaixo:

Essa imagem é parte deste antigo artigo, de 2016, do Daniel Collado-Ruiz, onde ele discorre sobre a forma com que o mercado enxerga e faz MVPs. A ideia do artigo é que as pessoas têm uma visão errada do que realmente é MVP, às vezes definindo erroneamente o que é o mínimo, ou o que é viável ou simplesmente tendo uma concepção de entendimento que a palavra produto, no MV P, deveria ser algo completo.

O artigo direciona esse uso errado do MVP para um momento sensível da construção de um produto que é a validação do desejo das pessoas para pagarem pelo seu produto. Geralmente produtos digitais começam com uma versão simples, às vezes grátis, estimulando as pessoas a usarem o produto para enfim entenderem se aquilo realmente traz algum benefício para elas, seja por que o produto resolveu o problema delas ou trouxe alguma vantagem para o seu dia a dia.

Nesse momento de vida do produto, é importante entender qual o preço ideal, quais planos fazem mais sentido para o mercado, o que será incluído nesses planos, além de saber se há demanda suficiente para manter o produto, validando se há espaço para escala e crescimento acelerado.

O artigo mostra diversos exemplos de estratégias de empresas como Dropbox e Buffer, que usaram para testar como eles começaram a cobrar pelos seus produtos. Veja bem, eles estão testando aqui como vão cobrar por seus produtos e isso não é a mesma coisa que testar se uma funcionalidade é a correta ou não para ser implementada. Além disso, eles não testando se a ideia ou a proposta de valor dessas empresas é a correta. E aqui, começa minha crítica sobre a imagem do começo do artigo.

Validar a proposta de valor vem antes do MVP. O MVP valida a execução.

A proposta de valor é algo difícil de ser validado com software. Value Proposition, minha opinião, está no nível macro de negócio, de posicionamento da empresa, não no nível de software, que é um nível mais tático, de execução.

Para chegar na fase de escrever software, qualquer que seja o tamanho ou o tipo, você já precisa ter validado — com o mercado e as pessoas que provavelmente seriam as impactadas pelo seu produto/serviço — se a sua ideia realmente é necessária e realmente vai trazer benefícios claros e valor percebido para as pessoas.

Geralmente você traz muitas hipóteses e suposições, carregadas de viéses pessoais ou de pessoas que acharam a sua ideia extraordinária, e que provavelmente são pessoa que não seriam o público do seu produto/serviço. Algumas suposições comuns que você precisa validar:

• Pessoas estão infelizes com os produtos e serviços existentes no mercado;
• Preço e planos de assinatura;
• Fit de mercado, localização e cultura;
• Mensagem e tom de voz de acordo com o momento do usuário (não necessariamente com tipos de personas);
• Fit de consumidores (quais as personas e em quais momentos elas usarão o produto);
• Demanda (existe demanda suficiente?);

Estou assumindo aqui que o MVP já é a construção mínima e viável do seu produto/serviço. Então, é muito perigoso se você construir o produto/serviço ANTES de saber qualquer um dos pontos acima. Não estou dizendo que é errado construir qualquer pedaço de software para validar esses pontos, mas que você já se coloca em risco muito cedo se você fizer isso. Primeiro, é interessante realmente fazer pesquisas de campo, muito qualitativo e observacionais do público e do mercado que queremos atacar.

O MVP então, serve para validar a execução da sua proposta de valor… Serve para validar a maneira, o meio de como você vai expor sua proposta de valor para as pessoas. Ela não pode validar a sua proposta de valor, porque a validação da proposta de valor deve vir antes do MVP.

Essas são algumas fases das quais a startup ou a empresa ou a pessoa, seja lá que queira executar uma ideia e criar um serviço/produto:

Problema e/ou necessidade e/ou desejo

Qual o problema/necessidade a startup está querendo resolver? Esse problema/necessidade está crescendo? Muitas pessoas já são impactadas ou serão impactadas no futuro com esse problema/necessidade? Esse problema é popular? Esse problema é difícil de resolver?

Gosto muito da abordagem do Kevin Hale. Para mim é muito simples, clara e completa. Precisamos avaliar se a necessidade, problema ou desejo é: — Popular: Bons problemas são populares, muitas pessoas tem essa necessidade/problema/desejo? — Crescente: é algo que tem um crescimento natural por algum motivo ou efeito colateral do mercado, do comportamento das pessoas, da sociedade ou sistemas econômicos? Mais e mais pessoas terão esse problema, desejo, desejo? — Urgente: é algo que precisa ser resolvido rápido ou que coloca em risco outros processos e sistemas estruturais da sociedade ou mundo corporativo? — Caro: o problema que é caro de ser resolvido? Não apenas do ponto de vista financeiro, mas também de trabalho e execução; — Mandatório: as pessoas/empresas que têm esse problema, precisam resolver esse problema? Não é algo que pode ser deixado de lado? — Frequente: é problema, desejo ou necessidade que acontecem sempre em uma frequência constante de acontecimento e que evoluem com o tempo;

A sua ideia já está pronta, e antes de executá-la com um MVP, você precisa ter certeza de que a sua ideia vai resolver um problema, necessidade ou desejo das pessoas e/ou empresas, levando em consideração os pontos indicados acima.

Encontre seu Por Quê (motivo de existir)

Os “por quês” (motivos) que leva a acreditar que essa solução iria funcionar. Esse é o insight. É aquele ahá moment que só vocês têm. É o que leva vocês a acreditarem só vocês ganharão essa competição e não as outras.

Geralmente para os investidores, logo no início, o interesse irá para o insight que mostre algo relacionado a growth ou sobre a velocidade de escala. Para as pessoas, em como você irá fornecer valor de forma evolutiva e progressiva (que geralmente é o que trará escala).

Isso leva você a pensar, novamente, no problema. A escala sob a forma de crescimento daquele problema. Porque o problema ou a necessidade não é algo trivial para resolver. Não irá sumir da noite para o dia e as pessoas, em diversas partes do mundo serão impactadas ou estão sendo impactadas por esse problema/necessidade.

Entrega da Solução

A sugestão da solução, de forma macro, que resolveria esse problema. Qual a razão para construir ou começar por essa solução e não por outra? Entendendo qual a solução, qual a tecnologia você usaria para resolver?

As pessoas, geralmente, cometem o erro de abrir um empreendimento pensando em uma solução maravilhosa sem pensar antes na totalidade das características dos problemas que elas querem resolver. Elas são apaixonadas pela solução, não pelo problema. Isso se chama SISP, que vem do inglês para o termo: Solution In Search of a P roblem. Elas dão prioridade para a solução, discutindo como iriam construir isso, quais as tecnologias, como seria a operação, quais especialistas precisariam e etc… só para depois conseguirem pensar no problema como algo prioritário.

Métodos de Aquisição

Qual o modelo de aquisição? Como será o início do modelo de aquisição e como ele poderá se transformar durante a evolução do produto e do mercado? Quais os canais de relacionamento e exposição que iremos construir? O produto será resumido apenas em software versão App e Web ou ele poderá usar outras plataformas para amplificar sua proposta de valor?

Esse assunto de aquisição é importante porque se você pensa em um produto e serviço como plataforma, pode ser que você caia no problema do Ovo ou a Galinha. Se sua produto precisa de duas pontas para funcionar, digamos vendedores e compradores, pessoas e motoristas, restaurantes e entregadores, você vai precisar se focar em adquirir um dos lados para conseguir estimular e chamar a atenção do outro. Por onde você começa?

O termo MVP é estranho, pois remete à SOFTWARE (é o P do MVP). Talvez poderia se chamar MVS (minimum viable service)

Eu estou assumindo que você que está lendo esse texto é alguém que trabalha com construção de produtos e serviços baseados em tecnologia, ou seja, em software. O seu meio de entregar valor, basicamente se dá por meio da web ou por um aplicativo ou por qualquer outro software.

O que acontece é que as pessoas confundem MVP com um método de validação do processo inteiro de negócio. O MVP nasceu para validar a execução de uma ideia por meio de software, seja ela uma funcionalidade ou um produto inteiro (isso vai depender do momento de construção e evolução da solução).

Contudo, quando falamos que queremos criar um MVP, nós queremos dizer que queremos testar a execução de uma ideia. Isso quer dizer que não precisa ter software envolvido nos primeiros momentos. Pode ser que você consiga entregar uma solução fazendo mudanças de processos internos ou externos, para então, conseguir passar para a fase de construção de software.

Logo, eu acho que o termo confunde bastante e poderia ser chamado de MVS — Minimum Viable Service. Quando falamos sobre serviço, nós temos uma visão muito mais ampla do que a construção de software, falamos sobre a entrega da proposta de valor por meio da empresa inteira, não apenas pelo pedaço de software. Por que como sabemos, o produto é apenas um meio da entrega de valor e não o fim.

O benefício só é entregue por meio das funcionalidades do produto

Novamente eu estou assumindo que estamos falando de produtos e serviços digitais aqui, ok? Por isso que eu estou me referindo ao comportamento do usuário por meio de funcionalidades implementadas em um produto, ou seja, em um software.

Veja que na imagem, as funcionalidades não estão sendo contadas logo de início no MVP. A minha visão de MVP é validar a execução de uma ideia, não validar se a ideia é a correta. Como vimos anteriormente, a ideia já deve estar validada, eu sei que ela tem fit com meu público e com o mercado, eu sei que ela é necessária porque eu entendi que o problema que eu quero resolver existe e é latente.

Quando falamos mais sobre serviços digitais e não apenas produtos digitais, entendemos que o valor só é percebido pelo usuário quando ele está usando o produto. Nessa fase, nós somos meros expectadores. Nossa influência terminou quando publicamos a nova versão do produto. Nós não estamos do lado do usuário quando nosso produto está sendo usado, é um relacionamento que acontece apenas com o usuário e nosso pedaço de software. Ou seja, somos responsáveis por facilitar a geração de valor, não criamos ou entregamos esse valor, só facilitamos.

E se o usuário só entende e percebe o valor que o serviço está entregando para ele no momento do uso, sabemos que a experiência de uso e as funcionalidades são os fatores principais de geração de valor. O usuário só usa seu produto porque ele resolve um problema. E ele resolve um problema por que existem ma funcionalidade no produto que faz com que ele tenha seu problema/desejo/necessidade resolvida. É o fato dessa funcionalidade existir que ele irá ter seu problema resolvido ou necessidade respondida.

Agora, a forma com que você fará essa funcionalidade é o que conta. Criar uma funcionalidade inteira, do começo ao fim, sem saber se essa execução irá dar certo é arriscado e perigoso, e eu até diria que é errado. Você precisa criar o mínimo viável dessa funcionalidade para conseguir entender o comportamento do usuário e a partir daí criar evoluções.

Tem algumas pessoas que querem ou precisam validar se determinada funcionalidade ou plano é o correto. Então, utilizam técnicas (que precisam ser bem entendidas e usadas com destreza) para validar se uma funcionalidade ou até mesmo uma pequena oportunidade é realmente válida. Algumas dessas técnicas: Fake Door, Fake Door Testing, Concierge, Wizard Oz.

Todas elas servem para testar o interesse e o apetite do usuário pela funcionalidade ou ideia de execução. Assim, tendo interesse, você tem mais confiança em aplicar o que estava sendo planejado. Eu não gosto muito delas, porque geralmente os times tendem a “enganar” o usuário, fazendo o usuário executar tarefas que irão terminar em uma “rua sem saída”. Não gosto de fazer isso quando se trata com validação de funcionalidades, prefiro quando são pra validar, por exemplo, cadastro ou interesse de compra, por exemplo.

Concluindo

Se eu tivesse que resumir todo esse texto, eu diria que:

• A ideia ou a proposta de valor da empresa/serviço/produto deve ser validada antes da construção do produto;
• O MVP é a validação da execução dessa ideia ou proposta de valor;
• Funcionalidades são a forma com que os usuários resolvem seus problemas, saciam suas necessidades e percebem o valor que o produto ou o serviço estão fornecendo;
• O conceito de MVP pode ser visto com uma visão macro, tendo em vista o produto como um todo ou também uma visão micro, sendo aplicado à níveis de funcionalidades no produto;

Referências

• Minimum Viable Product (MVP) — unnecessary jargon of the startup world? | Nestholma
• https://content.fme.de/en/blog/warum-und-wie-definiert-man-eigentlich-ein-minimum-viable-product-mvp
• The cake model of product strategy on Vimeo
• 5 mistakes to avoid when Testing your Value Proposition Canvas — YouTube
• https://medium.com/@upplabs/value-proposition-to-validate-a-business-idea-500266aeda42
• https://upplabs.com/blog/value-proposition-to-validate-your-business-idea/
• https://www.jevera.software/post/mvp-too-clear-or-not-too-clear
• https://buffer.com/resources/idea-to-paying-customers-in-7-weeks-how-we-did-it/
• https://techcrunch.com/2011/10/19/dropbox-minimal-viable-product/
• Fake door — The MVP before the MVP | Hacker Noon
• https://uxdesign.cc/how-we-run-a-fake-door-test-in-notino-ux-case-study-c7138940c1ec
• https://www.smartcompany.com.au/startupsmart/advice/mk-fake-door-product-testing-startups/
• Top 5 Misconceptions About Building A Minimum Viable Product | by Tyrannosaurus Tech | TyrannosaurusTech | Medium

Originally published at https://diegoeis.com.

Combinando os resultados de frameworks e canvas — Blog do Diego Eis

As vezes algumas coisas precisam estar escritas para terem mais valor ou simplesmente para gerar alinhamento entre as pessoas. O achismo é um argumento comum no mercado de Produtos e isso está presente em todos os níveis da empresa, desde os C- Levels até a última ponta. Todos acham que sabem o que é melhor para o produto e principalmente para o negócio. Algumas pessoas estão certas, outras erradas, o problema é descobrir isso muito tarde.

Uma das causas desses problemas é a falta de clareza e alinhamento sobre os fundamentos que formam a base da empresa, que consequentemente irão determinar o futuro do Produto.

Para ajudar os times a entenderem bem os fundamentos que movem as decisões da empresa, principalmente dos stakeholders que realmente tem o poder de decisão para mudar a direção da empresa, existem uma série de frameworks usados pelo mercado. Se você quiser saber sobre as ameaças e oportunidades que rondam a empresa, basta criar uma matriz SWOT. Se você quer saber quem são os parceiros chave, os segmentos de clientes, custos e linhas de receita, basta montar um Business Model Canvas. Se você quiser saber como novos entrantes ameaçam o negócio, qual o impacto dos fornecedores na operação e funcionamento da empresa, além do impacto da empresa perante o mercado e consumidores, você consegue visualizar isso montando um diagrama das 5 Forças de Porter.

Quando trabalhamos em Produtos Digitais, é muito difícil ver PMs usando essas ferramentas para determinar pontos fundamentais do seu produto. Tem aquela cultura de que PM trabalha só com frameworks e metodologias da atualidade, deixando fora de cogitação usar qualquer framework citado, só porque todos são do século passado. Contudo, essas e outras ferramentas importantes, podem deixar o produto mais perto do imaginário das pessoas que tratam de negócio e principalmente mais perto do que realmente seu produto deveria ser.

Essas ferramentas geralmente são usadas individualmente e sempre acabam esquecidas depois de um tempo. As empresas não revisitam os pontos especificados e não usam essas ferramentas para direcionar a estratégia ou os acionamentos táticos. Além disso, outro fator que faz toda diferença, é usar essas ferramentas em conjunto. Todos esses frameworks e métodos têm alguma sinergia entre si, se completando e aprofundando mais ainda os conceitos e contextos de mercado e do negócio.

Um exemplo de integração entre as ferramentas e frameworks

Em vez de usar apenas uma ou duas dessas ferramentas, é possível usar várias delas em conjunto, onde o resultado de uma potencializa o resultado de outra. Para quem constrói Produtos Digitais, essas ferramentas conseguem navegar da ponta estratégica até a ponta mais tática da construção.

Em projetos pessoais e em algumas empresas que passei, eu usava muito o Business Model Canvas para entender sobre os problemas que estamos resolvendo e segmentos de clientes que estamos atacando. Geralmente as pessoas conhecem só o quadro do meio do BMC. Embora apenas o quadro já traga uma visão muito boa sobre o negócio/produto, contudo, o BMC fica muito mais rico quando fazemos ele de forma completa:

• contemplando as visões externas de mercado, tendências e visão sócio-economica
• além do Value Proposition Canvas, que fornece uma visão mais micro e detalhada dos valores e serviços entregues para os segmentos de clientes que impactamos.

Para estabelecer objetivos do ano, que desdobram os objetivos de semestre e trimestres, é possível usar o SWOT, onde nos baseamos nas oportunidades e ameaças para gerar objetivos de negócio, que por sua vez podem ser visualizados em uma matriz BSC (Business Scorecard), dividindo esses objetivos em perspectivas financeiras, de mercado/cliente, processos e aprendizados/crescimento.

Quando isso está pronto, o time de produto consegue refletir esses objetivos em um formato de OKR ou Opportunity Tree.

Veja que a combinação acima pode ser modificada para outros frameworks que você preferir. No lugar do SWOT, você pode usar outro framework como o SOAR ou o SCORE, que trazem características semelhantes ao SWOT e são tão simples quanto.

Conectando tudo

Fiz esse Miro para diagramar as conexões dos vários resultados e correlações de diferentes frameworks, matrizes, canvas e diagramas usados no mercado. As pontas mostram as correlações.

Perceba que várias das ferramentas conseguem amplificar respostas a partir dos resultados de outras ferramentas. A partir das ameaças encontradas na SWOT, é possível definir objetivos no Hoshin Planning e no BSC. A partir do Value Proposition Canvas, é possível ajudar o preenchimento do Golden Circle, BSC e SWOT.

Nesse mesmo Miro, você pode ver outros boards com algumas outras organizações e informações para agregar mais nos seus estudos. Além de ter um template completo do Business Model Canvas.

Lista de algumas ferramentas

Eu citei ferramentas que eu gosto de usar, mas você pode trocar facilmente para ferramentas que seu time se sente mais confortável ou que refletem melhor a cultura da empresa. Algumas características que esses frameworks tentam ajudar a definir:

• Definição de Visão e Propósito de Valor;
• Definição de características da empresa ou da marca;
• Definição de Estratégia, Negócio, Mercado, Oportunidades, Ameaças, análises internas;
• Definição de Clientes, Segmentos, Custos, Propostas de Valor;
• Entendimento, Ideação, validação, discovery;
• Definição de objetivos táticos;

As minhas sugestões seguem abaixo. Existem ferramentas que aparecem mais de uma vez na lista, porque elas ajudam em momentos diferentes:

• Definição de características da empresa ou da marca:
• Definição de visão e propósito:
• Future Press Release;
• Board Vision Canvas;
• Golden Circle;
• VMOST;
• Visão estratégica, definição de Oportunidades, Problemas, Ameaças externas e internas:
• SWOT;
• PEST+A;
• Business Model Canvas (visão macro);
• Porter’s Five Forces;
• SOAR;
• SCORE;
• VMOST
• McKinsey 7S Model;
• Oportunidades de crescimento, desenvolvimento, penetração:
• BCG Matrix;
• Ansoff Matrix;
• Definição de Clientes e Segmentos:
• Empathy Map;
• Board Vision Canvas;
• Business Model Canvas;
• Value Proposition Canvas;
• Entendimento, Ideação, validação, discovery:
• Design Thinking;
• Double Diamond;
• Continuous Discovery;
• PDCA;
• Definição de objetivos táticos:

Concluindo

Lembre-se que o processo precisa trabalhar pra você, não contrário. Todas essas ferramentas servem pra treinar, exercitar, clarear e equalizar os vários pontos de vista do time. Nenhuma dessas ferramentas vai ser útil se elas não forem revistas e atualizadas de tempos em tempos.

Um Business Model Canvas — que talvez seja o Canvas mais popular dessa lista — muito bem feito e atualizado, pode ajudar um PM a definir funcionalidades, métricas e indicadores, pesquisas de usuário, roadmap de médio e longo prazo. Geralmente PMs desprezam esse tipo de ferramenta por não fazer parte da cartilha atual de gestão de produtos e isso é um erro enorme.

Muitos desses frameworks foram criados e estabelecidos há muitos anos atrás, quando o comportamento das pessoas e o mercado era totalmente diferente do atual, como por exemplo o McKinsey 7S Model, que foi criado em 1970, por isso, pode ser que essa ferramenta não se adeque a modelos de negócio mais atuais e baseados em um mundo fundamentado no digital. Contudo, a maioria dessas ferramentas foram criadas para definir conceitos de negócio e de mercados que são imutáveis.

Seria muito interessante ouvir sua opinião e principalmente ter sugestões de ferramentas que podem oferecer alguma sinergia com as citadas. Quero melhorar esse diagrama de forma contínua e seria legal receber sugestões.

Originally published at https://diegoeis.com.

Combinando os resultados de frameworks e canvas — Blog do Diego Eis was originally published in productoversee on Medium, where people are continuing the conversation by highlighting and responding to this story.

Anotação: Por que importa ter mais mulheres na tecnologia — Blog do Diego Eis

Esse é uma anotação que fiz na palestra da Mari Pezarini — COO da PrograMaria, feita em 08/09/2020, no Bootcamp de Startups da Liga Ventures e Tudux.

Assuntos abordados:

• 3 Mitos sobre o problema da desigualdade de genero na tecnologia;
• Por que isso importa ter mais mulheres?
• Algumas boas práticas para startups e empresas aplicarem agora;

Essa é a foto clássica dentro de uma empresa de tecnologia. Essa é a realidade do mercado. Se você for no Google e escrever Developer, só aparecem homens em frente ao computador.

Mito 1 — Mulheres não se interessam por tecnologia; Quais os estímulos que a sociedade ou os pais estão dando para seus filhos? Muitas vezes esses estimulos destinam os caminhos que as crianças vão tomar. Geralmente os meninos são estimulados de forma que mexam mais com o cognitivo de execução mais tática, pensamento estratégico etc.

Pensar assim, tem um direcionamento de que as meninas desde muito cedo são mais propensas em expressar fortes sentimentos de ansiedade em relação à matemática, porque desde cedo elas ouvem que matemática ainda é só para meninos, e que não podem errar.

Por causa da expectativa de perfeição, de não errar, as meninas não são ensinadas a ser ousadas ou a terem coragem. Já com os meninos nós encorajamos muito os meninos a se provarem mais… “Hey, sobe naquela árvore, você é corajoso, você consegue”… Enquanto para as meninas é: “Hey, cuidado, você está de saia, menina tem que sentar de perna fechada, e ficar comportada”

Dentro da noção de futuro, onde as vagas de tecnologia irão crescer exponencialmente, as mulheres podem não conseguir encontrar oportunidades, não pela falta, mas pela falta de estimulo, pela falta de esforço da sociedade de mudar.

Desafios para as empresas nesse cenário: — Tempo e custo para contratação vai ficar maior; — Custo de treinamento e onboarding; — Alto turnover por causa da pressão e falta de suporte da empresa; — A falta de diversidade nas equipes técnicas criam um ambiente mais tenso para mulheres;

Quando as pessoas veem pessoas iguais a ela, com seu perfil físico, mas também perfil de sociedade e habilidades, além de interagir com pessoas diferentes ela, isso tudo se torna em vantagem competitiva para as empresas, porque as pessoas se sentem mais representadas e por causa disso se sentem mais à vontade para errar, melhorar seus resultados e habilidades sem medo de ser substituída.

Mito 3 — O problema é só estatístico: se mais mulheres se formarem mais mulheres serão contratadas Mulheres só se aplicam numa vaga quando elas cumprem 100% das qualificações exigidas. Muito diferente da visão masculina, onde só 60% das qualificações basta.

Com a pressão da expectativa da perfeição, mulheres tem insegurança de mostrar seu trabalho incompleto com possíveis erros.

87% das mulheres procuram empresas que se importam com a diversidade de gênero para se candidatarem à cagas de emprego (fonte: Pesquisa HerForce) A empresa precisa ter iniciativas de diversidade, inclusão e força de cultura para apoiar e suportar as mulheres no seu trabalho diário.

O mercado de trabalho tem esse viés inconsciente. Uma pesquisa fez a pergunta: você contrataria John ou Jennifer?

As empresas contratariam o John. Eles deram o motivo:

• Mais competete;
• Mais empregável e
• Digno de um salário maior

Mas o curriculum avaliado pelas empresas era idênticos. Esse é o viés inconsciente.

Então, como fazemos para trazer mais mulheres para o mercado de tecnologia (e/ou empoderar mulheres no mercado de trabalho)?

• Educação livre de estereótipos: brinquedos, atividades, livros, filmes, etc;
• Dividir as tarefas domésticas igualmente. Porque meninas acham que é obrigação delas ajudarem as mães nas tarefas domésticas;
• Não utilizar rótulos. “Isso é de menino e aquilo é de menina”
• Estimular participação em diferentes atividades escolares, como aulas de robótica e esportes;

Empresas

Crie grupos de afinidades, para se sentirem abertas, acolhidas e seguras. Tenha dados sobre representatividade da sua empresa para trazer consciência no dia a dia de trabalho. Garanta que a cultura da empresa é inclusiva. Cultura inclusiva é feita de várias pequenas iniciativas.

Outro grande problema são os salários diferentes entre os gêneros, mesmo as pessoas fazendo e executando o mesmo trabalho

PrograMaria

EMPODERAR MULHERES ATRAVÉS DA TECNOLOGIA DIMINUINDO O GAP DE GÊNERO NO MERCADO DE TRABALHO.

A PrograMaria é um meta-site sobre mulheres e tecnologia. A PrograMaria é um convite para refletir, se inspirar e aprender. Nossos objetivos são:

• Contribuir para que mais meninas e mulheres sintam-se motivadas e confiantes a explorar os campos da tecnologia, da programação e do empreendedorismo;
• Incentivar o debate sobre a falta de mulheres nesses campos;
• Promover oportunidades e ferramentas para que elas deem os primeiros passos na aprendizagem da programação.

Originally published at https://diegoeis.com.

Anotação: Por que importa ter mais mulheres na tecnologia — Blog do Diego Eis was originally published in productoversee on Medium, where people are continuing the conversation by highlighting and responding to this story.

Esse texto foi publicado muito antes na PM Letter. A Newsletter feita para PMs e pessoas que trabalham com produtos digitais. Assine e entre para um grupo de mais de 1300 pessoas.

Semana passada rolou o maravilhoso Digital Product Week 2020. Um evento gratuito incrível sobre Produtos Digitais e Tecnologia produzido pelo pessoal da Tera.

Esse ano eles chamaram novamente o Marty Cagan, que fechou a primeira noite do evento com uma palestra chamada Product Management: the Good, The Bad and the Ugly.

Eu anotei partes dessa palestra. Quem já acompanhou eventos comigo, sabe que eu anoto palestras compulsivamente. Consigo absorver muito conteúdo assim e depois ainda serve para compartilhar, como estou fazendo agora. Por isso, por favor, não liguem se houver typos na escrita, além de algumas partes que podem ficar com sentido estranho, porque fui fazendo uma tradução simultanea de ingles para portugues enquanto o Cagan falava. ;-)

Sobre Tipos de Time de Produto

Os times que se focam no produto são importantes. Se uma empresa não tem times focados no produto, não há como ter produtos digitais fortes. Existem 3 tipos de times de produto que o Cagan enfatizou na palestra. Ele disse que esteve no Brasil várias vezes e encontrou esses três tipos de times aqui, mas também na Europa, na China, Índia e em todo o mundo.

A partir de uma visão muito macro, esses tipos são bem parecidos. Mas eles não são iguais quando vemos no detalhe e quando executamos o dia a dia. Os três tipos de times são:

• Delivery Teams (the ugly);
• Feature Teams (the bad);
• Empowered Product Teams (the good);

Existem os bons times de produto, os times de produtos feios e times de produtos ruins (The good, the ugly and the bad teams). Em grandes empresas, é muito dinheiro é gasto para obter apenas entregas. Os times são montados para entregar tarefas e/ou funcionalidades e só. Esses são os times “ruins”.

O Delivery Team

O delivery team (ugly teams) tem um PO, que não é um gestor de produto, mas que se diz ser o dono do produto. O Job principal dessa pessoa é gerenciar o Jira. É um administrador de backlog. Geralmente esse time não tem um designer dedicado que pensa na experiência do usuário. Existe um time de Devs, que estão lá apenas para implementar o backlog definido pelo PO.

Tudo nesse time se trata de entregar código. Geralmente eles usam SAFe. SAFe não tem nada a ver com Ágil. É apenas um truque de marketing para que as pessoas que preferem trabalhar com waterfall pensem que estão fazendo ágil, mas não é ágil. Se você está em uma empresa assim, a sugestão do Cagan é que você se mude para outra empresa. Não existe espaço para você fazer produtos nesse modelo.

Contudo, essas empresas fazem muito dinheiro, eles são líderes do mercado, então não há muito o que fazer para ajudá-los, porque o negócio “parece” estar dando certo. Felizmente a maioria das empresas que “fazem produtos” raramente usam esse tipo de times.

Os Feature Teams

Já os feature team ainda não são os bons times (são os ugly teams). Essa é a parte que frustra: porque esses times deveriam ser os bons times, mas as empresas não entenderam a diferença sobre como ótimos times funcionam. Empresas assim estão no meio do caminho do processo de produtos. Netflix, Slack, Amazon, Google, Apple, AirBnB são exemplos de empresas que entendem como os BONS times funcionam.

Os feature teams se parecem com um time real de produto, pois ele têm um PMs, eles têm um Designer, eles têm um Time de Devs… Mas a diferença é muito fundamental: os feature teams eles estão lá para servir o negócio. O que significa é que stakeholders tem uma necessidade, e eles priorizam essas necessidades e dão como um roadmap para times de produtos desenvolvedores. O trabalho desse time é servir o negócio.

Nesses times, Product Managers são melhores descritos como Project Managers, pois o trabalho deles é mover as tarefas do designer, para o time de desenvolvimento e depois para os testers e assim por diante até fazer o deploy. O Cagan não sugere que você saia de empresas que tem feature teams (assim como ele sugere que você saia de empresas que tenham Delivery Teams) pois essas empresas estão tentando se transformar, e para que elas ultrapassem a fase de transformação, elas precisam da sua ajuda.

Esses times são direcionados por outputs, não outcomes. É muito difícil distinguir esses times de times de produto reais, porque eles ainda entregam coisas que se parecem com valor que os usuários precisam ou que atingem as necessidades de negócio.

Os Empowered Teams

Esse são os times que que criam uma grande empresa com grandes produtos. Google e Intel foram construídas nesse modelo. Empowered Teams existem para servir os clientes (os clientes reais, que pagam para ter o produto), de uma forma que encontrem as necessidades do negócio.

Nesse contexto a relação do PM e do Time, juntamente com o resto da empresa, é fundamentalmente diferente dos outros dois tipos de times: um empowered team não é um servidor dos stakeholders, mas eles trabalham para resolver problemas servindo o cliente final.

Nesse contexto, temos PMs realmente responsáveis por encontrar a solução para o usuário que saciem as necessidades do negócio. Essa soluções são viáveis, valiosas, possíveis e usáveis.

Times de produto empoderados são times que tentam resolver problemas do negócio e dos consumidores. Eles são empoderados para descobrir, desenhar e entregar soluções para esses problemas, além de serem responsáveis pelos resultados (bons ou ruins).

Nesse caso, Product Managers têm um trabalho que demandam muito do seu tempo. É um trabalho mais difícil e estressante. É um trabalho que impacta o negócio e as pessoas. Pensa que você é um PM que trabalha em produtos como Gmail, que impacta bilhões de pessoas. Você precisa entender que há uma responsabilidade muito ampla e com muitos riscos envolvidos.

Times Empoderados de Produto tem as seguintes características:

• São times multifuncionais, compostos por especialidades como Product Manager, Product Designer, Devs e outras especialidades como QA, Data, Researcher etc. Tudo o que é necessário para resolver um problema daquele produto;
• Eles são times pequenos. Apenas os suficiente para resolver os problemas;
• Times duráveis. Eles não são times temporários. Esses times precisam estar juntos o suficiente para aprender, ganhar respeito, autoridade sobre o assunto que estão resolvendo;
• Times com sentimento claro de ownership. Eles não são donos do produto inteiro, eles são donos de um pedaço, mas eles são realmente donos desse pedaço que eles cuidam;
• Times empoderados, que podem tomar decisões para resolver problemas claros. Eles sabem qual a melhor forma de resolver os problemas que estão enfrentando. Eles fazem isso testando várias ideias e hipóteses;
• São direcionados por outcomes (resultados). Eles não são medidos pela quantidade de features ou tarefas que eles entregam, mas pelos resultados que eles criam, pelos impactos que eles causam nos ponteiros de negócio;

Como times de produtos empoderados resolvem problemas?

Eles fazem Discovery para descobrir qual a melhor hipótese eles precisam atacar. Eles precisam fazer produtos que são valorosos, usáveis, possíveis e viáveis. Para isso eles passam por uma fase de Discovery para entender e validar ideias.

Na fase de delivery eles trabalham para entregar uma solução que confiável, escalável, performática e de fácil manutenção.

Algumas pessoas chamam isso de Dual Track Agile, outras de Continuous Discovery e Delivery. Airbnb chama isso de “Build things don’t scale, then build things that do scale”. O Google chama de “Fake it, then make it”.

Esse é um teste que você pode fazer para entender se seu time é um Empowered Teams. O Canga disse que ficaria feliz se você me dissesse que trabalhasse em um time assim:

• Meu time é Cross Functional: O time é formado com competente pessoas que cobrem várias especialidades: Devs, design, produtos, qa, etc
• Meu time é empoderado: O time é alinhado para resolver problemas, e eles são capacitados para decidir as soluções desses problemas e tem o poder para decidir;
• Meu time é Accountable: O time que é responsável para resolver problemas de clientes e ou do negócio (outcome);

Como transformar seu time em um time empoderado de produto?

• Garanta que exista um líder sênior de produto. Se seus líderes não tem essa experiência e não conseguem Coach com pessoas competentes, isso se torna critico e a transformação falha;
• Aumente a base fundamental de conhecimento e experiência do time. Precisamos de Product Managers, não Project Managers, não Product Owners. Mas Product Managers. Eles também precisam de Coach. Se não há Coach para os PMs se tornarem melhores, também falharemos;
• Re-apresente os times para os times de negócio, executivos e stakeholders. Quando esse time existir, faça essa re-apresentação, para que haja uma cooperação de todas as partes;

Pontos chaves para uma transformação de sucesso:

1. Senior Leadership Support;
2. Embrace the role of technology;
3. Understand impact beyond product;
4. Strong Product Leaders;
5. True strong product managers;
6. Empowered engineers;
7. Intentional product strategy;
8. Business collaboration;
9. Continuous evangelisation;
10. Corporate courage;

O líder é responsável não apenas pela visão do produto, mas também pela estratégia do produto. A estratégia do Produto é necessária para que o time de produto faça a evangelização das outras áreas. É assim que podemos compartilhar as falhas e os sucessos do produto com os integrantes de outros times da empresa.

Algumas perguntas feitas no final da palestra

Quais os skills de um bom product managers ou um time empoderado?

São 4 pontos importantes:

1. Precisam aprender sobre os clientes/usuários. Visite, fale com os clientes… Entenda seus problemas, seus problemas, seus objetivos;
2. Aprenda sobre dados: entenda como os produtos são usados. Como o produto é comprado. Você precisa gastar um tempo perguntando com os analistas de dados. Mas você precisa ser um expert sobre como seu produto é usado;
3. Entenda sobre a indústria: qual o ambiente competitivo? Como o mercado se comporta? Esteja sempre antenado nas novidades da indústria;
4. Conhecimento profundo do seu negócio: como funciona os problemas financeiros? Quanto custa para manter a empresa? Quais os custos? Quais os competidores? Como a empresa ganha dinheiro? Como os competidores ganham dinheiro?

É possível um PM que não tem background técnico de atuar como um PM

Algumas empresas pedem esse background, outras não. Tudo o que um Product Manager precisa é coaching. Não encontre uma empresa que tenha só times de delivery. Procure empresas que tenham um ambiente que potencialize o papel do Product Manager.

O trabalho do PM é o pior trabalho se você quer chegar de manha, tomar um cafezinho e ir embora depois do expediente. Você precisa se preocupar com o seu produto. Precisa pensar como o dono, não como um empregado. Isso é essencial para PMs, mas também para Times de Produto.

Sobre KPIs e OKRs

Os KPIs são relacionados a OKR. OKR é apenas uma técnica, que primeiro há muita confusão e frustração sobre OKR exatamente porque as pessoas confundem o que o OKR é. Além disso as pessoas falham ao usar OKR, porque o OKR é feito para times empoderados (Empowered Teams), não para Feature Teams.

Minha (longa) conclusão

Tecnicamente o Cagan só reiterou seu discurso de anos sobre o papel do Product Manager, mas agora, o Cagan está discursando mais no ambiente de times de produto e não do papel do Product Manager. Embora ele já tenha falado bastante sobre o assunto de estruturação e como os times de produto deveriam ser, acho que faz sentido ele “reciclar” esse discurso para um tempo onde empresas acham que é só colocar o nome de SQUAD em grupos de duas ou mais pessoas que a coisa vai rolar magicamente.

Como sempre a palestra dele foi cheia de socos no estômago de quem acha que faz produto, e também encheu de alegria os papagaios que existem no mercado. Eu concordo com praticamente quase tudo do que o Cagan fala, exatamente porque é óbvio.

As palestras e as palavras do Cagan nos tocam tanto, porque nós não conseguimos fazer praticamente NADA do que ele fala/prega. Não por que não queremos, mas por que o ambiente atual das empresas e do mercado de tecnologia no Brasil é muito imaturo.

Não temos a cultura de tecnologia necessária (e se você estiver pensando só em Devs quando lê tecnologia, é uma prova do que estou falando), quando comparamos nosso mercado e o mercado lá de fora. Embora o Cagan fale que lá fora também existam problemas como aqui, com certeza não são problemas de um nível tão inicial quanto os daqui.

Existem sim empresas que chegam muito perto aqui, mas ainda assim, acho que a verdadeira mudança está por vir nos próximos anos, quando profissionais estarão mais maduros, empresas estarão mais acostumadas e espertas e consumidores mais disciplinados e preparados. Até lá, tente mudar o status quo e fuja de (ou ajude a mudar) empresas de produtos que se parecem com acampamentos hippie.

Originally published at https://diegoeis.com.

Anotação da Palestra Marty Cagan — Digital Product Week 2020 — Tera — Blog do Diego Eis was originally published in productoversee on Medium, where people are continuing the conversation by highlighting and responding to this story.