UX e gestão de produtos

Parece que estou bem ruim de pagar dívidas… No último post da série sobre diversificação de portfólio de produtos prometi dois posts, um sobre a relação de engenharia de produtos e gestão de produtos e outro sobre a relação de UX e gestão de produtos. Chegou a hora de pagar segunda parte da dívida!

Mas antes de pagar essa dívida, vou fazer mais uma promessa, a de não fazer mais promessas de posts, porque, pelo visto, quando eu prometo um post eu acabo ficando muito tempo sem escrever… :-/

O que é UX?

A “experiência do usuário” engloba todos os aspectos da interação do usuário final com a empresa, seus serviços e seus produtos.

Fonte: Nielsen Norman Group

Essa é uma definição bastante simples, mas ela realmente contempla todos os aspectos de UX. Quem trabalha com software tem a tendência de achar que UX é a interface do software, tanto do ponto de vista do planejamento da interação do usuário com o software, quanto do ponto de vista visual. Sim, UX é isso, mas não é só isso. UX tb se preocupa com o que esse software causa para quem o usa. De acordo com a ISO 9241-210, intitulada “Ergonomia da interação humano-sistema”, que fornece orientações sobre a interação humano-sistema durante todo o ciclo de vida de sistemas interativos:

Experiência do usuário são “as percepções de uma pessoa e as respostas que resultam do uso ou uso antecipado de um produto, sistema ou serviço.” De acordo com a definição ISO, experiência do usuário inclui todas as emoções dos usuários, crenças, preferências, percepções, respostas físicas e psicológicas, comportamentos e realizações que ocorrem antes, durante e após o uso. A ISO também lista três fatores que influenciam a experiência do usuário: sistema, do usuário e do contexto de uso.

Fonte: Wikipedia

UX no processo de desenvolvimento de produtos

No processo de desenvolvimento de produtos, UX é o responsável por entender a fundo o usuário e o problema que se deseja resolver para esse usuário. A imagem abaixo ilustra bem o papel de UX, bem como o de engenharia de produtos e o de gestão de produtos, no processo de desenvolvimento de produtos.

desejavel-viavel-possivel

Na fase de concepção do produto, UX tem um papel central. Baseado em muita pesquisa para entender a fundo os problemas e necessidades do cliente, UX constrói o protótipo que começará a materializar a ideia do produto. Esse protótipo deverá ser usado nas conversas com clientes e usuários para validar se a ideia faz sentido. E tb nas conversas com o time de engenharia de produto, para que eles já possam entender o que vem pela frente e se há tecnologia disponível para fazer.

É muito diferente ouvir a descrição de um produto ou funcionalidade (“Vc vai ver uma tela com login e senha e um botão de entrar. Tb verá um link caso vc tenha esquecido sua senha.”) e ver a tela onde essa funcionalidade acontece. A primeira versão pode ser um desenho em papel ou em quadro branco:

paper-prototype-1

paper-prototype-2

paper-prototype-3

Depois de acordadas as funcionalidades básicas, esse protótipo pode ser feito em computador. A primeira versão do protótipo feita no computador é normalmente feita só em preto e branco, só com os contornos dos elementos. Essa versão é muitas vezes chamada de wireframe:

wireframe-1

wireframe-2

O próximo passo é UX preparar um protótipo / wireframe navegável, ou seja, um protótipo que já tenha o comportamento de interação para que vcs possam mostrar para clientes e usuários que eles possam testar e interagir. Em seguida, o designer visual de UX começa a colocar cor e forma nessa telas, para transformá-las na versão que os usuários de fato verão.

Com um protótipo em mãos é possível fazer testes de usabilidade para identificar problemas de usabilidade ou validar soluções de interface. Para fazer esse teste convida-se usuários para executar determinadas tarefas em seu protótipo. Durante o teste é possível observar o comportamento do usuário ao realizar um conjunto de tarefas propostas, além de identificar as dificuldades e os motivos para algumas de suas decisões interagindo com o produto. O usuário é incentivado a verbalizar suas ações, opiniões e sensações, dessa forma, conhecemos o modelo mental criado por ele.

Esse protótipo servirá de guia para o time de engenharia desenvolver o produto. É a especificação do produto, mas lembre-se que ela não é escrita em pedra. Por esse motivo, o time de UX não entrega o protótipo para vc e para o time de engenharia e depois vai fazer outra coisa. A pessoa de UX que desenhou o protótipo deve continuar junto com o gestor de produto e com o time de engenharia enquanto o produto estiver sendo desenvolvido para ajustar o protótipo se necessário, descobrir melhorias e aproximar o time de engenharia das necessidades do usuário.

