Estrutura de Time de Product Engineering: Como Organizar para Responsabilidade

Seu CEO diz "precisamos shipar mais rápido." Seu VP de Produto diz "a engenharia não entende o cliente." Seus engenheiros dizem "estamos construindo features que ninguém pediu." Todo mundo está frustrado. Ninguém está errado.

Uma estrutura de time de product engineering é um modelo organizacional onde engenheiros são donos dos resultados de produto diretamente, ao invés de receber specs por uma cadeia de handoffs de product managers, designers e coordenadores de projeto. Ela colapsa a distância entre a pessoa escrevendo código é a pessoa (ou dados) que diz qual código deveria ser escrito.

O problema não são as pessoas. O problema é a conexão entre elas. A maioria das organizações de engenharia ainda está estruturada em torno de um modelo que fazia sentido em 2010: product managers escrevem specs, engenheiros implementam, é uma cadeia de handoffs conecta insight do cliente a código shipado. Esse modelo funcionava quando software era caro de construir e lento de iterar. Ele não funciona quando você pode shipar diariamente, quando IA comprime timelines de implementação, e quando a vantagem competitiva mudou de "conseguimos construir" para "estamos construindo a coisa certa." Se você quer entender o papel em si antes de redesenhar times ao redor dele, comece com o que um product engineer realmente é.

Este guia é para diretores de engenharia, VPs e CTOs que querem reestruturar. Sem teoria. Playbook.

Por que a estrutura tradicional não funciona mais

Como os dados da product.engineer mostram, o organograma convencional parece limpo. PM fala com clientes, escreve requisitos, entrega para engenharia, que constrói. Design fica no meio, traduzindo intenção em interfaces. É um modelo de fábrica aplicado a trabalho intelectual.

Aqui é onde ele falha:

Perda de informação a cada handoff. Um estudo de 2022 publicado na Harvard Business Review descobriu que handoffs cross-funcionais introduzem em média 25% de perda de informação por transição. Quando uma necessidade do cliente viaja por PM, design e engenharia, o sinal original está diluído além do reconhecível. O engenheiro construindo a feature nunca ouviu as palavras reais do cliente.

Loops de feedback lentos. Quando engenheiros não veem dados de uso, eles não conseguem corrigir o curso. Eles shipam o que a spec diz, esperam pelo próximo sprint planning, ouvem feedback filtrado por um PM, e ajustam. Isso é um loop de duas a quatro semanas para algo que deveria levar um dia.

Responsabilidade difusa. Quando uma feature falha, de quem é a culpa? O PM que definiu errado? O designer que perdeu um fluxo? O engenheiro que cortou atalhos? Ninguém é dono do resultado porque todo mundo tocou nele. Responsabilidade difusa significa que ninguém sente urgência.

Incentivos desalinhados. PMs frequentemente são medidos por features shipadas. Engenheiros são medidos por velocidade ou qualidade de código. Ninguém é medido por "o problema do usuário foi realmente resolvido?" As métricas puxam em direções diferentes.

Os dados por trás da mudança

Isso não é achismo. Os números contam uma história clara.

De acordo com a pesquisa de produtividade de desenvolvedores da McKinsey de 2023, organizações com alta propriedade do desenvolvedor (definida como engenheiros tomando decisões de produto, não apenas decisões de implementação) shipam 60% mais valor por engenheiro do que organizações com modelos tradicionais de handoff. O blog de engenharia da Stripe de 2024 reportou que após reorganizar em torno de pods de product engineering, o tempo-até-primeiro-commit em novas iniciativas caiu 40%. E o relatório de produto da Amplitude de 2023 descobriu que times onde engenheiros têm acesso direto a dados do cliente cometem 3x menos erros de "construir e matar."

O padrão é o mesmo em todo lugar. Quando engenheiros são donos do problema, não apenas da solução, o sistema inteiro performa melhor.

O modelo de estrutura de time de product engineering

Então como uma estrutura de time de product engineering realmente se parece na prática? Não existe um template único, mas as implementações mais eficazes compartilham características comuns.

O modelo de pods

A unidade fundamental é um pod: um time pequeno, cross-funcional, com propriedade total de uma área de produto. Não uma feature. Uma área. A distinção importa. Um time de feature constrói login. Um time de área de produto é dono de toda a experiência de autenticação e onboarding, incluindo as métricas, os experimentos é o roadmap daquela superfície.

