Triple Track Agile: uma combinação de Problem Space com Solution Space

Um olhar sobre desenvolvimento de produto e inovação

[Texto de 18/abril/2020]

Início

Em julho/2018 cunhei o termo Triple Track Agile ao publicar um post em inglês para reforçar o Problem Space junto ao Dual Track Agile, e por isso adicionando uma trilha com seu próprio ritmo.

Publiquei de forma simplista, pouco texto e apenas fotos de slides que eu havia rabiscado para compartilhar com mais pessoas e fazer a ideia girar para colher feedbacks.

Porém, além de não estar em português não explorava tão bem alguns pontos.

Com o lançamento de um episódio que participei para trocar uma ideia com o Paulo Chiodi sobre essa ideia de Triple Track Agile no podcast Product Guru’s em abril de 2020, resolvi publicar esse texto para estruturar e aprofundar mais o que está por trás do nome.

Sumário:

• O que é o Triple Track Agile e o que ele resolve?

• Problem Space

• Solution Space — Discovery

• Solution Space — Delivery

• Execução sequencial, em paralelo ou fora de ordem?

• Como implementar o Triple Track Agile?

• Ferramentas

• Observações sobre linguagem e termos utilizados no texto

O que é o Triple Track Agile e o que ele resolve?

É um mapa conceitual, processo ou metodologia — depende como enxergamos e nos atemos à isso — que distribui o desenvolvimento de produto em três trilhas:

• Problem space — Mapeamento de necessidades das pessoas em relação a uma intenção ou Job;

• Solution Space — Discovery — Descoberta da solução mais adequada;

• Solution Space — Delivery — Execução e entrega da solução.

Ele é uma expansão do Dual Track Agile — que ficou conhecido através de Jeff Paton e Marty Cagan — com uma trilha de Problem Space inserida no início.

A inclusão da trilha de Problem Space antes das trilhas de Solution Space (Discovery e Delivery), foi feita para evitar nos perdermos na exploração de ideias e otimização de soluções, e nos esquecermos do que de fato queremos resolver e quais são as necessidades das pessoas.

— Você já passou por aquele momento de não ter clareza em como evoluir o produto, não saber como inovar e nem saber quais são as necessidades das pessoas que o seu produto poderia resolver de melhor forma?

— Já sentiu falta de ter algum mapa de oportunidades de problemas a resolver para assim pensar em soluções de forma mais direcionada?

O Triple Track Agile é uma abordagem para te apoiar nesses desafios.

Representação do Triple Track Agile

Curiosidades

• Dual Track Agile: o Dual Track Agile foi inspirado no trabalho de Desiree Sy.

• Triple Track Agile: a inspiração para o Triple Track Agile veio principalmente de trabalhos e representações de Problem Space com o Solution Space da pesquisadora de Problem Space e autora Indi Young. E também inspiração de trabalhos de Dan Olsen, autor e consultor na área de produto.

• Double Diamond: o Triple Track Agile tem semelhanças com a abordagem de design Double Diamond — Divergir/Pesquisa + Convergir/Síntese + Divergir/Ideação +Convergir/Implementação — pensando no processo de desenvolvimento de produto com times multidisciplinares.

• Em 14/maio/2021 descobri que Dave Malouf publicou um artigo em 26/junho/2018, pouco antes do meu texto em inglês em 15/julho/2018 sobre “tri-track”, com uma trilha de “Design Operations” onde aconteceria o “entendimento” do problema: “I created tri-track: parallel to and integrated with discovery and delivery is a third track, understanding. On this track, we align on a strategy for building the “right” thing based on user needs and team insights”.

• A Ilegra publicou um texto com o termo “Triple Track Agile” em 24/setembro/2020. Em conversa com pessoas de lá em 14/maio/2021, me disseram que já usavam esse nome internamente sem inspiração no que eu já havia publicado. A empresa utiliza uma trilha de “foundation” no TTA: onde também há trabalhos envolvendo “escalabilidade das soluções, arquitetura, DevOps, novas tecnologias, plataformas de testes, tecnologias”. A terceira trilha da Ilegra é diferente do que descrevo e se tornou amplamente divulgado no mercado como “Triple Track Agile”.

Problem Space

O objetivo da trilha de Problem Space é entender o espaço do problema e desprender das soluções.

Como definir o problema que queremos resolver e fazer ideações se não entendemos bem esse espaço do problema?

Em 2018 publiquei um texto com o título “Nós realmente estamos priorizando as coisas mais importantes para os nossos produtos?” que aborda sobre esse tema. Se puder, dê uma pausa para ler e volte em seguida.