Outro ponto em que o pessoal de UX participa ativamente é na definição e acompanhamento das métricas. Como eu disse antes, todo item de um roadmap deve ter sua motivação e sua métrica. O designer de UX deve saber muito bem qual é essa motivação quando ele vai desenhar o protótipo e deve trabalhar junto com o gestor de produto e com o time de engenharia para definir qual(is) métrica(s) acompanhar para medir se a motivação foi atingida.

Ah, e tem mais um ponto!

Assim como os engenheiros de produto, alguns designer de UX acabam se tornando ótimos gestores de produto. É importante ser capaz de perceber quando um designer está procurando “outra coisa pra fazer” e dar a ele essa opção de carreira. Na Locaweb temos e tivemos ótimos gestores de produto que eram designer de UX. Em alguns casos acabaram se tornando gestor de produto do próprio produto dos quais eram responsáveis por UX. Por outro lado, existem alguns designer de UX que experimentam a gestão de produtos e não gostam. É preciso deixar a porta aberta para ele poder voltar a ser designer de UX, sem nenhum prejuízo para a sua carreira.

O trabalho a ser feito

Já discuti um pouco sobre o que vou tratar aqui no artigo intitulado Claro que o cliente sabe o que quer! onde descrevi que para criar um bom produto devemos:

  • perceber que existem pessoas com um problema para ser resolvido
  • entender muito bem qual é esse problema
  • entender o que motiva as pessoas a querer que esse problema seja resolvido

Uma maneira de se fazer isso é com uma técnica conhecida como “o trabalho a ser feito”, termo e técnica criados pelo professor Clayton Christensen, professor de Harvard e autor de vários livros, dentre eles The Innovator’s Dilemma, livro obrigatório para todas as pessoas que trabalham com tecnologia.

clayton

A ideia por trás do “trabalho a ser feito” é que precisamos entender para qual trabalho nossos clientes contrataram nossos produtos, ou seja, qual o trabalho que nossos clientes esperam que nossos produtos façam.

Clayton ilustra essa técnica com um exemplo muito interessante. Ele havia sido contratado para avaliar um produto específico de uma lanchonete, o milkshake. A empresa já tinha feito pesquisas com os clientes perguntando o que eles queriam, se milkshakes mais densos, ou com pedaços de biscoito, de fruta ou de chocolate, ou com mais calda. A resposta da pesquisa apontou para um preferência, que foi implementada. Contudo, essa preferência em nada mudou as vendas, que era o objetivo principal da empresa.

Clayton decidiu fazer então a pesquisa de forma diferente, ao invés de perguntar o que os clientes queriam, procurou entender qual era o trabalho para o qual as pessoas contratavam o milkshake. Após várias conversas com clientes descobriu que os clientes passavam na lanchonete antes de ir para o trabalho de carro e que ficavam bastante tempo no trânsito. O milkshake, por ser grosso e ser tomado de canudo, demorava para acabar. Demorava o tempo todo da viagem, ou seja, entretia o cliente durante toda a viagem até chegar ao trabalho. As pessoas contratavam o milkshake de manhã antes de ir para o trabalho de carro para ter com que se entreter no caminho. Elas já haviam tentado com outros “concorrentes” como bananas, mas acabava muito rápido. Tentaram também com bagels, mas o trabalho e a sujeira para passar manteiga não compensava. O milkshake era perfeito para esse trabalho a ser feito!

Entendendo o trabalho a ser feito, a lanchonete pode melhorar o milkshake, deixando-os mais densos e colocando pequenos pedaços de fruta e / ou cereais para adicionar pequenas surpresas enquanto seus clientes degustavam os milkshakes. Além disso, preparou um sistema de atendimento que minimizou as filas para garantir um tempo mínimo de espera por entender que seus clientes estavam com pressa e não queriam ficar esperando na lanchonete. Esses ajustes sim trouxeram melhorias nas vendas.

O alcance da técnica do “trabalho a ser feito”

O próprio Clayton comenta que no marketing mais tradicional é comum associar um determinado produto a um determinado conjunto demográfico. Por exemplo, no caso acima, se fôssemos responsáveis pela gestão de produtos da lanchonete poderíamos associar milkshakes com pessoas de certa idade que trabalham e que, consequentemente, sempre procuram milkshake densos que demorem para acabar. Acontece que, usando a técnica do “trabalho a ser feito” temos uma visão mais ampla do contexto onde o produto está inserido.

Clayton estendeu sua pesquisa para outros períodos do dia e pegou as mesmas pessoas voltando à lanchonete no fim da tarde, só que agora com seus filhos, para um lanche rápido. Com certa frequência os filhos pediam aos pais por um milkshake. A lanchonete servia o mesmo milkshake. Denso, grande, que demorava para acabar. Só que os pais não queriam esperar muito tempo para que os filhos terminassem seus milkshakes. Era pra ser um lanche rápido…