Um pod típico contém:

Perceba o que está faltando: um product manager dedicado. Neste modelo, o product engineer preenche a função de "o que construir" do PM tradicional, mas com a capacidade adicional de prototipar, validar tecnicamente e shipar sem esperar por ninguém.

Como isso difere de "squads"

Você pode estar pensando: "Isso parece squads do Spotify." Não é. O modelo do Spotify ainda assumia PMs e engenheiros separados com responsabilidades distintas. O pod de product engineering funde essas responsabilidades no nível individual. O product engineer não é um PM que codifica. Ele é um engenheiro que pensa em produtos. Esse é um papel distinto com características específicas que vale a pena entender.

Linhas de reporte

É aqui onde líderes ficam nervosos. Para quem o product engineer reporta?

Opção A: Escada única de engenharia. Todo mundo reporta pela engenharia. Product engineers são engenheiros seniores com escopo de produto. É assim que Linear e PostHog operam. Funciona quando a liderança de engenharia genuinamente valoriza pensamento de produto, não apenas profundidade técnica.

Opção B: Reporte duplo (matricial). O pod reporta para um engineering manager para crescimento de carreira e padrões técnicos, mas para um líder de produto para roadmap e priorização. Funciona em organizações maiores onde você precisa de coordenação entre pods. Figma usa uma versão disso.

Opção C: Lead do pod reporta para GM/CPO. O product engineer senior em cada pod reporta diretamente para um general manager ou chief product officer. Esta é a estrutura mais orientada a produto. Funciona quando você quer máxima velocidade e mínimo overhead de coordenação. A Vercel no início operava assim.

Minha recomendação: comece com a Opção A a menos que você tenha mais de 50 engenheiros. A matriz adiciona custo de coordenação que organizações pequenas não podem arcar.

Papéis e responsabilidades no time de product engineering

Deixa eu ser específico sobre o que cada papel faz em uma estrutura baseada em pods. Ambiguidade aqui mata a execução.

O Product Engineer

O product engineer é a unidade atômica deste modelo. Ele é um engenheiro de nível senior (tipicamente equivalente a IC4 ou IC5) que:

• Identifica problemas do cliente por meio de pesquisa direta, análise de dados ou conversas com clientes
• Define o escopo da solução (o que construir, o que pular, o que adiar)
• Escreve e shipa código de produção
• Instrumenta features para medição
• Revisa resultados e decide o que iterar ou matar
• Comunica contexto para o resto do pod

Ele não é um tech lead no sentido tradicional. Um tech lead otimiza para qualidade técnica. Um product engineer otimiza para resultados do cliente, usando qualidade técnica como uma ferramenta entre muitas. Se você está contratando para esse papel, precisa avaliar essa combinação específica de habilidades.

O Software Engineer

Software engineers em um pod de product engineering não são "code monkeys." Eles têm autonomia significativa em decisões de implementação, escolhas de arquitetura e direção técnica. A diferença é escopo: eles focam em profundidade onde o product engineer foca em amplitude.

Um ótimo software engineer neste modelo:

• É dono de subsistemas de ponta a ponta (a integração de pagamento, a camada de sync em tempo real, a infraestrutura de busca)
• Contribui para discussões de produto com viabilidade técnica e soluções criativas
• Cresce em direção a se tornar um product engineer se escolher esse caminho
• Mantém padrões de qualidade técnica para o codebase do pod

O Designer Embedded

O designer não é um bureau de serviços. Ele é um membro do pod. Participa dos mesmos standups, vê as mesmas métricas, ouve as mesmas calls com clientes. Ele projeta em contexto, não no vácuo.

Na prática, muitas organizações não conseguem bancar uma proporção 1:1 de designer por pod. Um padrão comum é um designer que é "baseado" em um pod mas contribui 20-30% do seu tempo para um pod adjacente. O princípio-chave: ele nunca deveria estar a mais de uma mensagem no Slack de distância do engenheiro implementando seu trabalho.

O Analista Fracionário

Letramento de dados é crítico para pods de product engineering, mas um analista full-time por pod frequentemente é exagero. O modelo fracionário funciona: um analista suporta dois a três pods, garantindo que instrumentação está correta, dashboards existem e design de experimentos é rigoroso. Com o tempo, os product engineers em cada pod desenvolvem fluência em dados suficiente para lidar com análises de rotina por conta própria.

