Como Criar Produtos Vencedores

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)

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. 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.

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.

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.

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.

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.

http://www.sambatech.com	278
http://www.sambatech.com.br	140
http://www.bernardoporto.com	123
http://www.slideshare.net	17
http://www.google.com.br	1

Como Criar Produtos Vencedores

by Gustavo Caetano on Sep 26, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

5 Embeds 559

Statistics

Como Criar Produtos Vencedores — Presentation Transcript