Aqui, apesar de o cliente ser o mesmo, o trabalho a ser feito é outro, agradar o filho do cliente de forma rápida. Sendo assim, o milkshake poderia ser menor, talvez metade do tamanho, e menos denso, para acabar mais rápido.

Ou seja, mesmo cliente quer que o mesmo produto faça trabalhos diferentes, a depender da situação. Daí a importância de entender o trabalho a ser feito.

Why the hurry to launch an MVP?

I mentioned earlier that I was starting:

a new project called “The startup guide: how to create and manage profitable web products”. It’s a blog that will eventually become a book where I’ll explain how to create and manage a web product with a profit.

Well, I finished writing the book which is called “The Startup Guide: how startups and established companies can create and manage profitable web products“. The book is focused on how any type of company – no matter if it’s a startup or an established company – can create and profitably manage a web software. All it’s content is available at the “Guia da Startup” blog. It’s currently in Portuguese so it’s a good opportunity for you to practice reading in a new language. If you are not up-to-date with your Portuguese skills, there’s the option of using Google Translate but some meaning may be lost in translation. For these reason I intend to translate the content into English eventually.

One of the most popular posts from this blog is about the reasons to make fast the first version of your product. Why do we need to make an MVP? Why not wait to have the product with more features to launch it? Herb Kelleher, co-founder and former CEO of Southwest Airlines has a famous phrase to motivate people to do things:

“We have a ‘strategic plan.’ It’s called doing things.”

This “strategic plan” can be translated into the #jfdi hashtag which means something in the lines of “just focus and do it” or “just freakin’ do it” (polite form).

But why the hurry? Why can’t we keep working on our product until we feel comfortable it has all the features we believe are needed to solve the user’s problem?

Well, there are 3 main reasons:

Reason #1: The moment of truth!

The longer you take to put your product in front of real users, the longer you take to start getting feedback from real people to know if you’re on the right track. And what’s even worse, you’ll probably be giving too many steps in the wrong direction.

A software is supposed to solve a certain problem of its users. You will not know if you have built a good product until the product is used by real users and it actually solves one of their problems. The longer it takes for this to happen, the longer it will take for you to know if your product is or is not the solution for someone’s problem.

And if it is not, what should you do? Change, adapt and present it again to real users! The sooner you know that what you’re developing is not on track, the better, because you’ll have spent less time, energy and money moving into the wrong direction.

Reason #2: Featuritis

There’s a limit to the number of features an user can understand. When we present a software full of features to a potential user, instead of providing her with a possible solution to one of her problems, we may end up creating a new problem for her. Kathy Sierra, a well known software development and user experience instructor, designed the Featuritis Curve that illustrates in a clear and fun way how user satisfaction diminishes as we increase the number of features of a product.

Reason #3: ROI

The longer you take to put your product in front of real users, the longer it will take for you get some revenue and the longer you’ll have to invest from your own money or investor’s money. Below is a typical return on investment chart. While you don’t launch your product and don’t have revenue, all you’ll have are costs, i.e., you’ll be in the investment phase of the curve below. This situation will only change when you get some revenue and this revenue pays your monthly costs. This is the monthly profitability phase in the chart. Only after a few months in the monthly profitability phase you’ll be able to get to the return on investment phase. It’s a long way:

Now take a look at the chart below. If you decide to delay your launch in 3 months, this can delay your return on investment in 6 months! Are the features that you intend to implement in those 3 months you are delaying the product launch worth the 6 months delay to get to the return on investment phase?

On the other hand, if you are able to launch 3 months sooner than what’s described in the first chart, you’ll get into the return on investment phase 6 months sooner. Isn’t that worth figuring out how to launch your product faster?

If you’re not embarrassed…

There is a famous quote by Reid Hoffman, founder of LinkedIn, which really resonates with the MVP concept:

“If you are not embarrassed by the first version of your product, you’ve launched too late.”

To illustrate this quote, here are some print screens of early versions of well known software products:


Google in 1998


Twitter in 2006


Linkedin in 2005


Facebook login screen in 2005


Facebook in 2005

Next post

Last year I decided to run a lean startup experiment. Would it be possible to build a software and market it without using Locaweb’s marketing power? The result of this experiment is a calorie counter web product with more than 17,000 registered users in less than one year of operation. In my next post I’ll explain how I built the first version of this product in 10 days.

Problema ou necessidade?

