The fallacy of the internal customer

I have seen quite often people using the concept of internal customer or internal user when discussing work done between areas. Something along the lines of “I have here a demand for you and, as I am your internal customer I need that demand solved as soon as possible, preferably until the day X”. I have even seen some people suggesting that we evaluate each other as internal customers and internal suppliers.

The problem with using the internal customer concept for relationship between areas is that it tends to put people in these areas on opposite sides. Someone from an area has a demand for another area. One area asks and the other area executes. If the other area does not execute well, the demanding area complains. If the other area does not deliver on the agreed time, the demanding area complaims. Then the area that has to execute the demand justifies that the request was unclear and that the demand should be made in Z format, specifying A, B and C because, without it, they cannot execute the demand correctly or on time. And so it continues…

In addition, companies typically have more than two areas. Thus, an area may have more than one internal customer and thus can receive various demands which, most often, are all “needed yesterday” and all are “the most important for the company.” Then begins the prioritization dispute.

Internal customer vs. teamwork

In 2001 a group of people who worked with on-demand software development met to discuss the best ways to make software. These conversations gave rise to the Agile Manifest containing the basis of the agility concepts that have improved considerably the success rate of software development projects in our industry. During these conversations they came to the conclusion that, among other things, there needed to be more customer collaboration. To have more success in software development projects is essential that the customer became part of the team that is developing software, and not a mere spectator plaintiff.

We must stop with this concept of internal customer and return to using the good old concept of teamwork, even among different areas. Teamwork is not just for people of the same area, but also for people from different areas. Any business can and should be seen ultimately as a team of teams.

To work well in a team, you must have empathy, that is, know how to understand and respect the viewpoints of others, put yourself in their shoes, try to understand how others think and why they think that way. Different areas have different cultures and different ways of thinking. And that’s good! Teams work mainly because different people, working together, are able to produce a result with greater impact than using only their individual skills. If everyone thought alike, this would not be possible. Therefore, in order to have real teamwork, it is important not only to tolerate and live with the differences: we must exploit them. We must cooperate. We must exchange knowledge. Valuing healthy conflict, not being afraid of debate and disagreements. When two people exchange ideas, each one gets out of the exchange with more ideas. Everyone wins. Different viewpoints help to build better results, s as long as people is not motivated by ego or distrust.

Practical example

Moving from theory to practice,  let me give you an example. I’ll use the need for hiring new employees in a given area that will need HR for this these example. When we need to make new hirings, we should avoid simply sending the job description to the HR and passively wait HR to do this task and only then get back to the HR and ask if they managed to fill the vacancy. The problem to be solved is to fill the vacancy with the best person possible within the budgeted salary range for the position and within the deadline. This is not an HR only problem. It is a problem to be solved by the HR team together with the demanding area. For this reason, the person who asked for a new hiring needs to work with the HR department to fill that vacancy, not only doing the interviews, but also helping to promote the vacancy, discussing each received curriculum, each candidate interviewed and so on. A new hire should be a teamwork of the HR team and the area who needs to do this new hiring. The chances of making a good hiring in proper time are much higher when the demanding area and HR come together and work as a team to do this hiring.

So I suggest we stop using the concept of internal customer and get back to the good old teamwork, even among areas. This will greatly increase the success rate of new endeavours, as well as the motivation of the people of the areas involved.

Product Management: Delight your customers with your software

In 2015 I wrote a book on Software Product Management in Portuguese. In the beginning of 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.

The book is organized in 5 sections:

  • Definitions and requirements
  • Life cycle of a software product
  • Relationship with other areas
  • Product portfolio management
  • Where to use software product management

This book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedback is always welcome!

Be the first to like.

A falácia do cliente interno

Tenho visto com alguma frequência pessoas usando o conceito de cliente interno ou de usuário interno, quando se referenciam a trabalhos feitos entre áreas. Algo na linha de “eu tenho aqui uma demanda para você(s) e, como sou seu cliente/usuário interno, preciso dessa demanda solucionada por você(s) o mais rápido possível, preferencialmente até o dia X”. Tenho inclusive visto algumas pessoas propondo que avaliemos uns aos outros como clientes-fornecedores internos, ou seja que avaliemos satisfação do cliente/usuário interno com seu fornecedor interno.

O problema de usar esse conceito de cliente interno para a relação entre áreas é que ele tende a colocar as pessoas dessas áreas em lados opostos, ou seja, uma pessoa de uma área pede algo ou, termo que também já vi sendo usado, tem uma demanda, para outra área. Uma área pede e a outra faz. Se a outra área não fizer bem feito, a área que pediu reclama. Se a outra área não entregar no prazo combinado, a área de pediu reclama. Aí a área que atendeu a demanda justifica que o pedido não estava claro e que o pedido tem que ser feito no formato Z, especificando A, B e C pois, sem isso, não dá para atender a demanda direito, nem no prazo. E assim por diante.

