Photo by Jukan Tateisi on Unsplash

Começando do começo: Finalmente lendo Marty Cagan.

As percepções de uma arquiteta migrando para produto em 2022 — Parte 1.

Olá! Sou a Cami Abad, uma arquiteta que resolveu migrar para produto.

Oficializei esta decisão no dia 24 de fevereiro de 2022 (considerei oficializada quando contei pra minha mãe, quem nunca?), e desde então venho conversando com várias mulheres que atuam em tecnologia, em sua maioria em produto.

Andei dando umas voltas aqui pelo Medium também, entrei em comunidades, ouvi podcasts e não teve um momento que um livro não tenha aparecido como essencial: Inspirado, de Marty Cagan. Fiquei um pouco receosa e fui empurrando com a barriga, porque desde pequena tive muita dificuldade em sentar e ler coisas que não me atraíam. Fiquei com medo de, mais uma vez, descobrir que estava entrando em algo que eu não gosto. Até que uma hora tomei coragem e comecei a ler. Me encantei.

Porém, como boa acadêmica que tento ser, não consigo reter o conhecimento sem fazer anotações e como boa comunicadora que sou, não consigo fazer anotações sem querer compartilhar com o mundo. Então aqui estou.

Hoje, começo a compartilhar aqui minhas impressões sobre o famigerado "Inspirado", iniciando pela parte 1: Lições das principais empresas de tecnologia.

De cara, autor começa com a reflexão de que estratégia e técnica andam juntas. Ou seja, para que um negócio tenha suas necessidades contempladas, devemos produzir com consciência de mercado aliada à habilidade técnica. Assim, para alinhar as expectativas do negócio à técnica e às necessidades reais dos clientes, alguém precisa estar dedicado à esta tarefa, este alguém, no caso, é o Gerente de Produtos.

É importante compreender o sentido que “produto” toma nos tempos atuais. Nem todo produto movido à tecnologia tem impacto digital, e nem todo produto cujo objetivo está fora do digital é pensado completamente offline. Marty fala que “Muitos dos melhores exemplos de hoje são misturas de experiências online e offline”. Esta fala me impactou bastante, porque vindo da arquitetura e construção civil, tinha um olhar muito binário e limitado sobre a relação entre produtos e serviços. Para mim, produtos digitais eram apenas APPs, enquanto serviços eram apenas uma atividade prestada por alguém. Fazendo uma analogia mais direta, em arquitetura nós, arquitetos, prestamos um serviço: a criação de um projeto arquitetônico, que mesmo o entregável parecendo um “produto”, é apresentado como serviço. Aprofundando meus estudos em produtos, começo a compreender que na verdade o produto em questão estava muito mais relacionado à minha técnica como arquiteta e como eu, a cada projeto entregue, agregava mais valor ao que eu oferecia.

Outra coisa importante é compreender os estágios de uma empresa no mundo da tecnologia. Muito vi sobre startups mas pouco absorvia por não compreender de fato o que era uma. Quando Marty coloca o ponto principal de uma startup, que “ainda está tentando inventar um produto que possa mover um negócio viável”, as coisas começaram a fazer mais sentido para a leiga aqui. E mais uma vez relacionando à minha experiência como arquiteta e urbanista, quando o autor fala que é “estressante, exaustivo e arriscado. Mas pode também ser uma experiência surpreendentemente positiva e, se tudo correr bem, pode haver uma recompensa financeira”, consegui de certa forma compreender e mensurar um pouco do fluxo de uma startup, que em muito se assemelha aos escritórios de arquitetura em fase inicial, onde projetos arquitetônicos quase completos são feitos para prospectar clientes e então receber pelo trabalho realizado. A diferença é: em arquitetura não se fala sobre o MVP. Inclusive, eu não sei se ouvi na graduação ou na atuação profissional algo neste sentido.

Seguindo, compreender o estágio de crescimento de uma empresa em tecnologia também me auxilia a ver o campo ampliado das possibilidades e, como boa "correlatora" que sou, senti falta de conseguir relacionar este estágio à atuação em arquitetura e urbanismo.

Na etapa de consolidação de uma empresa de tecnologia, Marty aponta que o trabalho se direciona mais para a constância inovativa, mantendo a entrega de valor para os clientes. Achei interessante também que o trabalho não foca em otimizar produtos existentes, mas sim no desenvolvimento de produtos que possam alcançar o potencial máximo.

Assim, o autor relata que há falta de satisfação das equipes de produto em empresas que assumem a postura de tomada de decisões “top-down”(usei certo a expressão?), uma vez que as equipes não possuírem autonomia, impacta na agilidade e fluxo do trabalho.

Ao compreender sobre os fracassos dos produtos, Marty inicia com o conceito de cascata. Aqui, já consigo identificar uma correlação muito direta com a arquitetura e na sequência, uma explosão de insights começa a surgir. Há um tempo, vi um escritório de arquitetura oferecendo um curso de metodologias ágeis para arquitetos e fiquei muito confusa, dada a falta de afinidade com tais metodologias. Agora, com esse início de jornada, consigo entender o quão visionário este escritório está sendo.