Tenho falado muito aqui no Guia da Startup sobre entender qual o problema que o produto web vai resolver. Contudo, por várias vezes vejo essa palavra problema sendo trocada pela palavra necessidade, ou seja, qual a necessidade do usuário que o seu produto web vai atender.

Qual a diferença entre problema e necessidade?

Na entrevista com o Flavio Pripas, do byMK/fashion.me, quando perguntei qual o problema que o produto web dele resolve, ele respondeu:

Não era um problema declarado. As pessoas não falavam para nós que queriam uma rede social de moda. Contudo, percebemos que estávamos atendendo a uma necessidade latente.

Ou seja, existe uma diferença entre problema e necessidade. Pois bem, vamos recorrer à Wikipedia:

Um problema é um obstáculo, um impedimento, uma dificuldade, um desafio ou qualquer situação que peça uma resolução; essa resolução é reconhecida como uma solução ou contribuição em direção a um propósito ou objetivo estabelecido.

Fonte: Wikipedia

Uma necessidade é aquilo que é necessário para que um organismo viva de forma saudável. Necessidades se distinguem de desejos pois a deficiência em atender uma necessidade causa um resultado negativo claro. Necessidades podem ser objetivas e físicas, como alimentação, ou subjetivas e psicológicas, como auto-estima.

Fonte: Wikipedia

Steve Blank, conhecido empreendedor do Vale do Silício, que foi o mentor do Eric Ries no desenvolvimento dos conceitos de Lean Startup, postou ontem no seu blog um artigo com um título bem chamativo: “Como construir uma startup de um bilhão de dólares”. Apesar do título chamativo, o texto é bem interessante e aponta mais uma vez para essa diferença entre problema e necessidade.

É um problema ou uma necessidade?

Eu agora acredito que a proposição de valor do seu modelo de negócios (proposição de valor é o nome chic para o seu produto ou serviço) se encaixa em uma dessas duas categorias:

  • Ele resolve um problema e faz algo para um consumidor final ou uma empresa (software de contabilidade, elevadores, ar condicionado, eletricidade, tablets, escova de dentes elétrica, aviões, software de email, etc.)
  • Ou ele satisfaz uma necessidade social humana fundamental (amizade, encontro, sexo, diversão, arte, communicação, blogs, confissão, networking, jogos, religião, etc.)

Segundo Steve Blank, as startups bilionárias acontecem quando elas atendem uma necessidade. Concordo com ele, mas não acontecem somente quando se atende uma necessidade. Acontecem tb quando se resolve um problema. Existem inúmeros exemplos de startups bilionárias que nasceram para resolver problemas. Google resolveu o problema de encontrar informação na internet. E fez dinheiro resolvendo outro problema, permitindo que pequenas empresas pudessem encontrar clientes com campanhas com custos acessíveis e permitindo que empresas de qualquer tamanho possam fazer campanhas com uma forma muita clara de medição de resultados. Salesfoce.com é outro exemplo de startup que vende software de CRM via web, um serviço claramente voltado para resolver problema de gestão de relacionamento com cliente das empresas.

Sendo assim, quando vc pensar no que o seu produto vai fazer, se vai resolver um problema ou atender a uma necessidade, não se prenda ao conselho do Steve Blank, pois há oportunidades de se criar startups bilinionárias em ambos. Só não se esqueça que as startup bilionárias, ou seja, aquelas que tem crescimento bem acelerado, são raríssimas. Segundo o relatório Empreendedorismo em revista – 2011 da Organização de Desenvolvimento e Cooperação Econônica (OECD – Organization of Economic Development and Cooperation), menos de 1% das empresas com mais de 10 funcionários têm crescimento de funcionários maior que 20% ao ano nos últimos 3 anos. O estudo chama essas empresas de gazelas, devido à sua velocidade. Segundo o mesmo estudo:

Empresas que crescem mais rápido que o ritmo das gazelas (as super gazelas) são ainda mais raras – tão raras que é muito difícil de medi-las estatisticamente.

Como sabemos que o número de funcionários normalmente está diretamente ligado ao crescimento de receita das empresas, é fácil concluir as “super gazelas” de receita tb são raríssimos, tão raras que sequer têm relevância estatística. Contudo, elas absorvem toda a atenção da mídia, exatamente por serem exceções.

Pirâmide de Maslow

A Pirâmide de Maslow, também conhecida como Hierarquia de Necessidades de Maslow, foi proposta pelo professor de psicologia Abraham Maslow em 1943. Ele agrupou as necessidades em diferentes categorias e empilhou essas categorias de necessidades no formato de pirâmide para explicar como as necessidades humanas são priorizadas. Segundo ele, se as necessidades da base da pirâmide não estiverem satisfeitas, dificilmente a pessoa vai se preocupar com as necessidades dos níveis superiores da pirâmide.