Além disso, as empresas normalmente têm mais do que duas áreas. Assim, um área pode ter mais de um cliente interno e, consequentemente, pode receber várias demandas que, na maioria das vezes, são todas “pra ontem” e todas são “a mais importante para a empresa”. Aí começa a disputa de prioridades.

Cliente interno vs trabalho em equipe

Em 2001 um grupo de pessoas que trabalhavam com desenvolvimento de software sob demanda se reuniu para conversar sobre maneiras melhores de se fazer software. Essas conversas deram origem ao Manifesto Ágil contendo a base dos conceitos de agilidade que melhoraram em muito a taxa de sucesso dos projetos de desenvolvimento de software em nossa indústria. Durante essas conversas eles chegaram à conclusão que, dentre outras coisas, era necessário haver mais colaboração com o cliente. Ou seja, para ter mais sucesso nos projetos de desenvolvimento de software é essencial que o cliente seja parte do time que está desenvolvendo software, e não mero demandante espectador.

cliente-interno-x-trabalho-em-equipe

É preciso parar com esse conceito de cliente-fornecedor interno e voltar a usar o bom e velho conceito de trabalho em equipe, inclusive entre áreas diferentes. Trabalho em equipe não serve apenas para pessoas da mesma área, mas também para pessoas de áreas diferentes. Qualquer empresa pode e deve ser vista, em última instância, como uma equipe de equipes.

Para se trabalhar bem em equipe, é preciso ter empatia, ou seja, saber entender e respeitar o ponto de vista do outro, colocar-se em seu lugar, tentar entender como o outro pensa e porque ele pensa dessa forma. Áreas diferentes têm culturas e modos de pensar diferentes. E isso é bom! Equipes funcionam, principalmente, porque pessoas diferentes, colaborando entre si, são capazes de produzir um resultado de maior impacto do que se usassem somente suas habilidades individuais. Se todos pensassem igual, isso não seria possível. Por isso, para que haja um verdadeiro trabalho em equipe, é importante não só tolerar e conviver com as diferenças: é preciso explorá-las. É preciso colaborar, trocar conhecimento. Valorizar o conflito saudável, não ter medo de debater e discordar. Quando duas pessoas trocam ideias, cada uma sai com uma ideia a mais, todos ganham. Opiniões diferentes ajudam a construir, desde que motivadas não por ego ou desconfianças, mas sim pela crença num resultado melhor.

Exemplo prático

Para sair do teórico e citar um exemplo prático, vamos usar a necessidade de contratações de novas funcionários de uma determinada área que vai precisar do RH para efetuar essas contratações. Quando precisamos fazer novas contratações, devemos evitar simplesmente mandar para o RH um descritivo do cargo e aguardar passivamente o prazo que o RH tem para fazer essa tarefa e só aí chegar para o RH e perguntar se conseguiram preencher a vaga. O problema a ser resolvido é preencher a vaga com a melhor pessoa possível dentro da faixa salarial orçada para a vaga e dentro do prazo. Esse não é um problema só do RH. É do RH e da área que pediu. Por isso quem pediu deve trabalhar junto com o RH para preencher esse vaga, não só fazendo as entrevistas, mas também ajudando a divulgar a vaga, conversando sobre cada currículo recebido, cada candidato entrevistado e assim por diante. Uma nova contratação deve ser um trabalho em equipe do RH e da área que precisa fazer essa nova contratação. As chances de fazer uma boa contratação no prazo adequado são muito maiores quando a área que precisa fazer essa contratação e o RH se juntam e trabalham em equipe.

Por isso sugiro pararmos de usar o conceito de cliente interno e voltarmos ao bom e velho trabalho em equipe, inclusive entre áreas. Isso vai aumentar em muito a taxa de sucesso das novas empreitadas, assim como a motivação das pessoas das áreas envolvidas.

Be the first to like.

Guerra, ar, comida, lucro e o mundo dos negócios

Esse artigo vai ser um pouco mais “filosófico” sobre dois temas que considero bastante importantes do mundo dos negócios. Ambos têm a ver com minha visão de liderança e por isso os compartilho aqui.

Guerra

É comum ouvir comparações entre o mundo dos negócios e situações de guerra, de combate e de luta. Aliás, a própria palavra “estratégia”, tão comum nas empresas de hoje em dia, vem do mundo militar. Vem da palavra grega strategos, junção das palavras stratos (exército) e agos (líder). Ou seja, strategos signifca originalmente o líder do exército, o general, aquele que define como o exércíto deverá agir frente às situações. Um dos livros que constantemente aparece na lista de mais recomendados para administração é “A Arte da Guerra”, um tratado militar escrito durante o século IV a.C. por Sun Tzu, general chinês.

