Warning: ob_start(): non-static method wpGoogleAnalytics::get_links() should not be called statically in /home/ericnsantos/manualdastartup.com.br/blog/wp-content/plugins/wp-google-analytics/wp-google-analytics.php on line 259

Warning: Cannot modify header information - headers already sent by (output started at /home/ericnsantos/manualdastartup.com.br/blog/wp-content/plugins/wp-google-analytics/wp-google-analytics.php:259) in /home/ericnsantos/manualdastartup.com.br/blog/wp-includes/feed-rss2.php on line 8
Manual da Startup » Eventos http://www.manualdastartup.com.br/blog Práticas sobre Lean Startups, Customer Development e empreendedorismo em geral Thu, 12 Apr 2012 16:08:11 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Prêmio RBS de Empreendedorismo e Inovação http://www.manualdastartup.com.br/blog/premio-rbs-de-empreendedorismo-e-inovacao/ http://www.manualdastartup.com.br/blog/premio-rbs-de-empreendedorismo-e-inovacao/#comments Thu, 25 Aug 2011 17:04:53 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=679

Clayton Christensen, no seu clássico livro The Innovator’s Dilemma, discutiu como as inovações disruptivas quase nunca surgem de empresas grandes e consolidadas em seu mercado (incumbents). Para quem ainda não leu recomendo fortemente o livro, mas de qualquer forma separei um trecho de um resumão que achei aqui:

Disruptive technologies or innovations are innovations that upset the existing “order of things” in a particular industry. The usual process is a lower-end innovation that appeals to customers who are not served by the current market. With time, because the capacity/performance of the innovation exceeds the market’s needs, the innovation comes to displace the market incumbents.

Incumbents generally don’t react to disruptive innovations until it’s too late, because they don’t represent an interesting market, being low end and often low cost. One successful strategy might be to hive off a separate “company within a company” that is responsible for the firm’s response to the disruptive technology. A smaller, more nimble organization is better placed to work in the initially smaller and less lucrative market that the innovation is creating.

Bom, e o que isso tem a ver com o título do post?

Estamos começando a ver aqui no Brasil um movimento que já é bem mais comum nos EUA: empresas incumbents tentando participar de forma mais ativa no estágio inicial da inovação através da aproximação de Startups com potencial. Entre outros exemplos, tivemos o recente “Sua ideia vale 1 milhão” do Buscapé.

A mais nova iniciativa nesta linha é da RBS em parceria com a SixPix, ao lançar o Prêmio RBS de empreendedorismo e inovação: um concurso para Startups “digitais” (áreas web, mobile, aplicativos, mídia e conteúdo, mídias sociais e transacional), com R$ 100mil em prêmios a serem distribuídos aos times vencedores. Mais infos e regulamento no próprio site.

Prêmio RBS

Além disso, acontecerão Meetups em quatro cidades do Brasil: Florianópolis, Porto Alegre, São Paulo e Recife (datas e locais aqui). Estarei em um dos painéis do Meetup de Floripa, que acontece nesta próxima terça.

Para os empreendedores, além da possibilidade de ganhar o prêmio, participar de competições deste tipo pode ser uma ótima forma de aprender mais e refinar a estratégia do próprio negócio. Já sobre a possibilidade de futura parceria/sociedade com essas empresas maiores, não diria que é um “no-brainer”. Leia a bula antes. :P

Aos que forem participar, boa sorte!

]]>
http://www.manualdastartup.com.br/blog/premio-rbs-de-empreendedorismo-e-inovacao/feed/ 1
Quotes da SLLConf 2011 http://www.manualdastartup.com.br/blog/quotes-da-sllconf-2011/ http://www.manualdastartup.com.br/blog/quotes-da-sllconf-2011/#comments Tue, 24 May 2011 14:57:36 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=626

Como todos já devem estar sabendo, ontem aconteceu a edição 2011 da Startup Lessons Learned Conference (SLLConf).

Assim como no ano passado, aos poucos farei observações em detalhes sobre algumas palestras, mas para aproveitar o embalo fiz a compilação de alguns ótimos quotes que foram ditos pelos palestrantes ao longo do dia. Seguem abaixo:

“It’s no longer “Can we build it?”. We gotta ask ourselves “Should we build it?”" – Eric Ries

“Better to have bad news that’s true than good news we made up” – Eric Ries

“If you succeed, you are more likely to fail next time unless you self-correct” – Mitch Kapor

“The capacity for self-delusion is infinite” – Mitch Kapor

“I don’t like self-funded companies. It’s too easy to make excuses about why things are not going well.” – Mitch Kapor

“You must be high if you think entrepreneurship makes financial sense. But money isn’t everything.” – David Binetti

“Why Lean? It mitigates your own reality distortion field.” – David Binetti

“Why Lean? It helps you convert Market Risk into Technical Risk” – David Binetti

“PR and vanity metrics give the illusion of progress.” – David Binetti

“The answer is not on your whiteboard. Go talk to customers.” – David Binetti

“You can’t A/B test your way to a successful business” – David Binetti

“Continuous deployment doesn’t mean our product changes 30 times a day, it means we can be responsive.” – Pascal-Louis Perez

“Do not create a company culture where it’s a contest of who can create the best PowerPoint.” Brad Smith

“If you don’t have innovation coming out of your company, look in the mirror. It’s you.” – Brad Smith

“Build just in time, not just in case” – Brad Smith

“Teams no bigger than two pizzas can feed” – Brad Smith

“Worst management philosophy is a genius with a thousand Helpers” – Brad Smith

“It’s easy to quickly get grandiose ideas, important to work with most basic version” – Manuel Rosso

