O Modelo Operacional de Produto: A Chave para Inovação e Agilidade

Como empresas como Amazon, Apple ou Tesla conseguem, repetidamente, revolucionar o mercado com inovações disruptivas? E isso numa velocidade que deixa outras empresas apenas a observar, admiradas? No seu livro "TRANSFORMED", o especialista em gestão de produtos do Silicon Valley, Marty Cagan, oferece uma resposta: O segredo está no chamado "Product Operating Model".

O Product Operating Model é um framework que ajuda empresas a tornarem o seu desenvolvimento de produtos mais estratégico, centrado no cliente e ágil. Consiste em três elementos centrais: Delivery, Discovery e Direction. Cada um destes elementos aborda um desafio central que as empresas enfrentam hoje.

Mas o que exatamente se esconde por trás destes conceitos? Sohrab Salimi, um consultor e coach experiente em desenvolvimento ágil de produtos, trabalha há anos em estreita colaboração com Marty Cagan e implementa com sucesso o seu Product Operating Model na prática. Um destaque especial foram também as Agile Insights Conversations com Marty, que proporcionaram insights valiosos sobre os seus métodos e abordagens.

Aqui estão as Agile Insights Conversations com Marty e Sohrab:

https://youtu.be/RPHZO-ckDWA?si=zpeKxzPM-d9GINlG

https://youtu.be/k1JMyN3X5yw?feature=shared

Na sua palestra no Product Owner Day 2024, ele explica os elementos centrais e mostra como as empresas podem implementá-los na prática.

Os Elementos Centrais do Product Operating Model

Como Sohrab explica, o Product Operating Model consiste essencialmente em três elementos: Delivery, Discovery e Direction. Cada um deles aborda uma questão central que as empresas precisam responder para permanecerem inovadoras e ágeis.

Delivery: Como garantimos que os nossos produtos são desenvolvidos e entregues de forma eficaz e eficiente?

O primeiro elemento "Delivery" gira em torno da capacidade de entregar valor continuamente ao cliente - e em ciclos o mais curtos possível. Como Sohrab sublinha, este é o pré-requisito fundamental para a capacidade de inovação e adaptabilidade. No entanto, muitas empresas têm dificuldade em encurtar os seus ciclos de release, frequentemente longos.

Na verdade, não é assim tão difícil: É necessário principalmente equipas pequenas, cross-funcionais e auto-organizadas, que tenham o mínimo de dependências e pontos de passagem possível na sua cadeia de valor, da ideia à entrega. Além disso, precisam de confiança e autoridade para tomar decisões de forma autónoma. Mas é exatamente aí que muitas vezes falha, como Sohrab sabe da sua prática de consultoria.

Um modelo aqui é certamente a Amazon com as suas "Two Pizza Teams" - ou seja, equipas tão pequenas que duas pizzas americanas são suficientes para alimentá-las. Tais equipas são capazes de levar produtos ou funcionalidades da ideia à entrega em poucas semanas. Mas isto só é possível se as equipas também tiverem a liberdade e a confiança para decidir e agir de forma autónoma.

Se queres mais insights sobre a Amazon, recomendamos o seguinte artigo: https://www.agile-academy.com/de/agile-leader/os-10-insights-mais-importantes-de-working-backwards-de-colin-bryar/

Outro exemplo de Delivery eficaz é o framework Scrum, que foi explicitamente desenvolvido para entregar valor em ciclos curtos. Através de Sprints, que normalmente duram de duas a quatro semanas, software funcional é entregue regularmente. Isto permite às equipas reagir rapidamente ao feedback e fazer melhorias contínuas. O Scrum promove equipas pequenas e cross-funcionais, que estão em contacto próximo com os stakeholders e têm autoridade para tomar decisões de forma autónoma. Isto minimiza dependências e aumenta a eficiência e eficácia do desenvolvimento de produtos.

Discovery: Como identificamos e validamos novas ideias de produtos e soluções que correspondem às necessidades dos nossos clientes?

Pelo menos tão importante quanto ciclos de entrega rápidos é, em primeiro lugar, resolver os problemas certos. É exatamente disso que trata o segundo elemento do Product Operating Model: Discovery.

O objetivo é compreender as necessidades e problemas dos utilizadores através de interação contínua e derivar daí as soluções certas.

Mas como funciona concretamente este processo de validação de problemas e descoberta de soluções? Sohrab explica que existem vários métodos que se provaram na prática:

1. Entrevistas com clientes: Através de conversas estruturadas com utilizadores, as suas necessidades, desafios e pontos de dor podem ser identificados. É importante não perguntar apenas superficialmente, mas investigar mais fundo e também compreender as motivações subjacentes.
2. Observações: Muitas vezes os utilizadores dizem uma coisa, mas fazem outra. Por isso, é importante observá-los também no seu ambiente natural. Como lidam com as soluções existentes? Onde é que o processo emperra? Que soluções alternativas desenvolveram?
3. Análise de dados: A análise de dados de utilização também pode fornecer insights valiosos. Onde é que os utilizadores desistem? Que funcionalidades são intensamente utilizadas, quais não são? Padrões e anomalias nos dados muitas vezes indicam necessidades não satisfeitas.
4. Prototipagem: Em vez de investir muito tempo no desenvolvimento de uma solução perfeita, empresas bem-sucedidas apostam em prototipagem rápida. Isto permite-lhes obter feedback de utilizadores reais no início do processo e validar ou refutar as suas suposições.