“A verdade é que a inovação nunca é um evento único e o ‘momento eureka’ é em grande parte um mito. A inovação sempre envolve combinações, por isso é menos uma questão de apresentar uma grande ideia do que reunir as ideias certas para resolver um problema significativo. Isso é um processo, não um momento. Por isso, em vez de começar com uma ideia, é melhor começar encontrando um bom problema.” — Greg Satell

Para essa trilha, entrevistas são utilizadas para mapear as necessidades, princípios norteadores, voz interior e emoções de um grupo de pessoas em torno de um Job ou intenção.

A pesquisadora e autora Indi Young, recomenda em seu texto “When to be Hasty with Product Research” que o ciclo de Problem Space “funcione separadamente. Lentamente. Em pequenos incrementos. Com uma cadência que faz sentido para o que você quer saber e quando precisa saber. Isso significa pequenas interrupções no desenvolvimento de produtos de vez em quando onde sua equipe entra na mente das pessoas”.

Ou seja, essa trilha rodará continuamente em seu próprio ritmo à parte e em paralelo às trilhas de Solution Space — Discovery e Delivery.

No Problem Space o aprendizado se constrói aos poucos e é duradouro. Ele não se perde com simples mudanças da tecnologia pois não é acoplado a qualquer solução.

A tecnologia pode mudar, o contexto das pessoas pode mudar, porém você possivelmente você ainda terá alternativas para explorar no Problem Space.

Essa trilha permitirá sua empresa atender melhor seu público, inovar, diferenciar o produto no mercado e até salvar o seu negócio.

Ela ajuda evitar que sua empresa fique orientada apenas a números, taxas de conversão ou funcionalidades. E também evita que fique rodando apenas em torno de ideias e apostas, sem um entendimento melhor sobre as necessidades do seu público.

Na área de produto seu propósito não deveria ser colecionar o máximo de ideias e entregar o máximo de features, e sim descobrir quais as necessidades são mais importantes para o seu público e quais ainda não são bem atendidas. Depois, alinhadas com sua estratégia de negócio, descobrir a ideia mais apropriada para solucioná-las.

“Normalmente, as organizações se concentram muito em seus ciclos de desenvolvimento, o que significa que gastam a maior parte de sua energia circulando em torno das ideias que têm. Os ciclos Think-Make-Check giram em torno de ideias ou soluções. Eles não giram em torno de pessoas. Se você quiser equilibrar esse foco nas soluções, você pode introduzir um ciclo separado de empatia que se concentra nas pessoas e em seus propósitos. Em outras palavras, estude o espaço do problema além do espaço da solução“ — Indi Young, no livro Practical Empathy: For Collaboration and Creativity in Your Work.

Atividades realizadas nessa trilha

Abaixo são algumas possíveis atividades realizadas nessa trilha:

• Realização de pesquisas de Problem Space;

• Análise e síntese do resultado das pesquisas;

• Criação de um mapa para estruturar todas descobertas;

• Compartilhamento do mapa com as pessoas da empresa;

• Descoberta e definição de oportunidades baseadas no mapa;

• Envio das oportunidades para a trilha de Discovery.

Processos e artefatos da trilha

A experiência de uma pessoa em realizar entrevistas e pesquisas faz diferença nessa trilha. É muito fácil influenciar resultados, reforçar vieses, gerar interpretações errôneas ou interpretar suposições como verdades absolutas.

Critérios para selecionar pessoas para entrevistas:

• Qualquer pessoa que busque resolver o mesmo problema que seu negócio deseja resolver ou já resolva, e não apenas usuárias da sua solução;

• Pessoas que tomaram alguma ação relacionada a esse problema recentemente: 1 a 3 meses atrás.

Dicas para entrevistas:

• Evite conversas sobre soluções;

• Foque no espaço do problema e entenda as necessidades, princípios orientadores, voz interior e emoções das pessoas relacionados ao Problem Space;

• Evite perguntas e respostas sobre suposições. Busque experiências recentes.

Se deseja começar de um jeito simplificado, comece pela alternativa 1 abaixo.

Se deseja utilizar metodologias aprofundadas e próprias para Problem Space, experimente as outras alternativas.

1 — Simplificada:

Comece escutando e entrevistando as pessoas selecionadas. Uma dica é dar uma olhada no Kit de perguntas e focar nas perguntas de Problem Space.

Registre as respostas. Nesse processo não faça suposições. Registre o que foi falado pelas próprias clientes. Se possível, em primeira pessoa, como elas mesmo falando.