A questão da proporção: PMs para engenheiros

Todo líder pergunta: "O que acontece com meus PMs?" Aqui está a resposta honesta.

Em uma estrutura tradicional, você pode ter uma proporção de 1 PM para 5-8 engenheiros. Em uma estrutura de time de product engineering, essa proporção muda drasticamente. Padrões comuns que vi funcionar:

• 0 PMs, modelo PE puro: Linear, PostHog no início, muitas startups YC. Funciona até aproximadamente 30-40 engenheiros.
• 1 PM para 15-20 engenheiros: O PM se torna um "estrategista de produto" que define direção trimestral, gerência comunicação com stakeholders e coordena entre pods. Ele não escreve specs para features individuais. Notion opera algo assim.
• 1 PM por 2-3 pods: O PM foca em coordenação cross-pod, pesquisa de mercado e trabalho de roadmap de horizonte mais longo que nenhum pod individual é dono. O modelo do Shopify se parece com isso.
• PMs se tornam product engineers: Alguns PMs com background técnico fazem transição para o papel de product engineer. Isso é mais comum do que você imagina. Se seu PM consegue ler código, rodar queries SQL e prototipar no Figma, ele pode prosperar como product engineer. Para líderes gerenciando essa transição, mover um time de engenharia existente em direção a product engineering requer sequenciamento cuidadoso.

A verdade desconfortável: na maioria das organizações fazendo essa mudança, você vai precisar de menos PMs. Não zero. Mas menos. Os PMs que ficam são estrategistas seniores, não escritores de specs.

Como reestruturar: uma abordagem em fases

Não reorganize sua empresa inteira na segunda-feira. É assim que você perde suas melhores pessoas. Em vez disso, rode um piloto.

Fase 1: Escolha um pod (semanas 1-4)

Escolha um time que já se inclina para produto. Talvez eles tenham um engenheiro que regularmente questiona specs, fala com clientes voluntariamente, ou tem projetos pessoais que demonstram instinto de produto.

Converta esse time em um pod de product engineering:

1. Remova o PM das decisões de features do dia a dia (realoque-o para coordenação cross-pod ou um time diferente)
2. Dê ao engenheiro senior propriedade explícita do roadmap do pod
3. Conceda acesso direto a dados de clientes, analytics de uso e canais de suporte
4. Defina métricas de resultados (retenção, ativação, contribuição de receita) ao invés de métricas de output (story points, tickets fechados)
5. Proteja o pod de interrupções organizacionais por quatro semanas

Fase 2: Meça e ajuste (semanas 5-8)

Após quatro semanas, avalie:

• O pod shipou mais ou menos do que antes?
• A qualidade melhorou ou degradou?
• Os membros do time estão mais ou menos engajados?
• Os resultados do cliente melhoraram?
• O que pareceu quebrado ou doloroso?

Documente tudo. Você vai precisar desses dados para justificar escalar o modelo.

Fase 3: Escale para dois a três pods (semanas 9-16)

Se a Fase 1 teve sucesso, expanda. Mas não copie o template cegamente. Cada pod terá dinâmicas diferentes. Um pode precisar de mais suporte de design. Outro pode precisar de uma fundação de dados mais forte. Adapte o modelo ao domínio.

Fase 4: Mudança em toda a organização (meses 5-12)

Uma vez que você tenha três ou mais pods operando com sucesso, você tem reconhecimento de padrões suficiente para redesenhar a organização mais ampla. É quando você:

• Redefine níveis de engenharia para incluir competências de propriedade de produto
• Ajusta compensação para recompensar resultados, não apenas complexidade técnica
• Retreina ou transiciona PMs para novos papéis
• Atualiza critérios de contratação (mais sobre isso na seção de contratação)
• Formaliza o modelo de pods no seu organograma

Para organizações enterprise com centenas de engenheiros, o caminho para product engineering em escala tem considerações adicionais sobre governança, compliance e coordenação.

O que eu vi funcionar (e falhar)

Da minha experiência como Sr. Product Engineer na AWS, construindo produtos usados por milhões de desenvolvedores, eu assisti essa transição ter sucesso e falhar em medidas praticamente iguais. Os sucessos compartilham um padrão: liderança se compromete totalmente, mede resultados não outputs, e dá ao pod piloto autonomia genuína. As falhas também compartilham um padrão: liderança anuncia a reorg, remove PMs, mas continua medindo story points e cobrando engenheiros apenas por velocidade de implementação. Isso não é um time de product engineering. Isso é um time de engenharia com responsabilidades extras e nenhuma autoridade extra.

