Innovation: Focus on the problem

In my last article, I discussed about innovation, the first phase of the lifecycle of a software product.

The first step to create a new software product is to understand the problem. It is very tempting, as you begin to understand the problem, go on and seek for solutions. The human nature is to solve problems. 

Every software developer has some story to tell about demands that goes like this: “So, I need a system that does this and that, I need to have a field so I can type this information and it should give me a report that shows this.” Then, when the system is delivered, the person says “Well, this helps me, but now I also need a field to insert this other data and I need the system to export a csv file with this and that info.” In other words, demands come in the shape of solutions and don’t even mention the problem to be solved. 

Next I’ll share some techniques to focus on the problem.


It is a good way to understand customers, the problems they have, the context in which these problems happen, and what motivates them to seek for a solution. However, it is necessary to be careful, because the respondent will try to hand out the solution of what is thought to be the problem. You must be careful not to belittle the suggestion, but should always keep the conversation focused on the problem. 

The interview in which you talk directly to your customer is considered a qualitative method, that is, you ask a few questions but get the opportunity to deepen the answers. 

Next, there is a set of questions that will help to keep the conversation focused on the problem:

  • Tell me more about your problem.
  • What is the greatest difficulty you have regarding this problem?
  • What motivates you to wanting this problem solved?
  • Where does this problem usually happen?
  • When it happened for the last time? What happened?
  • Why was it difficult/complicated/bad?
  • Did you manage to find a solution? Which one(s)?
  • What didn’t you like about the solutions you found?

For instance, let’s go back to the subject of Henry Ford’s car. Now imagine a dialogue between Henry Ford and a hypothetical Mr. Smith, a possible buyer for Ford’s product at that time:

> Ford: Mr. Smith, what distresses you the most?

> Smith: Mr. Ford, the most distressful thing for me is that I donít spend too much time with my family.

> Ford: And why is that?

> Smith: Because I spend too much time in the cart going from one place to another. If I could put one more horse to pull my cart it would go faster and I could spend more time with my family. 

> Ford: Oh, I see your problem, and I have a even better solution for you. It’s called car.

Do you think that Henry Ford got the problem? Or he understood the solution Mr. Smith presented to him, and developed a solution based on Mr. Smith’s solution? Do you think the real problem of Mr. Smith was that he didn’t spend too much time with his family?

Let’s try using the same questions showed previously to see if we can get the problem:

> Ford: Mr. Smith, what distresses you the most?

> Smith: Mr. Ford, the most distressful thing for me is that I don’t spend too much time with my family.

> Ford: And what is the greatest difficulty you have regarding this problem?

> Smith: I spend too much time at work, going from one place to another, without talking to people. 

> Ford: What motivates you to wanting this problem solved?

> Smith: I have small children and, because of work, I spent too much time out of home. When I get home, my kids are already asleep. 

> Ford: Where this problem usually happens?

> Smith: At work.

> Ford: When did it happen for the last time? What happened?

> Smith: Practically everyday. It happened yesterday. I think I manage to get home in time to see my kids woke up once a week…

> Ford: Why was it difficult/complicated/bad?

> Smith: Because it took me away from the kids.

> Ford: Did you manage to find a solution? Which one(s)?

> Smith: I got off from work earlier.

> Ford: What didn’t you like about the solutions you found?

> Smith: The work piled up on the other days.

Note that this conversation can generate a solution such as the invention of the car to help Mr. Smith to get home faster. However, it could be also the motivation for creating a more efficient work process, or a machine that would do the work for Mr. Smith.

You might have a solution in mind. But consider having a real interview, focusing on the questions for really understanding the client’s problem.


Another way of obtaining information from clients is through surveys. This method is considered quantitative because it seeks to survey a considerable amount of people in order to get what is known to be statistical relevant. This is, for being confident that the results weren’t obtained by chance. 

For example, in case you ask in a survey if a person has iPhone or Android, and only get two people to answer, that is, only two answers – being both iPhone, both Android or one iPhone and the other Android – it is very difficult to reach a conclusion. But, if you have many more answers, you have bigger chances to picture the real world in your survey. 

There are great tools for online surveys, such as Google Form and Survey Monkey. There is also a Brazilian tool called OpinionBox that, besides building your questionnaire and collect the answers, allows that you to select people for responding it based on the profile criteria you specify

