como criar produtos vencedores
Post on 30-Oct-2014
19 Views
Preview:
DESCRIPTION
TRANSCRIPT
Como criar produtos vencedoresSetembro 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
1. 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 26Modelos comuns de gerência de produtos
1. 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 26Construindo 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 2610 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 26Aspectos 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 26Planejamento 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 26Visã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 26Roadmap 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 26Customer 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 26Princí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 26Reinventando 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 26Especificaçõ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 26Vantagem 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 26Especificações baseadas em protótipos
• O protótipo de alta fidelidade é acompanhado por uma
documentação (mini-spec) que geralmente é colocada numa Wiki.
Functionality - Feature set, Capabilities, Generality, SecurityUsability - Human factors, Aesthetics, Consistency, DocumentationReliability - Frequency/severity of failure, Recoverability, Predictability, Accuracy, Mean
time to failurePerformance - Speed, Efficiency, Resource consumption, Throughput, Response timeSupportability - 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 26Desenvolvimento 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 26Design 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 26Teste 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 26Desenvolvimento 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.
top related