Quem me conhece sabe que sou uma pessoa pacífica. Odeio brigas. Aliás, se acidentalmente entro numa, estou disposto até a pagar para evitar a briga. Por isso, sempre que vejo essas comparações do mundo de negócios com guerra, combate, luta, competição, eu me sinto profundamente incomodado. Vou colocar abaixo algumas imagens para relembrar o que costuma acontecer durante uma guerra:

war-0

war-1

war-4

war-2

Vietnam The Real War

Acho que essas imagens falam por si… :-/

Usar guerra, combate, luta como analogia para o mundo dos negócios não faz o mínimo sentido. Nelas o objetivo é derrotar o adversário. É estranho imaginar uma empresa cujo objetivo principal seja derrotar algo ou alguém. Algumas pessoas já comentaram comigo que numa guerra, a guerra em si não é o objetivo, mas sim um meio para se atingir um objetivo. Ok, faz sentido, mas existem vários meios para se atingir um determinado objetivo. A guerra não é o único meio. Por que então a insistência em usar a guerra como analogia para as empresas?

Buscando na Wikipedia, encontramos a seguinte definição para empresa:

Empresa é uma instituição jurídica despersonalizada, caracterizada pela atividade econômica organizada, ou unitariamente estruturada, destinada à produção ou circulação de bens ou de serviços para o mercado ou à intermediação deles no circuito econômico.

Essa definição deixa claro que a empresa existe para produzir e/ou servir. Como pode algo que tem por objetivo produzir e/ou servir, ter por analogia algo que tem por objetivo ou por modo de ação a destruição? A maneira correta de olhar uma empresa e seus objetivos é pensando em construção, em relação ganha-ganha, ou seja, onde o cliente sai ganhando, os funcionários saem ganhando, os donos da empresa saem ganhando, a sociedade onde a empresa está inserida sai ganhando. Sempre que direcionamos energia para derrotar o “oponente” (cliente, competidor, funcionário, etc.), estaremos desperdiçando energia que poderia ser usada em algo construtivo.

Ar, comida e lucro

Não raro vemos acionistas, investidores e funcionários de uma empresa 100% focados nos resultados financeiros da empresa. Quando em período de crise, esse foco consegue ir além dos 100%… :-/

Certa vez ouvi uma frase, popularizada por Dick Costolo, CEO do Twitter, que compara receita a oxigênio:

Receita é como oxigênio, é necessário, é vital para a saúde e para o sucesso de uma empresa, mas não é propósito da vida. Você não acorda de manhã e a primeira coisa que pensa é “como eu posso conseguir mais ar?”

Gosto bastante dessa comparação. Toda empresa deve ter um propósito e esse propósito não pode ser derrotar os inimigos, como explicado acima, nem conseguir a maior quantidade de dinheiro possível.

O resultado financeiro deve sempre ser utilizado como uma das métricas que indicam que a empresa está tendo sucesso, que está cumprindo com o seu propósito. Contudo, mesmo como métrica, ela não deve ser olhada de forma isolada, pois existe a boa e a má receita. A má receita é toda receita obtida às custas do detrimento do relacionamento com o cliente. Por exemplo, uma empresa que presta um serviço com pagamento mensal e, quando um cliente quer cancelar, ela dificulta a sua saída para manter aquela fonte de receita por mais alguns meses, isso é uma má receita. Quando uma companhia aérea cobra uma taxa para adiantar o horário de um vôo, mesmo sabendo que o avião tem espaço de sobra, isso é má receita. As taxas de roaming internacionais exorbitantes também são um bom exemplo de má receita. Locadoras de veículos que cobram a taxa de gasolina, com preço de gasolina bem mais caro que a do mercado, quando você devolve o carro sem estar com o tanque cheio, isso também é uma má receita. Se uma empresa te vende algo com preço acima do adequado, se aproveitando que vc precisa daquele item como, por exemplo, o custo absurdo da garrafa de água em um hotel, isso também é uma má receita.

Ou seja, apesar da comparação de receita e lucro com oxigênio ser boa, ela é incompleta, pois não capta o efeito da má receita. Raramente você pensa no oxigênio, a não ser que esteja com falta de ar. Eu não acho que a receita se deva ser lembrada quando ela está faltando. Receita é o que mantém a empresa viva, capaz de executar seu propósito. Se for uma boa receita, a empresa vai continuar cumprindo seu propósito por muitos anos. Se for uma má receita, ela terá dificuldades no médio prazo.