Tendo contratado mais de 600 engenheiros e feito coaching com mais de 12.000 em transições de carreira, o maior preditor de se essa reestruturação funciona é cultural. Se sua cultura de engenharia recompensa "eu fiz o que me pediram eficientemente," você tem uma reprogramação profunda pela frente. Se ela recompensa "eu identifiquei um problema é resolvi," você já está na metade do caminho. As mudanças estruturais seguem a cultura. Nunca o inverso.

Modos de falha comuns

Falha 1: Remover PMs sem adicionar habilidades de produto

Você não pode simplesmente demitir seus PMs e chamar de product engineering. Se seus engenheiros nunca falaram com um cliente, nunca olharam dados de retenção, nunca tomaram uma decisão de priorização, eles vão se perder. A transição requer investimento em desenvolvimento de habilidades, coaching e expansão gradual de responsabilidade.

Falha 2: Tornar todo engenheiro um product engineer

Nem todo engenheiro quer esse papel. Nem todo engenheiro é adequado para ele. Alguns engenheiros brilhantes querem ir fundo em infraestrutura, performance ou design de sistemas. Eles não têm interesse em calls com clientes ou decisões de roadmap. Tudo bem. Uma estrutura saudável de time de product engineering ainda tem espaço para engenheiros que otimizam para profundidade técnica. O product engineer define a direção; outros contribuem sua expertise para a execução.

Falha 3: Manter as métricas antigas

Se você ainda mede cycle time, velocidade e linhas de código, você está incentivando o comportamento antigo. Pods de product engineering devem ser medidos por:

• Resultados do cliente (retenção, NPS, taxas de conclusão de tarefa)
• Resultados de negócio (impacto em receita, redução de custo)
• Cadência de shipping (não pontos de velocidade, mas releases reais que chegam aos usuários)
• Velocidade de experimentos (quantas hipóteses testadas por trimestre)
• Tempo-até-insight (quão rápido o time aprende se algo funcionou)

Falha 4: Pods sem limites

Todo pod precisa de um domínio claro. Quando dois pods podem plausivelmente ser donos de uma feature, você tem conflito, trabalho duplicado e manobra política. Defina limites explicitamente. Documente-os. Revise-os trimestralmente.

Falha 5: Sem caminho de escalação

Pods vão discordar entre si. O roadmap de um pod vai conflitar com a estratégia da empresa. Alguém precisa desempatar. Na maioria das implementações bem-sucedidas, esse é um diretor de engenharia ou VP que revisa roadmaps dos pods mensalmente e resolve conflitos. Sem isso, você tem otimização local às custas de coerência global.

Compensação e escadas de carreira

Você não pode rodar uma estrutura de time de product engineering em uma escada de carreira antiga. Se seus critérios de IC5 ainda dizem "projeta sistemas distribuídos complexos" sem qualquer menção a impacto de produto, você está incentivando o comportamento errado.

Reescreva sua escada de engenharia para incluir propriedade de produto em todo nível acima de IC3:

• IC3 (Engenheiro mid-level): Contribui para discussões de produto. Entende por que uma feature existe, não apenas como construí-la. Olha dados de uso das suas próprias features.
• IC4 (Engenheiro senior / Product engineer): Dono de uma área de feature de ponta a ponta. Identifica problemas, propõe soluções, shipa, mede. Fala com clientes pelo menos quinzenalmente. Consegue escrever um RFC convincente que não-engenheiros entendem.
• IC5 (Staff / Senior Product engineer): Dono de uma superfície de produto inteira. Define metas trimestrais para seu pod. Influencia estratégia de produto no nível da empresa. Mentora outros engenheiros em pensamento de produto.
• IC6 (Principal): Molda a cultura de product engineering em múltiplos times. Define frameworks para tomada de decisão de produto. Sua influência se estende além do seu próprio pod.

Compensação deve refletir isso. Se seus product engineers carregam responsabilidade no nível de PM por resultados de negócio, eles devem ser compensados de acordo. Em empresas como Stripe e OpenAI, product engineers no nível senior ganham 10-20% mais do que engenheiros de infraestrutura de nível equivalente, refletindo o escopo mais amplo é a responsabilidade direta por receita do papel.