Bom, seguindo com as percepções sobre a primeira parte do livro, ao explicar como funciona a metodologia de cascata, já é possível identificar onde as falhas acontecem. A começar pela necessidade de previsibilidade que buscamos enquanto montamos um planejamento trimestral ou anual. Mas como prever o que pode acontecer daqui 3 meses? E daqui 1 ano?! No ritmo que a vida vem tomando nos últimos tempos, principalmente durante a pandemia, estes planejamentos, “roadmaps” na linguagem de tecnologia, começam a soar precipitados. Aliado ao modelo cascata, onde o projeto/produto é esquematizado em etapas ordenadas, com baixa ou nenhuma comunicação e produção simultânea entre equipes, qualquer detalhe que não atenda razoavelmente às necessidades do cliente pode significar uma frustração em quem apostou as fichas no planejamento a médio-longo prazo. E aqui venho, mais uma vez, relacionar à minha experiência. Na arquitetura, dividimos o projeto em etapas e fazemos entregas prévias para os clientes, de modo que as expectativas vão se alinhando conforme o projeto vá andando. O problema é que, mesmo com as entregas prévias levam bastante tempo e esforço para serem elaboradas e, não atendendo às necessidades do cliente, geralmente as alterações são bastante onerosas aos profissionais. Claro, não devo ser injusta. Muitas vezes o arquiteto compreende já no briefing as necessidades do cliente, e na hora de alterar a primeira entrega, surgem apenas alguns ajustes pontuais.

Seguindo com o livro, é muito interessante quando Marty menciona 10 problemas recorrentes das empresas:

1. A fonte de ideias centralizada em determinados campos em detrimento da autonomia de outros;
2. Não temos como prever gastos e receitas de um produto que não existe e/ou não foi testado;
3. Duas verdades difíceis mas necessárias: nem toda ideia dá certo e as que dão, demoram pra dar retorno financeiro — e aqui o Marty insere mais um termo pro meu vocabulário tecnológico, o “time-to-money”, ou tempo de capitalização;
4. Empresas que trabalham em cascata não trabalham com gestão de produtos, mas sim com gestão de projetos;
5. O design, situado na cascata, acaba virando apenas visual;
6. Da mesma forma, quando os devs são solicitados apenas para a codificação, suas potencialidades também acabam subutilizadas;
7. O ágil, aparecendo apenas na entrega não traz muita agilidade;
8. Relacionando com o problema 4, “projetos focam entrega, e produtos têm tudo a ver com resultados”, e quando as entregas não agregam valor, não obtemos resultados, ou seja, não entregamos produtos;
9. Quando testamos as ideias no final do processo em vez de irmos testando aos poucos, podemos estar colocando um investimento desproporcional em uma ideia que talvez não dê retorno, uma vez que para chegarmos à entrega de um projeto, foi necessário investimento; e
10. Basicamente, tempo é dinheiro.

Então, Cagan começa a introduzir os princípios das empresas que de fato trabalham com agilidade: Antecipação de riscos, colaboração e resolução de problemas (em vez de incrementar o que talvez não funcione tão bem).

Ao fim da primeira parte do livro, temos a apresentação dos conceitos-chave essenciais para a compreensão dessa jornada.

O primeiro é o Produto Holístico: um produto que compreende a tecnologia, o design de experiência e a capitalização de uma funcionalidade, em vez de focar apenas nela. Então, temos a Descoberta e Entrega Contínuas: um produto precisa sempre estar em pesquisa e em aprimoramento, não é possível delimitar um começo, um meio e um fim. Falando em descoberta, a Descoberta de Produtos (Product Discovery) consiste em “separar rapidamente as boas ideias das ruins. O propósito da descoberta de produtos é um backlog do produto validado”, e para isso, precisamos entender se:

• o cliente precisa disso?
• ele vai saber usar?
• é factível?
• é viável?

Assim, entra o Protótipo, que é uma forma rápida e barata de testar os produtos descobertos através de experimentos não comercializáveis. Então, com a Entrega de Produtos (Product Delivery) conseguimos desenvolver, entregar valor e capitalizar o que já foi testado previamente. No entanto, é importante que tenhamos Encaixe de Mercado (Market Fit), ou seja, um produto real, em menor escala, que responda aos problemas dos clientes de maneira satisfatória. Não confundir com Produto Mínimo Viável (MVP). O MVP, na visão de Marty, seria um protótipo mais polido, no entanto ainda sem potencial de comercialização. Ele é um protótipo de teste mais direcionado ao cliente final, no entanto, não deve ser comercializado.

Por fim, temos a Visão de Produto (Product Vision), que “se refere ao objetivo de longo prazo deste produto, normalmente de 2 a 10 anos. É como nós, como uma área de produtos, pretendemos entregar a missão da empresa”, que é basicamente compreender todo o processo descrito até aqui como essencial para entregar a visão de produto da empresa.

Ufa! Por enquanto é isso. Estou empolgada com essa nova fase!