“People don’t care if you support everything, they care that you support what THEY use” – Manuel Rosso

“When you’re interacting with users and you can anticipate what they are about to say, it’s time to move on” – Manuel Rosso

“The main responsibility of person doing 5 why’s is educating” – Roy Bahat

“Adoration of your peers is not product-market fit.” – Adam Wiggins

“Not sure if you’re near product-market fit? Are you trending towards it or improving less and less and less…” – Eric Ries

“Pretty pixels are important but not sufficient” – Janice Fraser

“Prove <-> Improve. Test <-> invest.” – Janice Fraser

“Test in pennies, scale in dollars.” – Janice Fraser

“(in the old days) We would test to make sure [our waterfall product] was going well, and if it wasn’t, we’d launch anyways” – Jeff Gothelf

“Human to human communication always beats paper to human communication” – Jeff Gothelf

“Startups that pivot 1 or 2 times raise more money, have more users, than companies who don’t pivot or pivot more often.” – Steve Blank

“Essentials of how to do a startup do not include writing a business plan” – Steve Blank

“Good VCs have 50 to 100x more pattern recognition than entrepreneurs” – Steve Blank

“Good boards ask hard questions.” – Steve Blank

“What should matter is metrics and how I am progressing in search for business model.” – Steve Blank

“Find great people, and then get out of the way.” – Drew Houston

“Although we’ve read the bible, sometimes it’s hard to go to church.” – Drew Houston

“Figuring out what your customers want is your job, not theirs.” – Drew Houston

“Your customer is not your user” – Clara Shih

“Copernicus and Galileo were persecuted for scientific findings. It has to be OK to share good AND bad news in your company.” – James Birchler

“Arguing over a decision in your company? Run an experiment on your customers and prove it.” – James Birchler

“A/B testing without consulting the overall vision leads to muddled, ineffective products.” – James Birchler

“What’s the problem we’re trying to solve? What does success look like? How do we fail?” – Suneel Gupta

“MVP is not an excuse to think small” – Suneel Gupta

 

]]>
http://www.manualdastartup.com.br/blog/quotes-da-sllconf-2011/feed/ 4
Simulcasts da SLLConf 2011 no Brasil http://www.manualdastartup.com.br/blog/simulcasts-da-sllconf-2011-no-brasil/ http://www.manualdastartup.com.br/blog/simulcasts-da-sllconf-2011-no-brasil/#comments Tue, 17 May 2011 17:07:58 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=616

Para quem não conhece, a Startup Lessons Learned Conference (SLLConf) é a principal conferência em torno do movimento de Lean Startups, organizada pelo Eric Ries. Nesta próxima segunda-feira, dia 23/05, acontecerá a segunda edição da conferência em San Francisco.

No ano passado o conteúdo das palestras foi excelente, com estudos de caso, painéis e palestras memoráveis, como por exemplo as do Steve Blank e Kent Beck. Para quem não acompanhou, na época fiz um review das principais palestras com observações complementares. A lista dos posts está aqui: http://bit.ly/SLLConf2010.

Neste ano, a organização do evento novamente liberou a transmissão simultânea da conferência para alguns grupos em diversas cidades do mundo, e o Brasil também está bem representado.

Se no ano passado eram apenas Florianópolis e Belo Horizonte, neste ano vamos ter Simulcasts em 8 cidades, todas organizadas por grupos de empreendedores locais e com o apoio da Aceleradora. Seguem os links das páginas de inscrição que já estão disponíveis.

Para fechar o convite, deixo o flyer do nosso evento em Floripa que também contém a programação da Conferência.

Floripa Startups 2011

 

 

 

 

 

]]>
http://www.manualdastartup.com.br/blog/simulcasts-da-sllconf-2011-no-brasil/feed/ 0
O que o Dave McClure ensinou no Geeks on a Plane – BRNewTech http://www.manualdastartup.com.br/blog/o-que-o-dave-mcclure-ensinou-no-geeks-on-a-plane-brnewtech/ http://www.manualdastartup.com.br/blog/o-que-o-dave-mcclure-ensinou-no-geeks-on-a-plane-brnewtech/#comments Thu, 05 May 2011 18:37:35 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=579

Creio que todo mundo já saiba que a gangue do Geeks on a Plane passou pelo Brazil nos últimos dias. Na agenda de São Paulo, entre diversas outras coisas (incluindo até um passeio no Pacaembu para o tranquilo Corinthians x Palmeiras), eles fizeram parte de dois eventos muito bacanas que aconteceram no final de semana.

No sábado à noite, o Startupi junto com a ResultsOn e o Pto de Contato organizaram um happy hour entre os Geeks e alguns empreendedores/investidores da comunidade brasileira. Veja mais sobre o encontro aqui.  

Já no dia seguinte foi a vez da edição especial do BRNewTech, com uma agenda cheia de palestras e painéis, além do também ótimo networking.   (novamente, agradecimentos especiais aos organizadores!) Para abrir a agenda do domingo, Dave McClure apresentou a sua tradicional palestra “Startup Metrics for Pirates”. Compartilho abaixo o vídeo e os slides da sua palestra, junto com algumas passagens que eu fiz questão de separar. Mesmo para quem já conhece o AARRR, vale a pena conferir pelos rápidos e bons insights que ele vai colocando ao longo da sua fala.



Quotes
“Entretenimento significa retenção”

“O cliente é a parte mais importante de tudo, e Geeks geralmente não falam com os clientes.”

“Lean Startup não tem nada a ver com Startup barata.”

