Para equipes de produto e engenharia, construir um fosso competitivo é um dos aspectos mais críticos do seu trabalho. Mas na period da IA, esse fosso pode evaporar durante a noite.
Quando a IA altera o roteiro do seu produto, você pode perceber que precisa começar do zero. Sua solução unique não é mais viável, então você precisa criar um novo produto nativo de IA que possa competir no longo prazo no novo ambiente tecnológico.
Esta constatação coloca as organizações numa posição difícil, especialmente se tiverem obrigações contratuais com os seus clientes existentes. Como você equilibra seus recursos de engenharia para buscar a inovação em IA e, ao mesmo tempo, oferecer suporte ao seu produto existente? Como você resolve quando desligar a tomada e apostar tudo em uma solução de IA?
Há um ano, minha equipe de engenharia enfrentou exatamente esse desafio. Sabíamos que precisávamos construir um novo produto de IA para substituir a nossa plataforma existente, mas também tínhamos que manter os nossos compromissos com uma base de clientes para manter a nossa receita existente.
Veja como gerenciamos isso, o que eu faria de diferente se pudesse fazer tudo de novo e o que as empresas podem aprender com nossa experiência.
Manter seu produto enquanto se desenvolve na neblina
Devemos esclarecer duas ideias antecipadamente:
- Quando falamos sobre a construção de um novo produto de IA, não estamos falando sobre incorporar recursos de IA em uma solução legada. A IA é uma tecnologia transformacional, e as empresas que tentam proteger as suas apostas atualizando os seus produtos existentes com capacidades de IA estão fadadas ao fracasso. Produtos e recursos que são verdadeiramente nativos de IA inevitavelmente vencerão aqueles que ainda têm um pé preso no passado.
- Também vale a pena reconhecer que a melhor estratégia possível é arrancar o Band-Help, encerrar imediatamente o produto anterior e começar do zero com a solução de IA. No entanto, esta não é uma opção viável para muitas empresas, quer porque têm a obrigação authorized de continuar a servir os seus clientes, quer porque não podem arcar com a queda nas receitas que resultaria da descontinuação da sua solução unique.
Assim que percebemos que precisávamos construir um produto de IA, bifurcamos nossa organização de engenharia. Em vez de os engenheiros dividirem o seu tempo entre o suporte ao produto antigo e a construção do novo, dividimo-nos em duas equipas: uma que se concentraria inteiramente na inovação e outra que se concentraria em manter as luzes acesas para os nossos clientes.
Ambas as equipes tiveram uma visão clara. Para a equipe de IA, os objetivos eram óbvios, mesmo que as etapas para alcançá-los fossem tudo menos isso. Precisávamos “construir a névoa”, trabalhando para criar uma solução de IA que substituísse e melhorasse nossa ferramenta anterior. A equipe que ficou para trás também tinha uma missão importante: precisava determinar até que ponto poderíamos reduzir nossos recursos e, ao mesmo tempo, continuar a executar o produto existente. Esperávamos eventualmente transferir todos os engenheiros para o novo produto, por isso precisávamos entender o quanto poderíamos reduzir a equipe que ficava para trás e com que rapidez poderíamos formar a equipe de inovação.
Procuramos características-chave ao decidir como contratar cada equipe. Para a equipe de inovação, procuramos funcionários que fossem avançados em IA e mostrassem que eles se sentiriam confortáveis trabalhando na ambiguidade. Também contratamos funcionários com habilidades em design de UI para nos ajudar a alcançar um produto mínimo viável.
Por outro lado, reconhecemos que alguns funcionários se sentiam muito mais confortáveis no ambiente SaaS existente. Esses funcionários tinham conjuntos de habilidades específicas que os ajudaram a operar no ambiente legado e se sentiam muito menos confortáveis trabalhando sem especificações e expectativas claras. Há também alguns funcionários que tiveram que ficar para trás porque seu conhecimento period important para operar o produto existente – aqueles que entendiam o pipeline de huge knowledge e as integrações com parceiros-chave.
No que diz respeito aos nossos clientes, tudo continuou como sempre, mesmo quando estávamos fazendo mudanças radicais de engenharia. Entramos em contato com nossos clientes quando ficou claro que não haveria desenvolvimento de novos recursos no produto legado; a essa altura, a equipe de inovação havia feito progresso suficiente para termos confiança de que poderíamos transferir os clientes para a nova solução.
A comunicação é essential
Dividir uma organização de engenharia em duas não é fácil e você precisa de tempo para comunicar a lógica por trás de suas decisões de pessoal. Quando nos dividimos em duas equipes, alguns membros da equipe que ficou para trás sentiram que estavam sendo enviados em uma missão só de ida ao sol – construir um produto que já estava morto.
Para muitos dos nossos engenheiros, o seu trabalho é mais do que apenas um contracheque, e eles lutaram com a ideia de que não trabalhariam imediatamente no produto que representava o futuro da empresa. Fizemos questão de explicar o valor do trabalho que continuariam a realizar: a empresa tinha uma necessidade important de manter as suas obrigações contratuais; igualmente importante, se a equipe que ficou para trás fez bem o seu trabalho, nossa base de clientes existente deveria servir como nossa maior fonte de leads à medida que migramos para o novo produto.
Também explicamos antecipadamente a visão para reunir as duas equipes novamente, ao mesmo tempo em que fornecemos atualizações regulares sobre quando essa transição poderia ocorrer. Essa luz no fim do túnel foi elementary para manter o ethical em toda a organização.
Melhores práticas para um pivô de IA
Nossa mudança para a IA foi bem-sucedida, mas não foi isenta de desafios ao longo do caminho. Aqui estão quatro práticas recomendadas que aprendemos com a experiência, incluindo alguns erros que não gostaríamos de repetir:
- Comece identificando quem realmente precisa se mudar e quem realmente precisa ficar: Pode parecer complicado olhar para uma organização com dezenas de engenheiros e decidir como dividi-los em duas equipes. Você não precisa tomar todas as decisões imediatamente. Você será mais bem atendido identificando os engenheiros que realmente precisam migrar para o novo produto e, em seguida, enviando-os como uma equipe de tigres para estabelecer as bases. Você também deve identificar os funcionários que realmente precisam ficar para manter o produto unique funcionando. Dessa forma, você pode dedicar um pouco mais de tempo em algumas das decisões menos claras e terá a certeza de que quaisquer erros cometidos não terão consequências catastróficas para o produto legado.
- Divida as equipes existentes: Pode ser tentador transferir equipes inteiras dentro de sua organização de engenharia do produto antigo para o novo, mas desaconselho fortemente isso. Não subestime o alcance da mudança que você está fazendo. Se as pessoas permanecerem em ambientes e estruturas que consideram confortáveis e se mantiverem os rituais existentes, terão muito mais dificuldade em abandonar o que conhecem e abraçar uma nova forma de trabalhar. Se eu pudesse fazer tudo de novo, dividiria as equipes por padrão e as moveria individualmente para novas equipes.
- Comunicar, comunicar, comunicar: Mencionei isso acima, mas vale a pena repetir. Nem todos estão preparados para prosperar num período de transformação. Fornecer atualizações regulares sobre o rumo da organização e seu desempenho ajuda seus funcionários a encontrar estabilidade quando as coisas parecem caóticas.
- Nem todos irão abraçar a nova visão – tudo bem: Algumas pessoas são excepcionais no desempenho de funções específicas em ambientes SaaS legados. É justo esperar que essas pessoas assumam um novo papel num mundo para o qual não se inscreveram? Perdemos alguns funcionários que não estavam entusiasmados com a nossa nova visão e que queriam encontrar um trabalho com o qual se sentissem confortáveis. Isso é completamente compreensível e não houve ressentimentos. Mas é importante que essas pessoas reconheçam a sua situação e procurem outro lugar – neste mercado competitivo e em rápida evolução, não há espaço para alguém que não esteja disposto a correr a toda velocidade na nova direção.
Empresas em todo o mundo estão a enfrentar um ponto de ruptura da IA, percebendo que os seus produtos existentes não serão competitivos no novo ambiente tecnológico. Esse é um momento assustador. Para sobreviver, você precisa dar um salto de fé e confiar que seus engenheiros serão capazes de superar a neblina e sair do outro lado. A única maneira de garantir o fracasso é recusar a adaptação.