Pirâmide de Maslow

Pirâmide de Maslow

A Pirâmide de Maslow é uma boa fonte de inspiração para vermos que necessidade podemos atender como nosso produto web. E além dessas necessidades, existe uma infinidade de problemas por aí esperando para serem descobertos e resolvidos!

Próximo post

Semana que vem falaremos de números!

Comentários

Claro que vc sabia que problema e necessidade são diferentes, mas vc já tinha parado para pensar nessa diferença e que um produto web pode ou resolver um problema ou atender uma necessidade? Comente!

Como escolher uma ideia para transformar em produto web

No post anterior falamos sobre onde encontrarmos problemas para resolvermos e que quanto mais próximos da gente estiver esse problema, melhor. Hoje vamos falar sobre o que fazer quando encontramos mais de um problema que pode gerar um bom produto web. Aliás, essa técnica serve não só quando vc tiver várias ideias, mas mesmo quando vc tiver uma única ideia, pois antes de investir em transformar sua ideia em produto web, vale a pena ver se de fato existe alguém interessado nele e disposto a pagar por ele.

Vc consegue descrever sua ideia em uma única página web?

Então faça isso. Crie uma página web simples descrevendo sua ideia. Não precisa ser uma página super bonita, nem super bem desenhada. Basta ser simples e direto ao ponto, descrevendo sua solução e o problema que ela resolve.

Quando tive a ideia do ContaCal, tive tb a ideia de outras 2 startups e quis saber em qual das 3 ideias investir meu dinheiro, minha energia e meu tempo. Para tomar esse decisão, escolhi um nome e um domínio para cada uma das ideias e registrei esses domínios. Em seguida, criei uma página para cada uma das ideias de produto web que tive. Como não sou nenhum designer, usei um site chamado unbounce, que permite criar páginas simples e até testes A/B de forma bem fácil. Com o unbounce eu criei a página abaixo:

Primeira página do ContaCal

Primeira página do ContaCal

Note que essa página tem só 3 pontos que descrevem o produto, sendo:

  • um ponto para falar do problema;
  • outro para falar da solução e;
  • um terceiro para falar do preço (que nem é o preço praticado hoje).

O formulário de email serviu para captar a quantidade de interessados. Rodei uma campanha no Google AdWords de R$ 10,00 por dia por produto que eu queria testar durante um mês.

Eu tenho um print de um resultado parcial:

Resultado pesquisa

Esse print é de uma tela do unbounce. Depois dos 30 dias de testes terminei com 216 emails interessados no ContaCal e 1.043 pageviews, o que dá 20,7% de taxa de conversão. As outras duas ideias tb mantiveram a mesma tendência do resultado parcial acima.

O custo total desse teste foi de R$ 990,00:

  • Campanha AdWords: R$ 900,00
  • Domínios: R$ 90,00
  • unbounce: grátis por 30 dias, se passasse de 30 dias eu iria pagar R$ 85,00 por mês para até 5 domínios diferentes que eu quisesse testar ao mesmo tempo.

Cada nova ideia custa R$ 30,00 por registro de domínio .br mais R$ 300,00 por mês de campanha no Google AdWords se fizermos um investimento de R$ 10,00 por dia.

Uma outra opção ao unbounce é o launchrock. Não achei informação sobre preços mas me pareceu uma alternativa a ser avaliada.

Mais um exemplo

Mesmo quando vc tem uma única ideia, é bom validar antes de seguir adiante com o desenvolvimento do produto. O Rafael Lima, do Cobre Grátis fez isso. Ele tinha a ideia de fazer um produto web para facilitar emissão de boletos. Era um problema que ele tinha, que resolveu e que imaginou que outras pessoas iriam querer essa solução. Para confirmar sua hipótese ele rodou uma campanha de 3 meses no Google AdWords, gastando um total de R$ 800,00 que enviava para uma pesquisa do sistema de pesquisas online Wufoo que tinha a cara abaixo e o resultado foi 12.939 visualizações e 1.396 pessoas interessadas. Uma taxa de conversão de 10.8%, o que mostrou que valia a pena investir nesse produto pois parecia ser a solução do problema de mais pessoas além dele próprio. E já era uma boa base para o email marketing de lançamento quando o produto estiver pronto. Como curiosidade, veja abaixo como a página que ele fez para captar o interesse é bem simples. É um formulário de três perguntas, direto ao ponto.

Form de pesquisa do Cobre Grátis

Qual é taxa de conversão mínima?