Surveys don’t have to be necessarily taken online. You can also perform them by phone or live. There are companies that can help you to collect the answers. 

Deciding to do a survey is easy, but building the questionnaire is hard. The first step is having your survey goal very clear. Then, create your questions with these two main rules in mind:

1. Be brief. The shorter your survey, the bigger are the chances of getting a good number of answers and guaranteeing a highest statistical relevance. 

2. Be clear. Especially in online surveys, when you are not interacting with the respondent, there are big chances of the person misinterpreting your question. One good way of testing your questionnaire live with some people. Check if they understood each question, or if they had some difficulties in comprehending some part of it. 

Check some examples of bad questions that could bring up some misguided interpretations or mix up the quality of the answers, and suggestions of how these questions can be improved:

> Original question: How short was Napoleon?

> Improved version: What was Napoleon’s height?

> Original question: Should concerned parents use compulsory child seats in the car?

> Improved version: Do you think the use of especial child seats in the car should be compulsory?

> Original question: Where do you like to drink beer?

> Improved version: Break into two questions: Do you like drinking beer? If yes, where?

> Original question: In your current job, what is your satisfaction level regarding salary and benefits?

> Improved version: Break into two question: What is your satisfaction level with your salary in your current job? What is your satisfaction level with your benefits in your current job? 

> Original question: Do you always have breakfast? Possible answers: Yes / No.

> Improved version: How many days a week do you have breakfast? Possible answers: Everyday / 5-6 days / 3-4 days / 1-2 days / I donít take breakfast.


Another very useful technique to understand the problem is to observe. Seeing the client facing the problem or having a need, in the context that it occurs can be inspiring!

Observation is a qualitative way of understanding a problem. In order to make a good observation, be prepared; that is, hold in your hands a set of hypotheses. In each round of observation, re-evaluate your hypotheses and adjust them, if necessary. Usually, after 6 or 8 observations, you can already notice a pattern. 

Observation may or may not be interfered by the observer. For example, if you are observing consumption habits in a drugstore, you can watch people without them noticing you. But in a usability test, in which you invite people to test your software, people will know that you are observing them. The observations can be complemented with interviews, helping to improve the quality of the findings.

A very useful technique to find out problems in the use of software is to observe what the user does 10 minutes before and 10 minutes after using it. For example, if the user catches information in some other system to insert in the software. Maybe here there’s an opportunity for you to catch information from the other system automatically. And if, after using it, the user pastes information to a spreadsheet for building a graphic, eventually your software could spare the user from this work and automatically build this graphic. 

Observation usually is depicted as a qualitative method. But you can and should also use quantitative observation. For such, observe the user and some important metrics such as access and use statistics, engagement, NPS, revenue, new clients, churn etc. In other words, metrics are a way of observing your users’ behavior while they engage with your software. 

Final remarks

I put aside, on purpose, a technique called focus group, in which we gather a group of people (between 6 and 15 individuals) to discuss a certain problem. It is a technique considered qualitative as it enables to deepen in the questions that are being discussed. 

The reason I put it aside is that, in these discussion groups, there’s a strong social influencer element in which more assertive and extrovert people tend to dominate the discussion and end up polarizing the group’s opinion. In my point of view, individual interviews are generally much more relevant, unless in situations when the goal is to research exactly the influence and social interaction of the group. 

Another important point to consider during your discovery of the problem is who are the people holding this problem and which characteristics they have in common. Besides understanding very well the problem, it is important to know for whom we are intending to solve it and what are their motivations and aspirations. It is important to keep this in mind during the process of discovering the problem. 

You might be asking yourself “Why is so important to invest that much time and effort in understanding the problem?” The answer is simple: developing a software product is expensive. Investing in a good comprehension of the problem, of the people who hold the problem, of the context in which it occurs and the motivation people have to see it solved, is essential for not wasting time and money building the wrong solution. 

Lastly, as I mentioned before, the methods are not exclusionary, they can and must be used together, for they are complementary. An observation is complemented with an interview. The findings in observation and interviews can be confirmed (or confronted) with the results of a survey or the analysis of collected metrics. 

Product Management: how to increase the success of your software

In 2015 I wrote a book on Software Product Management in Portuguese. In 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.

