»
S
I
D
E
B
A
R
«
Prototype: first impression
ago 29th, 2010 by Joca

The word prototype is formed by two greek words, protos (first) + typos (impression). We know how important it is to use prototypes as a first impression of our products and systems, as suggested by the origin of the word.


If I can’t picture it, I can’t understand it

Albert Einstein

When we think about web systems prototypes, we normally imagine high fidelity prototypes or at least computer made prototypes which are interactive so they can be used in usability tests.

There are many tools to build prototypes:

However, before making a high fidelity interactive computer based prototype, we can draft this prototype. This draft will serve as a tool for very useful discussions about the product and its features. And to build this type of prototype there’s no better tools than pencil and paper. It’s cheap, fast and very easy to use!

I’ll finish this post with some examples of prototypes draw on paper, and they’ll give you an idea on how powerful they are.


Twitter Weekly Updates for 2010-08-28
ago 28th, 2010 by Joca

Powered by Twitter Tools.

Como saber o que o cliente quer?
ago 23rd, 2010 by Joca

No meu último post em que falei sobre as lições de gestão de produtos do fim do Google Wave comentei algumas vezes sobre a importância de conhecermos o cliente, de sabermos se nossa idéia de produto resolve um problema desse cliente e se o cliente está disposto a nos pagar por essa solução.

Mas como saber o que o cliente quer? Como saber se nossa idéia de produto resolve um problema? Como saber se ele está disposto a pagar por essa solução?

Bom, sendo bem direto: pare de perguntar!

Stop asking questions

Stop asking questions


Perguntar diretamente para o cliente o que ele quer pode não trazer bons resultados. Existe aquela frase famosa atribuída ao Henry Ford que se ele fosse perguntar o que os clientes querem, os clientes iam responder “um cavalo mais rápido”…

Existe também a primeira lei da usabilidade do Jakob Nielsen:

Não ouça os usuários.


What he says and what he really means

What he says and what he really means

What she says and what she really means

What she says and what she really means

Exageros à parte, o que frases como pare de perguntar e não ouça os usuário querem dizer é que mais importante do que ouvir o que o usuário ou cliente ou futuro cliente diz que quer é entender o que ele realmente precisa.

Os testes de usabilidade fazem uso desse conceito. Num teste de usabilidade é pedido que um usuário execute uma determinada tarefa com o produto e observa-se se o usuário consegue fazer essa tarefa e quais as dificuldades ele encontrou durante a execução. Se perguntássemos ao usuário se é fácil usar o produto para fazer a tarefa, as chances de a resposta não corresponder à realidade são grandes.

Outro exemplo interessante é assistir a um usuário 3 minutos antes e 3 minutos depois de ele fazer uso de nosso produto. É provável que ele tenha feito algo para se preparar para usar nosso produto ou algo logo após seu uso que indiquem alguma possibilidade de novo produto ou de nova funcionalidade. Se perguntássemos diretamente ao usuário o que ele faz antes e depois de usar o produto talvez não obtivéssemos uma resposta precisa pois as tarefas podem estar tão inseridas no cotidiano do usuário que nem seriam percebidas como oportunidades de melhoria.

Mas e se ainda não tivermos um produto? Simples, basta usarmos um protótipo! :-)

Resumindo

  • Só perguntar e ouvir o cliente não é o suficiente para para saber o que ele quer.
  • Temos que sair do escritório e ir até o cliente, conversar com ele, assistir ele usando o produto em seu “habitat natural”.
  • Se ainda não tivermos um produto para mostrar, devemos mostrar um protótipo.
Twitter Weekly Updates for 2010-08-21
ago 21st, 2010 by Joca

Powered by Twitter Tools.

Twitter Weekly Updates for 2010-08-14
ago 14th, 2010 by Joca

Powered by Twitter Tools.

Google Wave sunset provides some interesting product management lessons
ago 9th, 2010 by Joca

Last week Google’s announcement about the end of Google Wave made me review and rethink about some product manangement lessons.


Google Wave

Google Wave


Product discovery

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:

  • if there are customers interested in our product idea,
  • what’s the customer problem that our product idea intend to solve, and
  • if our product idea is the best solution for the customer problem.

Customer development

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

Featuritis

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

Featuritis


As it is Google Wave screen. There are so many things one can do with Google Wave…

Google Wave

Google Wave


Useful, usable and desirable

Every product must be:

  • useful: how much do people need this product? It does what needs to be done.
  • usable: how easy is the product? Easy to understand. Easy to master.
  • desirable: how much do people want this product? They and their friends want the product. The product is worth the time and money investment.

We must always remember:

Tricycle

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

Summary

  • Creating a product just because a new technology is available is shooting in the dark.
  • If a product doesn’t solve a real customer problem the chances of success of this product are nil.
Google Wave é uma aula de gestão de produtos
ago 8th, 2010 by Joca

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.


Google Wave

Google Wave


Descobrindo produtos

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:

  • se existem clientes interessados em sua idéia de produto
  • qual é o problema do cliente que sua idéia de produto se propõe a resolver e
  • se sua idéia de produto é a melhor solução para o problema do cliente.

Desenvolvimento de clientes

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

Featuritis

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:

Featuritis

Featuritis