Por esse motivo, eu prefiro comparar receita e lucro com comida. Da mesma forma que as pessoas saudáveis não pensam em oxigênio o dia inteiro, pessoas saudáveis também não pensam em comida o dia todo. Contudo, diferentemente do oxigênio, que só existe o bom oxigênio, quando falamos de comida, existe a comida boa, saudável, que faz bem para o seu organismo, e existe a má comida, que vai prejudicar seu organismo, com possibilidade de fazer você ficar doente. E é muito importante que a pessoa saiba o que é boa comida e má comida e que pense sobre como obter boa comida e como evitar a má comida.

Pegando a frase de cima e aprimorando-a trocando o oxigênio pela comida, teremos:

Receita é como comida, é necessária, é vital para a saúde e para o sucesso de uma empresa, mas não é propósito da vida. Você não acorda de manhã e a primeira coisa que pensa é “como eu posso conseguir mais comida?”. Contudo, tanto uma empresa quanto uma pessoa devem estar sempre atentas à qualidade da comida que está ingerindo, para ter certeza de que ela não vai causar nenhuma mal à saúde.

Resumindo

As duas dicas de liderança desse artigo são um pouco mais filosóficas, mas bastante relevantes:

  • Evite comparação de empresas com guerra, luta, combate. Enquanto uma empresa deve ser ter o propósito de construir, guerra, luta, combate, mesmo que não tenham a destruição por objetivo, passa pela destruição, nada mais oposto ao propósito de uma empresa.
     
  • Receita é como comida, é necessária, é vital para a saúde e para o sucesso de uma empresa, mas não é propósito da vida. Você não acorda de manhã e a primeira coisa que pensa é “como eu posso conseguir mais comida?”. Contudo, tanto uma empresa quanto uma pessoa devem estar sempre atentas à qualidade da comida que está ingerindo, para ter certeza de que ela não causar nenhuma mal à saúde.
Be the first to like.

Planejando e preservando a cultura organizacional

Cultura é um conjunto de premissas que foram aprendidas e compartilhadas por um grupo de pessoas enquanto resolviam problemas de adaptação externa e de integração interna. Esse conjunto de premissas funciona bem o suficiente para ser considerado válido e, consequentemente, ser ensinado aos novos membros do grupo como a forma correta de perceber, pensar e sentir em relação a esses problemas.

A definição acima é Edgard Schein, professor do MIT, considerado um dos criadores do conceito de Cultura Organizacional.

A cultura é uma característica de toda empresa. Até mesmo dentro de uma empresa existem sub-culturas, ou seja, cada área ou time dentro de uma mepresa pode ter uma cultura própria. Por exemplo, a cultura de um time comercial tem sempre algumas diferenças da cultura do time de engenharia de software. Não existe cultura certa ou cultura errada. Empresas diferentes têm culturas diferentes e mesmo assim podem ter sucesso apesar dessas diferenças. A charge abaixo ilustra a diferença de cultura entre Amazon, Apple, Facebook, Google, Microsoft e Oracle. Mesmo com essas diferenças culturais, todas são empresas de sucesso.

cultura

A cultura vem dos fundadores da empresa. Os fundadores tem sua própria cultora e é natural que imprimam essa cultura na organização que estão criando. Em função disso, é muito comum se pensar que cultura é algo que emerge em um organização. O fundador traz sua cultura e ao contratar novas pessoas, busca sempre pessoas com cultura similar à sua. Isso acaba criando uma cultura comum muito próxima daquela traziada pelo fundador da empresa. Esse conceito de cultura emergente dá a impressão de que não se pode alterar deliberadamente a cultura, e que ela irá se desenvolver de forma orgânica.

Schein alerta que isso é um engano. Culturas podem e devem ser planejadas. Por exemplo, se você acha importante que na cultura de sua empresa o erro seja sempre visto como oportunidade de melhoria e aprendizado, você deve evitar ao máximo a busca por culpados e deve sempre direcionar as discussões, quando um erro acontecer, para o aprendizado com esse erro.

Recapitulando

Com esse artigo fecho o tema de dicas de liderança essenciais para qualquer gestor de produtos:

Comentários

E vc, que dicas vc tem para compartilhar sobre liderança? Deixe seu comentário!

Be the first to like.

Não desperdice tempo buscando culpados

Como comentei no artigo Dicas de liderança para um gestor de produto:

