Como Criar Produtos Vencedores
Upcoming SlideShare
Loading in...5
×
 

Como Criar Produtos Vencedores

on

  • 9,868 views

Workshop sobre como criar produtos vencedores por Gustavo Caetano

Workshop sobre como criar produtos vencedores por Gustavo Caetano

Statistics

Views

Total Views
9,868
Views on SlideShare
8,428
Embed Views
1,440

Actions

Likes
5
Downloads
124
Comments
1

8 Embeds 1,440

http://www.sambatech.com 1151
http://www.sambatech.com.br 140
http://www.bernardoporto.com 123
http://www.slideshare.net 17
http://www.linkedin.com 4
http://sambatech.com 3
http://www.google.com.br 1
http://webcache.googleusercontent.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Como Criar Produtos Vencedores Como Criar Produtos Vencedores Presentation Transcript

    • Como criar produtos vencedores Setembro 2009.
      • Principais erros na gestão de produtos
      • Definição de Cargos e responsabilidades
      • Planejamento de produtos
      • Reinventando a especificação de produtos
      • Processo de desenvolvimento de produtos
      • Teste de protótipo
      • Conclusões finais
      2 26 Agenda
    • 3 26 Principais erros na gestão de produtos
      • Confundir requisições dos consumidores com requisições de produto
        • Não misturar requisições do cliente com roadmap do produto;
        • Não perguntar aos clientes o que eles querem (caso da Apple e da Ford) e o que o sistema consegue fazer
        • Criar features que agreguem valor ao produto (reduzindo tempo, custo ou melhorando algum processo ruim)
    • 3 26 Principais erros na gestão de produtos
      • 2. Confundir inovação com valor
        • Tecnologia permite fazer várias coisas. Mas o que o público-alvo realmente quer?
        • Os clientes normais compram pelo valor que a tecnologia proporciona. Os early adoptors compram pela inovação;
        • Google e Apple são bons neste tipo de abordagem;
        • Criar features que agreguem valor ao produto (reduzindo tempo, custo ou melhorando algum processo ruim)
    • 3 26 Principais erros na gestão de produtos
      • 3. Confundir você com o cliente
        • Geralmente as pessoas acham que o cliente gosta daquilo que elas gostam;
        • É importante tentar pensar como o cliente, buscar seus problemas, suas dificuldades;
        • Ninguém pensa como o cliente. Existem milhares de variáveis que envolve a mente dele.
    • 3 26 Principais erros na gestão de produtos
      • 4. Confundindo adicionar features com melhorar o produto
        • Gerentes de produtos acham que os melhores produtos são aqueles com mais festures;
        • Mais features representa: mais dificuldade de aprendizado, mais lentidão e maior possibilidade de surgimento de bugs.
        • O foco deve ser em fazer um produto que resolva problemas reais das pessoas. Sem inventar problemas que possivelmente não existem.
    • 3 26 Principais erros na gestão de produtos
      • 5. Confundindo “inspiring features” com “nice-to-have features”
        • As “inspiring features” são aquelas que fazem o produto se espalhar sozinho. Geram marketing boca-a-boca;
        • As vezes o produto pode nascer sem algumas features “nice to have”, mas com uma ótima “inspiring feature”. Caso do Iphone com MMS/Filmadora/Cut’n’Paste.
        • Faça o mínimo de produto. E algumas “cool features” e você terá mais chance de ter atenção dos usuários e da mídia.
    • 3 26 Principais erros na gestão de produtos
      • 6. Confundindo especificações maravilhosas com produtos maravilhosos
        • Especificações são apenas pedaços de papel que aceitam qualquer coisa;
        • O tempo que se passa planejando não é diretamente proporcional com a probabilidade de sucesso do projeto.
        • Relatórios de 40 páginas de P&D não criam produtos vencedores;
        • Coloque o produto no ar para teste o quanto antes. Quanto mais cedo você falhar melhor.
    • 3 26 Principais erros na gestão de produtos
      • 7. Modelo Feed the Beast
        • Não coloque features na sua aplicação só para dar trabalho pra TI;
        • Aloque os melhores engenheiros no que realmente importa.
    • 4 26 Modelos comuns de gerência de produtos
      • Marketing-driven Product
        • Gerente de produtos reune informações sobre o produto e passa diretamente pra área de TI.
      • 2. Duas pessoas, uma função
        • Product Marketing/ Manager: Requerimentos de nível mais alto;
        • Product Owner (SCRUM): Detalhamento do produto no backlog do Scrum.
      • 3. Uma pessoa, duas funções
        • Product Marketing = Product Manager ou
        • Product Manager = Project Manager
    • 4 26 Novas definições para o gerente de produtos
        • A função do gerente de produtos é criar produtos que tenham valor, uso e viabilidade (técnica e financeira);
        • A criação do produto contará principalmente com:
          • Product Manager (Valor) que vai interagir com: Marketing, Finanças, Jurídico, Vendas e Relacionamento com Consumidor;
          • Lead Designer (Uso) que vai interagir com Interaction Designer e Visual Designer.;
          • Lead Engineer (Viabilidade): Engenharia, QA e Arquitetos.
    • 4 26 Novas definições para o gerente de produtos
        • Perfil de um bom gerente de produtos exige:
          • Conhecimento do usuário final;
          • Conhecimento do mercado;
          • Conhecimento de tecnologia.
    • 4 26 Construindo um produto de ponta
      • Um ótimo produto combina algo que resolve problemas reais e que ao mesmo tempo resolva algum problema que só com ele é possível.
      • Primeiro foque no valor, depois foque na monetização;
      • Um produto de ponta é amado e apreciado por consumidores felizes e leais (Net Promoter Score)
      • Quando o PM tiver que escolher entre uma aplicação fácil de se desenvolver ou uma que resulte numa experiência melhor para o usuário final, deverá ficar com o usuário.
          • “ Great products are based on a great user experience”
    • 4 26 10 fatores-chave de um site de sucesso
          • Usabilidade
          • Personas
          • Escalabilidade
          • Disponibilidade
          • Atendimento ao consumidor
          • Privacidade e Proteção dos dados
          • Marketing viral
          • Lançamento/atualizações pequenas (ebay)
          • Comunidade de consumidores
          • Globalização
    • 4 26 Aspectos relevantes de uma plataforma
      • Os desenvolvedores trabalham para os provedores de aplicação e escrevem seus softwares usando a plataforma;
      • Os provedores de aplicação , por sua vez, são as empresas que escolhem sua plataforma para desenvolverem seus sistemas;
      • Os usuários finais são aqueles que rodam a solução dos provedores de aplicação e, consequentemente, a plataforma.
    • 4 26 Planejamento do produto 1. Qual é exatamente o problema que a plataforma resolve? (proposição de valor) 2. Pra quem resolvemos o problema? (mercado alvo) 3. O quão grande é essa oportunidade? (pequena – média – grande) 4. Como vamos mensurar o sucesso do projeto? (n de usuários? Receita?) 5. Quais alternativas para nosso produto existem hoje no mercado? (diferencial competitivo) 6. Porque somos os melhores para perseguir esta oportunidade? Porque agora? 7. Como lançaremos o produto no mercado? (go to market strategy) 8. Quais são os fatores críticos de sucesso? (riscos e requisitos de produto) 9. Após responder as questões acima, qual a recomendação? (go or no go)
    • 4 26 Visão do produto
      • Mostrar claramente onde o produto quer chegar, o que ele quer ser em alguns anos. O roadmap sempre mudará com frequencia, mas a visão tem que se manter a mesma.
      • Deve-se criar telas ou vídeos com uma idéia fictícia de como será o produto no futuro. (estilo microsoft) – chama-se VisionType e é basicamente um protótipo conceito da sua solução. Mostrando hoje como ela estaria em 2 anos.
      • A visão do produto deve estar bem alinhada com a estratégia da empresa.
    • 4 26 Roadmap do produto
      • O roadmap mostra de maneira simples e clara como você pretende chegar na visão à partir do que você já tem hoje.
      • Geralmente o roadmap é feito em bullets simples e publicado numa wiki. (mostrar exemplo)
      • Um bom roadmap é um repositório de todas as key features do sistema e as releases que vão entregá-las;
      • Os principais modos de montagem de roadmap são:
      • Temas: cada release tem um tema e as features relativas aquele tema entram no sprint;
      • Features: o release é montado inteiramente por funcionalidades específicas;
      • Trains: a release é movida por uma data final. Quando chegar a data de lançamento, as features que estiverem prontas entram. As outras, ficam pra o próximo release.
    • 4 26 Customer Adivisor Program
      • Usar clientes/parceiros para testarem seu produto antes dele ir ao mercado.
      • Identifica-se 6-8 clientes ( 10 – 15 usuários)
      • Positivo para o cliente pois ele usa a tecnologia de graça no período de beta e tem acesso à uma nova tecnologia antes de outras empresas. Além disso, a empresa pode promover estes primeiros clientes com um showcase de uso da ferramenta, marketing e divulgação na mídia.
      • Positivo para a Samba porque usa o cliente para dar imputs sobre o produto.
      • Os clientes devem estar disponíveis para conversar por telefone ou responder perguntas por email sobre a ferramenta; Além de permitir que nosso gerente de produto veja o cliente usando a tecnologia.
    • 4 26 Princípios do Produto
      • São definições sobre o que o time de produto acha importante:
      • Exemplo de Princípios do Produto (Ebay):
        • 1. Easy 2. Safe 3. Fun
      • Exemplo de Princípios do Produto (Tivo)
        • It’s entertainment, stupid
        • It’s TV, stupid
        • It’s Video, damnit
        • Respect the viewer’s privacy
    • 4 26 Reinventando as especificações de produtos
      • Paper Based Specs:
        • Leva muito tempo para ser escrito;
        • Dá um falso senso de segurança;
        • São supreficiais, pois não dão o tipo de informação que os engenheiros precisam;
        • Não há como testar uma especificação;
        • Eles são imediatamente obsoletos;
        • E qual a alternativa?
    • 4 26 Especificações baseadas em protótipos
      • Requerimentos dos produtos (função) e design de experiência devem ser feitos em paralelo. Sempre antes da implementação pelos engenheiros;
      • Idéias de produtos devem ser testadas o quanto antes e com frequência junto ao mercado alvo. Deve sair das muralhas das corporações antes que seja tarde demais;
      • É preciso ver se o produto tem valor, uso e aplicabilidade. (ex. Yahoo!);
      • Para isso é preciso um protótipo de alta fidelidade para testar as idéias de design do produto com uma experência próxima da real;
      • O protótipo de alta fidelidade é a melhor maneira de comunicar os requisitos do produto para os engenheiros, marketing e QA.
    • 4 26 Vantagem dos protótipos de alta fidelidade
      • Permite testes rápidos de produtos em clientes;
      • Força o PM a pensar no produto de maneira mais detalhada e profunda;
      • É o mecanismo de colaboração entre o PM, os designers e os engenheiros;
      • Permite uma estimativa de tempo e custo de produção do projeto mais acurada;
      • Provê para os engenheiros e QA uma definição rica do produto para se trabalhar;
      • Permite que o resto da corporação/stakeholders entendam o produto com mais facilidade;
      • Permite que o projeto falhe rápido;
      • Reduz a perda de clientes futuros;
      • Mantem o time focado na experiência do usuário.
    • 4 26 Especificações baseadas em protótipos
      • O protótipo de alta fidelidade é acompanhado por uma documentação (mini-spec) que geralmente é colocada numa Wiki.
      • F unctionality - Feature set, Capabilities, Generality, Security
      • U sability - Human factors, Aesthetics, Consistency, Documentation
      • R eliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean time to failure
      • P erformance - Speed, Efficiency, Resource consumption, Throughput, Response time
      • S upportability - Testability, Extensibility, Adaptability, Maintainability, Compatibility, Configurability, Serviceability, Installability, Localizability, Portability
      • “ Nobody loves a wireframe. Wireframes and mocks aren’t enough on their own. Functional specs are boring. We’ve found prototypes to be an incredible tool for bringing a design spec or concept to life.”
      • - Michael Leggett, Google
    • 4 26 Desenvolvimento do produto
      • Crie uma persona para seu produto. Personas são a descrição completa de seus usuários.
      • A idéia é ter um personagem para se basear na hora de desenvolver o produto;
      • Cada release da plataforma pode estar focado em personas diferentes. Ex. No Release 1 a persona é um jovem de 26 anos, formado em ciências da computação, que navega na internet e gosta de comprar coisas com cartão de crédito. Ele experimenta novas tecnologias que encontra em suas buscas na Internet. Sabe programar em PHP, Java, Ruby e C++.
      • No segundo release essa persona deve mudar, assim, devemos construir uma ferramenta que sirva para esta nova persona. Neste momento devemos inserir um workflow visual e widgets na plataforma.
      • Usuários experientes nunca devem ser o foco de um produto.
      • O design da interface deve ser em volta nesta persona.
    • 4 26 Design do produto
      • Crie um design que ajude os novatos a entenderem e usarem a plataforma;
      • Seja fanático por usabilidade e estética. O site mint.com só conseguiu convencer seus usuários a inserirem seus dados bancários no portal porque tinham um design que passava segurança e confiabilidade.
      • Divulgue os princípios de design para a empresa. Ex. Ebay:
        • Know your user / Keep the main thing the main thing;
        • Keep it simple / Don’t make the user work;
        • Be consistent / Provide a well lit path;
        • Optimize for the 80% / Make it personal;
        • Help should be helpful. But not necessary.
    • 4 26 Teste do produto
      • Não existe nada que substitua o teste de seu produto ou idéia direto nos usuários finais.
      • Teste por protótipo:
        • Encontrar usuários/agendar os testes
        • Preparar perguntas de navegação/usabilidade/valor;
        • Mensurar os resultados;
        • Melhorar o protótipo.
        • Duas regras de testes: Multiple Rounds (testes maiores em períodos maiores) ou Continuous Testing (testes em um espaço curto de tempo);
    • 4 26 Desenvolvimento do produto (resumo)
      • Monte o time do produto (PM, UX, ENG);
      • Utilize técnicas para aprimoramento do produto (visiontypes, personas, principles, customer development, testing);
      • Faça protótipos rápidos e frequentes dos produtos;
      • Visite os clientes e teste os protótipos;
      • Demonstre e discuta os protótipos com os stakeholders;
      • Uma vez na mão dos engenheiros, não faça mudança brusca no rumo do produto.
    •