Ferramentas e práticas que suportam o modelo

Estrutura sozinha não é suficiente. Você precisa de práticas que reforcem propriedade.

Exposição semanal ao cliente. Todo product engineer deve ouvir diretamente de pelo menos um cliente por semana. Não filtrado por um resumo de PM. Conversa direta, revisão de ticket de suporte ou gravação de sessão.

Dashboards compartilhados, não relatórios. Pods são donos dos seus dashboards de métricas. Eles são públicos para a empresa. Qualquer pessoa pode ver no que um pod está trabalhando, quais são os resultados e se o ponteiro está se movendo.

Decisões guiadas por RFC. Quando um pod quer construir algo significativo (mais de uma semana de trabalho), eles escrevem um RFC curto. Não uma spec. Um RFC que declara o problema, a abordagem proposta, os critérios de sucesso é o plano de rollback. Outros pods podem comentar. Isso substitui o PRD conduzido pelo PM.

Cadência de ship-and-measure. Pods shipam semanalmente no mínimo. Eles medem na semana seguinte. Eles ajustam na semana depois. O loop inteiro é de duas a três semanas, não dois a três meses.

Retrospectivas sem culpa. Quando algo falha (e vai falhar), o time discute o que o sistema perdeu, não quem errou. Isso requer segurança psicológica que a liderança deve proteger ativamente.

Comparação: tradicional vs. estrutura de time de product engineering

Contratação para essa estrutura

Uma vez que você tem a estrutura, precisa preenchê-la com as pessoas certas. Contratar para um time de product engineering é fundamentalmente diferente de contratar para uma org de engenharia tradicional.

Procure por:

• Projetos pessoais que shiparam. Não apenas repos no GitHub com código. Produtos que usuários reais usaram. Isso demonstra a mentalidade de propriedade full-stack.
• Opiniões sobre produto, não apenas código. Em entrevistas, pergunte "O que você mudaria em um produto que usa diariamente?" Candidatos fortes têm opiniões específicas e fundamentadas.
• Conforto com ambiguidade. Dê a eles um problema aberto na entrevista. Veja se fazem perguntas clarificadoras, reduzem o escopo e propõem uma hipótese testável.
• Fluência em dados. Eles não precisam ser data scientists. Mas devem conseguir escrever uma query SQL, interpretar um gráfico de retenção e projetar um teste A/B básico.
• Habilidades de comunicação. Product engineers escrevem RFCs, apresentam para stakeholders e alinham trabalho cross-pod. Se não conseguem comunicar claramente por escrito, não conseguem fazer esse trabalho.

Para um mergulho mais profundo em técnicas de entrevista e critérios de avaliação, veja nosso guia sobre entrevistando product engineers.

Coordenação cross-pod sem burocracia

A maior crítica a modelos de pod é coordenação. "Como seis pods autônomos constroem um produto coerente?" Pergunta justa. Aqui está o que funciona sem reintroduzir a burocracia que você acabou de remover.

Sync semanal de pods (30 minutos máximo). Um representante de cada pod compartilha: o que shipou semana passada, o que shipa semana que vem, onde está bloqueado. Sem updates de status em tarefas individuais. Apenas sinais no nível do pod. Essa reunião substitui o antigo all-hands de engenharia que levava 90 minutos e não realizava nada.

Design system compartilhado. Pods não devem reinventar botões. Uma biblioteca de componentes compartilhada, mantida por um time de plataforma pequeno ou propriedade rotativa, mantém o produto visualmente coerente sem exigir workflows de aprovação de design.

Contratos de API entre pods. Quando o Pod A depende de dados do Pod B, eles concordam em um contrato de API. O contrato é o mecanismo de coordenação, não reuniões. Se o contrato muda, o pod responsável comunica proativamente. Stripe faz isso excepcionalmente bem em suas centenas de microservices.

Revisão trimestral de roadmap. Uma vez por trimestre, leads de pods apresentam seus planos para liderança de engenharia e produto. O objetivo não é aprovação. É detecção de colisão. Dois pods estão construindo a mesma coisa? Alguém está construindo algo que conflita com a direção da empresa? Sinalize aqui, resolva rápido.

Quando não usar esse modelo

Honestidade intelectual importa. Esse modelo não é universalmente correto.

