Desenvolvimento voltado ao cliente
•Transferir como PPTX, PDF•
0 gostou•33 visualizações
O documento discute o desenvolvimento voltado para o cliente, enfatizando a importância de descobrir as necessidades reais dos clientes por meio de entrevistas antes de projetar soluções. Ele também discute como a Amazon aplicou esses princípios ao longo do tempo, com foco obsessivo no cliente e tomada rápida de decisões reversíveis com base em feedback.
Recomendados
Mais conteúdo relacionado
Semelhante a Desenvolvimento voltado ao cliente
Semelhante a Desenvolvimento voltado ao cliente (20)
Mais de Amazon Web Services LATAM
Mais de Amazon Web Services LATAM (20)
Desenvolvimento voltado ao cliente
- 2. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. AntesdeConstruir: DesenvolvimentovoltadoparaoCliente CustomerDevelopment Cláudio Chiba Senior Solutions Architect AWS Public Sector
- 3. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 4. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 5. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 6. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. RECAP Por que 85% dos novos produtos falham
- 7. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Nós construímos coisas erradas!
- 8. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2018, Amazon Web Services, Inc. or Its Affiliates. All rights reserved. POR QUÊ
- 9. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. QUAL É O OBJETIVO DELA????
- 10. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. POR QUÊ???? Para usar um vestido novo?
- 11. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. POR QUÊ???? Para usar um vestido novo? Ela tem uma competição na sexta?
- 12. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. POR QUÊ???? Para usar um vestido novo? Ela tem uma competição na sexta? A família dela tem histórico de diabetes?
- 13. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. PERGUNTA Qual a probabilidade de que as hipóteses da sua persona sejam verdadeiras?
- 14. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 15. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. “Todo mundo tem um plano até levar um soco na cara” – Mike Tyson
- 16. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Não vale a pena resolver um problema até provar que ele realmente existe
- 17. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. “Mais startups falham por falta de clientes do que por uma falha no desenvolvimento de produtos.” — Steve Blank
- 18. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 19. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. “Precisamos aprender o que os clientes realmente querem, não o que dizem que querem ou o que achamos que deveriam querer.” — Eric Ries
- 20. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. “A capacidade de aprender mais rápido do que seus concorrentes pode ser a única vantagem competitiva sustentável.” — Cindy Alvarez
- 21. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Um processo para descobrir evalidarseusclientes, mercado esolução.
- 22. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. OCiclodeAprendizado eConstrução Learn Build
- 23. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 24. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Não
- 25. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente Dynabook 1984 iPod 2001 2007, the iPhone
- 26. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. OCiclodeAprendizado eConstrução Learn Build
- 27. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Descoberta Começa antes de você estruturar a solução Validação do Cliente Descoberta do Cliente Criação do Cliente Construção da Empresa
- 28. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimento voltado paraoCliente Sobrepõe e direciona o Desenvolvimento do Produto Desenvolvimento para o Cliente Desenvolvimento Do Produto
- 29. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Product Market Fit Proposição deValor +CustomerSegment
- 30. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Sidebar: Mercados Considere: • Amplitude do Mercado • Existente versus Novo Mercado • Barreiras de entrada • Obstáculos de implementação • Necessidade de Capital • Ciclos de Vendas
- 31. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Como
- 32. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. “Thereare no factsinsideyour building”
- 33. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Get out of thebuilding.
- 34. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas Mas tenha cuidado Entrevistas
- 35. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas Erros comuns • Não encontrar as pessoas certas • Não fazer as perguntas certas • Insights incorretos • Demonstrar antes de entrevistar • Falar mais do que ouvir
- 36. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas Você gosta de sorvete? Pergunta Ruim Você compraria um shampoo para seu cachorro?
- 37. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimento voltado paraoCliente:Entrevistas Qual a sua maior dificuldade? Pergunta Boa
- 38. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas Você pagaria por isso? Pergunta Ruim
- 39. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas Quanto esse problema está te custando? Pergunta Boa
- 40. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas Características de uma pergunta irrelevante • Sim/Não • Muito Vaga • Centrado em você mesmo ao invés do cliente • Não passar no “teste da mamãe”
- 41. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 42. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas Como você resolve isso hoje? Pergunta Boa
- 43. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. CustomerDevelopment: Entrevistas O que você desejaria poder fazer? Pergunta Boa
- 44. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. CustomerDevelopment: Entrevistas Com quem mais eu poderia conversar sobre? ParaContinuar
- 45. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas Características de uma pergunta boa • Working backwards a partir do cliente • Perguntas abertas • Provoca discussões • Revela as principais dores
- 46. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas O que você está tentando descobrir • Ou comportamento ou feedback, mas não os dois ao mesmo tempo • Em primeiro lugar, a essência do problema • Não o que eles querem, mas o que eles estão tentando resolver
- 47. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas Melhores práticas • Times de dois • Um único assunto para a entrevista • Escutar mais do que falar • Entrevistar o suficiente para identifcar tendências • Aproveitar as oportunidades • Absorver o máximo possível
- 48. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Entrevistas Desafios • É difícil • Pode ser constrangedor • Se você é um engenheiro, pode parecer pouco natural • Construir seduz, traz a sensação de progresso
- 49. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Boas perguntas produzem insights e não apenas dados
- 50. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Comportamentos Existing behaviors that customer is exhibiting to solve their pains and achieve their goals Facts Factual information about your target customer Pains What are your target customer’s pains? Objectives What are the goals that the customer is trying to accomplish?
- 51. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Behaviors Existing behaviors that customer is exhibiting to solve their pains and achieve their goals Facts Factual information about your target customer Pains What are your target customer’s pains? Goals What are the goals that the customer is trying to accomplish? Facts + Behaviors = Customer
- 52. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Behaviors Existing behaviors that customer is exhibiting to solve their pains and achieve their goals Facts Factual information about your target customer Pains What are your target customer’s pains? Goals What are the goals that the customer is trying to accomplish? Pains + Goals = Problem
- 53. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Behaviors Existing behaviors that customer is exhibiting to solve their pains and achieve their goals Facts Factual information about your target customer Pains What are your target customer’s pains? Goals What are the goals that the customer is trying to accomplish? (Behaviors + Goals) – Pains = Solution
- 54. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Validação Outras Técnicas • Escreva um Press Release • Anuncie o seu produto que ainda não existe • Entrevistas com participantes em Conferências • Prototipação com storyboard em papel • Telefone, e-mail, café
- 55. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Validação Erros comuns • Esperar pela informação ideal • Amazon: Two-way doors • Não esperar que as coisas deem errado inicialmente • Não adaptar rapidamente • Tratar como um checklist
- 56. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Validação Critério de parada • Quais são os maiores problemas de seus clientes? • Quanto eles pagariam para resolvê-los? • As soluções que você propõe resolve esses problemas? • Os clientes concordam? • Eles pagariam pela sua solução específica?
- 57. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimentovoltado paraoCliente:Validação Validação Descoberta do Consumidor Validação Do Consumidor
- 58. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 59. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. ATENTO EM BUSCA EARLY ADOPTER SIM SIM EARLY MAJORITY SIM NÃO LATE MAJORITY NÃO NÃO COMO VOCÊ IDENTIFICA UM EARLY ADOPTER?
- 60. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 61. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimento voltado paraoCliente:Amazon lições aprendidas
- 62. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimento voltado paraoCliente:Amazon Obsessão pelo Cliente
- 63. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimento voltado paraoCliente:Amazon The PRFAQ
- 64. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. Press Release Draft “Final” PR/FAQ Problema / oportunidade
- 65. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. AMAZON CONFIDENTIAL 5Questões para responder emum PressRelease 1. Quem é o seu cliente? 2. Qual é o problema ou oportunidade do seu cliente? 3. Qual é o benefício mais importante para o seu cliente? 4. Como você sabe quais são as necessidades e desejos de seu cliente? 5. Como será a experiência do cliente?
- 66. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. AMAZON CONFIDENTIAL Press release • Foco na necessidade do cliente • A chave é o comentário do cliente • Um passo para o futuro: Pense GRANDE • Evite Jargões • Fale simples e claramente
- 67. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 68. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. DESCOBERTA DO CLIENTE
- 69. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. AMAZON CONFIDENTIAL Pitching para a Solução
- 70. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. AMAZON CONFIDENTIAL Protótipos físicos
- 71. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Mágico de OZ what
- 72. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. “Final” PR/FAQ Problema / oportunidade
- 73. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Desenvolvimento voltadopara oCliente: Amazon Tome decisões reversíveis rapidamente. Na Amazon, nós chamamos de decisões “two way door”.
- 74. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2018, Amazon Web Services, Inc. or its affiliates. All rights reserved. POR QUÊ? LEARN BUILD MEASURE
- 75. © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
- 76. Obrigado! © 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved. Claudio Chiba Senior Solutions Architect AWS Public Sector
Notas do Editor
- —== [O QUE DIZAR] ==— Esta van é o pior Pesadelo de todos os pais. Eu não sei quanto a você, mas quando eu estava crescendo, eu recebi instruções muito claras de meus pais toda vez que eu saía para brincar com amigos: Não entre em um carro com alguém que você não conhece Definitivamente, não tome doces de estranhos E, como eu envelheci, não beba bebidas que você não fez mesmo você Crédito: Foto de Dan Gold em Unsplash
- E então empresas como a Uber vem e perturbar as empresas inteiras com um modelo de negócio é literalmente: instalem este aplicativo em seu telefone para que você possa dizer a um estranho onde você mora, entrar em seu carro, e eles provavelmente o darão doces.
- --==[WHAT TO SAY]==-- Why should you care about innovation? I mean, there are lots of other things competing for your attention—what makes innovation so special? I think there are 4 reasons: Software is eating the world Other companies influence the perception your customers have about you Digital enables unlimited scale To say that success with new product development isn’t great would be charitable
- [Ler slide]. Essa visão central é de Steve Blank, um empresário, educador e escritor, e o cara que cunhou o termo “desenvolvimento de clientes”. Há alguns casos em que a engenharia caiu e uma empresa morreu como resultado — o amigo do passado vem à mente — mas eles são comparativamente poucos. Menos ainda, agora que você tem coisas como nuvem e serviços SaaS para construir. Mas você ouve “não conseguimos tração”, ou seja, clientes, constantemente. Então, por que temos tantas metodologias para o desenvolvimento de software, voltando pelo menos aos anos sessenta — cachoeira, programação extrema, desenvolvimento ágil, desenvolvimento rápido de aplicações (RAD!) , desenvolvimento em espiral — e poucos ou nenhum para descobrir o que os clientes realmente querem. Porque o melhor processo de desenvolvimento do mundo não importará se ninguém quiser o que você está desenvolvendo.
- Um tipo de exemplo do poder da tração é o Twitter (Fail Whale): ao contrário do Friendster, eles falharam em falhar, apesar de terem grandes problemas de desenvolvimento de produtos. Mas eles tinham clientes que realmente queiram o produto, então os usuários toleraram seus problemas por anos antes de serem corrigidos. Mark Zuckerberg uma vez chamou-lhes um carro palhaço que caiu em uma mina de ouro: -) Então, como você cria esse problema para si mesmo, ou pelo menos a meio positiva dele - um produto que os clientes realmente querem?
- Para começar, você realmente tenta aprender. Eric Ries, de quem tenho certeza que muitos de vocês já ouviram falar, é o autor de 'Lean Startup”, e ele era um estudante de Blank, e ele diz aqui é a idéia de que você quer fazer esse aprendizado adiantado, e rapidamente. Uma forma de aprender se uma idéia é válida é contrato 30 engenheiros e passar três anos construindo uma jóia belamente trabalhada, mas se você compreendeu errado (e provavelmente vai errar no início) você está morto. Você só deu uma chance a si mesmo, e gastou sua munição.
- Mais uma citação: Cindy Alvarez, autora de “Lean Customer Development”, estende este ainda mais [leia slide]. Portanto, precisamos não só aprender, mas aprender rapidamente. Junte isso e uma definição começa a ficar em foco:
- [read]... and what Blank, Ries, Alvarez, and other proponents of customer development have produced is a set of guidelines to do this, to add rigor to finding your customers in the same way we’ve added rigor to building software.
- Não há cerne disso está o ciclo aprender-construir-aprender. Realizamos pesquisas ou executamos experimentos, tomamos ações baseadas no que aprendemos com eles, e repetimos, iterando e corrigindo o curso até termos alguma idéia de que estamos indo na direção certa. E assim o mais cedo possível em nossa jornada. Observar que, nos estágios primários, depois de aprender algo, o que você começa a construir não é seu produto, mas mais pesquisa e mais experimentos. Você quer fazer isso antes de se comprometer com o trabalho de engenharia porque se o que você aprende é que não há mercado, ou é muito pequeno, ou você está direcionando isso incorretamente, ou que sua solução é a errada para o mercado — então você não quer que o trabalho Desperdiçado vá na direção errada. Uma vez que você tem alguma Validação de que você encontrou um cliente viável, em um mercado viável, cujas necessidades podem ser atendidas com uma solução viável, então você começa a construir um produto a sério. Então, essas noções estão iniciando a ganhar tração, em grande parte devido ao movimento Lean Startup, mas você ainda vê muito do culto do fundador visionário, a pessoa com insights indisponíveis para os outros, capaz de ver ao redor dos cantos onde outros nem mesmo vir os cantos. O modelo é o cara que sabe o que as pessoas querem antes delas mesmas. O modelo é...
- Steve Jobs.
- Eu não acho que isso esteja correto, e talvez por uma razão diferente do que você possa pensar. A tréplica comum ao caso Jobs é dizer: “Você, senhor, não é Steve Jobs.” O que, embora seja verdade, perde o ponto. A idéia de que tudo o que Jobs fez surgiu completamente do lado de sua cabeça simplesmente não é verdade, e pouco é verdade mesmo dos produtos mais visionários. Vamos explorar isso e olhar para o produto mais icônico de Job, o iPhone.
- Jobs passou pelo ciclo de aprendizagem—construir-aprender com o iPhone também — só levou algumas décadas. O iPhone não era uma coisa nova quando foi lançado, foi o culminar de décadas de trabalho de muitas pessoas. No canto superior esquerdo é o Dynabook, concebido por Alan Kay em 1968, mas nunca construído (este é o protótipo de papelão). Jobs era um grande fã — ele empurrou a Apple para construindo em 1984. Em vez disso, o conselho da Apple o demitiu, mas ele deve ter plantado uma sementeira, porque em 1993 a Apple lançou o Newton MessagePad. Telas mais importantes ao toque cobertas com ÍNOS? Agora uma coisa. 1996 o Palm Pilot lança. Um grande sucesso, embora a maioria deixasse você fazer uma coisa, que era tomar notas. Jeff Hawkins, é inventor, carregou um bloco de madeira com ele e rabiscou notas falsas sobre ele com um pauzinho, apenas para ter certeza de que parava certo - como parte de sua análise do fator de forma. 2001, o iPod. Um sucesso ainda maior. A Apple descobre que há mercado para belos computadores de bolso. O Perigo Hiptop, combinando um telefone e um PDA. Projeto por Andy Rubin, que mais tarde criou o sistema operacional Android! Já pode ver como as luminárias neste campo estavam aprendendo por um longo tempo antes de seus sucessos de fuga. 2002. Treo gira para fora de Palm e lança o 180. Parece incrível como...
- O resto desta palestra é sobre algumas das maneiras que você pode aprender mais, mais rápido e usar o que você aprende para informar seus produtos. E como fazer isso antes do lançamento, em vez de se ferrar uma vez que você está no mercado.
- The full customer development process as defined by Blank has four steps, but the later two are for companies that have reached product market fit (which we'll touch on shortly) and are working on things like creating a scalable sales process. We’re going to focus the rest of this talk on the parts of the process more relevant to early stage startups—validation and discovery—with an emphasis on customer discovery.
- Vamos dar uma vista em como o desenvolvimento do cliente se relaciona com o desenvolvimento do produto Pode haver exceções, digamos, se uma empresa se baseia em um desenvolvimento profundidade técnico, mas na maioria dos casos fundadores, incluindo fundadores técnicos, estar fazendo o desenvolvimento do cliente antes de começarem a codificar. [antecedência] Depois que o desenvolvimento inicial do cliente validar sua ideia pelo menos de forma direcionada, você pode começar a criar, mas a engenharia e o produto nunca devem ficar muito longe do cliente — continue fazendo entrevistas, para chegar aos usuários iniciais, para acompanhar dados de uso que podem revelar ações e intenções do cliente, e construir com a expectativa de mudar o curso com base no que você aprende
- So let’s loop back to that notion of product market fit and do a quick level set on what we mean by that. Blank is a proponent of something called a Business Model Framework, which has a number of components, but the most important of them, especially for startups and early on, are coming up with a value proposition, and then finding a sufficient number of customers who indeed do get value from that proposition and will pay for it (or subsidize it in some meaningful way, like tolerating advertising). If you do that, this is otherwise known as that mythical thing, Product Market Fit.
- Now let’s look at some characteristics of markets. Is the market you’re contemplabting big enough to support your business? It needs to be big enough in at least one dimension: Is it a small market where a few customers pay millions? Or a huge market, where billions pay pennies? Is it a new or existing market? The answer will affect your rate of adoption, and how you approach marketing. Are there implementation obstacles? Compliance & regulatory hurdles, IP issues, unique technical challenges? What are your capital needs? My first company launched, I’m not exaggerating, for $7. The electric truck company Rivian was founded 10 years ago, has raised $1.4B, and hasn’t launched a product yet. So it’s important to know where you are on the $7 to $1.4B continuum. What’s the sales cycle? For self-serve SaaS it might be days, if you’re selling to the feds it could be years. The answer will have a huge effect on cashflow. None of these exist in isolation. Do you have a small team, low costs, and can bootstrap? That permits a smaller market. If you need hundreds of engineers and a factory, you need a larger one.
- Ok, I’m sold, let’s do this customer development thing. Where do we start?
- Time for another Blank quote: “there are no facts in your building.” At least none related to your value proposition or your potential customers. To learn about them, you need to…
- Get out of the building. That’s where the facts live. This isn’t just Blank. I was a cub reporter in the mid 90s and heard this from editors all the time: get out of the building! What they meant is, to get the real story you need to talk to get out and talk to people. A story done from your desk is called a “phoner,” and the implication is that either you’re lazy, or it isn’t much of a story. Compare that to ”shoe leather reporting,” which is always a compliment. So in a moment we’ll talk about what you actually do once you’re out of the building, but first let’s look at some examples of companies that did, and did not, follow customer development patterns.
- Interviewing harder than it sounds, because if you do it wrong could be worse than not doing it at all, mostly because it can generate false positives. You need to get around people’s innate impulse to be polite. That impulse should give you faith in humanity—but it can also make you think any cockamamie idea is great, because if you just ask people if they like what you’re doing, a great many will just want to be nice, and say ”yes!” So you need to craft your questions carefully, and avoid certain pitfalls.
- What are some of those pitfalls? You need the right people: not just your friends, or randos online, or easy to find people—you need people who reflect your hypothesized market segment You need ot ask the right questions. We’ll be looking at good and bad questions in a moment. You need to draw insights, not just collect data, and to avoid confirmation bias. Likewise for demos. There’s a place for them of course, but they need to come after you’ve talked to people about their needs. The problem has to come before the solution. And we all love talking about our projects, we wouldn’t be doing this if we didn’t have a passion for what we build, but resist the urge, or you won’t learn anything. Ask questions about the subject, then listen. So some examples.
- This is about you, not them, and it’s the question most likely to elicit a knee jerk polite response. They may have a problem you could solve, but you’ve jumped to the solution too soon. They may not like it for subjective reasons unrelated to the solution, and you could dump a brilliant idea, or embrace a bad one, because someone liked or didn’t like the color of a button in the demo you shouldn’t have given them. You’ll get a single data point, which may or may not be of use, and the conversation slams to a halt. You may be able to get it rolling again with a ‘why?’ or the like, but maybe not. Avoid this show-stopper.
- This asks for a narrative, it’s open ended, and it gets to their needs, not yours. It given them the opportunity to describe their needs. Discovering a real need is a great thing, and if you’d leapt to the solution first, you may not have discovered anything. Even if you’re envisioning the wrong solution, if you need to go back to the drawing board, if you have a good sense of the problem you’re solving for, you’ll be way ahead of the game.
- Aside from being a non-flowing, politeness-plagued yes/no question, it also fails because the answer might be very dependent on the person you’re speaking to. Some people just aren’t buyers of software, regardless of utility, even if they are otherwise in the group you’re targeting. You may have a solution where the user and the buyer aren’t the same person, and this may not calibrate for that. And worst of all, once you’ve gone here, you’ve cut off a bunch of other more important questions.
- This is a more open ended, and it lets you ask about costs in the holistic sense—not just money, but time, management overhead, etc. This allows someone who wouldn’t themselves pay for something to still give you useful information. And it helps you learn if there’s a market. You may have found a universal problem, but if it’s a mild nuisance and there are free solutions out there, you haven’t found a business. This is also an opportunity to gather intelligence about pricing, which is hard, probably harder than you think if you’ve never had to do it. There’s a tendency to approach pricing from the perspective of how much the solution cost *you*--it took two engineers six months to make this, running it costs so much, so we’ll price it at X. That’s only useful in establishing a floor. The better way to look at it is, how much value is this providing the customer, and this question helps get at that.
- Perguntas vagas são como perguntas sim/não, elas param. “Então, você acha que usaria um aplicativo que melhorasse o e-mail?” Claro que sim. Melhor: “Você pode descrever a maior dor de cabeça que você tem relacionado ao e-mail?” Você centrado: “Eu construí este ótimo aplicativo de e-mail que eu acho que vai ajudar a gerenciar seu e-mail muito melhor, e ele usa AI e é incrível. Gosta?” Você não vai aprender com isso.
- “Thanks honey, that looks just like daddy!”
- This may get your subject to tell a story. You can see how your proposed solution lines up with what people are doing in the real world.
- A variation of the “If you had a magic wand and could have any solution, what would it be?” Better once you’ve started getting into more details about their problem—asked too early or too generally, you may get wishy-washy responses that aren’t very enlightening.
- The kicker? Who else should I talk to. You need to hear enough voices to start seeing patterns, and people with a problem often know other people with similar problems. Especially if you’re coming from outside an industry or domain, referrals are a great way to hear more voices from inside it.
- Hard to be a good listener if you’re furiously typing or scribbling. Work as a team. One interview subject: if you’re talking to a pair or a group your subjects may be self conscious. Focus groups can be great, but are more useful down the road. Alvarez again: “The more interviews I did, the more I felt I could tell the difference between people who were trying to be nice and people who really had a problem that I could solve.” Have a script for opportunistic interviews Capture everything in a single place: Gdocs, Asana, whatever.
- Blank’s story about his Cal students. Pre-conceived notions and a too-strong attachment to their original idea prevented them from seeing a better opportunity. [ Blank’s anecdote about 47 yes’s for $9.99 and 3 people saying they’d pay $10k for something that would work for their business] Blank tells a story about a group of his students interviewing 50 people for a consumer product they were testing. 47 subjects were enthusiastic, and it was all high-fives. Blank asked them what the other three had said,
- Before you do anything, write a press release announcing the launch of the product you’re envisioning. We’ll talk about that a bit more in a moment, but you need to be able to articulate your offering and the value it provides. If you can’t, it’s a red flag. Buy ads for your non-existent product on target them at your demographic, see what kind of click-through rate you get. Send people to a landing page with prices, see if anyone clicks on those. Offer a form to be put on a launch list, see how many people sign up. Conference freeloading: Go to conferences without necessarily buying a ticket for the event. Hover in the lobby buttonholing people to interview Interviewing for solution feedback? Draw screenshots on 8.5 x 11 sheets and walk interviewees through them, illustrating common paths. Simple B&W wireframes can avoid subjective interference based on reaction to something superficial like a palette. Show some hustle and do cold outreach. Be polite and to the point, make a modest ask for a short call or coffee meeting, and it’s amazing how helpful many people will be.
- Customer development isn’t a silver bullet--there are no silver bullets. It will improve your odds, but you’re still operating on limited information. Despite that, you need to make decisions and move quickly. One way to encourage that is understanding when you’re facing a two way door—a decision that can be reversed with low cost. Don’t hesitate to move quickly when the cost of being wrong is low. Related to that, you have to expect to get things wrong initially, and maybe repeatedly. The problem isn’t getting it wrong, it’s persisting in your wrongness. Doing low-risk research and experiments is intended to let you try out multiple doors—the *expectation* is that many won’t work out. So if the it looks like you’re barking up the wrong tree, believe it and move on. The sunk cost fallacy is when you continue to do something because you’ve already invested effort, despite signs that you shouldn’t. With startups this can manifest as an over-valuation of early engineering. A motto that will server you well: have strong opinions, loosely held. And lastly, ‘lean’ may have become a buzzword, but if you’re going to bother with these techniques, don’t just interview three of your friends and pronounce yourself agile. You’ll get more out of it with work and thought.
- So how do you know you’re done? We’re doing research and experiments, but the truth is we’re operating with imperfect information and this will be as much art as science. Alvarez says “The best indicator that you’re done is that you stop hearing people say things that surprise you.” The answer will also depend on where you are on the $7 to $1.4B continuum, and what the cost of building is. If you’re able to crank out quick prototypes in a week’s time and don’t get too attached to them, start building earlier, keep talking to people, and stay willing to learn from what you hear. Questions you should be able to answer: Have you discovered a meaningful problem you can solve? What kind of pricing signals do you see? What’s it costing people not to solve it? Will you product solve them How much are they currently paying, in both time and money, to solve it? Even better, how much are they losing due to not having solved it? The best way to know if someone will pay for your solution is if they actually try to pay. Or instead of asking them if they’d pay, ask them to actually pay—consider asking for pre-orders.
- If it doesn’t validate, make changes based on what you learned, and do more discovery!
- It is far easier to sell to someone who is aware that they have a need. It is easier still to sell to someone who is already actively looking for a solution, but has not yet found a perfect fit.
- AWS services are built by fast-moving, independent, and relatively small teams, and many of the techniques we’ve adopted can be used effectively at any scale, so .let’s take a look at a few
- This should be table stakes, but weirdly, it isn’t always. You should focus on your customer and their needs, in a positive way. I suppose you could go through a customer development process while still thinking your customer was a sucker, but you’ll learn more and be happier if you treat your customers or would-be customers with understanding and empathy. An obsession with your customers will go a long way towards helping you focus on their challenges and needs, rather than your own..
- The PRFAQ is a tool to improve the clarity of your problem and solution. Imagine you’re about to launch your solution, and write a one-page press release for it If you can’t succinctly explain what you’re doing, and why, to someone else, you probably don’t understand it well enough yourself. Back it with a FAQ to be able to answer anticipated questions and objections, and better understand the details. Writing refines your thinking It helps define the MVP, and can even act as a sort of spec
- --==[WHAT TO SAY]==-- As my team helps customers build a culture of innovation, some of the work we do involves helping customer teams develop a deeply empathetic relationship with their customers using a process we call Working Backwards. This is exactly the same process that we use inside of Amazon to invent everything from AWS itself, to products like the Kindle and everything in between. The working backwards process starts with the customer problem or opportunity, and we diverge on many possible solutions, filtering and pruning and critically examining ideas as we move forward. And then we select one idea, and build a press release set 3 years in the future that addresses 5 key questions. Who is the customer? What is the customer problem or opportunity? Is the most important customer benefit clear? How do you know what customers need or want? What does the customer experience look like? By positioning teams 3 years into the future, we pull them away from current constraints so they’re not worried about the problems of today, but don’t push them so far that they’re talking about the Star Trek Replicator as a solution. Each press release is accompanied by a set of frequently asked questions that customers may have about the product or service (e.g., how do I get started, where is it available, can I use this on my Kindle Fire tablet and so on). This exercise forces teams to think deeply about their solution, and to collect data to support their assertions, which reduces the risk of building the wrong thing. If you think this seems like an awful lot of work. You would be 100% correct. In fact, at an internal meeting, an employee asked Jeff Bezos if we always have to do this because it seems like an awful lot of work. He replied, “Done correctly, it’s an enormous amount of work, but much less than forming a team, building a product, launching it into the market, and then discovering customers don’t want.” Credit: Photo by Johannes Plenio on Unsplash
- Out of curiosity, do you know what the image on the slide is? Actually it is the very first MVP of the mouse at Zerox Parc. Do you think Xerox marketed this in computer peripherals shops? Of course not. This was an MVP. This was not the product with the fewest number of features. Instead, this was an experiment that tested a hypothesis about how users wanted to interact with their computers. In fact, this experiment cost 35 cents and took 7 hours to go from hypothesis to experiment, which is very typical of MVP – fast, cheap, and lots of iterations. But I want to press your assumptions one step further. This mouse is a physical prototype, so it is easy to think of it as a product. However, remember MVP is the process of experimentation. It is not about tangible things. A prototype could be a form of experimentation, but it does not have to be!
- I am sure you all know the company, Instagram. Very early on, Instagram had this hypothesis about the market that tourists would love if their tourist pictures were beautifully photoshopped. However, they did not have the skills or money to do it. So did they go out, raise 10 million investor dollars and build a functional product only to discover that real people didn’t want what they built? No? Instead, the founders took their laptops down to central park in New York and went up to tourists and asked them if they would like some real-time shopping. Of course, many tourists were quite keen and the founders manually shopped all the photos and helped the customer upload to social media. And that went on for a couple of weeks through thousands of snapshots. I am sure the work was laborious, but it was very fast and very free. In the process the founders confirmed their initial hypothesis. However, they also confirmed and rejected several other hypotheses about what filters customers were most keen to have. They tried hundreds of different Photoshop filters - blurred, sharp, high contrast, black and white etc. And they learned which filters the tourist loved most. Did the Instagram founders know which were going to be the 3 most popular flters when they started? No! Did those customers know whether they liked black and white, blurred or high contrast before they were asked? No! Frankly, they didn’t even know what the possible filters were, since they were not designers. However, through this concierge MVP process, the Instagram founders were able to determine what the customers wanted. I want to emphasize here that there was no physical prototype, even a 35 cent mouse. It was just people with hypotheses and laptops experimenting manually. I’d like to give you one more example, just to drive home this message that an MVP is not a “thing”. Specifically, I’d like to tell you a story about one of our regional multinational hotel clients. The CEO for this enterprise has a policy that whenever he travels, he will stay at the hotels of his competitors to stay sharp. So this CEO told me about his visit to HK in 2013. Like usual, he grabbed a taxi at the airport. He had a friendly taxi driver who chatted with him for the first 10 minutes or so. Typical HK banter. Anyway, he reached the hotel and as he was exiting the cab, the doorman said, “Hello Mr X, welcome to Hotel Y”. The CEO thought to himself how strange it was that the doorman should know him by name, but since he’d been there before, he thought it was just one really sharp doorman. But it kept going. As he walked in through the main doors, other staff greeted him by name. And by the time he reached the counter, his reservation was up and all he needed to do was sign and go. He was amazed and the minute he hit his room, he called his CIO, recounted this customer experience and told the CIO to make it so for his chain. Anyway, cut to 13 months and over 20M budget later, it was a total flop, The CIO came back and said that they simply could not get this kind’ve CRM system working. It was a good story for the CIO though. Don’t worry, he kept his job. But the CEO was demoralized nonetheless. Anyway, so it turned out that he was again in HK and so he went back to that hotel. And what do you know? The same thing happened again. So he was standing in the taxi rank looking around and asking the door man, “I just don’t get it? How do you know who I am? Where are the cameras and how are you managing the image recognition and hook up into your customer database! And the doorman laughed and said, “Nothing like that. I pay the cab driver $3 every time he gives me the name of an incoming guest. So when you told him you were coming here, he got your name and SMS’d it to me.” So there you go. No product. No technology. No million dollar budgets.
- --==[WHAT TO SAY]==-- Now, we have collected the data we need to and we can move forward. Sometimes that will means walking away from an idea because the experiment showed that customers aren’t interested. Sometimes, however, you’ll get the data you need to finish that press release and FAQ, quantify a clear benefit and describe the initial customer experience. And, the best news is that the technology you’ve used to conduct the simple experiments is the very same technology you can scale up to serve the most demanding, globally distributed customer base for your big idea. Credit: Photo by Federico Beccari on Unsplash
- This one is a true startup door, it’s not only two-way, but it pivots :-) Don’t spend hour agonizing over Times New Roman vs Helvetica. Do pause a bit before writing Bechtel a check for $1 billion.
- --==[WHAT TO SAY]==-- We talked about WHY innovation is important, touched upon the way Amazon thinks about and deliverers it, and covered ways you can use AWS to support innovative, hypothesis-driven development.