“Em uma Startup, não se mede progresso pelo número de features implementadas. Progresso = pessoas contentes.”

“Para saber se houve progresso, meça. (Essa features que acabei de lançaram melhoraram ou pioraram o comportamento dos usuários?)”

“Antes do Product/Market Fit, você está testando, tentando descobrir o modelo de negócio. Só depois disso a sua mentalidade muda para acelerar o crescimento.”

“A parte mais importante das Lean Startups são o mecanismo de feedback. Construa isso o quanto antes”

“Como saber se algo melhorou a vida dos usuários? Que tal conversar com eles? Feedback qualitativo também é importante.”

“Quando você lança o seu produto? Quando os clientes gostam a ponto de recomendá-lo para outras pessoas.”

“As melhores métricas são as que estão no meio do funil, as taxas de conversão intermediárias.”

“Aquisição é o primeiro item do AARRR, mas não é por lá que se deve começar a otimizar. Quem deve vir primeiro é Ativação e Retenção. Faça um bom produto antes de tudo.”

“Principal papel do CEO: definir quais métricas são realmente importantes. Fazer com que toda a empresa trabalhe focada para melhorar essas métricas, uma de cada vez preferencialmente.”

“Se você conhece o que traz dor ou prazer para o cliente, você já está na metade do caminho de construir um bom produto.”

“No primeiro momento que você lança o produto, geralmente você tem coisas demais nele (features, call-to-actions, etc.), e aí os usuários não sabem o que eles devem fazer no site. Descubra qual é a coisa mais importante para eles.”

“Via de regra, a taxa de conversão cai a cada feature adicionada ao produto.”

“Assuma riscos. Deixe os clientes p…. Você tem que achar as pessoas que amam o seu produto, mas aquelas que o odeiam também são boas. Elas falam para você porque o seu produto é ruim. A indiferença é a pior coisa que uma Startup pode ter.”

“Saiba quando o produto está bom o suficiente, e então foque os recursos para escalar marketing e aquisição de clientes (de preferência de forma lucrativa).

“Otimização não é um objetivo por si só. É apenas um processo para conduzir progressos incrementais. Tome cuidado com o problema da máxima local. Às vezes é preciso um salto arriscado para descobrir um novo modelo de negócio muito melhor.”

“Testes no Adwords são uma ótima forma de entender as intenções e vocabulário dos clientes. Use muito isso combinado com variações de Landing Pages (textos, imagens, etc.) para testar reações à oferta.”

“A beleza da Internet é que, quanto maior ela fica, menor você pode ficar. Escolher um nicho específico e segmentar a oferta e a mensagem é uma estratégia fundamental em mercados já ocupados por outros players.”

“Após Product/Market Fit, faça de tudo para entender Custo de Aquisição e Lifetime Value do cliente.”

]]>
http://www.manualdastartup.com.br/blog/o-que-o-dave-mcclure-ensinou-no-geeks-on-a-plane-brnewtech/feed/ 2
Eventos para Startups em Novembro http://www.manualdastartup.com.br/blog/eventos-para-startups-em-novembro/ http://www.manualdastartup.com.br/blog/eventos-para-startups-em-novembro/#comments Mon, 08 Nov 2010 19:07:18 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=462

Aqui no Brasil temos o costume de reclamar (e com uma boa dose de razão) de que o ecossistema de Startups é fraco. Tomemos como exemplo a excelente discussão neste post recente da Aceleradora.

No entanto, há muita gente que está trabalhando para que a situação toda melhore, e esse mês de Novembro está cheio de eventos para ajudar os empreendedores. Inspirado nessa agenda mais detalhada da ResultsOn, compartilho e adiciono outros itens. Para quem tiver a chance, vale muito a pena conferir e se envolver.

Dia 09/11  - Silicon Valley in Brazil em São Paulo.

Dias 15 a 21/11 – Semana Global de Empreendedorismo com agenda no Brasil todo.

Dias 16 a 19/11 – Empreende Floripa, dentro da agenda da Semana Global. (obs: no dia 17/11, farei uma apresentação sobre Lean Startups junto do painel de modelo de negócio)

Dia 17/11 – Tire do Papel e Startup Meetup em Campinas.

Dias 17 a 20/11 – Feira do Empreendedor SEBRAE em São Paulo.

Dias 19 a 21/11 – Startup Weekend em São Paulo.

Se alguém tiver mais algum evento bacana que ficou de fora dessa lista, por favor me enviem nos comentários.

Silicon Valley in Brazil
O Centro de Empreendedorismo e Novos Negócios da FGV e a BricChamber estão reunindo nomes de peso do mercado digital mundial em um evento muito bacana que estamos apoiando. Entre os convidados, nomes como Aber Withcomb (co-fundador do Myspace), Jawed Karim (co-fundador do Youtube), Reinaldo Normand (fundador do Zeebo) e muito mais. Vai rolar no dia 9 de novembro no auditório da FGV e será realizado das 14h às 18h (mapa de acesso). As inscrições são gratuitas (e limitadas!) e podem ser feitas aqui.
Feira do Empreendedor
Entre 17 e 20 de novembro, em plena Semana Global, estaremos na Feira do Empreendedor 2010, organizada pelo SEBRAE-SP,  em uma ARENA LIVRE sobre empreendedorismo, competitividade, tendências e inovação. Tudo isso comandado por um convidados como Edney Souza, Luiz Algarra, René de Paula, Diego Remus e muito mais. A programação completa, você confere aqui.
Startup Weekend
O Startup Weekend vai acontecer em várias cidades do mundo simultaneamente, com a proposta de oferecer um final de semana de orientação e atividades para viabilizar a incubação de ideias e transformá-las em realidade. Entre os palestrantes, o evento já conta com Rafael Siqueira (Apontador), Salim Ismail (Singularity University) e Marc Nager (Startup Weekend). Ocorre de 19 a 21 de novembro, no Prédio da FIAP (veja acesso aqui). Para mais informações e detalhes sobre a programação e como garantir o seu ticket, basta acessar o site oficial.
]]>
http://www.manualdastartup.com.br/blog/eventos-para-startups-em-novembro/feed/ 3
Como a Flowtown usou MVPs e um Pivô para encontrar o seu modelo de negócio http://www.manualdastartup.com.br/blog/como-a-flowtown-usou-mvps-e-um-pivo-para-encontrar-o-seu-modelo-de-negocio/ http://www.manualdastartup.com.br/blog/como-a-flowtown-usou-mvps-e-um-pivo-para-encontrar-o-seu-modelo-de-negocio/#comments Thu, 27 May 2010 22:02:09 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=364

