Criando funcionalidades que realmente importam
•
10 gostaram•1,044 visualizações
Este documento discute como gerenciar o escopo de um produto de software de forma efetiva. Primeiro, é importante definir uma visão clara para o produto e tomar decisões baseadas nela. Segundamente, é crucial focar em resolver bem um ou dois problemas centrais dos usuários, em vez de tentar adicionar muitas funcionalidades. Por último, é essencial medir o uso real das funcionalidades e não se apegar a novas entregas.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Criando funcionalidades que realmente importam
Semelhante a Criando funcionalidades que realmente importam (20)
Criando funcionalidades que realmente importam
- 2. SOBRE Gerente de Produto Co-FundadorAutor Co-Organizador passado presente
- 3. Software está mudando o mundo ○ Criar um produto está cada vez mais barato ○ O número de usuários que você pode alcançar é o maior da história. ○ Distribuir o software é mais simples do que 10 anos atrás Vantagens atuais
- 4. Os desafios continuam os mesmos ○ Evitar mudanças drásticas no escopo ○ Evitar que o seu produto vire um frankenstein ○ Manter a equipe focada em causar impacto e não apenas criar funcionalidades
- 5. 2. Gerenciando o escopo do produto 3. Entregando o que importa 1. Gerenciamento de um produto
- 6. “A dificuldade de gerenciar um produto começa a aparecer quando você ganha tração
- 7. Com o tempo ○ A sua visão fica melhor ○ Mais competidores aparecem ○ Mais usuários se cadastram ○ A equipe cresce ○ Você começa a aparecer mais na mídia
- 9. Quando seu produto começa a crescer ● Existe aquilo que os fundadores querem criar ● Existe aquilo que os competidores já fazem ● Existe aquilo que os usuários querem ● Existe aquilo que o board/investidores acham que você tem que focar ● Existe aquilo que os maiores clientes estão querendo pagar PRODUTO :( Demandas
- 10. É nessa hora que você pode estragar sua estratégia e até mesmo seu produto.
- 13. Como fazer isso? ● Decida uma visão para o seu produto ● Gerencie ele baseado nessa visão
- 14. Como definir uma visão? ● “Organizar a informação do mundo e torná-la universalmente acessível e útil. " — Google ● “Ser o pulso do planeta.” — Twitter
- 16. A importância de definir uma visão
- 17. Exemplo prático
- 18. 2. Gerenciando o escopo do produto 3. Entregando o que importa 1. Gerenciando um produto - Defina uma visão duradoura - A partir dela criar metas a longo prazo até as atividades do dia a dia - Não crie um Frankenstein
- 19. “Mais funcionalidades não aumentam o valor do seu produto
- 20. Startups normalmente cometem um erro de querer "se provar" com funcionalidades. ERRO 1: QUERER SE PROVAR
- 21. ERRO 2: MOTIVAÇÃO DO USUÁRIO A maioria das vezes que um usuário baixa ou compra o seu produto é por causa de um ou dois problemas especificos que ele resolve.
- 22. É intuitivo pensar que criar um produto que resolva uma série de problemas vai aumentar o valor da startup e a chance de vender o produto ou adquirir usuários. ERRO 3: INTUIÇÃO LEVANDO AO ERRO
- 23. O QUE FAZER NESSAS HORAS? ● Fique próximo dos seus clientes e tente identificar a maior dor que eles tem em comum ● Crie um produto que resolve apenas essas maiores dores. Mas que resolva muito bem
- 24. EXEMPLO: ZENDESK Zendesk foi lançado em 2007. Levou 6 anos de muitos experimentos e investimentos para que eles lançassem o Help Center, no qual é uma extensão natural do serviço de tickets deles. Referência: https://support.zendesk.com/hc/en-us/articles/203657626-Introducing-Help-Center-a-re-imagined-self-service- experience https://www.zendesk.com/company/press/zendesk-announces-60-million-financing/
- 25. EXEMPLO 2: Easy Taxi Empresas Outro segmento. Uma extensão do aplicativo para as empresas terem um controle das corridas na nuvem. Referência: http://corp.easytaxi.com/br/
- 26. “Só quando seu produto solucionar muito bem um problema você pode se preocupar em expandi-lo
- 27. ○ Fácil de explicar/vender ○ Fácil de manusear ○ Faz 1 coisa com excelência ○ Rápido de criar e testar
- 28. ○ Fácil de explicar/vender ○ Fácil de manusear ○ Faz 1 coisa de com excelência ○ Rápido de criar e testar Tesoura vs. Canivete Suiço ○ Difícil de explicar/vender ○ Díficil adesão ○ Não faz nada bem ○ Demorado pra criar e testar
- 29. “Um sistema complexo que funciona é invariavelmente a evolução de um sistema simples que funciona. Um sistema complexo projetado a partir do zero nunca funciona e não pode ser consertado. Você tem que começar partindo de um sistema simples Lei de Gall
- 30. Evolução
- 31. Evolução Robocop Depois de várias iterações
- 32. 2. Gerenciando o escopo do produto 3. Entregando o que importa 1. Gerenciamento de um produto - Defina uma visão duradoura - A partir dela crie tarefas a longo prazo até as tarefas do dia a dia - Não crie um Frankenstein - Sempre medir o uso das funcionalidades - Mais funcionalidades não vão te dar mais usuários - Primeiro resolva bem um ou dois problemas - Não comece por um sistema complexo
- 33. “Foque em coisas que não mudam - Jeff Bezos
- 34. O QUE PENSAR ANTES DE CRIAR NOVAS FUNCIONALIDADES? - Está dentro da sua visão? - Vai fazer sentido em 5 anos? - Beneficia todos os usuários? - Qual o objetivo? - Se for um sucesso, nós vamos conseguir dar suporte?
- 35. “Um bom produto é aquele que as pessoas usam quase todas as funcionalidades igualmente
- 36. UM PRODUTO LOGO APÓS O LANÇAMENTO http://blog. rocketinsights. com/the-next- feature-fallacy/? utm_campaign=hiten- dot- com&utm_medium=e mail&utm_source=sa as-weekly55
- 37. O PIOR CENÁRIO?
- 38. ESSA É A VERDADE QUANDO VOCÊ ADICIONA MAIS COISAS
- 39. COMO SE SAIR BEM CASO ISSO ACONTEÇA?
- 40. SER BOM NO QUE IMPORTA http://www.facebook.com http://www.messenger.com
- 41. OUTRO EXEMPLO
- 42. OUTRO EXEMPLO
- 43. “Empresas não fracassam porque elas não trabalharam 10% a mais. Elas falham porque elas trabalharam nas coisas erradas. - Paul Buchheit, Y Combinator
- 44. SABER DIZER NÃO Se você nunca disse não por causa da sua visão, então você não tem uma visão pro seu produto. Existem várias formas de dizer não: - “Agora não” ou - “Provavelmente não por enquanto”.
- 45. NÃO COMPLICADO VS COMPLICADO Notes - Aplicativo de notas da Apple Evernote versão desktop
- 46. “Existe uma diferença entre fazer um produto simples, e fazer o produto ser simples.
- 47. CELEBRAR O USO E NÃO ENTREGA
- 48. 2. Gerenciando o escopo do produto 3. Entregando o que importa 1. Gerenciamento de um produto - Defina uma visão duradoura - A partir dela crie tarefas a longo prazo até as tarefas do dia a dia - Não crie um Frankenstein - Sempre medir o uso das funcionalidades - Mais funcionalidades não vão te dar mais usuários - Primeiro resolva bem um ou dois problemas - Não comece por um sistema complexo - Faça as perguntas chaves antes de qualquer funcionalidade - Foque em coisas que não mudam - Saiba dizer não - Celebre o uso e não entregas
- 49. Muito obrigado! E-mail: almeidamarcell@gmail.com Twitter: @almeidamarcell Facebook: fb.com/almeidamarcell Startup: www.grana.me CELEBRAR USO E NÃO ENTREGA(momento jabá)
Notas do Editor
- Bom, acho que todo mundo aqui concorda que o software está mudando o mundo. E hoje existem uma série de vantagens pra isso. Por exemplo, criar um produto está cada vez mais barato. O numéro de usuários que você pode atingir é o maior da história. E esse número só vai aumentar! Sem contar que distribuir o software é muito mais simples do que 10 anos atrás. Afinal, quase todo mundo hoje tem pelo menos um smartphone. Pode nem ter computador, mas tem smartphone!
- Acontece que os desafios continuam os mesmos! Você precisa continuar tentando evitar mudanças drásticas no escopo para evitar que o seu produto vire um frankenstein e acima de tudo, enquanto você faz tudo isso, ainda é necessário manter a equipe focada e motivada em causar impacto ao invés de simplesmente entregar funcionalidades. E ah, só uma coisa, quando eu falo que é preciso evitar mudanças drásticas no escopo eu me refiro a mudanças que desviam o produto da sua visão ou dos objetivos. É óbvio que qualquer mudança é bem vinda, principalmente no agil, mas mudanças drásticas são arriscadas e precisamos tomar muito cuidado com elas.
- Então eu resolvi separar essa palestra em 3 partes. A primeira parte é sobre o Gerenciamento de um produto.
- A dificuldade de gerenciar um produto começa a aparecer quando você ganha tração. Ou seja, quando a quantidade de usuários aumenta muito ou quando você começa a ter uma exposição maior na midia e assim por diante.
- Acontece que com o tempo muitas coisas mudam. A sua visão para o produto fica bem melhor e mais competidores aparecem - mesmo aqueles mais antigos! Eles surfam na sua onda de crescimento também. E quando toda essa demanda aumenta, a sua equipe cresce junto.
- E o que acontece com tudo issso acontecendo ao mesmo tempo?
- Aí é quando tudo fica bastante caótico e os conflitos começam a acontecer. Afinal, existe aquilo que os fundadores ou donos querem criar. Existe aquilo que os competidores já fazem. Aquilo que os usuários querem, o que a midia diz que você vai fazer, o que o board de investidors acho que você deve fazer(dependendo do caso) e, pior ainda, se você for B2B o que os maiores clientes estão querendo pagar.
- Infelizmente é nessa hora que você pode estragar a sua estratégia e até mesmo todo o seu produto. Entao é por isso que eu sempre digo:
- NÃO CRIE UM SOFTWARE FRANKENSTEIN
- PELO MENOS CRIE UM ROBOCOP….pausa…descontração.. que é todo remendado (se vocês lembrarem do filme) mas forte e robusto pra caramba
- Mas como evitar que um produto vire um Frankestein? Bom, pra começar você precisa definir duas coisas: i) Decida uma visão para o seu produto ii) Gerencie ele baseado nessa visão. É a partir dessa visão que você cria uma série de principios que devem ser seguidos durante um bom tempo pra manter a ordem na casa.
- Ué, como assim? Como definir uma visão? Vocês devem estar se perguntando. Por isso eu trouxe aqui alguns exemplos. Vejam a Amazon, o Google e o Twitter. Amazon: “Ser a empresa mais centrada do mundo; construir um lugar onde as pessoas podem encontrar e descobrir qualquer coisa que queiram comprar online.” Google: “Organizar a informação do mundo e torná-la universalmente acessível e útil. " Twitter: Ser o pulso do planeta.” Lembre-se que o seu produto precisa se manter relevante. Vocês notaram que o Twiiter não fala nada sobre apps e tweets, o Google não menciona busca e a Amazon não fala sobre livros. A visão tem que ser robusta e duradoura. Tecnologias, redes sociais e coisas da moda sempre mudam. Então pense muito nisso quando for definir uma visão pra sua empresa ou produto.
- Vocês lembram do filme Alice No Pais das Maravilhas? Tem uma cena muito interessante no qual ela pergunta pro gato qual caminho deve seguir. O Gato pergunta pra onde ela quer ir e ela diz que não sabe. A partir desse momento o gato retruca dizendo que então não importa qual caminho ela seguir, como ela não sabe pra onde vai, qualquer caminho vai servir. Sabe o que é pior? Existem muitos produtos fazendo exatamente isso. E é por isso que estamos vendo cada vez mais produtos de má qualidade na rua.
- Pra vocês entenderem, eis um rápido exemplo do quão importante é a visão. A visão é algo a longo prazo, que, obviamente, não está escrito em pedra e pode mudar. Mas quanto menos você muda, maiores são as chances de você criar um Robocop e não um Frankestein. A partir da visão você cria metas, e então você define estratégias pra atingir essas metas e em seguida você faz seus planos e então cria as atividades do dia a dia.
- Aqui um exemplo prático de como estamos aplicando isso no Grana. Temos uma visão bem clara e abrangente. Por sermos uma startup bem pequena, definimos apenas uma meta para em um curto periodo de tempo - essa parte pode variar muito do tamanho da empresa e da velocidade que as coisas precisam ser entregue. Nossa estratégia para atingir isso é através de aquisição paga de usuários, e o como vamos executar é criando anuncios em redes sociais com diferentes segmentações. Isso aqui é só um exemplo mesmo. Tem várias outras coisas por trás.
- Então, antes de partir pra segunda parte, só recapitulando o que falei até agora para você criar funcionalidades que realmente importam Defina uma visão duradoura A partir dela crie tarefas a longo prazo e vá definindo pouco a pouco o que você precisa até chegar nas tarefas que você vai precisar executar no dia a dia E, claro, não crie um frankestein!! Agora vamos falar sobre o gerenciamento do escopo do produto. E Ah, quando eu digo escopo não estou falando apenas do escopo que você de uma user story ou algo do tipo e sim do escopo INTEIRO do seu produto. Nele hoje, amanhã e daqui a 5-10 anos. Você é o resposnável por tudo que está por vir.
- Muitas empresas, startups ou qualquer outro projeto de TI acha que a solução de todos os problemas está em funcionalidades. Mas, deixa eu contar a triste realidade. Não. Mais funcionalidades não vão aumentar o valor do seu produto!
- Existem alguns erros comuns que já vi acontecer. O primeiro é mais comum em startups. Elas costumam querer se provar com mais funcionalidades - como se isso fosse um diferencial hoje em dia. Você prefere o Excel ou o Google Drive? Eu aposto que o Excel tem mais funcionalidades. A maioria das pessoas hoje está usando o Drive já.
- Sim. Eu sei que isso parece estranho. Mas basta analisar todas as funcionalidades do seu produto, geralmente são duas que são usadas com muita recorrência.
- Muitas vezes a gente se pega pensando “Não. Agora com essa nova funcionalidade os downloads vão aumentar! Agora com essa funcionalidade vamos ter mais 1000 clientes pagantes”. Embora isso possa acontecer as vezes, as chances de você estar enganado são enormes. Não se iluda! Nessa hora é importante lembrar da visão e seguir com ela.
- O QUE FAZER NESSAS HORAS? Fique próximo dos seus clientes e tente identificar a maior dor que eles tem em comum Crie um produto que resolve apenas essas maiores dores. Mas que resolva muito bem
- Por exemplo o Zendesk. Pra quem não conhece é um software de helpdesk. Muita gente aqui deve conhecer e nem imagina que eles foram lançados em 2007 só como sistema de tickets. Depois de 6 anos que eles lançaram o Help Center, que é a extensão do sistema de ticket e foi quando o Zendesk começou a realmente se popularizar. O que o Zendesk fez aqui? Eles só expandiram o produto quando acharam que tinham resolvido o primeiro problema.
- O mesmo aconteceu com o Easy Taxi. Depois de alguns anos surgiu o Easy Taxi empresas, que é uma extensão do aplicativo do usuário comum focado em empresas para que elas possam ter um controle das corridas na nuvem
- Então fica a lição. Só quando seu produto solucionar muito bem um problema você pode pensar em expandi-lo
- Bom, aqui um exemplo mais amplo. Imagine essa tesourinha de cortar unha. É muito fácil de explicaro que ela faz e, por consequencia, é fácil de vender. Quer cortar unha? Compre essa tesourinha! É fácil de manusear porque ela faz uma coisa com excelência. E, por último, é rápido de criar e testar.
- Agora coloque um canivete suiço do lado de uma tesoura. O que o canivete suiço faz bem? Você já cortou a unha com algum? Aposto que não… No mundo real a gente não costuma utilizar ferramentas que fazem de tudo. Se o seu amigo precisa de ajuda para colocar alguns parafusos com certeza não vai ser com um canivete que você vai apertar os parafusos. É muito legal e bonito falar que você tem um (assim como as empresas costumam fazer com o seu produto). Mas no mundo real ele é dificil de explicar pra que serve, a adesão não é tão simples e não faz nada bem.
- Existe um grande pesquisador da teoria dos sistemas chamado John Gall que concluiu que um sistema complexa que funciona bem evoluiu de um sistema simples que funcionava bem. De acordo com a Lei de Gall um sistema complexo não pode ser projetado a partir do zero, caso contrário ele não vai funcionar bem e não vai poder ser consertado. É necessário partir de sistemas simples. Gall disse isso em 1975 e até hoje é válido. Encaixa em todos os conceitos de lean startup, ágil e etc.
- Lembram da tesourinha? O ideal seria evoluir ela para algo assim.
- Ou, se realmente fosse necessário evoluir para algo mais high power o ideal seria fazer uma tesoura semelhante com lasers. O que eu chamo de evolução Robocop (pausa….) O proposito continua o mesmo e nao cheio de coisas a mais
- Recapitulando antes de irmos pra última parte da apresentação. Pra gerenciar bem o escopo de um produto é necessário sempre medir as funcionalidades que estão sendo usadas. Entender que mais funcionalidades não vão necessariamente te dar mais usuários. E que o ideal é primeiro resolver um ou dois problemas antes de evoluir o produto, afinal, você minimiza suas chances de erro começando por sistema simples e não começando por um sistema complexo.
- Então eu sigo a risca algumas perguntas antes de criar uma nova funcionalidade. Isso tem me ajudado muito em todos os projetos que participo e dessa maneira quase nunca fugimos da visão do projeto. Essa funcionalidade está dentro da sua visão? Ela vai te manter no mesmo caminho? Ela vai fazer sentido em 5 anos? Ela não vai se tornar obsoleta em 5 anos? Ela beneficia todos os usuários? Se não todos, pelo menos a maioria. Você precisa evitar fazer funcionalidades que beneficiam poucos clientes. Qual o objetivo? Melhorar alguma coisa que não está bem feita? Aumentar o uso do seu produto? Uma nova feature pra dar suporte a algo totalmente. Foque em quanto as pessoas estão usando E se a funcionalidade for um sucesso e todo mundo tiver usando, você e sua equipe vão conseguir dar suporte?
- Criar um produto é algo muito fácil de se apaixonar. Mas quando as coisas não estão dando certo, é tentador criar mais produto. E aí cria-se o ciclo de ficar lançando coisas que nunca são diferentes na real. Startups, principalmente as focadas em mobile, estão falhando muito por causa disso. Basta olhar as métricas pra entender porque isso não funciona.
- Se você fez um bom trabalho, você vai entregar o MVP do seu produto em algumas semanas. E como ele é bem enxuto você vai perceber que a maioria das pessoas está usando tudo. A maioria das pessoas estão usando a busca ou a maioria das pessoas estão comprando mais comida. Tanto faz o que seja. O que importa é que elas estão relamente fazendo o que você quer que elas façam. Mas o seu produto vai evoluindo e evoluindo. Então em algumas semanas você simplesente faz isso
- Você lança mais funcionalidades achando que todas elas vão continuar sendo usadas bastante. Mas mesmo que você erre, vocês devem estar imaginando que esse é o pior cenário.
- Quando na verdade esse é o pior cenário. Você reduz o uso do seu produto como um todo. Afinal, ele ficou um pouco mais complicado.
- Agora imagine um cenário mais ou menos assim. Isso significa que você tem um produto incrivelmente bom nessas duas áreas. Mas que você adicionou um bocado de porcaria junto. Imagine se chega alguém e fala “Opa. A melhor parte na verdade é só essa. Então vou criar um produto que só é bom nisso e acabar e ganhar o mercado”
- Temos o Facebook como grande exemplo disso. Eles reagiram bem a isso. Lembram quando era tudo junto? O aplicativo de mensagens junto com a rede social? Eles primeiro separaram o aplicativo e em seguida separaram no site também. Agora você pode acessar exclusivamente o Messenger do Facebook. Isso, inclusive, é uma tendência
- Se vocês lembrarem o Foursquare também desmembrou o aplicativo - inclusive foi um dos primeiros. Focando realmente nas funcionalidades que importavame e criando um maior engajamento com os usuários. Foursquare só pra review de locais e swarm pra gamificação através de checkins.
- O Google também seguiu a mesma linha com Hangouts. Ele surgiu dentro do Google+ e rapidamente o Google viu que o Hangout gerava muito mais engajamento que o Google+ e desmembrou eles.
- Não precisa ser um curto e grosso não. Você não sabe a necessidade do futuro!
- Manifesto agil fala da entrega. Mais importante ainda é o uso. Isso inclusive é algo que o manifesto agil deveria evoluir nessa linha.
- Recapitulando antes de irmos pra última parte da apresentação. Pra gerenciar bem o escopo de um produto é necessário sempre medir as funcionalidades que estão sendo usadas. Entender que mais funcionalidades não vão necessariamente te dar mais usuários. E que o ideal é primeiro resolver um ou dois problemas antes de evoluir o produto, afinal, você minimiza suas chances de erro começando por sistema simples e não começando por um sistema complexo.