Depois de conversar com algumas clientes e registrar as conversas, descubra os padrões que surgiram das necessidades delas e registre esses padrões agrupados por temas.

Próximos passos:

• Crie um documento estruturado com os aprendizados coletados que facilite o entendimento para quem for ler;

• Atualize e enriqueça esse documento a cada novo ciclo de entrevistas e aprendizados do Problem Space;

• Classifique os padrões encontrados;

• Disponibilize o documento com as pessoas da empresa em um local de fácil acesso.

• Compartilhe com o time os insights que você for ganhando dessas conversas.

Continue rodando a trilha indefinidamente sempre que puder e precisar aumentar o conhecimento sobre o Problem Space.

Com o tempo você irá refinando suas habilidades, melhorando o resultado das entrevistas e do artefato que está gerando.

Se você é uma Product Manager e sua empresa tem alguma Researcher, convide-a para participar e até liderar a trilha com sua colaboração e acompanhamento. Se ela é uma Researcher mais voltada à contexto de solução, compartilhe com ela materiais sobre formas de estudar o Problem Space.

Se você é uma Researcher, convide uma líder de Produto para acompanhar as entrevistas e resultados.

Se você tem qualquer outro papel na empresa, converse com uma Product Manager ou Researcher sobre a trilha de Problem Space para medir o interesse delas para iniciarem a trilha.

Caso perceba que não tenham interesse e você deseja experimentar por si mesma, avalie se você pode tirar algumas horas por semana (exemplo: 2 horas) para conversar por vídeo ou telefone com as pessoas selecionadas.

Referências que podem ajudar para criar empatia e realizar pesquisas de Problem Space:

• Talking to Humans: Success starts with understanding your customers

• Just Enough Research

• Practical Empathy: For Collaboration and Creativity in Your Work

• Listening Well: The Art of Empathic Understanding

2 — Jobs To Be Done:

Se você deseja fazer algo mais estruturado e aprofundado, uma alternativa é utilizar a lente de Jobs To Be Done (JTBD) para o Problem Space.

Para ter uma ideia rápida sobre JTBD:

• “Um Job pode ser um objetivo, uma meta ou uma tarefa, um problema a ser resolvido, ou algo para ser evitado, uma meta de “Ser ou Fazer”, ou qualquer outra coisa que as pessoas estão tentando realizar” — Tony Ulwick.

• A premissa básica é que as pessoas não compram produtos e serviços apenas por suas funcionalidades ou atributos, elas os contratam para realizar um “Job”.

• Um “Job” é estável ao longo do tempo.

• Um profundo entendimento do “Job” do cliente torna a inovação mais previsível.

Para aplicação prática dessa lente, você pode seguir o processo abordado na minha série sobre Jobs To Be Done. O artefato gerado é um Job Map.

Abaixo está o exemplo de um Job Map que esse processo pode gerar. Nesse exemplo o mapa foi feito para o Job “chegar a um destino a tempo”, contendo etapas para executar o Job e uma lista de necessidades descobertas em uma das etapas.

Com o Job Map acima você pode determinar as oportunidades que irá focar, como descrito nesse artigo, e validar soluções para elas.

Se você tem interesse em saber mais sobre essa abordagem de Jobs To Be Done, consulte essas referências:

• E-book Estratégia e Inovação baseadas em Jobs To Be Done.

• Série de textos em português onde avanço desde o que é Jobs To Be Done até sua aplicação prática.

• Livros: Muito Além da Sorte: Processos Inovadores para Entender o que os Clientes Querem, The Jobs To Be Done Playbook e Jobs to be Done: Theory to Practice

• Alguns sites: 1, 2, 3 e 4.

[e-book] Estratégia e Inovação baseadas em JobsTo Be Done

Não confunda o Job Map com mapa da jornada do cliente pois este último foca no processo de compra ou contratação, tendo relação maior com o Solution Space. Isso equivaleria aos Jobs de cadeia de consumo e não ao Job Funcional principal, para o qual o Job Map é criado.

Um Job Map não é um mapa de processo ou um mapa de jornada […]: ele não descreve a jornada que o cliente realiza para comprar, receber, configurar, usar, atualizar, limpar e manter um produto. Essas atividades são tarefas da cadeia de consumo que são capturadas e tratadas separadamente. Se você está focando no processo de compra ou na experiência do cliente, não está focado no trabalho funcional principal. — Tony Ulwick no texto Mapping the Job-to-be-Done