Um exemplo de excelente trabalho de Discovery é o processo de desenvolvimento do Amazon Kindle. Em vez de simplesmente lançar um leitor de e-books no mercado, a equipa do Kindle dedicou-se intensivamente às necessidades e frustrações dos leitores. Através de inúmeras entrevistas com clientes e observações, perceberam que os utilizadores queriam principalmente uma experiência de leitura fluida e semelhante ao papel. Daí surgiram funcionalidades como o display E-Ink especial, a iluminação de fundo e a integração direta da Kindle Store.

Mas Discovery não é um processo único, é uma tarefa contínua. Como Sohrab enfatiza, os Product Managers nas melhores empresas estão em contacto com os clientes quase diariamente - seja através de entrevistas, observações ou outros formatos. Algumas empresas até medem o número de contactos com clientes por semana para garantir que esta interação realmente acontece. Além disso: Mesmo quando se conhecem os problemas dos utilizadores, é uma arte encontrar as soluções certas para eles. Para isso, é preciso coragem para experimentar algo novo e ser criativo.

Segundo Sohrab, empresas como Amazon, Apple ou Google estão constantemente a explorar os limites do possível. Estão dispostas a canibalizar as suas próprias cash cows quando se trata de oferecer aos clientes um novo valor. Um bom exemplo disto é a substituição do iPod pelo iPhone na Apple. Para isso, é necessária uma cultura que promova o espírito de experimentação e a disposição para assumir riscos.

Direction: Como definimos e comunicamos a direção estratégica e as prioridades para o nosso desenvolvimento de produtos?

Mas como é que as equipas sabem em que direção devem evoluir? Aqui entra o terceiro componente do Product Operating Model: Direction.

Como Sohrab explica, uma das tarefas mais importantes dos líderes é definir a direção estratégica e estabelecer o contexto mais amplo. Só assim se pode garantir que as diferentes equipas e iniciativas não trabalham em direções opostas, mas sim na mesma direção.

Mas como é que os líderes definem exatamente esta direção estratégica? Sohrab menciona vários formatos e processos que se provaram na prática:

1. Visão e estratégia de produto: Tudo começa com o desenvolvimento de uma visão de produto clara e inspiradora. Ela descreve para onde a jornada deve ir e que valor o produto deve criar para os clientes e para a empresa. A partir daí, deriva-se uma estratégia de produto que esboça o caminho para realizar a visão.
2. Objectives and Key Results (OKRs): Muitas empresas utilizam OKRs para traduzir a estratégia de produto em objetivos concretos e mensuráveis. A nível de empresa e de equipa, são definidos Objectives (objetivos) que se tornam mensuráveis através de Key Results (resultados-chave). Os OKRs servem como enquadramento de orientação e garantem que todos trabalham na mesma direção.
3. Roadmaps: Os roadmaps de produto são um instrumento importante para comunicar a estratégia de produto e coordenar as atividades de desenvolvimento. Ao contrário do passado, os roadmaps hoje já não são planos rígidos de vários anos. Em vez disso, são regularmente ajustados e servem principalmente para visualizar os próximos passos e prioridades.
4. Reuniões de alinhamento regulares: Para garantir que as equipas estão continuamente alinhadas com os objetivos estratégicos, as reuniões de alinhamento regulares provaram ser eficazes. Aqui, os líderes e as equipas de produto juntam-se para trocar informações sobre o progresso, obstáculos e próximos passos.

Mas tão importante quanto definir a direção estratégica é descentralizar as decisões e movê-las para onde o conhecimento e a proximidade com o cliente são maiores. Porque os tempos em que a direção decidia na sua torre de marfim o que os clientes querem já passaram. Em vez disso, as equipas devem ser capacitadas para decidir por si mesmas como alcançar melhor os objetivos da empresa.

Um exemplo disto é o desenvolvimento de produtos na Amazon. A empresa trabalha com o conceito de decisões Tipo 1 e Tipo 2. As decisões Tipo 1 são grandes decisões estratégicas, difíceis de reverter e, portanto, tomadas pela liderança. As decisões Tipo 2, por outro lado, são decisões táticas menores, fáceis de reverter e, portanto, tomadas de forma descentralizada.

Mas a descentralização das decisões pressupõe que os colaboradores tenham o contexto necessário e as competências certas. "A escalabilidade não acontece através de processos, mas através de pessoas", resume Sohrab. Por isso, os líderes devem fazer principalmente uma coisa: capacitar os colaboradores, dando-lhes contexto, transmitindo-lhes competências e encorajando-os a assumir responsabilidade.

Conclusão: O Product Operating Model não é um sprint, é uma maratona

A implementação de um Product Operating Model está longe de ser trivial. Como mostram os estudos de caso no livro "TRANSFORMED" de Marty Cagan, trata-se de uma transformação que pode levar anos. Porque não se trata apenas de introduzir algumas novas funções e processos. Requer antes uma mudança profunda na cultura, na mentalidade e nas competências de uma organização.

Mas o esforço vale a pena, porque só assim as empresas podem permanecer inovadoras e centradas no cliente a longo prazo. Como Sohrab enfatiza, não há como evitar: "Quem não se transforma, será disruptado." Por isso, as empresas devem começar agora a evoluir passo a passo em direção a um Product Operating Model.

O primeiro passo é criar consciência sobre a necessidade de mudança. Mas depois é preciso passar à ação. Porque, tal como no fitness, o que conta aqui também não é o conhecimento, mas a implementação consistente.

Se queres aprofundar este tema - uma keynote de 30 minutos só pode oferecer uma primeira visão geral - não hesites em contactar a nossa equipa. Estamos prontos para te fornecer mais informações e apoio sobre este tema.