Seguindo com a série de posts da SLLConf, além do excelente case da Aardvark e da entrevista com o Randy Komisar (farei o review do seu livro aqui no blog), o bloco Measure da conferência também contou com a apresentação dos cases da Flowtown e KISSMetrics (esse último virá no próximo post).

Ambos foram ótimos exemplos da utilização de Pivôs – mudanças significativas no modelo de negócio – a partir de aprendizados validados com os clientes. Especialmente no caso da Flowtown, também foi possível perceber o quanto é poderoso o conceito do Minimum Viable Product (MVP). Seguem abaixo os videos, os slides e algumas observações sobre o case deles.

Flowtown

A Flowtown é uma Startup que nasceu com o objetivo maior de ajudar as PMEs a fazer Marketing na Internet. O primeiro produto escolhido para isso foi um Criador de Landing Pages, o qual eles passaram três meses construindo. Algumas semanas após o “lançamento”, tudo que eles conseguiram foi apenas um usuário pago e mais alguns na versão free, e claramente o produto não estava pegando tração. Depois de várias conversas e investigações com os usuários, eles decidiram descontinuar o produto e fazer o Pivô.

A segunda ideia era um produto que o cliente poderia inserir o email de alguém e coletar uma série de informações demográficas sobre aquela pessoa provenientes das redes sociais. Só que desta vez, ao invés de simplesmente construir o produto, eles passaram algumas semanas apenas fazendo testes de demanda com usuários, lançando mão de iterações com Smoke Tests e protótipos (mock-ups) de alta fidelidade. Somente quando eles já tinham 20 clientes que efetivamente quiseram pagar pelo produto que eles começaram a codificá-lo.

A figura abaixo mostra a evolução da receita da empresa a partir desse pivô.

Receita da Flowtown antes e depois do pivô

Receita da Flowtown antes e depois do pivô

Eles finalizaram a apresentação com algumas dicas gerais aprendidas com o processo:

- Tenha uma “Bullshit Bar” para cada iteração maior: um objetivo (métrica) claro definido para cada hipótese que está sob prova. Não continue avançando na mesma direção se esse objetivo não for atingido;
- Use e abuse dos protótipos. Coloque-os na mão dos usuário rapida e frequentemente;
- Faça quantos pivôs precisar, mas valide alguma coisa antes de mudar de direção. Não adianta ficar pulando de um lado para o outro sem evidências e aprendizado;
- Desde o dia zero, seu mindset deve ser: “fracassos vão acontecer”. Não se preocupe muito com os usuários atuais se tiver que fazer o pivô, a não ser que tenha efetivamente cobrado algo deles.
(obs. Essa é mais uma evidência de que não se deve antecipar a hora de cobrar pelo uso do produto. Comentei sobre esse timing no segundo post da série Freemium).

Por fim, eles deixaram um comentário sobre o quão brilhante foi o processo “Mágico de Oz” usado pela Aardvark para buscar validar o problema antes de implementar a solução.


]]>
http://www.manualdastartup.com.br/blog/como-a-flowtown-usou-mvps-e-um-pivo-para-encontrar-o-seu-modelo-de-negocio/feed/ 3
Como a Aardvark aplicou MVPs e Pivôs do início até a venda para o Google – notas da SLLConf http://www.manualdastartup.com.br/blog/como-a-aardvark-aplicou-mvps-e-pivos-do-inicio-ate-a-venda-para-o-google-notas-da-sllconf/ http://www.manualdastartup.com.br/blog/como-a-aardvark-aplicou-mvps-e-pivos-do-inicio-ate-a-venda-para-o-google-notas-da-sllconf/#comments Fri, 21 May 2010 15:00:36 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=353

Uma das palestras mais interessantes da SLLConf foi o estudo de caso da Aardvark, empresa de “Busca Social” que foi comprada pelo Google no início do ano. A Aardvark é um dos exemplos recentes de Startups bem sucedidas que aplicaram conscientemente os conceitos de Customer DevelopmentLean Startup.

A apresentação foi dividida em quatro partes: uma explicação conceitual do produto, os princípios adotados pela empresa desde o início, a história do produto e por fim o processo de desenvolvimento.

O Slide abaixo resume o conceito por trás do produto, que foi explicada em bem mais detalhes pelos fundadores.

Aardvark Social Search

Desde o início, os fundadores sabiam do Espaço em que queriam atuar (Social Search), mas não tinham uma ideia exata de qual seria a forma que o produto assumiria. Além disso, eles sabiam que as Startups não são “sucessos do dia para a noite”, e que a probabilidade de fracasso é muito grande. Parafraseando Mike Cassidy, “em uma Startup, a chance de qualquer coisa boa acontecer é sempre menor que 50%”.

