Concrete Logo
Hamburger button

Aprendizados SVPG – Parte 1: DJux

  • Blog
  • 22 de Janeiro de 2014
Share

Participei na última semana do workshop “How to Create Products Customer Love”, ministrado pelo fundador do Silicon Valley Product Group, Marty Cagan. Percebi que alguns dos conceitos definidos lá já foram utilizados por nós em diversos momentos aqui na Concrete Solutions, e decidi escrever uma série de posts para compartilhar nosso aprendizado com exemplos práticos.

Para começar, vamos usar dois conceitos-chave utilizados pelo Marty no workshop: Customer Discovery e Product Discovery. A ideia do Customer Discovery é descobrir e desenvolver um grupo de clientes “referência” em paralelo com descobrir e desenvolver o produto. A definição está bastante próxima do customer development de Steve Blank, no qual você tem uma base de clientes/usuários efetivos ou em potencial que você aborda sistematicamente para saber se suas ideias são válidas de alguma forma, se são problemas que valem a pena serem resolvidos ou novas “dores” relacionadas ao seu produto.

customer-discovery

O Product Discovery, por sua vez, vem em seguida: uma vez que já temos as informações sobre os problemas e necessidades dos nossos clientes, definimos o mínimo produto viável e/ou criamos um protótipo, executando testes consecutivos para validar o conceito. É a partir daí que determinamos o conjunto de características e interações e definimos qual produto vamos colocar no backlog para que o time construa.

binóculos

Os dois são similares, mas um é mais focado no domínio do problema (Customer Discovery) e outro no domínio da solução (Product Discovery). Visto isso, vamos passar para um exemplo prático de como podemos usar esses conceitos.

DJux

Há algum tempo, aconteceu em São Paulo a primeira edição do Lean Startup Machine, que tem por objetivo ajudar a espalhar pelo mundo a abordagem Lean Startup. Em um workshop de 2 dias, hands on, os participantes precisam conceber, validar e invalidar diversas ideias com potencial de virar um negócio sustentável. O mantra é “fail fast, succeed faster”.

LSM

Funciona mais ou menos da seguinte forma: os participantes são divididos em dois grupos, os que possuem uma ideia de negócio e os que não possuem. Um a um, os que possuem ideias de negócio fazem o seu pitch, e no final os ouvintes, que não têm ideias, escolhem qual “startup” querem participar durante o workshop.

Éramos dois representantes da Concrete Solutions, Rafael Izidoro e eu. A ideia de negócio era do Rafael e havia surgido no almoço do dia anterior: fazer um aplicativo (sim, mais um) para controlar o som ambiente. Nosso pitch foi calcado em “revolucionar a forma como as pessoas escolhem as músicas dos ambientes onde elas se encontram”. Conseguimos recrutar mais três pessoas para nossa startup e começamos.

Primeiro, concebemos o canvas de modelo de negócios e encaramos o problema de um ponto de vista intelectualmente honesto: qual é o problema que um aplicativo desse tipo resolve? Por que alguém usaria esse tipo de app? Qual é o tamanho desse mercado? Ou melhor, existe um mercado?

Dividimos o time em duplas e fomos para shopping centers, bares e outros estabelecimentos da cidade para validar se as pessoas realmente queriam controlar o som do ambiente à sua volta. Afinal de contas, não existem tantas jukebox espalhadas pelo Brasil afora, existem?

Jukebox Illustration

Após validações e invalidações de algumas hipóteses, descobrimos que apesar de ser um problema relativamente pequeno, haviam algumas ocasiões em que as pessoas de fato gostariam de ter a possibilidade de mudar o som do ambiente à sua volta. A questão, agora, era saber o quanto, ou ainda se elas estariam dispostas a pagar por isso.

Para isso, montamos um experimento, que tinha que ser algo pequeno o suficiente para gerar valor (e validar a ideia), mas que não demorasse para ser construído. Como já tínhamos o bias de construir um aplicativo, teríamos também que decidir se faríamos para a plataforma iOS ou Android. Neste ponto, alguém sugeriu fazermos em html/css/js, usando jquery-mobile. Assim, as pessoas usariam os navegadores dos seus celulares para acessar o serviço. Menos um problema, já começariamos sendo multiplataforma.