Veja como Jim Kalbach define mapa da jornada de cliente:

Os mapas de jornada do cliente ilustram as experiências de um indivíduo como cliente de uma organização. Eles geralmente incluem a escolha, como a decisão de comprar um produto ou serviço, além de permanecer um cliente fiel. — Jim Kalbach no livro Mapping Experiences

3— Sessão de escuta e diagrama de Modelo Mental (Indi Young):

Essa alternativa segue um processo criado pela pesquisadora de Problem Space e autora Indi Young.

Usando sessão de escuta e montando um diagrama de modelo mental você terá acesso a princípios norteadores, voz interior e reações emocionais do seu público de uma forma estruturada que permitirá tanto criar soluções relacionadas ao modelo mental descoberto quanto apoiará a arquitetura de informação do seu produto, usando classificação e linguagem do próprio público.

Se tiver curiosidade para saber mais sobre o trabalho dela, acesse o site.

Algumas referências para saber mais sobre esse processo:

• Livros: Mental Models e Practical Empathy

• Artigo em português: Sessão de escuta.

Abaixo há um exemplo de diagrama de Modelo Mental em inglês. Se desejar ver em tamanho completo e ampliado, clique aqui.

Na parte de cima ele contém padrões sobre princípios orientadores, voz interior e reações emocionais das pessoas sobre um determinado tópico. E na parte debaixo possui soluções existentes ou possíveis soluções para cada uma das torres acima. A trilha de Problem Space seria responsável pela metade de cima.

Diagrama de Mental Model. Veja completo aqui.

4 — Fit For Purpose

Fit For Purpose é um processo que te ajuda a descobrir os propósitos das pessoas ao utilizar seu produto ou serviço, o nível de satisfação e os critérios utilizados ao avaliar a satisfação.

Você pode aprender mais sobre o framework no livro Fit For Purpose.

5 — Banco de insights

Inspiração do processo que a Fibery.io segue.

Um pouco sobre isso nos textos:

• Mapeamento simples de pesquisas e entrevistas com insights atômicos na ferramenta Fibery.io.

• How Fibery uses Fibery for product development

E mais nesse vídeo do próprio pessoal da Fibery.io:

6 — Demand Side (ou, em português, Lado da Demanda)

Expressão utilizada por Bob Moesta.

Você pode saber mais sobre a linha do Bob Moesta no livro Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress.

Quem participa na execução da trilha de Problem Space?

Depende do seu contexto e como deseja experimentar.

Uma alternativa é ter Researchers e líderes de Produto executando essa trilha.

A liderança da triagem e execução das entrevistas e pesquisas poderiam ficar com a Researcher tendo a participação da Product Manager.

Alinhamento — entre Problem Space e Discovery

Como definir as oportunidades que serão trabalhadas no Solution Space?

A trilha de Problem Space pode gerar uma grande quantidade de informação e possibilidades. Além disso, sua empresa pode ter várias oportunidades de negócio para validar.

Por isso é necessário um filtro.

Os primeiros serão:

• missão da empresa

• e possíveis objetivos de negócio (OKRs globais, por exemplo)

Os próximos dependerá da estratégia que irá utilizar para definir e priorizar o conjunto de necessidades para as quais deseja validar soluções:

• Se você está utilizando um processo de Jobs To Be Done, uma forma de encontrar oportunidades do mercado é seguir com a descoberta de oportunidades baseada no Job Map.

• Senão, avalie quais necessidades acredita que possuem mais oportunidade e arrisque nas que acha mais importante para o negócio. Como exemplo, você poderia utilizar algo como uma matriz de “Valor pro negócio x Valor pro cliente” se esses critérios forem o suficiente pro seu contexto.

Quem participa na decisão estratégica de quais problemas o produto irá resolver?

Depende do contexto, papéis e responsabilidades da organização e estrutura dos times de produto.

É importante que a empresa deixe claro de quem é a responsabilidade por essa estratégia e qual a autonomia da pessoa.

Aqui vão algumas alternativas de quem pode vir a participar da estratégia:

Se os times de produto são divididos por solução (tecnologia, fluxo ou funcionalidade), então será mais difícil saber quais times de produto você precisa envolver no Problem Space e quais líderes.

Nesse contexto uma alternativa é deixar a estratégia mais próxima de uma líder principal de Produto (Chief Product Officer , VP de Produto ou Head de Produto).

Além disso, pode ser importante que ela trabalhe nisso colaborativamente com Group Product Managers ou Product Managers.