The book is organized in 5 sections:

  • Definitions and requirements
  • Life cycle of a software product
  • Relationship with other areas
  • Product portfolio management
  • Where to use software product management

This book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedbacks are not only welcome, but needed!

Innovation: what is it?

Of all stages of the lifecycle of a software product, innovation is the one that uses to hold the greatest amount of questions. But what is innovation? How to find a problem to be solved? How to find out if this problem is, in fact, an opportunity to be looked for? And how to obtain return with your software product? 

These are the themes that I’ll approach in this and the following articles. 

Innovation is a very common term, but if you ask different people about it, each one will give you a different definition. Some will define it by focusing on creativity, that is, they will say that innovation is something creative, something that didn’t exist before, something different from what you usually find. 

There are many products, not only software products, that are very creative. There are stores specialized in these creative products. In United States, a very well-known store of creative products is Sharper Image.

Without a doubt, this portable air conditioner from Sharper Image is a very creative product.

Another company that sells creative products is SkyMall. The company distributes a catalogue full of different and creative products on local flights in United States. 

However, are these products really innovation? How many people do you know that really need a portable air conditioner? Does it solve a problem or need of a group of people?

Besides people that associate innovation to creativity, others understand innovation as being the latest technology. Quantic computer, wireless electricity transmission, genome editing, virtual reality, augmented reality, nanotechnology and the internet of things are some examples of the latest technologies. 

Whereas, once again, I’ve the same question: Are these really innovations? How many people need these technologies? Do they solve some problem or need of a group of people?  

Defining innovation: Innovating is not just simply being creative or knowing the latest technology. It is necessary to know the available technologies and how to use them to solve a problem or serve a need of a group of people, this has the potential of really producing innovation.

This definition makes clear that innovation – and we can consider creating a new software product as innovation – should start by discovering and understanding problems and needs of a group of people. 

But how can we do this? Do customers know what they want?

Of course customers know what they want!

Customers don’t know what they want.” Unfortunately, it’s common to hear such sentence in conversations about products and customers. At a certain point, someone will utter the famous quote from Henry Ford, the automobile inventor:

“If I had asked people what they wanted, they would have said faster horses.” –Henry Ford

Steve Jobs, Apple’s eternal CEO, enjoyed repeating this sentence to exhaustion.

Nevertheless, I disagree. Clients do know what they want. They want a solution for their problems. That’s where Henry Ford, Steve Jobs and us, mere mortals, come in, willing to develop products to solve these problems. 

The first steps to create a good product are:

  • To realize that there are people with a problem or need to be solved;
  • Understand very well what is this problem or need;
  • Understand what motivates people to want this problem or need solved.

When you talk to people with problems or needs, some will even say that this problem could be solved like this or that; however, in this initial moment, the priority is to find out if there really is a necessity to be solved. You must decouple the problem from the suggestion of solution your interlocutor is trying to give. 

People used to take a long time to move. This was the problem to be solved at Henry Ford’s time. No matter how. 

It could be more horses in front of the carts, it could be horses trained to walk on rollerblades, it could be using genetically modified horses that would ride faster, it could be the invention of the car, the invention of the airplane, even the invention of tele-transportation. 

The specific solution for the problem didn’t matter, as long as the problem was solved. Many people probably gave solutions, like the fastest horses from Henry Ford’s quote, but this is just a suggestion. The problem to be solved is that people took too long moving from one place to another. The problem was not that they wanted to move faster. That’s already part of the solution. 

In the following articles, we will approach some techniques that will help us to find out and understand the problems or needs.

Product Management: how to increase the success of your software

In 2015 I wrote a book on Software Product Management in Portuguese. In 2016, Paulo Caroli talked to me about how he enjoyed the book and how this book could be useful to people in the software industry not only in Brazil but anywhere in the world. For this reason, we decided to create an English version of my book.

The book is organized in 5 sections:

  • Definitions and requirements
  • Life cycle of a software product
  • Relationship with other areas
  • Product portfolio management
  • Where to use software product management

This book is suitable for anyone working with software. Even companies that do not have software as its core business use software in their day to day and often have developed some software that interfaces with its customers such as a website or a mobile application. It is important for these companies to understand the software product management role and responsibilities, so they can better manage this software and increase its chances of success.