Eles então definiram uma série de hipóteses e iniciaram a experimentação seguindo os princípios abaixo.

Princípios

- Minimizar risco (da catástrofe final: acabar o dinheiro)

- Maximizar os testes

- Ser paciente

A ideia central é mover através de blocos muitos pequenos, já que é impossível pular do zero para a perfeição. Sabendo que a maioria das experiências não vão dar certo mesmo, é importante olhar a “falha” como algo central para o aprendizado, tornando-a menos dolorosa para todos.

Histórico e lições aprendidas em cada etapa

Concepção

Duração: Meio ano
Feitos: Escolheram um problema, fizeram protótipos em série, abandonaram cinco ideias.
Aprendizados e dicas:
- Concentre seus esforços em um campo de atuação específico. Os pivôs devem ser extensões do aprendizado com a ideia anterior.
- Fique longe de ideias de produtos que tenham um componente visual muito forte e/ou baixa “latência” (demora muito para aprender algo). Escolha coisas em que se pode fazer protótipos e iterar com usuários de maneira muito rápida.

Implementação

Duração: Um ano
Feitos: Levantaram capital semente, implementaram o teste “Mágico de Oz”, recrutaram pessoas-chave (sobre esse teste, vale a pena ler este artigo)
Insight: “As pessoas estão usando e gostando dessa ideia do Aardvark (a sexta ideia implementada), mesmo nesse formato super rústico. Agora vale a pena continuar investindo no desenvolvimento, já que provavelmente eles gostarão ainda mais. Apesar da coisa toda ainda ser uma ilusão, pelo menos parece promissor agora”.
Aprendizados e dicas:
- Bons investidores estão muito mais interessados em apostar em algo que já mostrou que tem demanda mas que precisa ser melhor desenvolvido, do que investir em um produto “pronto” (tecnologicamente) mas que ainda precisa ser submetido ao teste do mercado.

Refinamento

Duração: Um ano
Feitos: Levantaram investimento Series A, estenderam o refinamento do produto, triplicaram o tamanho da equipe
Aprendizados e dicas:
- Testes qualitativos são essenciais para o refinamento do produto. (eles traziam semanalmente cerca de 20 pessoas para acompanhar os testes com protótipos de novas features)
- O objetivo é chegar ao Product/Market Fit ao longo do tempo. A preocupação maior não é “criar o produto certo desde o começo”, mas sim ficar melhor e melhor no processo de aprendizado com os usuários.
- Se você não tem um grande obstáculo interno (como um conflito com outro sócio, por exemplo), enquanto não acabar o dinheiro e você continuar melhorando a sua taxa de aprendizado, a tendência ao longo do tempo é você deixar os concorrentes para trás.
- Pense no desenvolvimento técnico do produto (engenharia) como um Hockey Stick. A evolução do produto (código) pode ser lenta por um bom tempo, e depois acelerada quando se conhece de fato o problema que se quer resolver.

Processo

Na Aardvark, o processo de design e desenvolvimento é a coisa mais importante para a empresa. Todos têm a responsabilidade de parar regularmente e discutir o resultado dos experimentos e aprender coletivamente. Para cada iteração, eles procuram identificar quais são as hipóteses-chave ou os problemas que estão incomodando mais e projetam uma solução para testar aquilo, buscando validar o design com usuários antes de investir recursos de engenharia na funcionalidade. O gráfico abaixo ilustra o ciclo de desenvolvimento de cada lote.

Processo de desenvolvimento Aardvark

Outras dicas gerais sobre o Processo da Aardvark:

- Faça a melhoria contínua do processo um dos objetivos da empresa;
- Faça experimentos no processo tanto quanto no produto;
- Contrate e doutrine as pessoas para apoiar o processo de desenvolvimento;
- Para cada novo problema, antes de tentar resolvê-lo defina a métrica para qual o sucesso será mensurado;
- Explore o aprendizado coletivo, tanto por parte dos funcionários quanto dos usuários do produto;
- Defina períodos de tempo regulares nos quais todos vão sentar e discutir sobre os aprendizados. Estimule o “confronto” sob pontos de vista diferentes;
- Seja transparente com todos stakeholders (investidores, funcionários, usuários, etc.).

Por fim, segue abaixo o video e os slides da palestra:

]]>
http://www.manualdastartup.com.br/blog/como-a-aardvark-aplicou-mvps-e-pivos-do-inicio-ate-a-venda-para-o-google-notas-da-sllconf/feed/ 6
Design vs. Métricas – notas do painel da SLLConf http://www.manualdastartup.com.br/blog/design-vs-metricas-notas-do-painel-da-sllconf/ http://www.manualdastartup.com.br/blog/design-vs-metricas-notas-do-painel-da-sllconf/#comments Fri, 14 May 2010 15:15:33 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=331

No final do primeiro bloco da Startup Lessons Learned Conference, tivemos a chance de acompanhar uma excelente discussão sobre o papel do Design em uma Startup e como ele se relaciona com uma postura de rigor e atenção com relação a Métricas.

Quem moderou o painel foi o Dave McClure, investidor e advisor de várias empresas conhecidas (ex. Bit.ly, Mint, SimpleHired, Slideshare, etc.) e completaram o painel pessoas não menos gabaritadas: Andrew Chen, Laura Klein, Siqi Chen e Rashmi Sinha.

Como o formato de painel é bastante difícil de se fazer um resumo em forma de narrativa, vou deixar abaixo algumas passagens interessantes de cada participante, bem como o vídeo e os links para os conteúdos relacionados.