Um gestor de produtos tem a difícil tarefa de liderar a evolução do produto sem ser “chefe” de ninguém, ou seja, ele deve convencer a todas as pessoas que trabalham com seu produto de que o caminho que ele definiu para o produto é o mais adequado. Em vários textos sobre gestão de produtos encontramos que o gestor de produtos é o CEO do produto. Não gosto muito dessa analogia pois um CEO, em última instância, tem ao seu dispor a liderança direta de todas as pessoas da empresa. Por outro lado, um gestor de produto trabalha em uma relação matricial, ou seja, não tem liderança direta de nenhuma das pessoas envolvidas com o produto. Aliás, esse é um excelente exercício de liderança e uma qualidade extremamente importante para um gestor de produtos: liderar sem ter a “chefia” organizacional.

Pensando nisso, resolvi criar uma nova categoria de artigos com o tema liderança, para ajudar gestores de produtos sobre essa faceta de seu trabalho, a liderança em um ambiente matricial, sem ter a “chefia” organizacional. Esses artigos poderão servir tb para outros líderes que tenham “chefia” organizacional, mas o foco será mesmo em dicas de liderança para gestores de produtos, que não são “chefes” de ninguém.

Não desperdice tempo buscando culpados

Quando erros acontecem, algumas pessoas têm uma tendência natural de ter como sua primeira reação procurar quem é o culpado. Especialmente em atividades de grupo. Como se ter alguém para culpar de alguma forma fizesse o erro menos prejudicial. Este é um grande desperdício de tempo e energia. Deixe-me explicar porquê.

blame

Perda de tempo

Ocorreu um erro. Erros acontecem. Este é um fato da vida. Não importa o que você está fazendo, desenvolvendo software, publicando código em produção, operando um paciente, cozinhando o jantar, construindo uma casa, tocando guitarra, jogando futebol, etc. Há boas chances de que erros venham a acontecer.

Quando você gasta tempo tentando descobrir quem foi o responsável pelo erro, você vai adiar suas tarefas mais importantes em relação ao erro:

  • compreender o que aconteceu
  • descobrir como corrigir
  • encontrar formas de evitar que isso aconteça novamente

Desperdício de energia

Quando você gasta tempo tentando descobrir quem foi o responsável pelo erro, as pessoas podem, naturalmente, tentar esconder o erro por temer as conseqüências. Será que vou ser demitido? Será que vou ser excluído do grupo? Será que vou ser punido? Será que as pessoas irão zombar de mim?

Quando as pessoas tentam esconder quem foi o responsável, você vai acabar adiando as tarefas mais importantes que listei acima para tratar o erro, pois será mais difícil entender o que aconteceu. As pessoas não vão dizer toda a verdade sobre o erro e as circunstâncias em que o erro aconteceu.

Lide com o responsável em particular

Se no processo de entender o que aconteceu você descobrir que alguém foi responsável pelo erro, lide com ele em particular. O mais provável é que ele tenha causado o erro sem intenção de fazer mal. Por isso você precisa ajudá-lo a melhorar para que ele não faça mais esse tipo de erro. Por outro lado, você tem a responsabilidade de criar um ambiente onde é seguro falar sobre os erros, para que esses erros sejam detectados o mais rápido possível.

Resumindo

  • Quando ocorrer um erro, não perca seu tempo buscando culpados.
  • Concentre sua energia em entender o que aconteceu.
  • Descubra como corrigi-lo.
  • Encontre maneiras de evitar que o erro aconteça novamente.
  • Se você descobrir que alguém foi responsável, lide com ele em particular, e o ajude a melhorar.

Comentários

Vc também tem dicas de liderança para gestores de produto? Dicas que funcionam nesse ambiente matricial onde o gestor de produtos tem a responsabilidade de liderança, mas não tem a “chefia” organizacional de ninguém? Compartilhe nos comentários.

Be the first to like.

Nem todo retorno é financeiro

Como eu havia comentado aqui, nem sempre o retorno que obtemos é o retorno financeiro. Eu particularmente não considero retorno financeiro umaboa métrica de sucesso de uma startup ou de uma empresa estabelecida. Retorno financeiro é igual ar para os seres vivos, essencial para a sobrevivência, mas não é por ter mais ar do que se consegue respirar que um ser vivo irá viver melhor.

O retorno de uma empresa acontece quando ela é capaz de cumprir sua missão. No começo desse ano defini a missão do ContaCal, sob a forma de resolução de fim de ano, como sendo:

Ajudar o maior número de pessoas a ter uma alimentação mais saudável e balanceada!

Hoje recebi uma mensagem, que compartilho aqui no Guia da Startup, pois me mostrou que estou conseguindo cumprir minha missão, pelo menos para uma pessoa! 🙂