Logo que começamos a conceber o protótipo, tivemos que lidar com o problema da galeria de músicas que usaríamos. Tivemos a sorte de contar com um HD cheio de músicas, o que poderia suprir a nossa demanda por vários estilos musicais e artistas, e seguimos no caminho em que uma aplicação Django apresentaria o html/css/js da app e o usuário escolheria, a partir de uma lista de músicas, qual ele gostaria de pagar para ouvir.

Isso tudo fazia algum sentido, mas a coisa começou a ficar maior do que queríamos, pois desde o início teríamos que lidar com o servidor plugado no som ambiente e executando um mp3,  listando os artistas/músicas no cliente, com a interface do cliente apresentando essa informação e a enviando de volta para o servidor, para só então ser executada. E o pior: nenhum desses detalhes era realmente imprescindível para validarmos se as pessoas pagariam ou não para tocar uma música no ambiente pelo celular. Tinha que existir um caminho mais rápido.

mvp

A solução que o time encontrou foi a seguinte: primeiro, o problema do acervo de músicas. É uma felicidade que hoje em dia podemos contar com um acervo quase infinito de músicas na internet e de graça, seja usando um serviço como o Grooveshark ou simplesmente dando um play em um vídeo no Youtube. Decidimos, então, que em vez de usarmos um acervo de mp3 usaríamos o Youtube. Com a essa decisão, o nosso protótipo não precisava mais exibir uma lista de músicas, apenas um campo de texto no qual o usuário digitaria o nome da música (como se estivesse buscando no Youtube) e apertaria um botão “tocar”.

O segundo problema que precisávamos resolver era como fazer para as músicas serem tocadas de fato no ambiente. Por sorte, o evento possuía um sistema de caixa de som, e pedimos permissão para plugar as caixas no MacBook que estávamos usando como servidor. A aplicação Django simplesmente apresentava o html/css/js específico para mobile com um campo de texto que, quando o usuário digitava o nome do artista e música, o servidor recebia um post de volta com essas informações. Nesse ponto, de novo, tivemos que nos ater ao problema que queríamos validar, em vez da implementação correta, caso o produto fosse para frente.

Ao invés de integrarmos o servidor com o Youtube/Grooveshark de alguma forma automática (dessa forma teríamos que lidar com diversos casos de borda – músicas inexistentes, falhas de conexão, fila, etc.), nós decidimos não integrar, pura e simplesmente. Cada post que chegava ao servidor era exibido em modo Debug no console da aplicação, rodando direto pelo servidor built-in do Django. Alguém ficava sentado em frente ao computador esperando os posts aparecerem e, quando chegasse uma música, o operador simplesmente copiava o nome do artista/musica, abria uma aba do navegador no Youtube, buscava a música e dava play. Voila!!!

music

O terceiro problema era como fazer os pagamentos, e para esse a solução foi mais simples. Ao invés de implementarmos algum sistema maquiavélico de pagamento, simplesmente sentávamos do lado da pessoa com a qual iríamos mostrar o protótipo, perguntávamos se ela tinha celular e, se sim, se ela gostaria de escolher a próxima música que tocaria no evento. Também destacávamos que podia ser qualquer uma, mas que a pessoa teria que entrar pelo celular dela no endereço no qual estava o webapp, digitar o nome da música e apertar “tocar”. Antes disso, nós avisávamos que era cobrada uma taxa de R$0,10 por música escolhida, e que o pagamento podia ser feito em pessoa. Simples, não?

Resultado

Conseguimos arrecadar cerca de R$6,00 ao longo de duas horas, e o protótipo inteiro demorou algo em torno de 1 hora para ficar pronto. Independente de entrarmos no mérito se é uma ideia boa ou não, se é um mercado bom ou não, ou ainda se vale a pena entrar nessa para brigar, o ponto é que conseguimos validar parte do problema e ainda ganhar dinheiro de verdade com a ideia em um espaço menor do que 24 horas. É exatamente esse é o espírito do Discovery, seja ele Product Discovery ou Customer Discovery.

Update: Saiba mais sobre o que fizemos no Comprafácil na segunda parte desta série.