Isso é um pouco difícil dizer, pois depende um pouco de qual é o produto web que vc está pensando em vender. Se for um produto de nicho, ou seja, mais especializado como por exemplo sistema de controle de pacientes para médicos especialistas em coxartrose, pode ser que a taxa de conversão seja pequena mesmo, pois a quantidade de médicos com essa especialidade não deve ser grande. Nesse caso, se vale ou não desenvolver o produto web, vai depender se o seu produto web realmente resolve um problemão para essas pessoas e quanto essas pessoas estão dispostas a pagar por essa solução.

Usando os dois casos acima como parâmetro, que são casos mais genéricos, o ContaCal é um produto que podemos classificar, de acordo com a classificação que fizemos de um produto web em um dos primeiros posts aqui do Guia da Startup, como um produto para consumidor final, não é um produto de nicho e eu decidi ir para o desenvolvimento do produto com algo próximo de 20% de taxa de conversão. O Cobre Grátis é um produto para empresas, também não é de nicho e o Rafael decidiu desenvolvê-lo tendo uma taxa de conversão em torno de 10% o que mostra que em produtos para empresas é aceitável uma taxa de conversão menor.

Vi outras experiências de produtos que não são de nicho e diria que, de forma geral, pelo menos 10% de taxa de conversão, com pelo menos uns 150 emails válidos cadastrados após um mês de campanha no Google AdWords, é o mínimo recomendável para seguir adiante.

Próximo post

Com o post de hoje terminamos o capítulo sobre ideias e problemas e amanhã vamos falar sobre por a mão na massa. Essa parte de por a mão na massa será dividida em duas partes:

  • fazendo o produto web
  • gerenciando o produto web

Os próximos posts serão sobre como fazer o produto web. Contudo, como eu já expliquei antes como o ContaCal foi feito, agora eu vou explicar porque é importante fazer rápido o produto web para entrar logo no modo gerenciando produto web.

Comentários

Como vc testa suas ideias de produto? Gostou dessa forma de testar? Já tinha usado algo parecido alguma vez? Compartilhe!

Qual é o problema?

Como vimos no post anterior, as pessoas sabem o que querem, uma solução para seus problemas. Só que, muitas vezes elas não sabem qual é o problema, ou pior, acham que sabem qual é o problema quando, na verdade, o problema delas é outro.

Muitas vezes as pessoas não sabem qual é o problema

Quando vamos pesquisar por problemas para serem resolvidos e conversamos com pessoas buscando por esses problemas, muitas vezes o que elas nos descrevem não é necessariamente o problema mas sim a forma como elas enxergam o problema ou, o que dificulta ainda mais, a forma como elas imaginam que seja a solução.

Por exemplo, voltando à questão do carro e da carroça do Henry Ford, imagine um diálogo imaginário entre Henry Ford e um hipotético Sr. Smith, um possível comprador de sua futura invenção:

– Sr. Smith, o que mais te aflige?
– Sr. Ford, o que mais me aflige é que passo pouco tempo com minha família.
– E por que?
– Porque passo tempo demais na carroça indo de um lado para o outro. Se eu pudesse colocar mais um cavalo puxando minha carroça, ela andaria mais rápido e eu passaria mais tempo com minha família.
– Ah, entendi seu problema, e tenho uma solução ainda melhor para você, chama-se automóvel.

Será mesmo que Henry Ford entendeu o problema? Ou ele entendeu a solução que o Sr. Smith apresentou para ele? Será que o problema real do Sr. Smith não era que ele passava pouco tempo com a família e talvez precisasse rever sua lista de afazeres fora de casa?

Enfim, esse foi um diálogo hipotético, mas acho que deu para ter uma idéia de como é fácil a gente querer pular logo para a solução sem gastar tempo suficiente tentando entender exatamente qual é o problema. Um bom entendimento de qual é o problema vai ajudar em muito a fazer um bom produto web.

E às vezes as pessoas não sabem que têm um problema

Imagine uma pessoa utilizando um sistema de internet banking. É comum quando uma pessoa vai utilizar um software ela fazer alguma coisa antes de utilizar o software, em preparação para usar esse software e alguma coisa depois, com o resultado do uso desse software. A pessoa pode estar tão acostumada a fazer essas tarefas que simplesmente não enxerga nisso um problema. Esse é o momento em que uma pessoa com o conhecimento do que é possível fazer com a tecnologia disponível tem a ideia de uma solução para um problema que ainda não foi percebido, mas que existe.

A grande questão nesses casos é saber se, pelo fato de o problema não ter sido percebido, quando o for, se ele realmente vai ser visto como um problema por muitas pessoas que estarão dispostas a pagar por uma solução. Se não for, não existe solução a ser vendida.

Devo solucionar problemas de quem?