Se os times são divididos por segmento de pessoas, Job, atores de um marketplace (fornecedores ou clientes) ou por problemas específicos que precisam resolver, então acredito que uma alternativa seja deixar a estratégia mais próxima das Product Managers que têm relação direta com o escopo do Problem Space.

Pode ser importante que elas trabalhem nisso colaborativamente com as suas líderes de produto.

Solution Space — Discovery

O objetivo da trilha de Discovery é encontrar a solução mais adequada para as necessidades de um público — ou oportunidades de negócio — minimizando os riscos antes de se comprometer com o desenvolvimento completo da solução em Delivery:

• Risco de valor: se as pessoas têm interesse na solução e elas se comprometerão — pagarão ou utilizarão.

• Risco de “execução” ou “realização” (em inglês: feasibility ): se você é capaz de resolver o problema; se é possível construir o que você precisa no tempo, habilidades e tecnologias disponíveis;

• Risco de usabilidade: se as pessoas saberão utilizar.

• Risco de negócio: se a solução é viável em termos de negócio e funciona pra outros aspectos do negócio e dentro dos seus limites e regras.

Algumas perguntas iniciais que podem auxiliar o time:

• Qual o grande problema que estamos querendo resolver? Quais são as principais dores com isso? Quais são as hipóteses?

• De que forma as pessoas resolvem o problema atualmente? O que faria elas desejarem outra solução?

• Como a solução pode ser mais previsível, fácil de utilizar, com maior rendimento ou mais barata para um determinado contexto comparada às soluções atuais que resolvem o mesmo problema?

• Quais suposições estamos fazendo sobre as oportunidades e ideias? O que precisa ser verdade para que essas ideias tenham sucesso?

Faça experimentos da forma mais local, rápida e barata possível.

Nessa trilha o aprendizado é rápido apesar de transitório, pois já está acoplado a soluções, e conforme a tecnologia avança, novas soluções podem ser mais adequadas.

Como priorizar as oportunidades?

Abaixo citarei alguns frameworks, não como recomendação, mas como ideias do que se pode utilizar.

Priorizar suposições atuais que precisam ser validadas:

• Assumption Mapping

Estruturar e priorizar oportunidades e soluções para validação e experimentação:

• ICE : Impact (Impacto), Confidence (Confiança) e Easy (Facilidade). Para medir “Confidence” você pode utilizar esse medidor de confiança.

• GIST Framework

• Opportunity Solution Tree

• JTBD Growth Strategy Matrix

• Cup Method

Quem participa na execução da trilha de Discovery?

Depende do seu contexto e como deseja experimentar.

Irei explorar algumas alternativas abaixo.

Alternativa A:

Uma alternativa é ter um time fixo contendo a Product Manager, uma Product Designer e uma Desenvolvedora — podendo ser um Tech Lead ou uma desenvolvedora sênior — fazendo validações, experimentos e definição de iniciativas. A Product Designer e Desenvolvedora poderiam atuar em Delivery quando não tiverem iniciativas em Discovery.

A Product Manager poderia ter as seguintes responsabilidades:

• decidir as iniciativas que irão para Discovery;

• mitigar os principais riscos das iniciativas junto com a Product Designer e Desenvolvedora;

• garantir as informações necessárias para cada iniciativa.

Nada impede dessas responsabilidades estarem distribuídas entre outros papéis.

Alternativa B:

Product Manager se mantém. Já a Product Designer e a Desenvolvedora são trocadas, fazendo rodízio, a cada oportunidade a ser validada.

Alternativa C:

Uma outra alternativa é o time multidisciplinar inteiro de Delivery também realizar Discovery.

Nessa alternativa, algumas das ideias abaixo podem te ajudar a montar um processo com o seu time dependendo da etapa.

Entendimento do problema:

• artefatos e evidências compartilhados com o time para todos estudarem assincronamente. Podem discutir assincronamente também ou se juntar apenas para discutirem;

• ou, time se junta para ler o material juntos — com um tempo para cada um ler em silêncio — e após isso discutem sobre o que leram.

Ideação:

• time inteiro junto numa dinâmica;

• ou, “pitch” assíncrono de iniciativas com prazo determinado para avaliação dos pitches.

Formação de pequenos grupos:

• diferentes grupos (2 a 3 pessoas) trabalhando em diferentes ideias em paralelo para validá-las;

• ou time inteiro trabalhando para validar uma ideia por vez, cada pessoa ajudando com sua especialidade em uma parte da validação.

Assim que uma ideia passar da validação inicial e ganhar confiança para atender uma oportunidade:

