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.