“A maior diferença entre construir um produto de infra-estrutura empresarial altamente técnico e um produto SaaS mais tradicional é que você não está apenas projetando para usuários humanos, você também está levando em conta os usuários de máquinas”, diz Nate Stewart, Diretor de Produtos da Cockroach Labs.
A empresa é a criadora do CockroachDB, um banco de dados SQL distribuído em nuvem que foi projetado para construir, escalar e gerenciar aplicações de dados intensivas. (Como disseram os fundadores, eles deram o nome de seu início de operação ao insecto resistente porque é quase impossível de derrubar – o que é uma ordem muito alta para Stewart viver como um líder de produto).
Independentemente de para quem você esteja projetando, com o final do ano se aproximando rapidamente, o planejamento anual é provavelmente o mais importante – analisando se você atingiu suas marcas no plano anterior e o que poderia orientar seu trabalho para o ano seguinte. Mas os planos mais bem elaborados podem facilmente parar quando sua estratégia sai da página e a borracha encontra a estrada.
“Em um mercado tão grande quanto o nosso, há diferentes estratégias possíveis que podem ser bem sucedidas. Quando decidimos concentrar nossa estratégia de produto em cargas de trabalho de missão crítica e transacional que se concentram em manter os dados próximos aos usuários, outras estratégias viáveis se abriram para nossos concorrentes”, diz Stewart. “Você começa a ver clientes cujas características exigem que você diga não para entrar nos braços de seus concorrentes – e isso pode ser desmoralizante se você não tiver convicção em seu caminho e em seu sucesso a longo prazo”.
Há muita coisa escrita sobre estratégia de inicialização e como você pode usar os OKRs para ir da estratégia à execução. Mas não há muita literatura por aí sobre a razão de algumas estratégias falharem no mundo real.
Quando o pessoal do produto começa a afiar seus planos anuais, Stewart desembala seu livro de brincadeiras para ganhar convicção e criar uma estratégia resiliente que ainda está de pé desta vez no próximo ano. Nesta entrevista exclusiva, ele compartilha os modos de falha para que os líderes de produtos fiquem atentos (como o foco na qualidade do cliente em detrimento da quantidade), e como ele se esquivou desses erros em seu papel na Cockroach (incluindo uma nova abordagem para parceiros de design).
Vamos mergulhar.
MODO DE FALHA Nº 1: VOCÊ ESTÁ SE ESQUIVANDO DAS CHAMADAS CONTROVERSAS.
Quando uma partida está apenas começando a trilhar seu caminho, pode parecer que há rotas aparentemente ilimitadas no mapa para o produto/mercado caber. A barata enfrentou um ponto de contenda semelhante nos primeiros dias ao decidir o que construir. “Os bancos de dados funcionam em todos os setores e em muitos casos diferentes de uso. Como primeiro Chefe de Produto, eu tive que colocar em prática os processos para tomar decisões em torno do que construir. Quais são as capacidades às quais devemos dizer sim, e quais são as características que devemos evitar”, diz ele.
Mesmo no início, você precisa de alguma forma de dizer não e filtrar todos os pedidos e casos de uso potencial para seu produto.
Então Stewart começou a olhar para as diferentes maneiras de segmentar o mercado de banco de dados, olhando para as caixas de borda onde a barata poderia se encaixar de forma mais natural. Isto levou a equipe a uma bifurcação na estrada, uma escolha antecipada que seria uma das decisões definidoras para a empresa.
“Poderíamos construir um banco de dados que fosse um sistema analítico como o Snowflake, que é excelente para executar grandes agregações e fazer cálculos através de muitas linhas de dados”. Ou podíamos construir um banco de dados que fosse muito eficiente quando se tratava de escrever e ler dados transacionais”, diz Stewart. “O ponto de decisão inicial mais natural foi: Para que tipos de consultas queremos tornar Cockroach mais performante?” diz ele.
É uma pergunta que muitos líderes de produtos têm enfrentado nos primeiros dias: Onde você deve concentrar o ICP? “Em última análise, a grande decisão que tomamos foi focar em casos de uso transacional – porque o que torna a CockroachDB única é a resiliência do produto. Se seu banco de dados analítico cair por dois segundos, tudo bem. Basta atualizar e executar a análise novamente. Mas se o banco de dados que está alimentando seu processamento de pagamentos cair por dois segundos, você pode perder milhões de dólares. Nosso molho secreto é manter seus dados online, em funcionamento e perto dos usuários”, diz ele.
Isto desenhou a linha na areia que Stewart (e todos os outros líderes de produtos) estão procurando quando começam a esboçar o roteiro do produto. “O alinhamento com os fundadores e a equipe de receita que seríamos um banco de dados transacional nos ajudou a dizer não a muitas coisas que nos aproximariam dos concorrentes, como o Floco de Neve, e nos permitiu dizer sim a coisas que se baseariam na força de nosso produto durante um longo período de tempo”, diz ele.
Mas, como diz Stewart, esta foi uma escolha controversa entre a equipe e a recontagem desta história suaviza algumas das arestas mais afiadas. “Houve algumas pressões do mundo real que tornaram difícil manter a linha sobre esta decisão de se tornar um banco de dados transacional”. Na época, éramos pré-vendas e tínhamos alguns grandes clientes dizendo: “Nós lhe daremos seus primeiros $100.000 ou $200.000 – mas somente se você desenvolver estas capacidades analíticas. É incrivelmente difícil dizer não às primeiras fontes potenciais de receita de uma empresa iniciante”, diz ele.
MODO DE FALHA #2: VOCÊ NÃO É INTENCIONAL SOBRE SUAS PARCERIAS DE PROJETO.
Para reforçar a convicção na escolha de se concentrar em bancos de dados transacionais, Stewart formou estreitas parcerias de projeto com clientes potenciais. Mas aqui, ele observa uma diferença chave quando se trata de construir infra-estrutura empresarial em comparação com outros tipos de ferramentas SaaS. “Os compradores de infra-estrutura empresarial tendem a ser mais conservadores – por definição, a infra-estrutura é o que suporta algum processo comercial central. Se sua infra-estrutura for instável ou cair, seu negócio principal pode cair”, diz ele.
No final das contas, as pessoas não estavam exatamente alinhando a porta para serem testadores antecipados. “Não foi tão fácil quanto eu esperava conseguir que as pessoas dessem feedback sobre o software beta – porque havia um investimento de engenharia tão grande que era necessário para um novo recurso que não estava totalmente cozido. Não valia realmente a pena para nossos clientes testar no início – eles só queriam que o produto funcionasse”, diz Stewart.
E enquanto a maioria das pessoas quer a mais recente tecnologia – o mais novo lançamento do iPhone, ou o novíssimo modelo de carro fora do lote – com infra-estrutura empresarial, os compradores tendem a adotar a abordagem oposta. “Quando nossos clientes estavam comprando o software, eles não queriam o mais recente e maior. Eles queriam que fosse seis meses ou até mesmo um ano atrás”, diz ele.
Assim, um já longo ciclo de feedback do produto foi estendido ainda mais. “Muito do feedback que recebemos de nossos clientes foi baseado em decisões que tomamos há um ano – o que significa que você está dirigindo através do espelho retrovisor”, diz Stewart.
Assim, a equipe da Cockroach se apoiou fortemente no dogfooding do produto nos primeiros dias, mesmo que não fosse tão elegante.
“Houve um ponto em que insisti que toda a análise do produto fosse feita no banco de dados da CockroachDB”. CockroachDB não é um painel analítico, mas era uma maneira de vermos como era a interface SQL e como era fácil obter dados dentro e fora do CockroachDB”, diz Stewart. “Inicialmente, algumas dessas oportunidades de “dogfooding” foram um pouco forçadas e, francamente, bastante dolorosas, mas foi necessário testarmos as bordas do produto e pagarmos enormes dividendos mais tarde”.
Mas a transição de “dogfood” com seus usuários internos para colocar seu produto no mundo real pode ser um grande salto. É aí que os parceiros de design podem ajudar a amortecer a queda. Mas ao invés de abordar parcerias de design de forma tradicional, Stewart tentou uma abordagem diferente. Seu conselho para outros líderes de produtos que enfrentam ventos de proa similares é encurtar seus parceiros de projeto em diferentes categorias, para que você possa desarrolhar aspectos específicos do negócio.
MODO DE FALHA #3: VOCÊ ESTÁ SE COMPROMETENDO COM DEMASIADA FACILIDADE COM POTENCIAIS CLIENTES.
Particularmente nos primeiros dias, quando o roteiro do produto é um pouco mais exigente e os clientes estão menos e mais distantes, pode ser tentador se comprometer com novas características, em nome da assinatura de um contrato. Mas desde o início, a barata tornou incrivelmente difícil comprometer-se com as características aos clientes. “Quando novos gerentes de produto e novos vendedores se juntam a nossa equipe, eles são frequentemente apanhados de surpresa por nossa falta de vontade de comprometer-se a construir algo para um determinado cliente. É como conseguir um projeto de lei através do Congresso”, diz Stewart.
Isto é bastante raro no início da fase inicial – quando os planos são amorfos, os compromissos são muito mais comuns. “Você pode dizer: ‘Ei, ainda não temos produto/mercado em condições”. Portanto, se um cliente nos pagar receita, podemos nos comprometer a construir as características A, B e C.” Se você puder obter seu primeiro cliente 500K através de compromissos com o cliente, isso pode mudar materialmente sua taxa de execução. Mas isso também muda significativamente sua agilidade. O custo de oportunidade é enorme”, diz ele.
Os compromissos do cliente são dívidas tecnológicas para as equipes de produtos. Você limita sua flexibilidade – e o que é mais valioso para uma inicialização do que a capacidade de mudar de rumo rapidamente?
MODO DE FALHA #4: VOCÊ É IRREALISTA SOBRE O QUE PODE EXECUTAR.
Uma das maiores arames de viagem que Stewart vê, particularmente para as estrelas com recursos e mão de obra, é que as pessoas sonham grande quando se trata da estratégia – sem levar em conta as verdadeiras capacidades da org. “Você tem algumas opções aqui: você pode ter uma contabilidade honesta das capacidades de sua equipe, dada sua estratégia, e descobrir como você pode fechar a lacuna entre as duas. Ou você pode decidir que esta é a equipe que você tem, e descobrir uma estratégia que esta equipe atual pode executar”, diz ele.
Houve alguns pontos de inflexão na jornada de Cockroach, onde Stewart enfrentou exatamente esta situação.
“Este foi um desafio que enfrentamos diretamente quando começamos a nos mudar para um produto SaaS, entregando a CockroachDB como um serviço, onde nossos clientes não administram o banco de dados eles mesmos – nós administramos o banco de dados para eles”.
Havia uma macro tendência empurrando mais pessoas para descarregar suas operações para os fornecedores, e havia se tornado cada vez mais claro que precisávamos oferecer a CockroachDB como um serviço”, diz Stewart.
Portanto, sua próxima pergunta é algo que ele sugere que todas as pessoas do produto se perguntem repetidamente ao elaborar qualquer tipo de estratégia:
O que precisa ser verdade para que esta estratégia seja bem-sucedida?
“A primeira coisa que percebemos é que nossos clientes estavam tendo problemas para contratar esses operadores de banco de dados – mas agora temos que encontrar uma maneira de contratá-los”. E estes engenheiros de confiabilidade do site não vão apenas gerenciar um banco de dados, eles vão gerenciar milhares deles. Como podemos encontrar estas SREs? Como os entrevistamos? Como integrá-las à nossa cultura e torná-las bem-sucedidas? Se decidirmos seguir esta estratégia, é uma enorme capacidade que temos de desenvolver”, diz ele.
Stewart esboça outro exemplo de como sua estratégia precisa saltar fora da página. “Estamos no negócio de lidar com dados de livros de pagamentos de missão crítica”. Se estamos pedindo às pessoas que nos confiem esses dados, precisamos construir um conjunto substancial de habilidades de segurança”. Portanto, temos que contratar especialistas em segurança do lado do produto e engenharia para nos ajudar a conseguir isso. Se você não for muito específico em delinear todas as diferentes contingências com sua estratégia escolhida, sua estratégia falhará”, diz ele.
MODO DE FALHA #5: VOCÊ ESTÁ CAINDO NO MITO DE QUE A CONCORRÊNCIA NÃO IMPORTA.
Há um adágio de inicialização frequentemente repetido de que a concorrência não importa – basta manter a cabeça baixa e não se distrair muito com o que as pessoas ao seu redor estão fazendo. Stewart foi apanhado por este mantra, mas desde então mudou de tom. “Inicialmente pensei que a competição não importava. Basta focar nos clientes, trabalhar com os primeiros princípios e você vai acabar em um bom lugar. Mas quando se trata de uma venda de uma empresa ou de passar por um processo de avaliação minucioso, é inevitável que os concorrentes estejam envolvidos. É útil entender onde seus concorrentes são fortes e onde você é forte, e como falar sobre esses diferenciadores de uma forma que o favoreça”, diz ele.
Portanto, quando se trata de elaborar a estratégia da empresa, mantenha seus concorrentes em sua visão periférica. “Temos uma classe de concorrentes que tomaram decisões estratégicas fundamentalmente diferentes das nossas”. Como exemplo, a Amazon Aurora é uma grande base de dados. Em vez de tornar todo o banco de dados nebuloso, eles fizeram apenas o nível mais baixo de nebulosidade. Para eles, isso é uma escolha estratégica porque significa que é uma migração muito mais simples pegar um banco de dados existente e administrá-lo na Amazon”, diz Stewart.
“O que está a nosso favor é que esses bancos de dados não são todos nativos das nuvens, de modo que não se obtêm as mesmas características de resiliência”. Você não pode mover seus dados para qualquer lugar do mundo, e não pode escalar para o mesmo nível que pode com CockroachDB – isso é um compromisso fundamental”, diz ele. Este diferenciador chave então arma a equipe de vendas com as mensagens que eles precisam para posicionar o produto para conquistar clientes”.
Quando você pensa nos investimentos estratégicos que pode fazer, invista nos diferenciais essenciais que o diferenciam dos concorrentes.
MODO DE FALHA #6: VOCÊ ESTÁ PULANDO O FEEDBACK INTER-FUNCIONAL.
Como diz Stewart, ele lidera suas equipes de produtos como um sistema operacional de produtos: “Os gerentes de produto estão tomando insumos externos do mercado – o que os clientes estão dizendo e o que os concorrentes estão fazendo”. Eles também estão recebendo insumos internos, como o feedback da equipe de vendas e o que o pessoal de pré e pós-vendas está falando. Eles estão destilando todas essas informações através da lente de uma estratégia e depois descobrem as maneiras pelas quais podemos mudar ou melhorar nosso produto para nos aproximar de nossa missão”, diz ele.
As questões que surgem nesta fase incluem:
Quão profundamente entendemos o problema?
Como podemos enquadrar melhor o problema?
Ajustado ao risco, isto é um bom investimento para a empresa, dado o custo de engenharia?
Se acrescentarmos algo ao roteiro, algo terá que cair. Estamos de acordo com o compromisso?
Como estas características começam a frutificar, como podemos desarrolhá-las?
Mas estas decisões não podem acontecer no vácuo – é aí que entram seus parceiros multifuncionais. Stewart recomenda a criação de conselhos de produtos para ajudar a integrar estas idéias em toda a empresa. Um conselho de produtos é uma revisão mensal de negócios, onde um PM para uma área de produtos em particular se reunirá com um grupo de partes interessadas interfuncionais para falar sobre como as coisas estão indo. “É um mecanismo de correção de curso e compartilhamento de informações que temos mensalmente no contexto deste plano anual mais amplo”, diz ele.
Aqui está o guia passo-a-passo de Stewart para conduzir um conselho de produtos:
- Em vez de criar um baralho ou fornecer um cartão de pontuação, escreva uma narrativa de seis páginas sobre o que está funcionando e o que não está funcionando.
- Traga 7-10 pessoas de toda a orgia para a reunião.
- Reserve uma hora para a reunião; comece os primeiros 20 minutos deixando as pessoas lerem individualmente o memorando e acrescentarem seus comentários.
- O gerente de produto então retira os principais temas, perguntas e pontos de discussão, que são debatidos para o restante da reunião.
Stewart adverte contra fazer desta reunião um convite aberto. “Quanto mais pessoas você tiver na sala, menos pessoas estarão dispostas a levantar a mão e dizer algo”. Equilibre onde você tem representação de pré-vendas, pós-vendas, suporte, engenharia, gerenciamento de produtos, design e marketing. Mas não abra as comportas”.
Add Comment