• o time inteiro pode se juntar e avançar nas próximas etapas de validação da ideia até ela ganhar confiança para ir para Delivery ou ser descartada.

• ou, continuam em grupos paralelos e apenas as pessoas que iniciaram a validação daquela ideia vão até o fim para confirmar ou descartar.

Assim que uma ideia for validada o suficiente e estiver pronta para Delivery:

• o time todo pode decidir focar em Delivery para entregar essa iniciativa;

• ou, um grupo de 2 a 3 pessoas foca em Delivery dessa ideia e as outras pessoas continuam em Discovery validando outras oportunidades;

• a ideia pode ficar aguardando pra ser iniciada em Delivery e as pessoas que estavam envolvidas na ideia validada podem ajudar a validar outras oportunidades com o restante do time.

O apoio de outras especialidades pode ser importante dependendo do contexto.

Referências para aprofundar na trilha de Discovery

Artigos sobre Discovery:

• Um roteiro prático para Product Discovery & Validação de ideias

• Como descobrir a ideia certa? — Compilado em português do livro The Right It

• A guide to mapping assumptions for product development teams

• Canvas para Problem Space + Solution Space

• Mapping: An introductory guide for product teams

Artigos sobre processos de Discovery:

• Mission Driven Development

• Product Discovery — ​A Practical Guide for Agile Teams

• Testing Product Ideas

• Why you should stop using product roadmaps and try GIST Planning

• Design Sprint

• Why This Opportunity Solution Tree is Changing the Way Product Teams Work

Livros:

• The Right It: Why So Many Ideas Fail and How to Make Sure Yours Succeed

• The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback

• Inspired: How to Create Tech Products Customers Love

Refinamento — entre Discovery e Delivery

Ao levar uma iniciativa de Discovery para Delivery é importante termos respondido e confirmado algumas questões.

• Iremos quebrar a iniciativa em partes? Como serão priorizadas as entregas? Realizar User Story Mapping pode ajudar o seu time a quebrar a iniciativa em algumas partes e definir o que será prioridade.

• Temos evidências sobre as necessidades que estamos resolvendo? Ou, temos hipóteses bem declaradas sobre isso? Ou, temos uma visão forte o suficiente para assumir o risco do que desejamos realizar?

• Existe uma decisão difícil que devemos resolver com antecedência para que não atrapalhe a equipe? (decisão pré-tomada sobre os limites do escopo: o que não desenvolver ou explorar; decisão técnica: o que manter simples; etc)

• Isso vai exigir um trabalho técnico que nunca fizemos antes?

• Estamos fazendo suposições sobre como as coisas se encaixarão no final? Se sim, como podemos validá-las antes ou minimizar os riscos?

• Imaginando que o desenvolvimento da solução falhou, o que poderia ter dado errado? Antecipe e evite as possíveis falhas.

• Estamos assumindo uma solução que não poderíamos criar?

• O que desejamos nessa entrega mas é nice-to-have? Coisas que podemos deixar de fora se necessário mas ainda conseguiremos entregar valor.

Solution Space — Delivery

O objetivo nessa trilha é a execução correta.

O aprendizado aqui é tardio e transitório, porém, ao mesmo tempo é a palavra final para saber se de fato conseguirá executar, escalar, automatizar e integrar o produto para atender as necessidades do público, se de fato terá um público comprometido com sua solução.

A cada entrega nessa trilha, novas evidências surgem e nos dão mais insumo para a trilha de Discovery e até novas questões para explorar no Problem Space.

Quem participa na execução da trilha de Delivery?

Depende do seu contexto.

Em geral, numa empresa de produto digital, há no mínimo Product Designers e Desenvolvedoras.

Uma ideia é minimizar a participação da Product Manager em Delivery, dando mais autonomia para uma Product Designer, Tech Lead ou uma analista QA liderar a execução dessa trilha.

A Product Manager poderia ter as seguintes responsabilidades:

• decidir as iniciativas que irão para Delivery;

• garantir as informações necessárias para cada iniciativa.

Nada impede dessas responsabilidades estarem distribuídas entre outros papéis.

Como exemplo, aqui está uma lista informações que podem ser necessárias para as iniciativas dependendo da situação:

• problema a ser resolvido;

• hipóteses;

• evidências atuais;

• descrição da solução e regras de negócios;

• rascunho bruto da solução: conceitos e fluxos;

• fronteiras da iniciativa / limites do escopo;

• endereçamento de riscos;