Indústrias altamente reguladas onde decisões de produto requerem revisão de compliance, aprovação legal e trilhas de auditoria podem precisar de PMs dedicados para gerenciar essa coordenação. Um product engineer ainda pode ser dono das decisões técnicas de produto, mas navegação regulatória frequentemente justifica um especialista.

Estágio muito inicial (menos de 5 engenheiros) onde todo mundo já é um product engineer por padrão. Você não precisa de uma estrutura formal quando a empresa inteira cabe em uma sala.

Times de plataforma ou infraestrutura onde o "cliente" são outros engenheiros é as decisões de produto são fundamentalmente técnicas. Aqui, um modelo forte de tech lead funciona melhor do que um pod de product engineering.

Organizações em crise onde a necessidade imediata é velocidade de execução em um plano conhecido, não exploração de novas direções. Se a casa está pegando fogo, você não precisa de alguém para redesenhar a casa. Você precisa de alguém para apagar o incêndio.

Principais conclusoes

• Times de product engineering se organizam em pods pequenos de 5-6 pessoas, cada um com ownership de um espaco de problema de ponta a ponta.
• PMs mudam de escrever specs para coordenacao estrategica, garantindo que pods se alinhem nas prioridades da empresa.
• Cada pod precisa de pelo menos um product engineer senior para definir padroes de qualidade e fazer coaching de julgamento.
• Essa estrutura falha quando aplicada durante execucao de crise que precisa de um plano conhecido, nao exploracao.
• Para uma empresa de 50 pessoas, mire em 4-5 pods autonomos com acesso compartilhado a recursos de design e dados.

FAQ

Qual é a estrutura ideal de time de product engineering para uma empresa de 50 pessoas?

Para uma empresa de 50 pessoas com aproximadamente 25-30 engenheiros, mire em quatro a cinco pods de product engineering de cinco a seis pessoas cada. Cada pod deve ter um product engineer senior, dois a três software engineers, e acesso compartilhado a recursos de design e dados. Você provavelmente precisa de um a dois PMs em um papel de coordenação estratégica, não escrevendo specs mas garantindo que pods se alinhem em prioridades da empresa.

Como papéis e responsabilidades de um time de product engineering diferem de times de engenharia tradicionais?

Em times tradicionais, papéis são separados por função: PMs definem problemas, designers criam soluções, engenheiros implementam. Em uma estrutura de time de product engineering, essas responsabilidades convergem. O product engineer define o problema E constrói a solução. Software engineers contribuem para pensamento de produto enquanto são donos de subsistemas técnicos. Designers são colegas embedded, não prestadores de serviço externos. Todo mundo vê dados do cliente diretamente.

Product engineers devem reportar para liderança de engenharia ou de produto?

Para organizações com menos de 50 engenheiros, mantenha simples: reporte para liderança de engenharia. A escada de engenharia deve incluir propriedade de produto como competência em níveis seniores. Para organizações maiores, uma matriz leve (engenharia para crescimento de carreira, liderança de produto para alinhamento de roadmap) funciona bem. Evite estruturas matriciais pesadas com reporte duplo em decisões do dia a dia, pois elas desaceleram tudo.

O que acontece com product managers em uma estrutura de time de product engineering?

Eles evoluem, não desaparecem. PMs juniores que escreviam specs e gerenciavam backlogs vão ter dificuldade; esse trabalho é absorvido pelos product engineers. PMs seniores que definiam estratégia, conduziam pesquisa de mercado profunda e coordenavam esforços cross-time se tornam mais valiosos, não menos. O padrão mais comum: menos PMs com senioridade maior, focados em estratégia e coordenação ao invés de decisões no nível de features.

Como product vs engineering teams diferem na forma de medir sucesso?

Times de engenharia tradicionais medem outputs: velocidade, taxa de conclusão de sprint, code coverage, uptime. Times de product engineering medem resultados: retenção de usuário, taxa de ativação, receita por feature, taxa de sucesso de experimentos. A mudança de "construímos isso" para "isso funcionou" muda o comportamento diário. Engenheiros começam a perguntar "deveríamos construir isso?" antes de perguntar "como deveríamos construir isso?"

Leitura relacionada

• What Is a Product Engineer? The Definitive Guide
• How to Hire Product Engineers
• Transition Your Engineering Team to Product Engineers
• Product Engineering in the Enterprise
• Product Engineer vs. Software Engineer