Dave McClure

“Para Startups Web, Design geralmente é mais importante do que Engenharia”
(artigo relacionado: http://www.businessweek.com/innovate/content/jan2010/id20100120_303529.htm)
“Design não é sobre aparência. É sobre storytelling. O teste de um design é a resposta no cérebro de um usuário e as ações que ele toma”.
“Em uma Startup, há duas coisas que o empreendedor precisa trabalhar para otimizar: satisfação/felicidade do usuário e valor de negócio.”
“É melhor obter dos usuários uma reação extrema de amor ou ódio do que uma reação de indiferença. É mais fácil iterar sobre o ódio do que sobre a indiferença. No início, busque amplificar a magnitude dessa reação.”

Amor ou odio sobre o produto


“Uma boa parte do Design pode ser testada sem a necessidade de produção de código (palavras, imagens, call-to-actions, etc.)”
Lean Design significa buscar descobrir e testar a reação do seu produto nos usuários, e tentar descobrir mais e melhores formas de converter essa reação em felicidade do usuário ou valor de negócio.”


Pergunta para os painelistas: ” O que é Design?”


Andrew Chen
“Design é aplicar ao produto um conceito sobre o que você precisa fazer dado o seu objetivo de negócio no momento, mantendo uma User Experience consistente ao longo do produto”.


Rashmi Sinha
“Design é a maneira como você expressa sua visão de negócio. Por isso é difícil saber a diferença entre ótimo e  péssimo design (ex. eBay e Craigslist têm um design ruim?). Métricas são a maneira de mensurar se o Design está funcionando, ou seja, se você está caminhando em direção à sua visão de negócio”.
“Design Visual muitas vezes pode ser bem simples ou até ruim”.
“Otimização para uma métrica local às vezes pode causar danos à experiência geral do produto.”


Siqi Chen
“Quotando Steve Jobs: “Design is not about how something looks, but how something works.”"
“Métricas são muito importantes, mas não é possível criar uma ótima experiência de usuário (prazer, entretenimento, etc.) apenas com dados. No final, User Experience também é uma arte.”
“A hipótese inicial tem que ser criativa. Já a prova é analítica. Use métricas para comprovar suas hipóteses”.
“Métricas são excelentes para testar coisas que são tanto fáceis quanto rápidas de se mensurar. Para se chegar a outras coisas, a abordagem deve ser necessariamente através de bom Design.”
“Basicamente, não dá para fazer Split-Tests em qualquer coisa que dure mais de uma semana, a não ser que o seu produto não mude toda semana, o que já é uma má-ideia por si só.”


(vídeo complementar)



Andrew Chen
“Em uma Startup, você tem hipóteses em diferentes níveis do negócio. Mesmo que testes quantitativos sejam excelentes para várias situações, cuidado para não querer usá-los para tudo.”


Dave McClure
“Analytics e métricas podem te levar a um ponto máximo local. A criatividade tem um papel importante em ajudar a descobrir outros pontos de máximo não-locais.”


Laura Klein
“Há uma diferença entre Design de Interação e Design Visual. Design de interação tem a ver com fazer um produto que o usuário consiga entender e usar. Design Visual é para fazer um produto bonito. Ambos funcionam melhor juntos”.
“Foque no Design de Interação antes. Deixe o produto bonito depois. Ande sempre na direção de fazer o produto ficar mais fácil de ser usado.”


Andrew Chen
“Para muitas Startups Web, a otimização para o usuário vem antes da otimização para valor de negócio. Nesses casos, o Minimum Viable Product (MVP) toma a forma de Minimum Desirable Product (MDP).”
(artigo relacionado: http://andrewchenblog.com/2009/12/07/minimum-desirable-product/)

Minimum Desirable Product



“No início, a questão principal para o empreendedor é: Quanto de valor eu consigo gerar para as pessoas?. Otimização vem depois disso.”
“O que fazer primeiro: MVP, MDP ou MFP? Depende do tipo de negócio e dos objetivos do empreendedor.”


Laura Klein
“Coisas artísticas podem ser “mensuradas” qualitativamente. Use e abuse de mockups para testar a reação dos usuários. Coloque-os na frente das pessoas e assista o seu uso. Veja o que eles gostam e não gostam, no que eles reagem e no que eles não reagem. Tente entender os porquês depois.”
“Faça com o que o seu loop de feedback tenha tanto feedback qualitativo quanto quantitativo.”


Siqi Chen
“Trabalhe de forma obcecada para melhorar a experiência dos primeiros 5 minutos dos novos usuários. É isso que define se eles voltam ou não ao produto.”


Dave McClure
Falando sobre experiências de Design e Marketing com o Mint.com
“Eles estavam “atrasados” no mercado. Tinham ainda três meses para ter uma versão aceitável do produto e os concorrentes já tinham lançado. O que fizemos:
- Criamos um blog e começamos a criar conteúdo próprios ou de autores convidados sobre o assunto Gestão Financeira Pessoal.
- Muitos testes com links patrocinados (SEM) e Landing Pages. Os dados coletados serviam para realimentar o braço de produção de conteúdo.
Resultado:
- Mesmo antes do lançamento do produto eles já estavam com um ranking muito melhor do que os concorrentes nos termos de busca mais importantes.
- Mais de 10.000 usuários cadastrados para serem beta-testers antes do produto entrar em Beta. ”




Pergunta sobre testes com usuários de diferentes perfis:


Laura Klein
“Separar os usuários em diferentes perfis para testes qualitativos e quantitativos tem uma importância muito grande nas definições do marketing: segmentação, mensagem, etc.
Após um certo tempo, já é possível começar a “prever” quem vai gostar do produto e porque, e aí a geração de demanda se torna muito mais efetiva.”




Pergunta sobre o papel dos Designers e sua integração com o time de desenvolvimento


Laura Klein
Os designers têm que estar completamente integrados com a equipe de programação.


Dave McClure
Designers devem saber sobre qual é o objetivo (no nível tático ou de negócio) e trabalhar para alcançá-lo junto com a equipe.


Andrew Chen
De uma forma geral, a grande maioria dos desenvolvedores já “abraçaram” a ideia do Desenvolvimento Ágil, mas muitos designers – especialmente os provenientes de agências – ainda não. Eles tendem a guardar o trabalho e só mostrá-lo quando sentem que está muito bom. Isso é extremamente prejudicial em uma Startup.


Rashmi Sinha
“Nós só contratamos pessoas que já fizeram Design para produtos Web e estão acostumadas com os ciclos curtos de desenvolvimento. Garanta que eles saibam da parte técnica o suficiente para conseguirem conversar e interagir bem diretamente com os engenheiros/programadores.”




Observações finais do Dave McClure
“Quando você está começando sua Startup, o maior risco é de que os usuários não dêem a mínima para o seu produto. É por isso que é melhor buscar a otimização para uma reação de extremos – amor ou ódio.”
“Coloque o produto no ar e comece a iterar o quanto antes. Não se preocupe com a ideia de que “a primeira impressão é a que fica”. Mesmo que a experiência dos primeiros usuários seja ruim, a impressão deles sobre o produto não é irreversível, e  ainda assim eles representam uma parcela minúscula do público total potencial do produto.

Segue abaixo o video do painel:



]]>
http://www.manualdastartup.com.br/blog/design-vs-metricas-notas-do-painel-da-sllconf/feed/ 3
Palestras da Web 2.0 Expo SF 2010 http://www.manualdastartup.com.br/blog/palestras-da-web-2-0-expo-sf-2010/ http://www.manualdastartup.com.br/blog/palestras-da-web-2-0-expo-sf-2010/#comments Sat, 08 May 2010 21:17:04 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=322

Assisti hoje uma série de palestras e entrevistas da Web 2.0 Expo 2010 em San Francisco e selecionei algumas interessantes para compartilhar aqui no blog.

Ressalto o destaque que o tema Lean Startup teve na conferência desse ano. Depois de uma palestra dada pelo Eric Ries no passado em uma das sessões da extensa programação (palestra já reconhecida pelo próprio como a grande alavancagem do movimento), tanto Eric Ries quanto Steve Blank foram convidados para apresentar Keynotes no auditório principal do Moscone Center.  Os vídeos deles estão abaixo, junto com o excelente vídeo do Tim O´Reilly falando sobre o estado do “Sistema Operacional da Internet”, além de uma apresentação da Rashmi Sinha, do Slideshare (meio “merchan”, mas teve umas dicas relevantes), e de uma conversa com o Paul Buchheit, criador do Google Adsense, Gmail, Friendfeed e hoje responsável pela plataforma de desenvolvedores do Facebook.


Steve Blank

Eric Ries

Rashmi Sinha

Paul Buchheit

Tim O´Reilly




Ps. Momento “informação inútil”: No ano passado eu e o Miguel Cavalcanti tivemos o prazer de participar da conferência e especialmente de conhecer e bater um papo rápido com o Tim O´Reilly por lá.

Miguel e Eric com Tim O´Reilly

]]>
http://www.manualdastartup.com.br/blog/palestras-da-web-2-0-expo-sf-2010/feed/ 0
Continuous Deployment em uma Lean Startup – notas da palestra do Ash Maurya na SLLConf http://www.manualdastartup.com.br/blog/continuous-deployment-em-uma-lean-startup-notas-da-palestra-do-ash-maurya-na-sllconf/ http://www.manualdastartup.com.br/blog/continuous-deployment-em-uma-lean-startup-notas-da-palestra-do-ash-maurya-na-sllconf/#comments Fri, 07 May 2010 14:18:57 +0000 Eric Santos http://www.manualdastartup.com.br/blog/?p=313

Uma dos estudos de caso da SLLConf que eu esperava bastante era o do Ash Maurya, da WiredReach. Ash escreve ótimos posts em seu blog,  especialmente sobre práticas e aprendizados específicos da aplicação dos conceitos de Customer Development e Lean Startup no mais novo produto da sua empresa, chamado CloudFire.

Quando assisti ao vivo, achei que a apresentação ficou muito cheia, e consequentemente, corrida demais. Já quando vi pela segunda vez com mais calma, pude perceber uma série de ótimos insights escondidos nas entrelinhas dos slides. Faço a seguir o resumo e deixo no final o vídeo e os slides da apresentação.

Como maximizar o progresso em uma Lean Startup?

Ash começou a palestra relembrando a definição do Eric Ries sobre progresso em uma Startup: Aprendizado Validado sobre Clientes. Ou seja, para maximizar o progresso, temos que buscar maximizar o aprendizado ao longo do processo de desenvolvimento.

O problema é que muitas vezes o desenvolvimento do produto acaba “atrapalhando” o aprendizado. A figura abaixo mostra como isso acontece quando usamos processos tradicionais de desenvolvimento.

Onde ocorre o Aprendizado no processo tradicional de desenvolvimento

Onde ocorre o Aprendizado no processo tradicional de desenvolvimento