Product Designers e Desenvolvedoras da trilha de Delivery ficariam responsáveis por quebrar as iniciativas em pequenas tarefas, executarem e validarem antes de entregar o resultado. E, caso tenha uma analista QA, ela também apoiaria na validação durante o ciclo.

No Delivery, a Product Manager:

• participaria do kickoff do ciclo de desenvolvimento;

• acompanharia esporadicamente o progresso do trabalho do time;

• participaria da apresentação final do que foi entregue.

Referências para a trilha

A trilha de Delivery é a mais comum nas empresas. Apesar de saber que muitas empresas ainda possuem desafios com essa trilha, talvez seja a trilha que mais possua materiais e frameworks disponíveis na internet.

Atualmente é muito comum ouvir sobre Scrum e Kanban nessa trilha. Quem não sabe o que significa, vale a pena dar uma pesquisada e avaliar o quanto podem te ajudar.

Mas aqui deixarei referências menos conhecidas sobre processos para a trilha de Delivery:

• Shape Up: Stop Running in Circles and Ship Work that Matters

• Mission Driven Development

• This Is How We Manage Projects on a Fully Remote Team

• How we structure our work and teams at Basecamp

• Fluid Scaling Technology for Agile

[Dúvidas comuns]

Execução sequencial, em paralelo ou fora de ordem?

Apesar das trilhas serem conceituadas iniciando por Problem Space e seguida por Discovery e Delivery (ambas Solution Space), não necessariamente você seguirá nessa ordem estrita em toda situação.

Claro, analisando teoricamente faz todo sentido começarmos pelo Problem Space, avançarmos pro Discovery e irmos pro Delivery.

Porém, na prática, podemos acabar tomando decisões diferentes.

Avalie seu contexto

Você pode iniciar as trilhas em ordem diferente.

Tudo depende do quanto conhece do seu mercado, do quanto está disposta a tomar riscos, do quanto tem uma visão forte para algo e do quanto está preparada para apostar (dinheiro e tempo).

Iniciar por Discovery e rodar o Problem Space em paralelo

Se você tem uma hipótese clara e sabe como validá-la rapidamente, você pode decidir começar pelo Discovery e logo em seguida começar a rodar a trilha de Problem Space para ir coletando evidências e mapeando mais aprofundadamente as necessidades do público que independem da sua solução.

Para começar por Discovery, essas duas referências abaixo podem te ajudar:

• Como descobrir a ideia certa? — Compilado em português do livro The Right It, do autor e ex-diretor de engenharia na Google,

  Alberto Savoia

  .

• Um roteiro prático para Product Discovery & Validação de ideias

Iniciar por Delivery

Se você tem um produto maduro e deseja adicionar funcionalidades simples, por exemplo, você pode acabar decidindo ir direto pelo Delivery baseada em sua visão do que acredita ser importante e útil junto com o conhecimento adquirido do seu mercado e público ao longo do caminho.

Quanto mais complexa ou inovadora uma solução, possivelmente uma boa alternativa é você passar pela trilha de Discovery ou voltar mais e ir para a trilha no Problem Space buscando entender quais necessidades do público você está resolvendo e qual potencial de oportunidade há nisso.

Algumas perguntas que podem ajudar na decisão de iniciar mais em Delivery ou Discovery:

— O quanto essa iniciativa é arriscada para o negócio?

— O quanto essa iniciativa é reversível?

— Qual o custo de adaptação dessa iniciativa ou de mudança de direção?

— Qual o nosso apetite de tempo para Discovery ou Delivery?

As trilhas de Delivery e Discovery não possuem delimitações tão exatas quanto possa parecer. Há um pouco de sobreposição nelas dependendo do contexto.

Para entender, é mais fácil imaginar um espectro das trilhas de Discovery e Delivery:

De um lado você pode ter Discovery com um pouco de Delivery e do outro pode ter Delivery com um pouco de Discovery.

• Ao validar uma funcionalidade que é executada manualmente por trás dos panos você está descobrindo a melhor forma de resolver uma necessidade e ao mesmo tempo entregando uma solução, mesmo que manual. — Isso é Discovery ou Delivery?

• Ao lançar uma funcionalidade, mesmo que toda integrada, automatizada e na mesma estrutura de performance e escala dentro do seu produto, você pode decidir liberá-la apenas para um grupo pequeno de pessoas para medir o retorno do resultado e colher feedback.— Isso é Discovery ou Delivery?

• E mesmo que libere algo para todo o seu público, de alguma forma você ainda está validando o produto com o mercado enquanto ele existir, já que novas tecnologias ou contextos podem minimizar sua utilidade ou atratividade. — Isso é Discovery ou Discovery?

