Last week Google’s announcement about the end of Google Wave made me review and rethink about some product manangement lessons.
Google Wave
Marty Cagan, former eBay Product Management VP and currently product management consultant, uses to say that all product management processes must start with a “product discovery” phase where we need to find out:
For Steve Blank, a retired serial entrepeneuer who started 8 technology companies, knowing the customer is so important that is not enough for the companies to have a product development process. They must have a “customer development” process prior to the product development, where customer demands and problems are the main focus.
More startups fail from lack of customers than from fail of product development.
Steve Blank
In a 2005 post at her “Creating Passionate Users” blog, Kathy Sierra shows happiness as a function of the number of product features. The chart is quite self explanatory:
Featuritis
As it is Google Wave screen. There are so many things one can do with Google Wave…
Every product must be:
We must always remember:
Tricycle
Source: http://flickr.com/photos/jevolella/437838621/
If ease of use were the only requirement, we would all be riding tricycles.
Douglas Engelbart, mouse inventor
O anunciado fim do Google Wave na última semana é uma verdadeira aula de gestão de produtos e eu não pude deixar a oportunidade passar. Por isso vou dar uma pausa no tema gestão de projetos para falar sobre algumas lições de gestão de produtos que o fim do Google Wave nos faz relembrar.
Marty Cagan, ex-VP de Produtos do eBay que atualmente faz consultoria de gestão de produtos, costuma dizer que todo processo de desenvolvimento de produtos deve começar com uma fase de “descobrimento de produtos” onde se deve descobrir:
Já para Steve Blank, um empreendedor em série que já fundou 8 empresas de tecnologia, a importância de se conhecer o cliente é tão grande que não basta as empresas terem um processo de desenvolvimento de produtos, elas devem ter um processo anterior chamado de “desenvolvimento de clientes”, onde se busca entender o cliente e suas necessidades para só depois pensar em desenvolver uma solução para essas necessidades.
Mais startups fracassam por falta de clientes do que por não saber como desenvolver um produto.
Steve Blank, fundador de 8 empresas de tecnologia
Em um artigo de 2005 em seu blog “Creating Passionate Users”, Kathy Sierra mostra a felicidade do usuário como função do número de features de um produto. O gráfico é auto-explicativo:
Assim como o é a tela do Google Wave. São tantas coisas que se pode fazer com o Google Wave…
Todo produto precisa ser:
Lembrando que:
Triciclo
Fonte: http://flickr.com/photos/jevolella/437838621/
Se facilidade de uso fosse o único requisito, estaríamos todos usando triciclos.
Douglas Engelbart, inventor do mouse
Essa semana tive a oportunidade de conversar com Gil Barros, um profissional muito experiente de design de interação e de arquitetura da informação, que está fazendo doutorado na FAU-USP sobre prototipação e o uso de croquis.
…croquis (palavra francesa eventualmente aportuguesada como croqui ou traduzida como esboço ou rascunho) costuma se caracterizar como um desenho rápido, feito com o objetivo de discutir ou expressar graficamente uma idéia… O que costuma ser mais importante no croquis é o registro gráfico de uma idéia instantânea, através de uma técnica de desenho rápida e descompromissada.
…croquis (palavra francesa eventualmente aportuguesada como croqui ou traduzida como esboço ou rascunho) costuma se caracterizar como um desenho rápido, feito com o objetivo de discutir ou expressar graficamente uma idéia…
O que costuma ser mais importante no croquis é o registro gráfico de uma idéia instantânea, através de uma técnica de desenho rápida e descompromissada.
fonte: http://pt.wikipedia.org/wiki/Croquis
Ele comentou que vê pouca gente se valendo do desenho feito à mão para mostrar ideias e que, por achar essa opção como uma das formas mais ágeis de comunicacão, resolveu dedicar seu doutorado a esse tema.
Eu já havia comentado sobre a importância dos rascunhos, ou protótipos feitos à mão, no post “Protótipo: primeira impressão” e no post “Mais um exemplo de protótipo de baixa fidelidade“.
O que me atrai nos protótipos de baixa fidelidade e em croquis de forma geral é sua simplicidade inerente. Quem me conhece sabe que sou fã da simplicidade, tanto que já escrevi sobre o tema no post “Simplicidade” e em um outro post onde comento sobre um site de 1 única página.
Semana passada, quando escrevi sobre as vantagens do uso dos gráficos de burnup como opção aos Gantt Charts para acompanhamento do andamento de projetos, acabei não comentando de uma das vantagens mais óbvias do burnup: o burnup é mais simples que o Gantt Chart pelo simples fato de que burnups podem ser feitos à mão. Já o Gantt Chart é muito difícil de ser feito à mão.
A prova disso é a busca de imagens do Google. Experimente pesquisar por Gantt Chart e por burnup chart.
Logo na primeira página da pesquisa por imagens de burnup chart são 4 gráficos feitos à mão. Já na pesquisa por Gantt Chart, não encontrei nenhum…
Burnup feito à mão
Outro exemplo de burnup feito à mão
Burn down feito à mão que aparece na busca por imagens de burnup
Mais um exemplo de burnup feito à mão
O processo de desenvolvimento de um novo produto em uma empresa já estabelecida tem semelhanças e diferenças com o processo de criação de uma nova empresa, ou uma startup como são chamadas as novas empresas nos EUA.
As principais diferenças são:
Já a semelhança está no processo em si:
Desenvolvimento de produtos
Acabo de encontrar uma apresentação de Steve Blank, um empreendedor em série do Silicon Valley que fundou 8 empresas de tecnologia em 21 anos e hoje é consultor, professor e escritor sobre empreendedorismo.
Nessa apresentação ele começa apresentando um estatística que, na minha opinião, é mais forte semelhança entre o processo de desenvolvimento de um novo produto em uma empresa já estabelecida e o processo de criação de uma startup:
Mais startups falham por falta de clientes do que por falha no desenvolvimento do produto.
No seu blog ele comenta que 9 de cada 10 startups falham o que me parece ser uma estatística válida também para novos produtos desenvolvidos em empresas já estabelecidas.
E por que isso acontece? Porque o foco do processo de desenvolvimento de produtos tradicional está voltado o lançamento do produto, deixando de lado o que Steve chama de Processo de Desenvolvimento de Cliente, ou seja, descobrir se esse produto que está sendo desenvolvido atende uma necessidade real do cliente. É o que Marty Cagan, ex-VP de Produtos do eBay e atualmente consultor de gestão de produtos, chama de Product Discovery.
Na apresentação abaixo, Steve Blank mostra como é o Processo de Desenvolvimento de Cliente e como ele se encaixa no desenvolvimento ágil de software.
Vale a pena ver também uma série de 9 vídeos de uma aula do Steve em Stanford. O 7º vídeo da série ilustra bem o Processo de Desenvolvimento de Cliente:
Por isso, se você não quer que seu produto falhe, quer você seja parte de uma startup ou de uma empresa já estabelecida, vá pra rua e teste suas idéias com clientes reais. Só assim seu produto poderá deixar de ser parte dessa triste estatística.
Actually, it’s quite simple, as Donna Spencer points out:
Just make it up.
Wait? Is it that simple? But in order to make it up you just ned one thing: information.
You need to understand what you are trying to achieve, what users of the service need and know, and you need to know the content well. If you don’t have these things, it will be hard. But if you do have them, pulling them together into a first draft is surprisingly easy.
Which one is the right product to invest?
Ice Cream Glove:
Snuggie:
Answer: there’s no way to know if you base your answer on opinions. The only way to be sure which one is the right investment is:
getting “out of the building” and testing ideas against reality, to find out what creates value for customers before spending all of our resources building it.
For those curious to know which of these products is a good product development investment and want to read more about how important it is to do customer research:
http://radar.oreilly.com/2009/09/is-your-product-an-ice-cream-g.html
Uma tendência interessante é a de interfaces de usuário sensíveis a contexto. Além dos exemplos citados nesse link, outros bons exemplos são o Basecamp:
Ao passar o mouse sobre o primeiro item aparecem as ações que podem ser feitas nesse item:
Isso deixa a interface mais leve e, ao mesmo tempo, permite invocar as ações quando necessário.
A versão 2.7 do WordPress implementou esse conceito. Vejam a lista de posts:
E, ao passar o mouse sobre um título de post:
A palavra protótipo vem do grego protos (primeiro) + typos (impressão) e é importante que usemos os protótipos de UX como primeira impressão de nossos produtos e sistemas, como sugere a origem da palavra.
If I can’t picture it, I can’t understand it
Albert Einstein
Na maioria das vezes que pensamos em protótipos de sistemas web, pensamos em protótipos que tenham alguma fidelidade ao produto final e que, se possível, sejam interativos para que possam ser usados em testes de usabilidade.
Existem várias ferramentas para se fazer protótipos. Algumas das mais conhecidas são:
Mas antes de se fazer um protótipo interativo fiel ao produto final, podemos fazer um rascunho de protótipo, algo sirva como ferramenta para discussão sobre o sistema. E para fazer esse tipo de protótipo não há ferramenta melhor do que lápis e papel! É barato, rápido e muito fácil de usar!!!
Termino esse post com alguns exemplos de protótipos rascunhados no papel, para dar idéia de quão poderosa é essa ferramenta.
Recentemente li dois posts sobre como “encaixar” UX em times que estão usando metodologias ágeis. Um deles é o “Agile UX: Como trabalhar com os designers” do Guilherme Chapiewski que trabalha na Globo.com. O outro é o “Agile UX: como integrar UX e desenvolvimento” do Antonio Carlos Silveira do Yahoo! Brasil.
Como o próprio Antonio apontou bem, essa preocupação sobre como integrar UX em um time de desenvolvimento de software que segue alguma metodologia ágil existe desde o início das metodologias ágeis. Alguns posts sobre o tema:
Aliás a busca por Agile UX no Google retorna muitas e muitas páginas dedicadas ao tema.
Um exemplo interessante é a apresentação abaixo, da Leisa Reichert que ela apresentou na Web 2.0 Expo Berlin:
Sem dúvida há várias maneiras de se integrar UX e metodologias ágeis e o correto é escolher a maneira que se adapta melhor à sua situação e disponibilidade de recursos (tempo, dinheiro e pessoas).
Contudo, queria adicionar meus 2 centavos a essa conversa. Apesar de ser importante termos especialistas em UX, pessoas que conheçam a fundo sobre arquitetura da informação, design de interação, design visual e todos os temas relacionados à experiência do usuário, acredito que UX deve ser uma preocupação de todas as pessoas do time. Não há razão alguma para o PO e os membros do time não se preocuparem com o tema e deixarem tudo nas mãos de um especialista. E se esse especialista um dia não estiver disponível? Se ele estiver ocupado cuidando de outras coisas? Ou mesmo se não tivermos um especialista em UX no time?
Não estou querendo dizer que UX não é um tema complexo, que requer muito estudo e prática, mas acredito que todos nós devemos conhecer os conceitos básicos de UX.
Vou citar duas situações exemplo que ilustram bem a importância de todo o time se preocupar com UX:
Ou seja, não é necessário ser um especialista em UX para ajudar no desenvolvimento e melhoria de UX dos sistemas que seu time cuida. Leia, estude, informe-se, afinal conhecimento nunca é em excesso!
Acabo de publicar mais um post sobre padrões de uso no UXBlog da Locaweb:
[Padrão de Uso] Navegação em grandes conjuntos de dados
Sobre a crise, acabo de assistir o vídeo abaixo, dica do Jason da 37signals:
