Concrete Logo
Hamburger button

"It's product management, stupid!"

  • Blog
  • 31 de Janeiro de 2014
Share

Não somos uma empresa de software. Nós desenvolvemos produtos digitais.

“‘It’s the economy, stupid’ is a slight variation of the phrase ‘The economy, stupid’ which James Carville had coined as a strategist of Bill Clinton‘s successful 1992 presidential campaign against sitting president George H. W. Bush. Carville’s original phrase was meant for the internal audience of Clinton’s campaign workers as one of the three messages to focus on”.

“Remember that it doesn’t matter how great your engineering organization is if you don’t give them something useful and usable to build” – Marty Cagan.

Introdução

A trajetória da Concrete Solutions em desenvolvimento de produtos digitais começa como tantas outras: mais erros do que acertos e uma fase vergonhosa waterfall seguida de um autoengano infernal utilizando processo unificado. Finalmente, entre 2006 e 2007, o início real do aprendizado: começamos a implantar Scrum e entramos em uma trajetória inacabada (por construção) para nos tornarmos uma boa empresa de desenvolvimento de produtos digitais.

trajetoria

Engenharia Ágil

Primeiro começamos a implantar o framework nos times. Treinamos várias turmas de PSMs e PSPOs e certificamos um dos sócios como CST (Certified Scrum Trainer). Os times foram ganhando fluência e passamos aos poucos a melhorar as práticas de engenharia com muita influência de práticas de XP, que gradativamente foram ganhando importância.

VO_Scrum

Alex Osterwalder e BMG

Depois de dez anos de atuação, em 2011 fomos apresentados ao Canvas e ao BMG em uma reunião de conselho. Ficamos maravilhados com a ferramenta, nossa concepção (inception) de projeto teve uma nova inspiração. Patrocinamos, então, a vinda de Alex Osterwalder ao Brasil para um MasterClass no Rio de Janeiro. A iniciativa foi fora de contexto, mas o efeito foi perturbador.

bmg

Steve Blank e Eric Ries

O livro de maior impacto na empresa foi, sem dúvida, o “The Four Steps to the Epiphany”, do Steve Blank, que foi depois complementado pelo trabalho do Eric Ries no “The Lean Startup”. Apesar de não ter inovado em nada, Eric Ries organizou a terminologia e complementou o trabalho de Blank.

tools

Novamente, ficamos impressionados com “shiny new tools” e fizemos experimentos usando o Lean Launch Lab e outros.

1369031311_lean-launch-lab

Ash Maurya e Ralph Jocham – Bizagility

A partir daí, ficamos inquietos. Precisávamos trazer os conceitos de Lean Startup para mais perto de nós para educar a comunidade em que estávamos atuando. Nesta época, já começávamos a entender que as competências tinham que “se empilhar”, e que os bons POs ágeis eram o início da figura do PO Fundador, que também saía do escritório. Treinamos mais de uma dezena de POs da Concrete e oferecemos, a preço de custo, um workshop com um conhecido praticante de Lean Startup, Ash Maurya, em uma iniciativa que chamamos de Bizagility.

ash

Brant Cooper

Para a primeira geração de nossos projetos que utilizaram Lean Startup buscamos experiência e legitimidade, claro, no Vale do Silício. Conversas com Brant Cooper e seus associados levaram a uma primeira tentativa de Joint Venture, na qual a mentoria dos nossos POs seria feita por eles.

brant

Fundo Moonlight

A partir de todo esse aprendizado, surgiu a ideia de implantar o intraempreendedorismo na Concrete. A iniciativa, chamada de Fundo Moonlight, permite que os nossos funcionários empreendam sem sair da empresa, trabalhando no tempo livre. Desta iniciativa surgiram três startups, das quais duas vingaram: a CloudRetail, plataforma que unifica os canais de venda digital, facilitando a experiência de mobile commerce do cliente, e a FIX Support, que oferece serviços de suporte, monitoramento e operações personalizados aos clientes.

ConcreteMoonFix

dafiti

Lean Startup Machine

E não paramos por aí: continuamos pensando em novas maneiras de apoiar o ecossistema de Lean Startup no Brasil. Por sugestão do Brant Cooper, entramos em contato com o pessoal da Lean Startup Machine, evento itinerante que tem como objetivo fazer um workshop “mão na massa” utilizando customer development durante 3 dias. Desde o início, Victor Oliveira atuou como co-organizador e mentor e eu acabei apoiando como mentor também.

3monthdays

Marty Cagan

Consideramos que existem poucas grandes escolas de desenvolvimento de produtos digitais no Brasil, e estão concentradas em mídia e em empresas que evoluíram de um datacenter para um portfólio de produtos em nuvem. São companhias que tiveram um imperativo de inovação claro: lançar produtos digitais de sucesso ou trocar de negócio.

Se a Globo.com nos levou a ter uma Engenharia ágil de primeira linha e a trazer UX como prática de primeira importância, a Locaweb nos trouxe o Marty Cagan como referência. Eric Ries popularizou o conceito de Lean Startup, mas Marty Cagan e o Silicon Valley Product Group se tornaram referência de conhecimento validado “duro” sobre desenv
olvimento de Produtos digitais. Os times da Concrete que trocaram de patamar de aprendizado no Moonlight agora tinham um referencial. Lean Startup é como um livro de divulgação científica, Inspired é “The Real Deal”.

marty

Digital Performance: as oito práticas de desenvolvimento de produtos digitais

O estado atual de nossa busca por aprendizado leva a uma reflexão muito importante: fazer produtos digitais de sucesso é uma tarefa hercúlea, composta de muitas práticas organizadas sob uma cultura focada no modelo de pensar e de executar do Vale do Silício. Ao longo da nossa trajetória, os anti-padrões se empilharam e pediram soluções que implicavam em novos papeis e novas competências.

O salto de reflexão atual surgiu do desenvolvimento de produtos internos (Fundo Moonlight) e as subsequentes tentativas de aplicar Lean Startup em corporação, associados ao fato de que a causa mortis principal dos projetos não era mais falta de agilidade e engenharia de software, mas a falta de gestão de produto.

A partir dessa conclusão, entendemos que desenvolver produtos digitais de sucesso é formado por oito práticas que devem ser aplicadas por nós ou por nossos clientes, com times mistos e sem a cultura do medo. É uma trajetória difícil, mas possível.

diagrama

1 – Agile Engineering e Cloud

Você vai ter que aprender a fazer software direito e gastar pelo menos 20% do seu orçamento para mantê-lo direito (refatorando o produto) sob pena de se encontrar com tanto débito técnico que o produto vai parar de evoluir. Isto implica em inúmeras “subpráticas”, mas destaco as três mais relevantes, na minha opinião:

– Agile development (Scrum/XP/Kanban)

Metodologia SCRUM

– Continuous delivery/integration

Cloud + open source

cloud-computing

2 – UX

É loucura tentar fazer um produto sem alguém de experiência de usuário e design. As pessoas têm que amar seu produto, e esse ponto é chave.  Acreditamos que o processo de UX tem que obedecer alguns princípios influenciados por três escolas: UX tradicional, desenvolvimento ágil e lean startup. É preciso focar em resultados (não em entregas); entregar iterativamente soluções que organizem a informação e a experiência de uso de forma rápida; e analisar junto ao time o resultado de negócio destas entregas. Também é preciso pouca documentação intermediária, ou seja, nenhum paperware, e trabalho junto com o time multidisciplinar, saindo do escritório e focado no problema do cliente. Lotes pequenos, menos análise prévia e muito conhecimento validado.

lean-agile-and-ux1

3 – Product & Client Discovery, customer development

Antes de começar, você precisa validar o problema que seu cliente quer resolver, o tamanho do mercado e que tipo de produto você precisa. Nesta fase, Alex Osterwalder, Steve Blank e Eric Ries ajudam muito, mas novamente quem tangibiliza melhor o processo é o Marty Cagan. Você descobre e desenvolve seu cliente descobrindo o problema a ser resolvido e a visão inicial do produto que depois evolui iterativamente.

Apesar de parecer um processo serial em primeira análise, Customer e Product Discovery são trabalhos contínuos e devem ser paralelos à execução de produto feita pelo P.O. As novas hipóteses que entram no backlog têm que ser geradas da forma mais científica possível e próxima do cliente, ou seja, juntando a análise das evidências com a proximidade dos clientes (grupos de clientes-chave ou conselhos de produto). Estas hipóteses são validadas com protótipos com dados reais (live data prototypes), que podem ser “de jogar fora” ou o embrião do produto. A experiência de uso destes pré-produtos alimentam o PO e evitam o processo, antes desordenado, de alimentação de novas features no backlog.

blank

4 – Product Execution, o papel do Product Owner

Alguém vai ter que entender como funciona o trabalho de “gerente/dono de produto”. O Product Owner é o CEO do produto e é pessoa que vai conseguir traduzir a visão e a estratégia em hipóteses e depois em funcionalidades que serão colocadas no produto. Este trabalho vai ser organizado em um backlog e em um roadmap de produto de longo prazo. Os fundamentos estão na formação do PO dos times ágeis, mas rapidamente precisa ser contaminado com a visão de ciclagem rápida de hipóteses que geram aprendizado. Os ciclos são chamados de “construa, mensure e aprenda” pelo Eric Ries no livro The Lean Startup. A experiência mostra que o ciclo deveria ser construa, mensure, analise e aprenda.

BML

5 – Growth Hacking e Product Marketing

Neste momento, você está buscando tração para seu produto. Então, terá que utilizar seu orçamento de marketing com sabedoria. A palavra-chave é que toda campanha tem que ser medida, tem que ter uma hipótese de negócio relacionada e tem que ter orçamento limitado. Com o resultado medido de cada campanha, você monta um portfólio iterativo e continuamente otimizado de apostas que devem aprender com as ações anteriores.