We are working on the translation but as we progress we are already releasing the content. If you want to see the work in progress, please visit the book page at LeanPub. Still in beta but already with valuable content. Feedbacks are not only welcome, but needed!

Guia da Startup – edição atualizada

Essa semana ficou pronta a edição atualizada do Guia da Startup! \o/

Quem comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço

A primeira edição deste livro foi escrita em 2012, há mais de 4 anos. Muita coisa aconteceu na indústria de software e no cenário de startups do Brasil e do mundo. Por esse motivo, resolvi escrever uma segunda edição, trazendo algumas dicas novas, atualizando sobre o andamento do ContaCal e com um update das entrevistas publicadas na versão original, e mais algumas novas.


Veja aqui o changelog completo:

  • De produto web para produto de software — Mudei as refereÌ‚ncias a “produto web” para “produto de software”. Fiz isso pois mobile é agora o novo veículo do software. No mobile, o software pode ser entregue via web ou via app. No futuro, o software será usado em relógios, em carros, em qualquer lugar. Por esse motivo, troquei onde falo “produto web” por “produto de software” ou simplesmente por “produto”. Aliás, isso me motivou até a mudar o subtítulo deste livro. Se voceÌ‚ já o leu, talvez isso lhe motive a releÌ‚-lo, vendo produto sob este novo prisma. 
  • Adição ao capítulo Recebendo feedback — Adicionei a este capítulo uma seção explicando a importaÌ‚ncia do porqueÌ‚ antes do como. 
  • Adição ao capítulo Cuidado ao lançar um produto mínimo — Adicionei a este capítulo um exemplo de experimento de fake feature que fiz no ContaCal e que me poupou muitas horas de desenvolvimento que se mostrariam desnecessárias. 
  • Capítulo novo: Dicas básicas (e não tão básicas) de SEO — Para ajudar a atrair tráfego para o site de sua startup, é importante entender de SEO (Search Engine Optimization). Neste capítulo, compartilho um pouco do que aprendi sobre o tema. 
  • Capítulo novo: Vá vender! — Essa é a melhor maneira de entender se seu produto resolve o problema dos clientes. Em uma startup, todos teÌ‚m de vender. Então, o que voceÌ‚ está esperando? Vá vender! 
  • Capítulo novo: Churn — Um capítulo inteiro dedicado ao churn, quantidade de usuários e clientes que deixaram de ser usuário ou cliente. Neste capítulo, explico também sobre o tão falado churn negativo. Como é possível ter churn negativo? 
  • Capítulo novo: Mudança de rumo (pivot) — Aqui conto o caso da Eventials, uma plataforma para transmissão de palestras online, que precisou mudar para sobreviver. Qual era o problema, o que eles fizeram e as 10 formas possíveis de mudança de rumo são os temas deste capítulo. 
  • Adição ao capítulo Quanto tempo demora até ter retorno? — Adicionei a este capítulo informações sobre o primeiro meÌ‚s positivo do ContaCal. 
  • Capítulo novo: Cinco anos depois, como está o ContaCal? — Aqui conto como está o ContaCal, se ele está dando retorno financeiro e se atingiu seus objetivos. 
  • Entrevistas — Todas as entrevistas foram atualizadas com a situação mais recente das empresas e de seus produtos. Inclui também algumas novas entrevistas:
    • Sonia Tuyama, da empresa Aurum, com mais de 20 anos de mercado, que tem um software não web e que, em um determinado ponto de sua vida, percebeu que precisava fazer uma versão web de seu software.
    • Thiago Lima, fundador da Eventials, que citei em dois capítulos novos.
    • Vinicius Roveda, um dos fundadores da ContaAzul, empresa que escolhi para voltar a viver esse clima tão gostoso de Startup.

Gostou das novidades? Como disse acima, se vc comprou a edição anterior em e-book, já pode fazer o download da nova versão pelo link de download que você recebeu quando comprou a primeira edição. Caso você tenha perdido o link, é só mandar um email para a Casa do Código no endereço

Agora, se vc ainda não comprou sua cópia do Guia da Startup, o que está esperando, adquira sua cópia hoje mesmo!!!

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.


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:




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:



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.


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/, 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. é 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!


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.


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.


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