Quanto mais próximas de você estiverem as pessoas que você vai pesquisar e para quem você vai eventualmente resolver o problema, melhor. A situação ótima é quando você está resolvendo um problema seu pois, nesse caso, você sabe exatamente o que esperar da solução. E é mais fácil descobrir problemas não percebidos seus do que dos outros. Há vários casos de startups que nasceram como soluções para problemas próprios. O ContaCal é um exemplo. Se vc solucionar um problema próprio, quando seu produto estiver pronto e vc o estiver usando, vc sempre terá alguém usando e criticando seu sistema, vc entenderá claramente o fluxo de interação do seu sistema. O único cuidado a ter é que rapidamente vc será um usuário avançado de seu próprio produto e vc não deve se esquecer sempre haverá novos usuários entrando, que nunca viram seu produto e precisarão de uma experiência de uso bem diferente da experiência de uso necessária para um usuário avançado como vc.

Olha que tecnologia bacana!

Uma tecnologia bacana não é nada se ela não resolve um problema. Como estamos cada vez mais cercados por novas tecnologias, é comum encontrar gente que vê uma nova tecnologia e logo pensa que daria um bom produto. Isso é muito comum no mundo das startups, ter uma ideia bacana baseada numa nova tecnologia e fazer um produto em cima dessa nova tecnologia, simplesmente porque agora é possível.

Startups não falham porque não conseguem desenvolver um produto. Startups falham porque não conseguem encontrar clientes dispostos a pagar.

Steve Blank

Uma tecnologia, por mais incrível que seja, se não resolve um problema, nunca será um produto.

Resumindo: problema + tecnologia = solução = ideia de produto

Resumindo, quando juntamos um problema, que nem sempre é fácil de descobrir, mas que quanto mais próximo estiver da gente, melhor, com a tecnologia capaz de resolver esse problema temos uma possível solução que pode virar uma ideia de uma produto.

Próximo post

Na próxima semana veremos o que fazer quando temos mais de uma ideia de produto nas mãos. Vou mostrar um caso prático pois, quando fiz o ContaCal, tinha mais outras 2 ideias de produto web que poderia fazer e acabei optando pelo ContaCal.

Comentários

Vc tem algum história interessante em que o usuário insistiu em dar a solução achando que era o problema? Compartilhe!

Claro que o cliente sabe o que quer!

É comum ouvir em conversas sobre produtos que o cliente não sabe o que quer. Em determinada altura alguém vai soltar a famosa frase de Henry Ford, o inventor do automóvel:

“Se eu tivesse ouvido os usuários, ao invés do automóvel eu teria inventado uma carroça mais rápida”

Aliás, quem gostava de repetir essa frase à exaustão era o eterno CEO da Apple, Steve Jobs.

As pessoas sabem o que querem, uma solução!

As pessoas sabem sim o que querem. Elas querem uma solução para os seus problemas. O que elas não costumam saber é qual é a solução para esses problemas. E é aí que entra Henry Ford, Steve Jobs e o nós, o resto dos mortais, que queremos desenvolver produtos para resolver esses problemas.

Os primeiros passos para criar um bom produto são:

  • perceber que existem pessoas com um problema para ser resolvido
  • entender muito bem qual é esse problema
  • entender o que motiva as pessoas a querer que esse problema seja resolvido

Quando você conversar com pessoas com problemas, algumas até dirão que acham que esse problema poderia ser resolvido assim ou assado mas nesse momento, o mais importante é descobrir se existe um problema a ser resolvido!

Problema: as pessoas demoravam muito tempo para se locomover

Esse foi o problema que as pessoas queriam que alguém resolvesse para eles na época de Henry Ford. Não importava como. Podia ser com mais cavalos na frente da carroça, podia ser cavalos treinados para andar de patins, podia ser com cavalos geneticamente modificados para andar mais rápido, podia ser com a invenção do automóvel, podia ser com a invenção do avião, podia até mesmo ser com a invenção do teletransporte. Note que para quem tinha o problema de demorar para chegar, a forma como seria resolvido não importava, desde que fosse resolvido.

Problema: pais querem ir ao restaurante com seus filhos pequenos e querem ter um almoço tranquilo

Esse é um problema que muitos pais têm. Existem várias formas de se resolver esse problema. Um deles é com um iPhone, iPad ou qualquer aparelho touch carregado com joguinhos e filmes para crianças. Com certeza essa é uma solução para esse problema que ninguém tinha pensado antes da existência dessa tecnologia. Acho até que nem Steve Jobs havia pensado nesse tipo de uso. Contudo, como nosso foco é no problema, e não no produto, é fácil ver que essa não é a única solução. Há outras como, por exemplo, o restaurante distribuir kits para crianças com caderno de atividades e desenhos para colorir, ou ainda o restaurante ter uma área reservada para crianças com monitores que fazem brincadeiras com os filhos enquanto os pais podem ter uma refeição tranquila.