Para cada tipo de modelo de negócio você tem ferramentais mais adequados. Mas em uma visão geral temos:

a) PPC, pagar por click em redes sociais como LinkedIn ou buscadores como o Google. Vale estudar como funciona a questão de remarketing (marcação do cliente e uso de peças direcionadas);

b) PPM, banners e conteúdo;

c) Redes sociais, ações de engajamento orgânico via conteúdo e promoções de posts no Twitter, Facebook e outros;

d) Marketing de conteúdo: pode fazer muito sentido ter um blog, um canal no Youtube e uma presença forte no Pinterest. O sucesso neste caso é proporcional a três fatores: a utilidade, a qualidade e o quão inusitado é o conteúdo.

e) SEO e SEM: otimização de mecanismos de busca são importantes tanto para buscadores quanto para as appstores. Entender os algoritmos é chave;

f) Para mobile temos duas modalidades principais: ou você compra instalações PPI e conta com a inteligência da empresa para posicionar seus anúncios como JAMPP em mais de 400 redes de anúncio, ou faz isso você mesmo;

g) Viralidade: gosto muito do Neil Patel e do material que ele produz sobre a anatomia da viralidade no blog Quicksprout;

h) E-mail marketing: ferramentas como Mail Chimp podem te atender
durante muito tempo;

i) Força de vendas: ferramentas como o Pipedrive ou Salesforce funcionam bem, procure literatura específica sobre o que funciona no seu setor.

gh2

6 – Measurement

O mundo de métricas depende um pouco do modelo de negócios e do canal usado. Existe um modelo básico proposto pelo Dave McClure chamado AARRR e que representa seu funil de vendas, mas outras referências muito boas são o livro Lean Analytics e, para negócios SaaS, o blog do David Skok.

Em relação a ferramental web temos, além do Google Analytics, o Kissmetrics, e o MixPanel. Para mapas de calor o CrazyEgg funciona bem. Se seu produto é mobile, por outro lado, o Flurry é muito bom, mas dá para passar com o Google Analytics também. É importante procurar material sobre como estruturar segmentação de clientes (cohorts, em inglês) para evitar a síndrome do valor médio e para que os números te digam alguma coisa.

AARRR-model leananalytics

7 – Product Governance

Este tema é também bastante complexo. O trabalho de “portfolio grooming” tem que ser complementado com ciclos de inspeção e comunicação na estrutura de produto da empresa e mais acima, nos níveis de diretoria e board. Esse processo de grooming tem algumas subpráticas principais:

– Avaliação de ativos digitais e intangíveis;

Innovation Accounting: foco em aprendizado validado e tração;

– Gestão e otimização de portfólio e alocação de recursos como uma startup (rounds);

– Orçamento para novos produtos;

– Gestão do burn rate e portões periódicos de avaliação de decisão de investimento;

– Reuniões semanais e mensais com os POs e PMs e trimestrais com a diretoria e board;

governance

8 – Product Structure & Organization

Além da questão direta de como implementar uma estrutura matricial centrada nos times e seus POs, o tema central aqui também é Cultura. Se não eliminarmos a cultura do medo não conseguiremos fazer produtos. Definidos os papeis, existe uma problemática de desenvolvimento pessoal na qual a mistura de treinamento e mentoria continuada é chave. Essas pessoas, além de organizadas em times, estarão em outra estrutura ortogonal que organiza conhecimento e participantes com responsabilidades comuns (capítulos ou áreas). Isto pode ser tão amplo como juntar toda a engenharia, infra/devops, QA, UX, Métricas e Marketing de Produto em grupos ortogonais aos times, mas é muito dependente de cada situação. Podemos simplificar em alguns temas:

– Papeis e responsabilidades;

– Capacidades e habilidades;

– Cultura de inovação (pessoas podem errar?)

Estrutura organizacional (dedicada, multidisciplinar, “empowered”, times autônomos)

structure

Conclusão

A maturidade dos times e das empresas pode ser medida pelas perguntas que são feitas. Quando você para de perguntar “o que fazer” e “como fazer” e vê que a pergunta certa é “por que” fazer, talvez você esteja começando a entender a extensão da trajetória do que ignoramos.

Temos um ecossistema de engenharia de software de primeira linha (pequeno, mas de classe mundial), temos investidores maduros que entendem como ninguém como lidar com volatilidade e temos um mercado grande e quase virgem.

Nosso calcanhar de Aquiles é uma incrível incapacidade de entender como se faz produtos digitais, como ciclar rápido e produzir coisas como o Whatsapp, o Netflix e o Google Glass ou como manter times realmente multidisciplinares trabalhando de forma ótima durante 24 ou 26 meses até produzir produtos que as pessoas amem. O desafio é enorme, mas o prêmio também é.

*Agradecimentos especiais a todo o time da Concrete e clientes. Especialmente ao Victor Lima, Luis Felipe Castro e Joaquim Torres, que me ajudaram a validar esses conceitos.