No meu último post em que falei sobre as lições de gestão de produtos do fim do Google Wave comentei algumas vezes sobre a importância de conhecermos o cliente, de sabermos se nossa idéia de produto resolve um problema desse cliente e se o cliente está disposto a nos pagar por essa solução.
Mas como saber o que o cliente quer? Como saber se nossa idéia de produto resolve um problema? Como saber se ele está disposto a pagar por essa solução?
Bom, sendo bem direto: pare de perguntar!
Stop asking questions
Perguntar diretamente para o cliente o que ele quer pode não trazer bons resultados. Existe aquela frase famosa atribuída ao Henry Ford que se ele fosse perguntar o que os clientes querem, os clientes iam responder “um cavalo mais rápido”…
Existe também a primeira lei da usabilidade do Jakob Nielsen:
Não ouça os usuários.
What he says and what he really means
What she says and what she really means
Exageros à parte, o que frases como pare de perguntar e não ouça os usuário querem dizer é que mais importante do que ouvir o que o usuário ou cliente ou futuro cliente diz que quer é entender o que ele realmente precisa.
Os testes de usabilidade fazem uso desse conceito. Num teste de usabilidade é pedido que um usuário execute uma determinada tarefa com o produto e observa-se se o usuário consegue fazer essa tarefa e quais as dificuldades ele encontrou durante a execução. Se perguntássemos ao usuário se é fácil usar o produto para fazer a tarefa, as chances de a resposta não corresponder à realidade são grandes.
Outro exemplo interessante é assistir a um usuário 3 minutos antes e 3 minutos depois de ele fazer uso de nosso produto. É provável que ele tenha feito algo para se preparar para usar nosso produto ou algo logo após seu uso que indiquem alguma possibilidade de novo produto ou de nova funcionalidade. Se perguntássemos diretamente ao usuário o que ele faz antes e depois de usar o produto talvez não obtivéssemos uma resposta precisa pois as tarefas podem estar tão inseridas no cotidiano do usuário que nem seriam percebidas como oportunidades de melhoria.
Mas e se ainda não tivermos um produto? Simples, basta usarmos um protótipo!
Last week Google’s announcement about the end of Google Wave made me review and rethink about some product manangement lessons.
Google Wave
Marty Cagan, former eBay Product Management VP and currently product management consultant, uses to say that all product management processes must start with a “product discovery” phase where we need to find out:
For Steve Blank, a retired serial entrepeneuer who started 8 technology companies, knowing the customer is so important that is not enough for the companies to have a product development process. They must have a “customer development” process prior to the product development, where customer demands and problems are the main focus.
More startups fail from lack of customers than from fail of product development.
Steve Blank
In a 2005 post at her “Creating Passionate Users” blog, Kathy Sierra shows happiness as a function of the number of product features. The chart is quite self explanatory:
Featuritis
As it is Google Wave screen. There are so many things one can do with Google Wave…
Every product must be:
We must always remember:
Tricycle
Source: http://flickr.com/photos/jevolella/437838621/
If ease of use were the only requirement, we would all be riding tricycles.
Douglas Engelbart, mouse inventor
O anunciado fim do Google Wave na última semana é uma verdadeira aula de gestão de produtos e eu não pude deixar a oportunidade passar. Por isso vou dar uma pausa no tema gestão de projetos para falar sobre algumas lições de gestão de produtos que o fim do Google Wave nos faz relembrar.
Marty Cagan, ex-VP de Produtos do eBay que atualmente faz consultoria de gestão de produtos, costuma dizer que todo processo de desenvolvimento de produtos deve começar com uma fase de “descobrimento de produtos” onde se deve descobrir:
Já para Steve Blank, um empreendedor em série que já fundou 8 empresas de tecnologia, a importância de se conhecer o cliente é tão grande que não basta as empresas terem um processo de desenvolvimento de produtos, elas devem ter um processo anterior chamado de “desenvolvimento de clientes”, onde se busca entender o cliente e suas necessidades para só depois pensar em desenvolver uma solução para essas necessidades.
Mais startups fracassam por falta de clientes do que por não saber como desenvolver um produto.
Steve Blank, fundador de 8 empresas de tecnologia
Em um artigo de 2005 em seu blog “Creating Passionate Users”, Kathy Sierra mostra a felicidade do usuário como função do número de features de um produto. O gráfico é auto-explicativo:
Assim como o é a tela do Google Wave. São tantas coisas que se pode fazer com o Google Wave…
Todo produto precisa ser:
Lembrando que:
Triciclo
Fonte: http://flickr.com/photos/jevolella/437838621/
Se facilidade de uso fosse o único requisito, estaríamos todos usando triciclos.
Douglas Engelbart, inventor do mouse
Nos meus posts recentes sobre acompanhamento de projetos ágeis e o uso de burnups acabei me deparando com algumas questões mais “filosóficas” sobre produtos, projetos, gestão de produtos e de projetos e os papéis de PO (product owner) e scrum master nas metodologias ágeis.
Projetos e produtos
Primeiro algumas definições básicas:
A project in business and science is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim.
Fonte: http://en.wikipedia.org/wiki/Project
The noun product is defined as a “thing produced by labor or effort” or the “result of an act or a process”, and stems from the verb produce, from the Latin prōdūce(re) ‘(to) lead or bring forth’.
Fonte: http://en.wikipedia.org/wiki/Product_(business)
Ou seja, enquanto o projeto é um processo com começo, meio e fim, o produto é o resultado de um processo, de um esforço.
Parece que sim. Enquanto se está gerindo um projeto, a preocupação é com o processo e com tudo o que o cerca, ou seja, se está no prazo, se tem os recursos necessários e se está sendo feito conforme esperado (qualidade e escopo).
Por outro lado, quando se gere um produto, a maior preocupação é, ou pelo menos deveria ser, garantir que produto resolve um problema do cliente a quem esse produto é destinado.
Em um post de 2007 do blog How To Be A Good Product Manager, o autor Jeff Lash lembra alguns pontos importantes que não devemos esquecer quando pensamos em gestão de projetos e gestão de produtos:
Just like every product needs a product manager, every project needs a project manager. Just because product managers think they can manage their own projects does not mean they should. The skills, talents, and traits involved in project management are very different from those involved in product management. Just like it is hard to find one single person who can fill the product management role and the product marketing role, it is hard to find one person who can be successful at both the product management and the project management role. Project management is not a stepping stone to product management, nor vice versa. Good project managers are just as valuable as good product managers. Finding a good project manager to manage your projects will help you be an even better product manager. The less time product managers spend on project management, the more time they will be able to spend on product management. To avoid conflicts between product management and project management, product managers, project managers, and project teams should all agree on shared goals and objectives as much as possible.
Já Marty Cagan deixa claro a necessidade de separação desses papéis em um de seus posts:
For Internet services companies, it really is important that the roles be separate. You’ll thrash in release management if you don’t, and releases will consistently be delayed and take longer than they should.
As metodologias ágeis, mais especifcamente o Scrum, tem dois papéis claros no time, um focado mais no projeto, o Scrum Master e outro focado mais no produto, o Product Owner (PO):
[Scrum] Roles: Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders. ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits. Team: A cross-functional group of people responsible for managing itself to develop the product. Scrum Team: Product Owner, ScrumMaster and Team
[Scrum] Roles:
Product Owner: The person responsible for maintaining the Product Backlog by representing the interests of the stakeholders. ScrumMaster: The person responsible for the Scrum process, making sure it is used correctly and maximizing its benefits. Team: A cross-functional group of people responsible for managing itself to develop the product. Scrum Team: Product Owner, ScrumMaster and Team
Fonte: http://en.wikipedia.org/wiki/Scrum_(development)
Há um artigo na InfoQ com o título “Can Product Owner and Scrum Master be Combined?” em que o tema de ter um única pessoa gerindo projeto e produto é discutido. Tanto nas opiniões que compõem o texto e que incluem testemunhos de pessoas como Mike Cohn e Ken Schwaber, quanto nos comentários do texto é unânime que apesar de ser possível combinar as duas funções e, se o time for muito pequeno, ser até aceitável, o mais recomendado é que essas funções sejam desempenhadas por pessoas diferentes.
Essa semana tive a oportunidade de conversar com Gil Barros, um profissional muito experiente de design de interação e de arquitetura da informação, que está fazendo doutorado na FAU-USP sobre prototipação e o uso de croquis.
…croquis (palavra francesa eventualmente aportuguesada como croqui ou traduzida como esboço ou rascunho) costuma se caracterizar como um desenho rápido, feito com o objetivo de discutir ou expressar graficamente uma idéia… O que costuma ser mais importante no croquis é o registro gráfico de uma idéia instantânea, através de uma técnica de desenho rápida e descompromissada.
…croquis (palavra francesa eventualmente aportuguesada como croqui ou traduzida como esboço ou rascunho) costuma se caracterizar como um desenho rápido, feito com o objetivo de discutir ou expressar graficamente uma idéia…
O que costuma ser mais importante no croquis é o registro gráfico de uma idéia instantânea, através de uma técnica de desenho rápida e descompromissada.
fonte: http://pt.wikipedia.org/wiki/Croquis
Ele comentou que vê pouca gente se valendo do desenho feito à mão para mostrar ideias e que, por achar essa opção como uma das formas mais ágeis de comunicacão, resolveu dedicar seu doutorado a esse tema.
Eu já havia comentado sobre a importância dos rascunhos, ou protótipos feitos à mão, no post “Protótipo: primeira impressão” e no post “Mais um exemplo de protótipo de baixa fidelidade“.
O que me atrai nos protótipos de baixa fidelidade e em croquis de forma geral é sua simplicidade inerente. Quem me conhece sabe que sou fã da simplicidade, tanto que já escrevi sobre o tema no post “Simplicidade” e em um outro post onde comento sobre um site de 1 única página.
Semana passada, quando escrevi sobre as vantagens do uso dos gráficos de burnup como opção aos Gantt Charts para acompanhamento do andamento de projetos, acabei não comentando de uma das vantagens mais óbvias do burnup: o burnup é mais simples que o Gantt Chart pelo simples fato de que burnups podem ser feitos à mão. Já o Gantt Chart é muito difícil de ser feito à mão.
A prova disso é a busca de imagens do Google. Experimente pesquisar por Gantt Chart e por burnup chart.
Logo na primeira página da pesquisa por imagens de burnup chart são 4 gráficos feitos à mão. Já na pesquisa por Gantt Chart, não encontrei nenhum…
Burnup feito à mão
Outro exemplo de burnup feito à mão
Burn down feito à mão que aparece na busca por imagens de burnup
Mais um exemplo de burnup feito à mão
Na gestão de projetos tradicional existe o famoso Gantt Chart que permite saber com precisão quanto tempo um projeto vai levar, quanto tempo demorará cada tarefa do projeto, que tarefa depende de qual tarefa e se alguma atrasar, o que acontece com o projeto.
Gantt chart
O Gantt Chart não se aplica a contento para projetos de software que usam metodologias ágeis pois ele pressupõe o conhecimento completo de todas as tarefas e fases do projeto antes de seu início, enquanto que nas metodologias ágeis “responder às mudanças tem mais valor que seguir um plano”, ou seja, as metodologias ágeis entendem que mudanças sempre vão acontecer e que o melhor a fazer é estar preparado para as aceitá-las.
O cone da incerteza
Já que mudanças sempre vão acontecer, como podemos acompanhar um projeto ágil, saber qual é o prazo de entrega desse projeto e, ao longo do projeto, saber se ele está dentro do prazo? Mesmo antes das metodologias ágeis já existia o conceito do cone da incerteza que diz que a precisão das estimativas de prazo de um projeto é muito pequena no início do projeto e aumenta ao longo do tempo. Aliás, não só a precisão das estimativas de prazo, como também de custos e de escopo que, juntos com o prazo, são os três limitadores de todo projeto.
Cone da incerteza
O cone da incerteza se aplica a qualquer projeto, quer ele use metologias ágeis ou metodologias de gestão de projetos mais tradicionais. Ou seja, mesmo tendo um Gantt Chart, no início do projeto não teremos precisão sobre seu prazo. O Gantt Chart passa uma falsa impressão de que está tudo sob controle, mesmo com todas as incertezas que existem no início de qualquer projeto.
Mas eu tenho que ter um prazo…
Contudo, mesmo levando em conta o cone da incerteza, é possível ter uma estimativa de prazos, nem que seja algo como “esse projeto vai ficar pronto em setembro” o que significa que ele pode ficar pronto em qualquer um dos 30 dias de setembro, ou “esse projeto será entregue no terceiro trimestre de 2011″ o que dá 45 dias para mais ou para menos de margem de erro!
Prazos têm que existir e te que ser respeitados.
E não raro há casos em que prazo é fixado por quem pediu o projeto (“o site dessa promoção tem que ser publicada até 15 de julho pois nesse dia teremos uma campanha direcionando para esse site”). Nesses casos nos sobram escopo e recursos para mexer sendo que às vezes adicionar mais recursos não faz o projeto andar mais rápido.
De qualquer forma, tanto tendo um prazo fixo (“15 de julho”) quanto podendo dar estimativas um pouco mais abertas (“em setembro”, “terceiro trimestre de 2011″), é preciso saber se estamos dentro do prazo para podermos tomar decisões (trazer mais gente? reduzir escopo? negociar mais prazo?).
Como fazer acompanhamento de projetos ágeis?
Projetos ágeis podem fazer uso de gráficos burnup para podermos ter melhor visibilidade de seu andamento. Não estou falando dos gráficos burnup de cada iteração, que interessam apenas à equipe que está tocando o projeto, mas sim um burnup do projeto inteiro que trará informações úteis para todas as pessoas interessadas nesse projeto.
Veja o exemplo do gráfico abaixo:
Burnup
Nesse exemplo temos uma definição inicial do esforço necessário para terminar um determinado projeto que teria começado em 7/1/2008. O esforço necessário para concluir esse projeto é de quase 100 “xpto”, que está marcado na linha verde. Esse “xpto” pode ser pontos ou horas ou features ou o que quer que usemos para medir progresso de desenvolvimento.
Note no exemplo que nos dias 4/2, 18/2 e 31/3 houve aumentos do esforço necessário. Se não fossem esses aumentos o projeto estaria concluído até 24/3. Com os aumentos passou para 21/4, quase um mês de atraso.
A linha vermelha mostra a velocidade do time. A inclinação dessa linha é o indicativo da velocidade: quanto menor a inclinação, mais devagar o time e, consequentemente, o projeto está andando.
Por que um gráfico burnup como esse é importante?
Ele vai ajudar o time e todos os interessados no projeto a entender seu andamento. Esse gráfico deve andar junto com uma espécie de log para entendermos porque aumentou o esforço necessário, ou porque o projeto está andando mais devagar.
Não é necessário nenhum software especial para fazer esses gráficos. Uma planilha pode dar conta do recado, ou mesmo o bom e velho papel e lápis!
Normalmente o esforço necessário para entregar um projeto pode aumentar porque aumentou o número de funcionalidades a ser entregue (aumento de escopo) ou apareceram dificuldades técnicas não previstas. Esse esforço pode diminuir quando há diminuição do escopo do projeto.
Razões comuns para diminuição de velocidade do projeto são o surgimento de dificuldades técnicas não previstas ou a entrada de um projeto extra que está divergindo esforços da equipe ou ainda a saída de um ou mais membros da equipe antes do término do projeto.
Enfim, a idéia é conseguir ter maior visibilidade e, consequentemente, mais informações para que se possa intervir quando necessário para garantir a entrega dos projetos dentro do prazo estimado.
Nunca vi em nenhuma organização uma situação em que abundavam os recursos e havia escassez de oportunidades. Via de regra sempre há muitas oportunidades pela frente e não sabemos qual ou quais perseguir, pois não conseguimos perseguir todas já que não temos os recursos necessários (tempo, dinheiro ou pessoa) disponíveis.
Muitas oportunidades...
Nessas situações gosto de usar o modelo de análise de oportunidade proposto por Marty Cagan.
Respondendo a um conjunto de 10 perguntas pode-se ter melhor base para decidir se vale ou não a pena ou perseguir um determinada oportunidade agora, ou se é melhor deixar para reavaliá-la no futuro. As perguntas são bem simples:
As perguntas 1 a 4 servem para entender melhor a oportunidade.
As 5 e 6 são bem interessantes pois não basta só entender a oportunidade e ela ser muito boa. É preciso ter certeza de que esse é o momento certo e que nós somos os melhores qualificados para perseguir essa oportunidade.
Da 7 a 9 são perguntas do tipo “e se…”, ou seja, supondo que se decida por perseguir essa oportunidade, como ela vai ser levada ao mercado, como será medido o sucesso e que fatores são críticos para o sucesso.
O processo de desenvolvimento de um novo produto em uma empresa já estabelecida tem semelhanças e diferenças com o processo de criação de uma nova empresa, ou uma startup como são chamadas as novas empresas nos EUA.
As principais diferenças são:
Já a semelhança está no processo em si:
Desenvolvimento de produtos
Acabo de encontrar uma apresentação de Steve Blank, um empreendedor em série do Silicon Valley que fundou 8 empresas de tecnologia em 21 anos e hoje é consultor, professor e escritor sobre empreendedorismo.
Nessa apresentação ele começa apresentando um estatística que, na minha opinião, é mais forte semelhança entre o processo de desenvolvimento de um novo produto em uma empresa já estabelecida e o processo de criação de uma startup:
Mais startups falham por falta de clientes do que por falha no desenvolvimento do produto.
No seu blog ele comenta que 9 de cada 10 startups falham o que me parece ser uma estatística válida também para novos produtos desenvolvidos em empresas já estabelecidas.
E por que isso acontece? Porque o foco do processo de desenvolvimento de produtos tradicional está voltado o lançamento do produto, deixando de lado o que Steve chama de Processo de Desenvolvimento de Cliente, ou seja, descobrir se esse produto que está sendo desenvolvido atende uma necessidade real do cliente. É o que Marty Cagan, ex-VP de Produtos do eBay e atualmente consultor de gestão de produtos, chama de Product Discovery.
Na apresentação abaixo, Steve Blank mostra como é o Processo de Desenvolvimento de Cliente e como ele se encaixa no desenvolvimento ágil de software.
Vale a pena ver também uma série de 9 vídeos de uma aula do Steve em Stanford. O 7º vídeo da série ilustra bem o Processo de Desenvolvimento de Cliente:
Por isso, se você não quer que seu produto falhe, quer você seja parte de uma startup ou de uma empresa já estabelecida, vá pra rua e teste suas idéias com clientes reais. Só assim seu produto poderá deixar de ser parte dessa triste estatística.
No primeiro post dessa série de 3 posts sobre precificação falamos sobre o livro Don’t just roll the dice, a usefully short guide to software pricing, leitura obrigatória para quem trabalha com software ou serviços de internet. Em seguida falamos sobre o livro Smart Pricing: How Google, Priceline, and Leading Businesses Use Pricing Innovation for Profitability:
Capa do livro Smart Pricing
Esse livro foi scrito por Jagmohan S. Raju e Z. John Zhang, dois professores da Wharton University of Pennsylvania, onde ministram o cusro Pricing Strategies: Measuring, Capturing, and Retaining Value.
Jagmohan S. Raju
Z. John Zhang
Já falamos sobre:
E no segundo post da série falamos sobre:
Vamos agora aos capítulos finais:
7. Subscribe and Save: Pricing for Marketing Profitability
Serviços como acesso a internet, telefonia, TV a cabo são as opções que vêm à mente quando pensamos em assinatura. Logo lembramos também de itens físicos como jornais e revistas que podem ser comercializados por assinatura. Nesse capítulo, os autores falam sobre o serviço Subscribe and Save da Amazon.
Subscribe and Save da Amazon
A Amazon oferece 15% de desconto mais taxa de envio gratuita se o cliente pedir a entrega mensal, bimestral, trimestral ou semestral de qualquer item do site. É o sistema de assinatura aplicado a qualquer coisa física. Afinal, nós compramos vários itens de nosso dia-a-dia com regularidade. Por que não deixar essas compras no automático?
Para o cliente a principal vantagem é não precisar mais se preocupar com certas compras. Para a Amazon as vantagens são muitas, pois ganha uma receita recorrente que não varia tanto quanto a receita de compras eventuais.
8. The Snob Premium
Aqui a idéia é cobrar caro pela exclusividade. Um bom exemplo é o cartão Amarican Express Centurion, que tem taxa anual de US$ 2.500, mais uma taxa inicial de US$ 5.000. Não é a toa que só existem 17.000 pessoas com um cartão desses.
American Express Centurion
Outro exemplo apresentado no livro é o Trump Tower, na esquina da Rua 56 com a Quinta Avenida, empreendimento do empresário americano Donald Trump.
Trump Tower
Para tornar o Trump Tower um empreendimento exclusivo, Donald Trump resolveu assumir um grande risco: ele pôs os apartamentos à venda por preços acima do mercado, com “os mais altos preços pagos por um homem” (fonte: Trump: The Saga of America’s Most Powerful Real Estate Baron). Um apartamento de 4 quartos era vendido por US$ 5 milhões, o que ainda era muito dinheiro em 1983. A teoria de Trump era que as pessoas que estão na estratosfera do mercado são insensíveis a preços, mas são muito sensíveis sobre suas companhias e seus status. Liberace comprou o primeiro apartamento, seguido por Johnny Carson.
9. Pay If It Works
Esse modelo de precificação é baseado no conceito de preço baseado em performance. Um bom exemplo disso é o AdWords do Google, onde o anunciante paga apenas quando seu anúncio for clicado. Outro exemplo são os serviços de internet que oferecem o trial antes de a pessoa contratar o serviço.
O que me chamou a atenção nesse capítulo foi um modelo de preço baseado em performance para um remédio. Velcade é um remédio para tratamento de mieloma múltiplo, um tipo de câncer ósseo incurável. Cada ciclo de tratamento custa US$ 4.500.
Velcade
O remédio estava sofrendo duras críticas do National Institute for Health and Clinical Excelence (NICE), que provê aconselhamento para o sistema de saúde inglês.
O laboratório responsável pelo Velcade decidiu então oferecer um reembolso total para qualquer paciente que não tiver uma redução de 25% nas paraproteínas produzidas pelo câncer após 4 sessões de tratamento.
10. Conclusion
Conseguir definir o preço certo é tanto uma ciência como uma arte. Como qualquer prática de administração, as melhores decisões de precificação não dependem apenas de teoria, mas de prática, instinto e um profundo conhecimento do seu cliente.
Outros posts de interesse sobre o tema
Vamos agora aos próximos 3 capítulos:
4. Thinking Small
Apesar de desprezarmos os centavos, há muito valor neles.
Um centavo
Muhammad Yunus, economista e banqueiro bengali que em 2006 foi laureado com o Nobel da Paz, provou o valor dos centavos com a prática da concessão de microcrédito:
Morando em Bangladesh – um pequeno país no subcontinente Indiano, com 130 milhões de habitantes, uma renda per capita de cerca de US$ 300 e com 62% da população analfabeta – para onde retornou após ter estudado Economia nos Estados Unidos, como bolsista do programa Fulbright – o Professor Yunus lecionava Teoria Econômica na Universidade Chittagong, enquanto tentava descobrir como poderia utilizar tanta “teoria” para resolver o simples problema das pessoas que morriam famintas a seu redor. Yunus atribui a origem de sua visão a um encontro fortuito, em Jobra, com Sufia Begum, uma jovem de 21 anos que lutava desesperadamente para sobreviver. Para poder trabalhar Sufia tinha tomado emprestado cerca de 25 centavos de dólar americano a um agiota de seu bairro, que lhe cobrava juros de 10% ao dia. Com esse dinheiro, Sufia comprava bambu para fazer tamboretes. De acordo com o “contrato de empréstimo”, Sufia era obrigada a vender seus tamboretes exclusivamente ao agiota que lhe financiara e que pagava um valor muito abaixo do valor de mercado. Assim Sufia conseguia obter um “lucro” de cerca de 2 centavos de dólar. Para todos os efeitos a condição de trabalho de Sufia era equivalente à de escravo. Yunus encontrou 42 mulheres em Jobra nas mesmas condições e resolveu, ele mesmo, emprestar-lhes seu próprio dinheiro a taxas bancárias normais. Inicialmente emprestou 27 dólares, aproximadamente 62 centavos por tomadora. Surpreendentemente, Yunus recebeu de volta, com pontualidade, o capital e os juros de todos os empréstimos que fizera Isso lhe deu a idéia que talvez fosse possível expandir esse processo.
Morando em Bangladesh – um pequeno país no subcontinente Indiano, com 130 milhões de habitantes, uma renda per capita de cerca de US$ 300 e com 62% da população analfabeta – para onde retornou após ter estudado Economia nos Estados Unidos, como bolsista do programa Fulbright – o Professor Yunus lecionava Teoria Econômica na Universidade Chittagong, enquanto tentava descobrir como poderia utilizar tanta “teoria” para resolver o simples problema das pessoas que morriam famintas a seu redor.
Yunus atribui a origem de sua visão a um encontro fortuito, em Jobra, com Sufia Begum, uma jovem de 21 anos que lutava desesperadamente para sobreviver. Para poder trabalhar Sufia tinha tomado emprestado cerca de 25 centavos de dólar americano a um agiota de seu bairro, que lhe cobrava juros de 10% ao dia. Com esse dinheiro, Sufia comprava bambu para fazer tamboretes. De acordo com o “contrato de empréstimo”, Sufia era obrigada a vender seus tamboretes exclusivamente ao agiota que lhe financiara e que pagava um valor muito abaixo do valor de mercado. Assim Sufia conseguia obter um “lucro” de cerca de 2 centavos de dólar. Para todos os efeitos a condição de trabalho de Sufia era equivalente à de escravo.
Yunus encontrou 42 mulheres em Jobra nas mesmas condições e resolveu, ele mesmo, emprestar-lhes seu próprio dinheiro a taxas bancárias normais. Inicialmente emprestou 27 dólares, aproximadamente 62 centavos por tomadora.
Surpreendentemente, Yunus recebeu de volta, com pontualidade, o capital e os juros de todos os empréstimos que fizera Isso lhe deu a idéia que talvez fosse possível expandir esse processo.
Outra forma de ver o valor dos centavos é a diferença de preço entre R$ 10,00 e R$ 9,99. Há estudos que comprovam que a venda aumenta em 5% quando se usa o preço de R$ 9,99 se comparado com o preço redondo. Por outro lado, os preço redondos são vistos como indicativo de produtos de qualidade.
Também se usam os centavos na precificação por meio da frase clássica de marketing, “por apenas X centavos por dia”.
5. The Automatic Markdown
O automatic markdown é uma estratégia de precificação que se aplica mais adequadamente a itens de moda. Seus principais expoentes são:
Filene's Basement
Syms
Um artigo da New York Times descreve o automatic markdown:
… every article is marked with a tag showing the price and the date the article was first put on sale. Twelve days later, if it has not been sold, it is reduced by 25 percent. Six selling days later, it is cut by 50 percent and after an additional six days, it is offered at 75 percent off the original price. After six more days — or a total of 30 — if it is not sold, it is given to charity.
Fonte: artigo “Shopper’s World; BOSTON’S FAVORITE BARGAIN STORE”
Os autores do livro justificam o sucesso do automatic markdown comparando-o ao leilão holandês, ou descendente. Nesse tipo de leilão, ao contrário do leilão tradicional, também conhecido como inglês ou ascendente, o leiloeiro inicia o leilão com um valor alto e o reduz continuamente. A primeira pessoa que aceitar o lance corrente obtém o item. A motivação de compra é o receio de perder a oportunidade de comprar o item, que é a mesma motivação do automatic markdown da Filene’s e da Syms.
6. Name Your Own Price
Aqui o exemplo é a Priceline.com:
Priceline.com
The “Name-Your-Own-Price” (NYOP) system is where a buyer specifies a price and a product and/or service, and asks sellers to match that combination. NYOP is a special type of reverse auction originally pioneered on the Internet by Priceline.com. Name-your-own-price sales are considered “opaque” by marketers because buyers “don’t know the name of the supplier (airline, hotel or car rental company) or the schedule (with air tickets) until after” they make a nonrefundable purchase. Suppliers benefit because they can sell to the most price-conscious travelers without publicly disclosing those low rates. By 2005, Priceline began to de-emphasize this system, and added published price options on their websites.
Fonte: Wikipedia
Próximos capítulos
Os próximos capítulos são:
7. Subscribe and Save: Pricing for Marketing Profitability 8. The Snob Premium 9. Pay If It Works 10. Conclusion
Fique ligado no próximo post onde irei falar sobre os capítulos acima!