Assim como o é a tela do Google Wave. São tantas coisas que se pode fazer com o Google Wave…

Google Wave

Google Wave


Útil, usável e desejável

Todo produto precisa ser:

  • útil: quanto as pessoas precisam desse produto? Ele faz o que precisa ser feito.
  • usável: quão simples é o produto? Simples de entender, simples de mexer ao ponto de facilmente o usuário se tornar um expert no produto.
  • desejável: quanto as pessoas querem o produto? Elas querem esse produto. Seus amigos também querem esse produto. Ele vale o tempo investido.

Lembrando que:

Triciclo

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

Resumindo

  • Criar produtos somente porque uma uma nova tecnologia está disponível é um tiro no escuro.
  • Se o produto não resolve um problema real de seus possíveis clientes, as chances desse produto ser um sucesso são nulas.
Twitter Weekly Updates for 2010-08-07
ago 7th, 2010 by Joca

Powered by Twitter Tools.

Qual a diferença entre gerir um projeto e gerir um produto?
ago 2nd, 2010 by Joca

Nos meus posts recentes sobre acompanhamento de projetos ágeis e o uso de burnups acabei me deparando com algumas questões mais “filosóficas” sobre produtos, projetos, gestão de produtos e de projetos e os papéis de PO (product owner) e scrum master nas metodologias ágeis.

Projetos e produtos

Projetos e produtos

Definições

Primeiro algumas definições básicas:

A project in business and science is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim.

Fonte: http://en.wikipedia.org/wiki/Project

The noun product is defined as a “thing produced by labor or effort” or the “result of an act or a process”, and stems from the verb produce, from the Latin prōdūce(re) ‘(to) lead or bring forth’.

Fonte: http://en.wikipedia.org/wiki/Product_(business)

Ou seja, enquanto o projeto é um processo com começo, meio e fim, o produto é o resultado de um processo, de um esforço.

Então gerir projetos e gerir produtos são duas funções distintas?

Parece que sim. Enquanto se está gerindo um projeto, a preocupação é com o processo e com tudo o que o cerca, ou seja, se está no prazo, se tem os recursos necessários e se está sendo feito conforme esperado (qualidade e escopo).

Por outro lado, quando se gere um produto, a maior preocupação é, ou pelo menos deveria ser, garantir que produto resolve um problema do cliente a quem esse produto é destinado.

Em um post de 2007 do blog How To Be A Good Product Manager, o autor Jeff Lash lembra alguns pontos importantes que não devemos esquecer quando pensamos em gestão de projetos e gestão de produtos:

  • Just like every product needs a product manager, every project needs a project manager.
  • Just because product managers think they can manage their own projects does not mean they should.
  • The skills, talents, and traits involved in project management are very different from those involved in product management.
  • Just like it is hard to find one single person who can fill the product management role and the product marketing role, it is hard to find one person who can be successful at both the product management and the project management role.
  • Project management is not a stepping stone to product management, nor vice versa.
  • Good project managers are just as valuable as good product managers.
  • Finding a good project manager to manage your projects will help you be an even better product manager.
  • The less time product managers spend on project management, the more time they will be able to spend on product management.
  • To avoid conflicts between product management and project management, product managers, project managers, and project teams should all agree on shared goals and objectives as much as possible.

Marty Cagan deixa claro a necessidade de separação desses papéis em um de seus posts:

For Internet services companies, it really is important that the roles be separate. You’ll thrash in release management if you don’t, and releases will consistently be delayed and take longer than they should.

E como as metodologias ágeis vêem essas funções?

As metodologias ágeis, mais especifcamente o Scrum, tem dois papéis claros no time, um focado mais no projeto, o Scrum Master e outro focado mais no produto, o Product Owner (PO):

[Scrum] Roles:

Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders.
ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits.
Team: A cross-functional group of people responsible for managing itself to develop the product.
Scrum Team: Product Owner, ScrumMaster and Team

Fonte: http://en.wikipedia.org/wiki/Scrum_(development)

Há um artigo na InfoQ com o título “Can Product Owner and Scrum Master be Combined?” em que o tema de ter um única pessoa gerindo projeto e produto é discutido. Tanto nas opiniões que compõem o texto e que incluem testemunhos de pessoas como Mike Cohn e Ken Schwaber, quanto nos comentários do texto é unânime que apesar de ser possível combinar as duas funções e, se o time for muito pequeno, ser até aceitável, o mais recomendado é que essas funções sejam desempenhadas por pessoas diferentes.

Resumindo

  • Gerir um projeto é garantir que o processo está fluindo da melhor forma possível, dentro do prazo, com os recursos disponíveis e atingindo os objetivos de escopo e qualidade definidos. Ou seja, gerir projetos é olhar para dentro da organização.
  • Gerir um produto é garantir que o resultado de um processo satisfaça as necessidades do cliente. Ou seja, gerir produtos é olhar para fora da organização.
  • É possível e, se o time for muito pequeno (até 5 pessoas), pode ser até aceitável combinar as duas funções. Contudo, o mais recomendado é que essas funções sejam desempenhadas por pessoas diferentes.
Twitter Weekly Updates for 2010-07-31
jul 31st, 2010 by Joca

Powered by Twitter Tools.

»  Substance: WordPress   »  Style: Ahren Ahimsa