Fiz o periodo grátis de 5 dias e adorei já tinha eliminado 3 quilos com muita dedicação e com o apoio de vcs mas precisei esperar o tempo da assinatura ser liberada e com isso veio a pascoa e ai dei uma desanimada engordei 2 quilos pois me senti sozinha pois vcs ñ são só um conta calorias mas amigos que nos insentivam todos os dias a seguir em frente que iremos conseguir porque vcs só de escutarem este desabafo é como se fosse uma familia que cuida da gente fala o que podemos e ñ podemos comer ñ desanimando a gente mas se importando c a gente que bom ter vcs de volta vamos lá familia conta cal esta luta já esta ganha e com certeza comemorarei com vcs logo logo a minha vitória bjs fiquem c Deus

Por isso, sempre que pensarmos em uma novo projeto ou empreendimento, é importante pensar o que queremos com esse projeto além do retorno financeiro que, como eu disse acima, nada mais é do que o ar necessário para a existência da empresa. Qual o retorno esperado? Que problemas queremos resolver? Que necessidade queremos atender? Só assim sabermos medir os resultados de forma adequada para entender se estamos conseguindo atingir o retorno esperado.

Be the first to like.

Por que antes do como

Neste último fim de semana eu estive na QCon São Paulo, uma ótima conferência feita por desenvolvedores para desenvolvedores.

Nesta conferência eu tive a oportunidade de falar sobre o Guia da Startup.

Martin Fowler (@martinfowler) da ThoughtWorks fez o primeiro keynote. Em um certo momento ele usou uma frase interessante para introduzir o tema de bom design e débito técnico.

Eu normalmente me deparo com desenvolvedores que estão frustrados porque “a gerência quer mais recursos, eles não se preocupam com qualidade”

A citação me chamou a atenção especialmente porque, como um desenvolvedor falando para desenvolvedores em uma conferência de desenvolvedores, Martin se focou na parte da frase que normalmente chama a atenção dos desenvolvedores, a parte do “como”. Ele se focou na palavra “qualidade” para explicar o quanto é importante ter um bom design para evitar o endividamento técnico para que os desenvolvedores possam adicionar mais recursos com mais facilidade. Como eu estou mais focado no lado de gestão de produto, assim que eu ouvi a frase, meu foco foi imediatamente para a parte do “porquê”. Isso me motivou a criar um novo slide na minha apresentação sobre as práticas de gerenciamento de produtos:

Quando eu ouvi a frase, meu foco foi direcionado diretamente para a palavra “funcionalidades” e minha primeira reação foi perguntar “Porque é que estas funcionalidades estão sendo solicitadas?”

Quando nos pedem para implementar uma funcionalidade em um software, a reação natural é pensar como essa funcionalidade pode ser implementada. No entanto, precisamos dar um passo atrás e entender o que estamos tentando obter com essa funcionalidade. Que valor essa funcionalidade traz para os usuários do software? Que valor essa funcionalidade traz para os proprietários de software? Cada novo recurso, não importa quão pequena e quão simples de implementar seja, cria complexidade no nosso código. Qual é o valor que esperamos dessa complexidade? Esta é uma pergunta que não apenas um gestor de produto deve fazer, mas todas as pessoas a quem for pedido para implementar uma nova funcionalidade devem tb fazer a mesma pergunta.

Assim, a minha recomendação para todos os desenvolvedores que recebem solicitações para implementar novas funcionalidades é que, antes de correr para descobrir o “como” a funcionalidades deve ser implementada, pergunte “por que” essa funcionalidade está sendo pedida. Isso ajudará você a compreender a importância da funcionalidade e ajudará quem está pedindo a funcionalidade a reafirmar a motivação por trás dessa funcionalidade.

Be the first to like.

Os 99,9%

Quem me conhece sabe que gosto muito de natação. Treino uma hora de segunda a sexta e, nos finais de semana, quando possível, vou para alguma praia ou lago competir em provas de natação em águas abertas.

Na natação, assim como em inúmeras outras habilidades que se queira adquirir, o dom, ou seja, a habilidade inata, conta pouco para as pessoas se tornarem especialistas nessa habilidade. O que é necessário é que:

  • se pratique bastante (10 anos ou 10.000 horas – equivalente a 4 horas por dia útil durante 10 anos);
  • a prática seja consciente, ou seja, que o praticante entenda o que está fazendo;
  • se tenha um bom guia (treinador, coach, mentor, etc.) e;
  • se tenha um ambiente propício.

Esses quatro fatores foram explicados em um artigo intitulado “The Expert Mind” publicado na revista Scientific American em agosto de 2006. Em 2008 Malcolm Gladwell, autor dos livros “O ponto da virada (The Tipping Point: How Little Things Can Make a Big Difference)” e “Blink, a decisão num piscar de olhos (Blink: The Power of Thinking Without Thinking)“, dedicou um livro inteiro a essa tema em “Fora de Série (Outliers: The Story of Success)“.

Eu não pratico natação 4 horas por dia útil. Pratico “apenas” 1 hora por dia útil, ou seja, preciso de 40 anos para virar um especialista. E mesmo que eu consiga praticar mais horas por dia, dificilmente conseguirei ter a performance do César Cielo ou Michael Phelps.


Já que não posso ser o melhor na natação, eu devo parar de praticar? Para que continuar investindo uma hora por dia treinando se não tem como eu competir com os melhores do mundo? Pelo simples prazer de nadar! Pela sensação de bem estar que sinto após cada treino. Pelo prazer de conhecer novas pessoas durante os treinos e nas provas em que participo que compartilham desse meu prazer de nadar. Por saber que a prática de uma atividade física é bom para o corpo e para a mente. Pelo prazer de melhorar. Para incentivar minha filha a praticar esportes. Enfim, existe uma quantidade grande de motivos para eu continuar nadando, mesmo que não exista nenhuma chance de eu competir com os melhores do mundo.

Faço parte dos 99,9%

César Cielo, Michael Phelps e todos esses nadadores que competem em olimpíadas e em provas mundiais de natação representam 0,1% dos praticantes de natação. Eu faço parte dos 99,9%. A mídia esportiva só fala dos 0,1%. A mídia dedicada à natação fala dos 0,5%. A mídia que fala de natação em águas abertas fala dos 0,1% de nadadores que praticam e competem em águas abertas. A mídia que fala de natação masters, ou seja, nadadores acima de 25 anos que deixaram a alta competição também se foca nos 0,1% dos nadadores masters. E está certo falar dos 0,1%, afinal a mídia fala do que é exceção. Os 0,1% é que são notícia.

E os 99,9%?

Continuam praticando natação pelos motivos que descrevi acima ou por outros que nem consigo imaginar. Esses 99,9% olham para esses 0,1% como fonte de aprendizado. O que eles fazem para conseguir nadar tão bem? Posso copiar alguma coisa que eles fazem para eu também melhorar? E o que eles fazem exageradamente que eu não quero fazer, pois não tem a ver como minha motivação para nadar?

O mesmo vale para startups e empresas em geral. A mídia fala apenas dos 0,1%. Fala de Google, Facebook, Twitter, Slideshare, Skype, Instagram, Yammer e de várias outras empresas grandes ou que conseguiram investimentos milionários ou que foram vendidas por valores bilionários. E são esses 0,1% que são notícia, exatamente por serem as execeções.

Como exliquei no post sobre problemas e necessidades, as startup bilionárias, ou seja, aquelas que tem crescimento bem acelerado, são raríssimas. Segundo o relatório Empreendedorismo em revista – 2011 da Organização de Desenvolvimento e Cooperação Econônica (OECD – Organization of Economic Development and Cooperation), menos de 1% das empresas com mais de 10 funcionários têm crescimento de funcionários maior que 20% ao ano nos últimos 3 anos. O estudo chama essas empresas de gazelas, devido à sua velocidade. Segundo o mesmo estudo:

Empresas que crescem mais rápido que o ritmo das gazelas (as super gazelas) são ainda mais raras – tão raras que é muito difícil de medi-las estatisticamente.

Como sabemos que o número de funcionários normalmente está diretamente ligado ao crescimento de receita das empresas, é fácil concluir as “super gazelas” de receita tb são raríssimas, tão raras que sequer têm relevância estatística. Contudo, elas absorvem toda a atenção da mídia, exatamente por serem exceções.

Sramana Mitra, uma reconhecida consultora de estratégia para startups que colobora frequentemente no site ReadWriteWeb, escreveu um artigo falando sobre os outros 99% de empreendedores onde ela diz:

Mais de 99% dos empreendedores que buscam por financioamento de VCs e investidores anjo são rejeitados. Alguns porque apresentam suas ideias muito cedo e estão despreparados, outros porque seu mercado é muito pequeno ou o ritmo de crescimento é lento. Mike Maples, um conhecido investidor anjo do Vale do Silício, recebe mais de 7.000 propostas de investimento por ano e escolhe apenas de 10 a 12 para investir. (Isso dá uma taxa de rejeição de 99,8%) […] Mesmo assim, a mídia se foca nos 1% que são “financiáveis”. Quando a mídia fala sobre uma startup, ela está interessada em saber qual VC investiu e quanto investiu. Raramente pergunta quanta receita a startup tem e se a startup é rentável. […] Por outro lado, existem inúmeras histórias de empresas de sucesso que cresceram sem nenhum centavo de investimento de VCs. […] Elas existem num mundo de empreendedores que gostam de sua liberdade e não estão procurando vender suas empresas ou torná-las públicas. Pode-se dizer que são empresas feitas para curtir (build-to-enjoy) em oposição às empresas feitas para vender (build-to-flip).