A ideia central do Continuous Deployment é minimizar o tempo gasto na parte intermediária deste ciclo, e consequentemente, aumentar a quantidade de aprendizado ao longo do processo.

Continuous Deployment diminuindo o tempo no ciclo de desenvolvimento

Continuous Deployment diminuindo o tempo no ciclo de desenvolvimento

O Antes e Depois da Aplicação de Continuous Deployment na WiredReach

Antes: Ciclos de desenvolvimento de duas semanas
Depois: Múltiplos releases todo dia

Antes: Área comum (centralizada) de testes pré-produção
Depois: Sandboxes individuais, possibilitando escalar a infraestrutura de desenvolvimento horizontalmente

Antes: Releases eram “eventos de um dia inteiro”
Depois: Releases não são “eventos”.
(Obs. Quando os releases vão para o ar, eles monitoram as métricas por algum tempo e revertem caso alguma coisa ruim aconteça. Há medidas automáticas e manuais para essa reversão.)

Antes: Tamanho médio de um Release – centenas de linhas de código
Depois: Tamanho médio de um Release – menos de 25 linhas de código

Antes: Mais Releases de emergência
Depois: Menos “apagar incêndio”

Antes: “Dias de Programação” vs. “Dias de Clientes” (atividades de Customer Development)
Depois: “Dias de Programação” E “Dias de Clientes” juntos
(Obs. Ash mencionou o artigo do Paul Graham: Maker´s Schedule, Manager´s Schedule.  Ele concentra suas atividades de programação nas horas iniciais da manhã, enquanto deixa as atividades de clientes e marketing para mais tarde. Para mais sobre esse assunto, recomendo a leitura desse post dele.)


Dicas para começar a implementar Continous Deployment

- A coisa mais importante: Dividir a programação em lotes muito pequenos (no caso dele, esse tamanho é definido como o resultado de 2 horas de programação);

- Fazer antes as modificações que não envolvam a interface com o usuário (banco de dados, APIs, etc.), diminuindo o risco geral de integração;

- Não tentar alcançar 100% de automação desde o início. Fazer o deploy manualmente primeiro, e depois ver o que vale a pena automatizar. Isso também ajuda a estabelecer confiança aos poucos na parte automática do processo;

- Monitorar o tempo do ciclo de Release;

- Esteja pronto para “parar a linha de produção” em caso de falha nos testes. Não subestime o fato de que os testes estão falhando, já que em pouco tempo eles serão a única linha de defesa do sistema;

- Construir, devagar e incrementalmente, um Cluster Immune System. (sobre isso, recomendo a leitura desse artigo do Eric Ries no Venture Hacks sobre Five Why´s e Immune System)

Como construir as Funcionalidades

Ash lembrou que Continuous Deployment ajuda na tarefa de diminuir o tempo em que uma funcionalidade é construída, mas não diz nada sobre quais são as funcionalidades certas para entrar em desenvolvimento. (o que lembra a proposição do Kent Beck para inverter a ordem do Loop da Startup para Learn->Measure->Build).

Para isso, na WiredReach eles criaram duas regras simples:

Regra #1: Não “empurrar funcionalidades”
Para isso, 20% do esforço é aplicado na construção de novas funcionalidades, enquanto 80% do esforço vai para as melhorias das funcionalidades atuais. A demanda pelas novas funcionalidades deve ser validada por atividades de Customer Discovery.

Regra #2: Restringir o número de funcionalidades que entra na fila
- Novas funcionalidades não podem ser desenvolvidas sem que as funcionalidades anteriores possam ser validadas.
- Para entrar no Backlog, a funcionalidade deve ser pedida por mais de um cliente. Isso aumenta a resistência para entrar uma nova feature no software (ajudando a regra #1) e evita que se faça customizações para clientes específicos, atividade que não escala e ainda tem o risco do efeito “colcha de retalhos”.

Como validar uma Funcionalidade?

Fila de desenvolvimento de funcionalidades

Fila de desenvolvimento de funcionalidades

Depois de desenvolvida, é importante validar a funcionalidade, ou seja, saber responder se ela atendeu de fato o problema que o cliente tinha. Especialmente quando não se tem uma massa de usuários muito grande, a validação Qualitativa (conversa com o cliente) é mais importante do que a Quantitativa (métricas).

Para Validação Qualitativa, Ash sugere que se contate os clientes que pediram a funcionalidade e disponibilize-a só para eles, coletando feedback depois do uso. As duas perguntas que ele procura responder são: Essa feature funciona de forma a resolver o problema que o cliente tinha? E em um nível mais macro, ela afeta a capacidade de fazer ou manter uma venda para ele?

Se não conseguir extrair um sinal positivo para essas perguntas, é importante tentar entender o porquê: se a funcionalidade foi mal implementada ou se o problema foi mal interpretado. No caso desse último, a sugestão do Ash é matar a funcionalidade imediatamente.

Para Validação Quantitativa, ele sugere a combinação do uso de ferramentas como Mixpanel, KISSMetrics e Google Analytics, mas focando mais no macro-efeito da implementação da funcionalidade (resultado nas métricas de negócio) do que nos dados de taxa de Click-Through ou uso da mesma.



Para fechar a apresentação, Ash lembrou que os benefícios do uso de Continuous Deployment são incrementais, e que o quanto antes iniciar a sua prática no desenvolvimento do produto, melhor.

Deixo agora o vídeo e os slides da apresentação:

Continuous Deployment: Startup Lessons Learned

]]>
http://www.manualdastartup.com.br/blog/continuous-deployment-em-uma-lean-startup-notas-da-palestra-do-ash-maurya-na-sllconf/feed/ 0