Grandes produtos: Discovery vs. Delivery

A maioria de nós trabalha em problemas bastante difíceis e normalmente precisamos de sistemas bem complexos para resolver esses problemas.

Muitas equipes enfrentam dois grandes desafios:

Primeiro, você precisa descobrir como deve ser a solução para o cliente (Discovery). Isso significa tanto descobrir se existem clientes que precisam dessa solução (demanda), quanto encontrar uma solução que funcione para os clientes e para a própria empresa. Ainda mais difícil é encontrar uma única solução que funcione para muitos clientes e não apenas para alguns clientes específicos. Para conseguir isso, precisamos aprender rapidamente.

Em segundo lugar, é preciso garantir uma implementação robusta e escalável, cujo valor nossos clientes possam confiar (Delivery). A equipe deve ter confiança no Release. Mesmo que nunca se possa ter 100% de confiança em algo, também não deveria ser necessário rezar para que tudo dê certo quando se faz um release.

Portanto, é preciso tanto aprender rapidamente quanto ter confiança nos seus releases.

Isso pode funcionar?

É compreensível que muitas pessoas pensem que esses dois objetivos diferentes são contraditórios. Precisamos tentar lançar algo rapidamente para descobrir o que funciona e o que não funciona. No entanto, também não queremos lançar algo que ainda não está maduro e, com isso, arriscar prejudicar nossos clientes e nossa marca.

Conversei com muitas equipes de produto e frequentemente fui questionado porque, em um momento, incentivo uma equipe a fazer releases de forma mais agressiva e coletar feedback dos clientes, e ao mesmo tempo exijo que não façam concessões em relação a software confiável, de alto desempenho e seguro.

O Produto Mínimo Viável

Para muitas equipes, o conceito de um Minimum Viable Product (MVP) não é simples, pois por um lado há motivação para entregar algo rapidamente ao cliente e obter feedback, mas por outro lado surge rapidamente a sensação de que o chamado "produto" poderia ser um constrangimento – e como alguém poderia lançar algo assim ao público?

Aprendizado rápido e releases sólidos

Quero explicar aqui como boas equipes conseguem conciliar os dois objetivos – aprendizado rápido e releases sólidos.

Fundamentalmente, acredito que para a maioria das equipes o segundo objetivo – entregar software de qualidade – é mais fácil do que experimentar coisas rapidamente e obter novos insights. Continuous Delivery, ou seja, a entrega contínua, é um bom método que pude observar nas equipes que compreenderam a importância de muitas pequenas mudanças incrementais em um sistema complexo.

O que é afinal um produto?

O motivo dessa confusão é, entre outros, o fato de que muitas vezes simplesmente não se sabe exatamente o que significa quando se fala de "produto", "qualidade do produto", "live in production" etc. Eu sempre tento usar o termo "produto" para um produto que está em um estado em que é realmente comercializável. Ele é escalável e oferece uma certa performance. Existe uma suite robusta de testes de regressão. Ele foi projetado para que se possa coletar as análises necessárias. Dependendo da necessidade, foi internacionalizado ou restrito localmente. É fácil de manter. Corresponde à promessa da marca. E o mais importante é o fato de que a equipe pode lançar o produto com a consciência tranquila.

Isso não é simples e consome a maior parte do tempo no desenvolvimento. Por isso, nos esforçamos para não desperdiçar todos esses esforços.

Realizar esses trabalhos, mesmo quando o próprio product manager não tem certeza se os clientes sequer querem ou precisam da solução, é uma receita absolutamente certa para desperdício.

A Product Discovery

O objetivo da Product Discovery é, portanto, reunir evidências de que todo o esforço dos desenvolvedores para criar software de alta qualidade não será em vão.

Por isso existem tantas técnicas diferentes para Product Discovery. Temos técnicas para entender melhor nossos usuários e clientes e para validar ideias de produto de forma qualitativa e quantitativa. E a maioria dessas técnicas nem sequer consome tempo dos desenvolvedores (isso é importante, porque sabemos quanto tempo e esforço custa produzir boa qualidade).

Product Discovery eficaz tem muito a ver com conseguir acesso ao cliente, e não simplesmente implementar nossos experimentos para novos produtos o mais rápido possível.

Se você ainda é uma startup bem jovem e não tem clientes, isso obviamente não é um problema (e talvez seja até cedo demais para software com qualidade de produção).

A maioria de nós, porém, tem clientes reais e receitas reais, e por isso precisamos pensar nisso. Já escrevi sobre as principais técnicas para experimentação rápida e responsável com a Product Discovery em empresas estabelecidas.

Muitas dessas técnicas envolvem convencer alguns de nossos clientes ou potenciais clientes a testar nossas novas ideias de produto (de qualquer forma que seja). Um programa de desenvolvimento de clientes é especialmente adequado para isso, porque essas pessoas se voluntariaram para ser cobaias. Podemos conversar com elas ou simplesmente observá-las experimentando nossas ideias de produto, ou então deixá-las testar nossos protótipos por um tempo e ver o que acontece.

Conclusão: Discovery vs. Delivery

Se você realmente quer descobrir produtos incríveis, é extremamente importante testar suas ideias com usuários e clientes reais, cedo e com frequência. Se você quer entregar produtos incríveis, deve usar as melhores práticas de desenvolvimento e procurar não ignorar as preocupações dos engenheiros.

Quando queremos avançar rapidamente e descobrir novas ideias, usamos métodos de Discovery e envolvemos os clientes. Assim que descobrimos qual solução devemos desenvolver, deixamos os desenvolvedores criarem um software com qualidade de produção, pois assim eles podem entregá-lo com total convicção.

Este texto foi extraído do blog de Marty Cagan e foi traduzido por nós para o português.