Ou seja, o fato de uma empresa não estar nos 0,1% que a mídia fala não significa que ela não é uma empresa rentável e bem sucedida. Ao contrário, a quantidade de empresas rentáveis e bem sucedidas que iremos encontrar nos 99,9% das empresas que não aparecem na mídia é muito maior do que nos 0,1%.

Continue praticando e não se esqueça de sua motivação

Assim como na natação ou em qualquer outra habilidade que você queira adquirir, não existe pessoas com o dom de criar startups. Tanto Sergey Brin e Larry Page, fundadores do Google, quanto Mark Zuckerberg do Facebook, chamaram pessoas experientes para ajudar no crescimento de suas startups. Steve Jobs estava no seu auge em seus últimos anos de Apple, certamente muito melhor do que no começo. Por esse motivo, é importante que você continue praticando, experimentando e estudando sobre como criar e gerenciar produtos web. Procure mentores para lhe ajudar nesse caminho. Troque experiências com outros empreendedores. Como explicado na Scientific Americam e no livro “Fora de Série”, quanto mais praticarmos de forma cosciente, mais nos tornamos especialistas no assunto.

E lembre-se sempre de sua motivação para ter uma startup. Assim como na natação, esses 0,1% de empresas que aparecem na mídia devem ser observados como fonte de aprendizado tanto positivo quanto negativo para a sua startup. O que essas empresas fazem que vc admira e que faz sentido para a sua startup? E o que elas fazem que não faz sentido para você pois não tem a ver com a sua motivação em abrir uma startup?

Be the first to like.

Pense em startup como experimento, e não como negócio

A dica rápida de hoje veio do Paulo Silveira, da Caelum. Ele me mandou um post interessante de um rapaz chamado Vinicius Vacanti que tem uma startup e descreve nesse post as inúmeras desculpas que fizeram ele demorar para lançar logo o produto:

  • Não está bom o bastante.
  • Não queremos dar uma má impressão para os usuários.
  • Precisa de mais algumas funcionalidades.
  • Precisamos de alguns mess para construir o back-end do produto.
  • Precisa escalar para acomodar centenas de mil hares de usuários.
  • Alguém via ver e via copiar.
  • Um investidor potencial vai ver.
  • TechCrunch via escrever sobre a gente e o site não está pronto.

No final do post ele termina com uma frase que define muito bem o que é uma startup:

Pense em startup como experimento, e não como negócio.

Startup é um experimento. Vc deve experimentar para encontrar a solução para o problema de seus clientes e para garantir que esses clientes vão lhe gerar o retorno financeiro suficiente para que vc continue oferecendo essa solução. Quando vc achar que não deve mais experimentar, ou deve diminuir o ritmo de suas experiências, provavelmente vc já encontrou um retorno mensal dentro do que vc esperava e nesse momento vc estará fazendo a transição de startup para um negócio.

Próximo post

Amanhã vamos falar sobre como atrair visitantes para o seu site.

Comentários

Já tinha pensado em startup dessa forma? Ajuda a ver que temos que, já que é uma experiência, devemos experimentar logo, não é?

Be the first to like.

Se vc não tem vergonha da primeira versão de seu produto, vc demorou demais para lançar.

Nos dois últimos posts falamos sobre porque devemos fazer rápido um produto web e que não basta ter bons profissionais, bons equipamentos e boa metodologia, é fundamental definir o produto mínimo, ou seja, que funcionalidades entram e que funcionalidades ficam de fora da primeira versão de seu produto web.

Reid Hoffman, fundador do Linkedin disse certa vez que:

Se vc não tem vergonha da primeira versão do seu produto, vc demorou demais para lançar.

Para ilustrar essa frase, que de certa forma sumariza os dois posts anteriores, resolvi pegar prints da tela da primeira versão de alguns serviços bem conhecidos.


Google em 1998

Google em 1998

Twitter em 2006

Twitter em 2006

Linkedin em 2005

Linkedin em 2005

Tela de login do Facebook em 2005

Tela de login do Facebook em 2005

Facebook em 2005

Facebook em 2005

Buscapé em 1999

Buscapé em 1999

Locaweb em 2002

Locaweb em 2002


Próximo post

No próximo post entramos na segunda parte do mão na massa, a parte que fala sobre gerenciar o produto web. Uma vez que produto web está pronto, o que fazer?

Comentários

E aí, se divertiu revendo as imagens acima? Tem mais imagens bacanas? Compartilhe!

Be the first to like.