Problema: pessoas querem fazer reeducação alimentar para poder ter uma alimentação mais balanceada e assim perder peso e se sentir melhor

Sempre que se vai a médicos ou nutricionistas, surgem aquelas folhinhas com dietas e várias sugestões de cardápio para serem seguidas. Quem já fez dieta sabe, restringir alguma coisa na alimentação é muito difícil. A gente fica contando os dias para acabar a dieta e poder comer de novo aquilo que nos foi restringido. E na correria do dia-a-dia, seguir sugestão de cardápio é impraticável.

Até que um dia encontrei uma nutricionista que não fez nenhuma restrição, apenas me pediu que eu fizesse um diário alimentar, ou seja, que eu anotasse o que eu comia e a quantidade para que depois pudéssemos analisar juntos o que precisava ser ajustado, quais “escorregadas” não faziam muito mal e quais deveriam ser evitadas, enfim um controle mais adaptável ao meu dia-a-dia. Ela me contou que pessoas que mantêm um diário alimentar perdem até o dobro do peso que as que não têm o registro.

Daí surgiu a ideia de procurar algum sistema contador de calorias. Encontrei vários, todos com alguns pontos interessantes mas nenhum deles suficientemente bom para me manter motivado a continuar usando.

Para atender a essa minha necessidade, resolvi montar o ContaCal.

Próximo post

Amanhã veremos onde encontrar problemas para resolver e onde estão os melhores problemas.

Comentários

Vc conhece algum problema com alguma solução inusitada? Compartilhe!

Restriction driven simplicity

I just returned from vacation and was reviewing some photos in my cel phone when I found some old photos from a previous trip to SF. In the airport there was an exhibition about TV sets and some old remote controls got my attention. Here’s a picture of them:

Old TV remote control

Old TV remote control

Checkout the number of buttons in the remote control. The maximum is 4. There are some remotes with only one button. When I was a kid I remember the first TV bought in my house with a remote control that had only 2 buttons, one for volume and other for changing channel. That simple! That was around 1975. At the time, the technology for making a remote control was too expansive, so it could not be too complicated and have too many buttons, otherwise it would be too expansive to be sold in the market. That was the restriction that drove the simplicity of those 1st generation remote control. Now we don’t have that restriction and we get remotes that can accomplish much more tasks but are way more complex. Take a look at the picture below (and I even picked a not-so-complex one!):

Digital TV Remote Control

Digital TV Remote Control

So maybe next time we want to design something more simple, we can think of imposing some restrictions to the design process! 🙂

Agile Product Discovery in a Non-Startup Environment – Building MVPs

As mentioned in my first post about Agile Product Discovery, I’m trying to take the ideas I used in my lean startup experiment (phase 1, phase 2 and phase 3) in a non-startup environment.

Locaweb has almost 700 employees now. We ended 2010 with approximately $100M in revenue. We have around 130 people in our engineering group which include software developers, system administrators, user experience designers and product managers. We decided to use the SaaS team – around 25 people – as the group who will be part of the experiment.

In phase 1 we worked on figuring out what to do. The next phase is building the MVPs!

Organizing the team

From the 10 ideas we tested, 6 had enough traction to motivate us to build the MVPs, i.e., the minimal viable product. However, one of them was not simple enough to be developed as an MVP in 1 week so we decided to move on with 5 MVPs. The self-organized into 5 groups of 5 people each to work on developing the 5 MVPs. We wanted the groups to have focus during a whole week, so the groups were allowed to work in a different place so they ware not disturbed by daily work. Since we could not leave the company without anyone capable to deal with daily needs of our existing SaaS products, we decided to have 2 teams working during one week and the other 3 teams working during the next week.

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

Building the MVP

The MVPs

And with no further ado, here are the MVPs:

Lessons learned

  • It was good to have the teams fully focused for a whole week.
  • Since we put in the same team people who are not used to work together, it was a bit difficult to estimate the effort and many times we under estimated the effort.
  • In some products we believe we didn’t get the M for minimal correctly. We may have built sub-minimal viable products that may require another week to get to the minimal level.
  • Back to the daily activities of the non-startup environment it’s a bit difficult put some energy, even a small amount, to the MVPs.

Next steps

Now we are measuring the interest in each of the MVPs. We intend to have another Agile Product Discovery week in Feb/2012. During this week we intend not only to discover new products, but also work on the existing MVPs, specially those that we believe are sub-minimal.