— O que define com exatidão se algo é Discovery e Delivery?

Tempo investido? Quantidade de evidências? Demanda para a solução? Comprometimento de um público? Qualidade final da solução? Automatização e escala da solução? Certeza sobre a solução de um problema? Complexidade da solução? O tamanho do público que utiliza a solução?

Enfim, toda essa exploração com perguntas foi apenas para demonstrar que as trilhas são uma representação e não limites exatos.

Se você iniciar uma solução mais pro extremo de Delivery no espectro apresentado acima, algumas formas de minimizar os riscos poderiam ser:

• você e as colaboradoras de sua empresa serem usuárias do próprio produto, sentindo as dores como clientes ou serem grandes conhecedoras do domínio de negócio.

• garantir uma solução simples, de baixíssima complexidade e reversível, e que respeite o modelo mental atual das usuárias;

• delimitar o tempo de desenvolvimento: defina qual seu apetite de tempo pra apostar nessa solução, sabendo do risco de falhar e tendo a garantia de poder seguir em frente com outras entregas após o tempo delimitado. O Basecamp, por exemplo, define um apetite de 2 a 6 semanas para vários projetos que desenvolvem em seu produto. Ao final do ciclo, ou o projeto foi entregue ou em geral é engavetado. Se falhar na execução do projeto, você perdeu apenas o período que assumiu como apetite. Se falhar no atendimento de necessidade de cliente, você terá outros ciclos para adaptar.

• estabelecer o limite do escopo: defina qual será o foco para não deixar a solução se tornar mais complexa ou robusta do que o necessário, e para não tentar resolver outras dores não planejadas. Nesse contexto é necessário dar flexibilidade para modelar o escopo dentro do limite estabelecido e garantir autonomia ao time que desenvolverá. É possível que o time precise adaptar a solução e cortar algumas coisas para caber dentro do tempo delimitado para desenvolvimento, mas ainda garantindo a entrega do resultado esperado.

Como implementar o Triple Track Agile?

Triple Track Agile não é um processo prescritivo. É uma abordagem a ser adaptada de acordo com o contexto.

O valor está em entender as ideias das trilhas e refletir como isso pode te ajudar em descoberta de oportunidades, estratégia, minimização de riscos e processo de produto.

Avalie o que foi explorado mais acima em cada trilha, experimente e adapte.

Ferramentas

Gerenciamento de produto e roadmap:

• ProductBoard

• Glidr.io

• Craft.io

Pesquisa:

• EnjoyHQ

Adapte um sistema próprio para gerenciar produto e pesquisas, e muito mais:

• Fibery.io

• Notion.so

• Coda.io

Observações sobre linguagem e termos utilizados no texto

• Linguagem no feminino: utilizei a linguagem no feminino como uma agente socializante de gênero, no intuito de evitar que usando no masculino houvesse uma interpretação de discriminação fundamentada no sexo.

• Termos em inglês: apesar de considerar que em geral termos em inglês são menos inclusivos, acredito que muitos dos termos são comuns em startups de tecnologia — possivelmente o maior público desse texto — e mais entendidos do que os próprios termos em português. Aceito sugestões.

• Iniciativas: referência a algo que defina o que deve ser realizado e qual o resultado esperado em algum ciclo de Delivery. Isso pode acabar sendo chamado de História, Épico, Projeto ou outros nomes em sua empresa.

• Chief Product Officer, Head de Produto, Group Product Manager, Product Manager: usei esses termos para fazer relação a líderes de produto e possíveis níveis hierárquicos. Ao mesmo tempo, as responsabilidades em sua empresa podem estar divididas em papéis diferentes que não sejam esses. Não faço recomendação específica sobre esses termos e nem sobre esses níveis hierárquicos.

• Product Designer: em sua empresa é possível que o papel de uma Designer ou UX/UI Designer tenham responsabilidades e escopo com certa semelhança ao de uma Product Designer.

• Researcher: papel responsável por pesquisas e entrevistas. Em sua empresa pode ser uma pessoa no papel de UX Research ou qualquer outra pessoa que tem essas responsabilidades e habilidades.

• Tech Lead: referência a possível líder de tecnologia, mas podendo ter alguma desenvolvedora sênior fazendo o mesmo papel nesse contexto.

Agradecimento

Agradeço a Laís Lara e Bernardo Srulzon pelas revisões e feedbacks para a publicação e primeira versão desse texto (18/04/2020).