Arquitetando o Produto (c/ Product Thinking)
Em 2018, depois de uma carreira técnica de mais de 12 anos atuando no desenvolvimento de software, percebi que era hora de me aprofundar mais na gestão de produtos, em especial nos produtos digitais por conta do meu background. A partir disso comecei a consumir livros, vídeos e participar de eventos. Foi então que resolvi ir no evento Product Camp 🤯
Considero a ida nessa edição do evento um divisor de águas, não só pelas ótimas palestras e pelo network estabelecido, isso foi de grande valia, mas também pela aquisição de um livro recém lançado pela Melissa Perri, chamado “Escape the Build Trap”. Ela resumiu muito bem as prioridades do Product Thinking na seguinte observação:
“nossa maior prioridade é satisfazer os clientes por meio da entrega antecipada e contínua de software valioso”.
“Software valioso” pode significar coisas diferentes, mas é fundamental que nossos esforços como organização estejam sintonizados em “maximizar a troca de valor com os clientes”, ou seja: entregamos e desenvolvemos o produto para satisfazer os problemas dos clientes e construímos um produto orientado pelo “espaço do problema” dos clientes, de forma que apoiamos na resolução de um desafio/problema, e com isso os clientes ficam satisfeitos e consequentemente dispostos a pagar pelo valor que o produto traz.
Tá, blz! Exclama aquele cara mais crítico pensando: “Mas precisou ir em um evento de produto para descobrir algo que o Ágil prega desde sempre?”. E de fato, o primeiro princípio ágil que nos é apresentado fala:
“Nossa maior prioridade é satisfazer o cliente por meio da entrega antecipada e contínua de software valioso.” — Agile Manifest
Porém, naquela oportunidade pude perceber de forma destacada que em Product Thinking, além do foco no cliente, há também um foco claro no “resultado de negócio” em vez de um simples “resultado de entrega”. Em resumo, trata-se da descoberta, entrega e evolução do produto centrado no cliente (ao mesmo tempo que leva em consideração as metas de negócios). Não sei bem ao certo, qual a razão de não ter identificado isso no Ágil, talvez até imaturidade, a forma como aprendi e ensinavam ou meu puro desconhecimento, não importa agora. O fato é que até então (2018) minha mente era voltada para entregas de algo que era solicitado pelos clientes e não no valor de negócio elas traziam. A figura abaixo mostra seus principais elementos.
Como pode ser visto, o objetivo do Product Thinking é construir e evoluir o produto a partir de um “ciclo de aprendizado contínuo” com o cliente. Essa é a principal diferenciação dos modelos clássicos de desenvolvimento de produtos sales-driven e tech-enabled, que tendem a priorizar outros elementos, não os problemas reais do cliente e, consequentemente, não conseguem maximizar a troca de valor. Aliás, deixo aqui um link para quem deseja entender empresas que se apoiam em product-led, sales-led e marketing-led.
Ok, feita essa introdução e com esse modelo mental, a próxima pergunta que podemos nos fazer é: “como podemos conseguir isso?”, ou seja: como maximizar a troca de valor com o cliente continuamente e em alta velocidade? Há uma série de fatores que contribuem para isso. Uma observação importante é: estamos falando de produtos, não de projetos. Esta é uma distinção fundamental, pois um projeto é uma iteração no desenvolvimento de algo e, em geral, tem um objetivo final e um escopo claro para um cliente específico. Por outro lado, os produtos tendem a evoluir continuamente e ser aprimorados com base nos aprendizados e necessidades que descobrimos com os clientes.
A resposta da pergunta acima pode estar na resposta de outra pergunta: Como aproximar as pessoas técnicas das pessoas do negócio e aumentar o alinhamento entre as partes? A seguir, vamos observar algumas características que precisam de atenção ao abordar o desenvolvimento e a evolução do produto. Usarei um exemplo de execução de “Um Produto Circo” para mostrar essas diferentes características.
Característica 1 — Seus times e sua organização moldam seu produto
Seja qual for o produto que estamos construindo, precisamos garantir que os times (e sua configuração, arquitetura organizacional e estruturas de comunicação) estejam alinhadas com as ambições que temos para o produto que está sendo projetado (a “arquitetura técnica” real do produto). Isso é basicamente a Lei de Conway [aqui um vídeo resumido], ou seja:
“Qualquer organização que projeta um sistema (definido de forma ampla) produzirá um software cuja estrutura é uma cópia da estrutura de comunicação da organização”.
Perceba, se não temos um mínimo alinhamento/esboço do objetivo do produto e da arquitetura do produto e já estamos pensando nos times ou já estamos com eles definidos, certamente enfrentaremos problemas com a formato final do produto. Antes de pensar em times, “o que” e “como” precisam iniciar um alinhamento.
Circo: se queremos construir um ótimo circo russo, de show e atrações, precisamos ter bons artistas russos e especialistas na arte circense para que trabalhem juntos, cada qual no seu objetivo, na construção de um produto que reúna esses elementos como uma ótima experiência para o cliente.
Característica 2 — Seus times devem ter as condições certas para construir o produto para seu cliente
Isso basicamente significa que seus times devem ter o escopo e a capacidade certa para construir o produto para o cliente. Portanto, ao moldar o produto a ser construído (arquitetura), devemos considerar explicitamente como ficarão os times (e sua topologia e configuração) para realmente poder fazê-lo funcionar. É aqui que o trabalho das Topologias de Times [Team-Topologies ] — e sua “abordagem de times em primeiro lugar” pode ajudar muito.
Negligenciar os times no processo de arquitetar os sistemas — e focar puramente no produto desejado (e sua Arquitetura Técnica) levará (quase certamente) a surpresas na própria construção, entrega e evolução do produto. Avalie as capacidades dos times e se suas responsabilidades de negócio (valor e interação com outras partes) estão claras.
Circo: para ter um circo funcionando sem problemas e criando continuamente as melhores experiências para os clientes, precisamos ter pessoas suficientes montando, atuando e realizando todas as diferentes atividades do circo. Não podemos esperar que os artistas montem o palco, confiram os ingressos, vendam pipoca e façam o show ao mesmo tempo.
Característica 3 — Seu produto é uma combinação de fluxos de valor pertencentes a diferentes times, mas alinhados para maximizar a troca de valor com o cliente
Um produto pode ser visto como um sistema com diferentes partes que juntas (e com suas interações) definem e entregam o valor que o cliente busca. Queremos que esses diferentes fluxos de valor se unam de forma harmoniosa para o nosso cliente. Não queremos que as otimizações locais “em silos” sejam feitas sem o contexto e os objetivos do produto (todo o sistema) em consideração. Tais abordagens (quase) nunca levam ao objetivo que temos: maximizar a troca de valor geral com o cliente. Essa abordagem de compreensão holística é uma propriedade central do pensamento sistêmico (aqui um livro) [aqui um resumo].
Circo: no nosso circo não queremos simplesmente apresentar o “melhor globo da morte” combinado com o “melhor malabarista”. Essa combinação do que há de melhor em cada peça não necessariamente leva ao melhor produto final para nossos clientes. O melhor resultado resulta de uma combinação contextual das partes, que requer interação e compreensão na concepção da experiência (ex: vamos pensar desde as filas para ingressos, até as vendas de comidas e bebidas e no tempo de espera para a preparação de cada show).
Característica 4 — Seus times devem ser capacitados para descobrir (com o cliente) quais são as melhores coisas para construir no produto
Um dos pilares do Product Thinking é permitir que os times ouçam, descubram, entendam os problemas do cliente, sejam capacitados para mapear isso durante o desenvolvimento do produto e que possam resolver esses problemas. Para conseguir isso, os times precisam estar no comando das atividades de “descoberta e aprendizado” com o cliente. Deixar de fazer isso em equipe e ter áreas proprietárias e que definem o produto longe dos clientes, atrás de várias “camadas de outras equipes/pessoas”, levará a uma compreensão mais pobre do cliente.
Além disso, também levará a um ciclo de vida de desenvolvimento de produto muito mais lento (e lead time para entrega de valor, que é uma métrica bem conhecida para medir alto desempenho, conforme descrito nas métricas do livro Accelerate ). Mesmo quando os times fazem a descoberta, também é importante garantir que todos estejam habilitados para fazer a descoberta do produto. Este não é um trabalho para apenas algumas pessoas do time (ex: PM, UX). Os membros dos times são um dos principais impulsionadores de grandes ideias de desenvolvimento de produtos, portanto, garantir que isso aconteça é crucial.
Obs.: Se o seu time aceita qualquer pedido para o cliente sem entender o que foi dito acima, você tem um pilar comprometido e perigo à vista!
Circo: queremos que as pessoas que trabalhem na montagem do palco entendam como os clientes estão reagindo a suas acomodações, para que possam ajustá-los e evoluí-los. Por exemplo, eles podem precisar entender se o produto que usam está funcionando bem para determinado show. Caso contrário, eles podem precisar procurar fontes alternativas. Montadores, artistas, malabarista do circo em conjunto estarão mais preparados para raciocinar sobre essas atividades de descoberta.
Não apenas “o quê”, mas também “quem” + “como” precisam ter Compreensão Holística!
Se analisarmos as características apresentadas acima, podemos ver que, para atingir o objetivo do Product Thinking, não podemos focar apenas em “O que permite a troca de valor máximo” (parte “O quê”). Devemos também atender a outras importantes partes inter-relacionadas: “Quem” está ouvindo o cliente e construindo/evoluindo o produto; e “Como” é o produto que está sendo construído para entregar a maximização de valor que o “O quê” descobre e define.
Além disso, como todas essas partes se inter-relacionam e reúnem entendimento relevante para conduzir decisões significativas que afetam positivamente todo o sistema. A figura abaixo mostra uma visualização dessas três partes.
Estes (o quê, quem e como) são todas partes relevantes na equação de objetivo geral do Product Thinking. É fundamental aceitar que eles devem ser entendidos de uma perspectiva holística para definir estratégias para melhorar nosso objetivo geral do produto. Por exemplo: para melhorar o nosso Circo, consideramos as atrações que temos (parte “O quê”), mas também os times que temos e como estão organizados (parte “Quem”) e como constroem os shows e as diferentes experiências para os clientes (parte “Como”). Eles estão todos inter-relacionados e suas relações definem o Circo (Produto).
Essas ideias se baseiam nas ideias do Pensamento Sistêmico, que fala que a otimização local de partes separadas não melhorará o desempenho do todo. O Dr. Russell Ackoff, um dos Pioneiros dos movimentos de pensamento sistêmico, afirmou que:
o sistema é mais do que a soma de suas partes, é um produto de suas interações. E a maneira como as peças se encaixam determinam o desempenho de um sistema, não como elas funcionam separadamente.
Por exemplo, não queremos ficar “reconhecidos pelo melhor show de humor com os palhaços”, sem qualquer noção do que se passa no resto do Circo e das experiências que queremos otimizar para os nossos clientes. Tais otimizações locais tendem a levar a resultados abaixo do ideal e, em muitos casos, diferentes sistemas podem “sabotar” as melhorias uns dos outros. Amigo leitor, você conhece alguém que já deixou de ir a um circo porque em dias chuvosos a estrutura não era adequada, ou porque o lugar não transmitia segurança ou até mesmo porque havia maus-tratos nos animais? Então…
Agora o desafio é: como podemos aplicar essas características para construir produtos digitais que maximizem a troca de valor?
Pretendo compartilhar algumas ideias sobre isso nos próximos artigos:
Arquitetando o Produto: Guiado pela Estratégia;
Arquitetando o Produto: Separando em Partes;
Arquitetando o Produto: Organizando os Times;
Arquitetando o Produto: Juntando as Peças;
Espero que tenham gostado e até lá!!! 😃
