Empresas de software menores tendem a superar seus concorrentes maiores em retorno dos investimentos em P&D. Como as empresas de software podem garantir a escala de P&D, mesmo à medida que crescem? Como resultado, os programas de pesquisa e desenvolvimento estão entre suas funções mais indispensáveis. A empresa média de software gasta cerca de 20% da receita em P&D; Alguns gastam mais de 40%. A eficácia das equipes de P&D - cuidadosamente, sua capacidade de inovar - é em muitos casos o diferenciador mais significativo de uma empresa de software.
Software companies live by the mantra of “innovate or die.” As a result, research and development programs are among their most indispensable functions. The average software company spends about 20% of revenue on R&D; some spend more than 40%. The effectiveness of R&D teams—chiefly, their ability to innovate—is in many cases a software company’s most significant differentiator.
Ao contrário da maioria dos outros aspectos dos negócios, no entanto, a P&D não escala com o tamanho. De fato, pesquisas recentes do BCG mostram que empresas menores tendem a superar seus concorrentes maiores em retorno dos investimentos em P&D e velocidade no mercado. Isso pode parecer óbvio-depois de todas as empresas mais antigas geralmente têm produtos mais maduros em mercados de crescimento mais lento-, mas descobrimos que a maturidade do mercado por si só não explica RDIs em declínio.
Unlike most other aspects of business, R&D doesn’t scale with size.
De fato, as nuances e valores discrepantes em nossa análise nos convenceram de que tivemos que olhar mais profundamente e responder a essas perguntas: o que separa as empresas de software que escalaram com êxito seus P&D dos muitos concorrentes que não o fizeram? Quais são os fatores que atrapalham as empresas à medida que escalam? Finalmente, o que as empresas de software que desejam crescer sem perder a vantagem na inovação fazem para resolver o enigma de P&D?
When R&D Lags
BCG recently analyzed nearly 200 mostly public software companies from around the globe to compare the change in one-year revenue growth (excluding acquisitions) against the percentage of revenue allotted to
By contrast, smaller companies, under $250 million, which tend to focus on product development and incremental product improvements, have median RDIs as high as 1.6, boosted by rapidly compounding growth rates. But as software companies surpass $2 billion in revenue, their RDI tends to decline precipitously (median values of 0.6), often the result of fewer new product features and advances.
RDI also tends to be worse in companies whose growth is based on acquiring other companies. Few acquisitions achieve the hoped-for product and operational synergies, often because the two companies have separate technology stacks that are difficult to integrate. Consequently, the more acquisitions that a software company makes—which usually means that they are deferring organic growth—the more its RDI suffers.
Some software companies defy this pattern, but it is hard to place them in precise categories. On the one end of the spectrum of the outliers, there are some larger software outfits with more traditional enterprise sales business models—such as Adobe, Microsoft, and Salesforce—that maintain decent RDIs. On the other end of the spectrum, a few product-led companies, whose growth strategies are driven by attracting customers to a flagship product line, have low RDIs. These outliers only make the R&D conundrum more perplexing.
Why R&D Efficiency Lags
Broadly, we attribute the inability to scale R&D to increased organizational complexity, a natural but problematic by-product of growth and maturity that companies often fail to create strategies to control. The types of complexity that hinder efforts to scale R&D can be broken down into four categories. (See Exhibit 2.)
Vamos examinar cada uma dessas categorias em maiores detalhes: || 3709
Engineering and Technology. Older, larger companies are often wedded to aging products and technologies. Frequently, this happens because their legacy products represent their largest revenue streams, and there is little organizational will to risk losing the sales tied to their core product platforms and architectures. These products have often accumulated technical debt, such as leftover and obsolete code, bugs, and design requirements that are a drag on continuous innovation and modernization.
As empresas presas nessa situação enfrentam aumento da irrelevância tecnológica à medida que novas estruturas e plataformas de desenvolvimento de aplicativos-como computação em nuvem e sem servidores, armazenamento de dados de próxima geração e IA-mude a economia e a velocidade ao mercado do desenvolvimento do produto. Esses avanços, que muitos concorrentes mais novos adotaram ansiosamente, facilitaram que os novos participantes enfrentam empresas mais velhas em mercados específicos com produtos essencialmente chave na mão e mantenham sua liderança através de melhorias rápidas. Consequentemente, gastos em P&D em empresas mais velhas para produtos menos relevantes diminuem em eficácia e valor. Além disso, várias linguagens de programação, entre elas versões herdadas de C/C ++, e um modelo de dados ineficiente criaram uma base instável para a inovação. Reconhecendo o problema e buscando um retorno ao crescimento, a empresa começou um esforço para modernizar e reescrever sistematicamente seus produtos. Disse de outra maneira, a construção de produtos escaláveis requer modelos operacionais cuidadosamente orquestrados. Muitas empresas maiores e multiprodutas têm estruturas de desenvolvimento excessivamente complicadas porque ficaram inchadas, com uma série de equipes em silêncio trabalhando em diferentes partes dos mesmos produtos. A colaboração e a coordenação entre as linhas de produtos, os recursos e as funções são prejudicados enquanto as equipes se tornam maiores e mais estratificadas. E o trabalho em desenvolvimento pode ser redundante e duplicado entre as equipes. Nesse ambiente insular, planejamento, coordenação e desenvolvimento de produtos - e, como resultado, a eficiência de P&D - sofre. Para integrar totalmente empresas e produtos adquiridos, as empresas precisam combinar vários modelos operacionais com diversas pilhas de tecnologia e equipes variadas de planejamento e desenvolvimento de software. Em muitos casos, as empresas desistem de tentar combinar ofertas separadas em um portfólio lógico de produtos e, em vez disso, permitem que elas continuem seus esforços díspares com pouca ou nenhuma integração. Isso cria funções e operações de desenvolvimento duplicado e, às vezes, portfólios redundantes e, por sua vez, confusão do cliente. Como resultado, é praticamente impossível impulsionar as sinergias e economias de escala pretendidas. Uma empresa de software que estudamos adotou uma abordagem do laissez-faire de uma aquisição significativa, combinando equipes de engenheiros em um único pool sem um roteiro claro para seus papéis e suas prioridades de desenvolvimento de produtos. O resultado: mais da metade de seus melhores talentos deixou a empresa, frustrada com a operação das táticas e expectativas de integração da empresa. Primeiro, empresas de software mais jovens ou que operando em mercados com grande concentração de clientes são excessivamente reativas aos seus clientes mais altos de receita recorrente (ARR) anuais para projetar novos recursos de produtos que esses clientes ostensivamente valiosos exigem, mas que poucos outros clientes pagarão. Isso afeta a eficiência de P&D, que depende da construção de produtos que são escalados para grandes mercados e vários clientes; Por outro lado, priorizar os recursos sob medida ou personalizados no curto prazo prejudicam inevitavelmente a economia do produto a médio a longo prazo. Em outros casos - particularmente aqueles que envolvem empresas mais velhas - os clientes são responsáveis por impedir as tentativas de atualizar produtos sem adicionar complexidade operacional. Empresas de software com produtos legados no local são particularmente suscetíveis a esse problema e enfrentam o desafio de apoiar várias versões de seus produtos, aumentando bastante a P&D e apoia a carga. Ao mesmo tempo, muitas empresas relutavam para forçar esses clientes de longa data a se modernizarem abraçando produtos baseados em SaaS- ou PaaS-cloud ou a glóbulos. Mesmo que eles estejam atualizando e inovando seus produtos, a incapacidade de dar as costas aos clientes mais velhos os força a adotar modelos de duas velocidades-desenvolvendo, vendendo e suportando modalidades diferentes dos mesmos ou similares. Essas relações um tanto disfuncionais com os clientes colocam as empresas de software em um atoleiro, mantidas reféns por seus mais velhos - e geralmente maiores - usuários e prejudicando sua capacidade de modernizar e competir.
We have witnessed this play out at numerous companies, including a leader in gaming and operations center software that has been beset by engineering and development slowdowns and redundancy due to its large and complex code base, which grew unchecked over many years. In addition, multiple programming languages, among them legacy versions of C/C++, and an inefficient data model have created a shaky foundation for innovation. Recognizing the problem and seeking a return to growth, the company has begun an effort to systematically modernize and re-write its products.
Organization and Operating Models. Many software companies serve as apt exemplars of Conway’s law, which states that a company’s software design function and software architecture reflect the organization’s ability to collaborate and communicate. Said another way, building scalable products requires thoughtfully orchestrated operating models. Many larger, multiproduct companies have overly complicated development structures because they have become bloated, with a raft of siloed teams working on different parts of the same products. Collaboration and coordination across product lines, features and functions are hindered while teams become larger and more stratified. And the development work itself may be redundant and duplicated across teams. In this insular environment, planning, coordination, and product development—and, as a result, R&D efficiency—suffer.
Sometimes operating model complexity comes from inorganic moves—primarily acquisitions—to expand growth. To fully integrate acquired businesses and products companies have to combine multiple operating models with diverse technology stacks and varied planning and software development teams. In many cases, companies give up trying to combine separate offerings into a logical product portfolio and instead allow them to continue their disparate efforts with little or no integration. This creates duplicative development functions and operations and sometimes redundant portfolios and, in turn, customer confusion. As a result, it is virtually impossible to drive the intended synergies and economies of scale.
In addition to its impact on productivity, acquiring companies without a fully thought-out integration plan can lead to downstream problems in workforce retention and further erosion of company performance. One software company we studied took a laissez-faire approach to a significant acquisition by combining teams of engineers into a single pool without a clear roadmap for their roles and their product development priorities. The result: more than half of their best talent left the firm, frustrated by the opaqueness of the company’s integration tactics and expectations.
Relationships with Customers. There are two types of customer dynamics that hold software companies back. First, younger software companies or ones operating in markets with large customer concentration are overly reactive to their so-called highest annual recurring revenue (ARR) customers in designing new product features that these ostensibly valuable customers demand but that few other customers will pay for. This impacts R&D efficiency, which depends on building products that scale to large markets and multiple customers; by contrast, prioritizing bespoke, or customized, features in the near term inevitably hurts product economics in the medium to long term. In other cases—particularly those involving older companies—customers are responsible for stymieing attempts to upgrade products without adding operational complexity. Software companies with legacy on-premises products are particularly susceptible to this problem and face the challenge of supporting multiple versions of their products, greatly increasing R&D and support burdens. At the same time, many companies are loath to force these long-standing customers to modernize by embracing SaaS- or PaaS-cloud-based or turnkey products. Even if they are upgrading and innovating their products, the inability to turn their backs on older customers forces them to adopt two-speed models—developing, selling, and supporting different modalities of the same or similar products. These somewhat dysfunctional relationships with customers place software firms in a quagmire, held hostage by their older—and often largest—customers and hurting their ability to modernize and compete.
Janelas de mercado ausentes em alguns trimestres podem significar a diferença entre a construção do próximo produto de bilhões de dólares ou a perda de concorrentes.
Termismo curto. É a manifestação do dilema do inovador, formulado pelo professor da Harvard Business School e pelo ex -aluno da BCG Clayton Christensen. O dilema do inovador sustenta que os conselhos e executivos de empresas estabelecidas não conseguem valorizar a nova inovação o suficiente, porque muitas vezes não traz os retornos imediatos que podem eliminar os clientes e arquiteturas de produtos existentes. Em outras palavras, os líderes da empresa rejeitam o mercado com produtos novos, estratégicos ou adjacentes, porque o potencial de curto prazo desses produtos parece muito limitado para gerar receitas mais altas e seu risco percebido muito alto. No mundo da tecnologia, onde as tendências mudam rapidamente e o sucesso depende de ficar à frente da curva, faltando janelas de mercado por apenas poucos trimestres podem significar a diferença entre a construção do próximo produto de bilhões de dólares ou a perda de concorrentes. Vimos isso se desenrolar com produtos, plataformas de dados e software de aplicativos baseados em nuvem em todas as categorias. Mas, no entanto, é adotado por muitos CEOs e outros executivos cujos incentivos e empregos estão vinculados a melhorias no próximo trimestre, em oposição à criação de valor a longo prazo. No final, essa abordagem leva a portfólios mal alocados e impede as empresas inovadoras, mantendo produtos competitivos ou fazendo os tipos certos de investimentos para escalar P&D e sustentar o crescimento a longo prazo. No processo, as empresas podem criar caminhos para dimensionar pesquisas e desenvolvimento, permitindo que os ganhos de receita ultrapassem as marcas de P&D. (Consulte o Anexo 3.) For many incumbent software companies, short-termism is, unfortunately, the way of doing business. It is the manifestation of the Innovator’s Dilemma, formulated by Harvard Business School professor and BCG alumnus Clayton Christensen. The Innovator’s Dilemma holds that boards and executives of established companies fail to value new innovation sufficiently because it often doesn’t bring the immediate returns that can wrung out of existing customers and product architectures. In other words, company leaders reject going to market with new, strategic, or adjacent products because these products’ short-term potential appears too limited to drive higher revenues and their perceived risk too high. In the world of technology, where trends change rapidly and success depends on staying ahead of the curve, missing market windows by a mere few quarters can often mean the difference between building the next billion-dollar product or losing out to competitors. We have seen this play out with cloud-based products, data platforms, and applications software across all categories.
Short-termism is, of course, a myopic attitude that deters effective planning for the future. But it is nonetheless adopted by many CEOs and other executives whose incentives and jobs are linked to next quarter improvements as opposed to longer-term value creation. In the end, this approach leads to misallocated portfolios and stands in the way of companies innovating, maintaining competitive products, or making the right types of investments to scale R&D and sustain long-term growth.
How to Scale R&D
Complexity can be daunting, but we have identified a series of specific steps that software companies can take to avoid its worst aspects. In the process, companies can create pathways for scaling research and development, allowing revenue gains to outpace R&D earmarks. (See Exhibit 3.)
Adote uma estratégia de investimento de produto de longo prazo, mantendo um portfólio efetivo no curto prazo. Por mais difícil que seja, atingir o equilíbrio entre o curto e o longo prazo é essencial para garantir que a P&D e o desenvolvimento de produtos estejam alinhados com estratégias de crescimento e criação de valor. As empresas precisam de um portfólio eficaz que entregue consistentemente resultados trimestrais fortes e para realizar o planejamento da inovação para o futuro. Esse orçamento deve ser flexível o suficiente para mudar as prioridades à medida que surgem novas tecnologias ou expedições de mercado. E deve ser disciplinado: não mais que 10% do total de P&D destinado a fotos da lua de longo prazo. Alocar a capacidade de P&D por si só não é suficiente. As empresas devem adotar um processo e estrutura do ciclo de vida do software que priorizem novos produtos, mede seu sucesso e os gerencie de maneira diferente das ofertas legado ou de vaca em dinheiro. Os gerentes devem ser recompensados por apoiar projetos de longo prazo que acabam impulsionando um maior crescimento. Os bônus podem basear-se em receitas de portfólios de inovação, vários novos produtos que superam um certo limite de vendas por um período de tempo ou expansão do mercado, entre outras possibilidades. Isso significa que as empresas devem evitar fazer muitas apostas em muitos produtos e devem estar dispostos a arquivar produtos que não são bem -sucedidos. Eles devem evitar portfólios tecnologicamente pesados e fragmentados em favor de linhas de produtos simples com duas ou três âncoras que podem ser contadas para fluxos de receita consistentes. Com essa abordagem, a P&D está focada em projetar aplicativos adjacentes e melhorar os recursos e funções em um universo limitado, mas em expansão, resultando em canais de crescimento direcionados, eficiência de desenvolvimento de software e um uso mais eficiente de recursos.
A long-term product investment plan should ideally include three elements:
First, the plan must have a clearly articulated innovation budget for medium- and long-term product development initiatives. This budget should be flexible enough to shift priorities as new technology or market expediencies arise. And it should be disciplined: no more than 10% of total R&D earmarked for longer-term moonshots.
Second, the plan should include a defined process to incubate and bring new products to market and to do so without bureaucratic roadblocks or technological inertia. Allocating R&D capacity alone is not enough. Companies should adopt a software lifecycle process and framework that prioritizes new products, measures their success, and manages them differently from legacy or cash-cow offerings.
Third, the plan must feature incentives that minimize short-termism. Managers should be rewarded for supporting longer-term projects that ultimately drive greater growth. Bonuses can be based on revenues from innovation portfolios, a number of new products that surpass a certain sales threshold over a period of time, or market expansion, among other possibilities.
However, long-term innovation gains are only possible if product portfolios are well managed in the short term. That means companies must avoid placing too many bets on too many products and must be willing to shelve products that are not successful. They must avoid technologically cumbersome and fragmented portfolios in favor of simple product lines with two or three anchors that can be counted on for consistent revenue streams. With this approach, R&D is focused on designing adjacent applications and improving features and functions in a limited but expanding universe, resulting in targeted growth channels, software development efficiency, and a more efficient use of resources.
Empresas de software de primeira linha da Apple para a Microsoft adotaram esse modelo de portfólio reduzido. De fato, para parafrasear Steve Jobs comentando sobre os perigos da proliferação de produtos, a marca registrada de uma boa companhia nem sempre está dizendo que sim, mas sim dizer não a 1.000 outras boas idéias que serviriam apenas para distrair. Nossa análise constatou que as empresas de software com o mais alto RDI oferecem seus produtos nas plataformas de software mais modernas. No cenário tecnológico de hoje, isso significa ter um software de arquitetura e design altamente modular e nativo da nuvem usando metodologias modernas de desenvolvimento e implantação de aplicativos automatizados. Mudar para essas arquiteturas em escala acelera a inovação, melhora a aceitação do produto e facilita a atualização dos produtos com frequência. As melhores empresas de software da categoria destinam aproximadamente um quarto de seus orçamentos de desenvolvimento de produtos para modernização e automação de plataformas e reembolsar a dívida técnica de maneira contínua e deliberada, segundo nossa pesquisa.
Track and repay technical debt to drive continual architecture modernization. Software architecture is always evolving. Our analysis found that software companies with the highest RDI offer their products on the most-modern software platforms. In today’s technology landscape that means having a highly modular and cloud-native architecture and designing software using modern automated applications development and deployment methodologies. Moving to such scaled architectures accelerates innovation, improves product acceptance, and makes it easier to update products frequently.
Established companies with older technology stacks should build a modernization roadmap to better compete with newer rivals and enjoy the benefits that hyperplexed architectures offer. Best-in-class software companies earmark roughly a quarter of their product development budgets for platform modernization and automation and repaying technical debt in a continuous and deliberate way, our research found.
Avoid massive re-architectures of aging technology stacks related to products that are past their expiration date.
No entanto, é importante direcionar os esforços de modernização em crescimento mais rápido ou produtos e mercados estrategicamente importantes, um imperativo que muitas empresas cometem o erro de negligenciar. Re-arquiteturas maciças de pilhas de tecnologia de envelhecimento relacionadas a produtos em mercados que passaram da data de vencimento geralmente são um exercício desperdiçado, uma distração de investimentos mais lucrativos que se alinham melhor aos planos de crescimento de uma empresa.
Break organization silos by investing in shared services and product management. Para superar a complexidade organizacional e os silos que talvez sejam os maiores impedimentos para escalar P&D e desenvolvimento de produtos, essas etapas podem ser valiosas:
Primeiro, maximizar a reutilização e o compartilhamento dos esforços de P&D. Em uma estrutura ideal, uma empresa de software deve ter um serviço compartilhado ou uma equipe de plataforma que cria componentes comuns de dados e middleware, interfaces de usuário, serviços de segurança e estruturas de ferramentas para todos os produtos. As funções estratégicas principais desta equipe são garantir a reutilização do código, direcionar tempo mais rápido para comercializar os recursos de aplicativos e melhorar a experiência geral do usuário, tornando o software mais integrado e consistente com o portfólio de produtos da empresa. Uma grande fintech SaaS que adotou essa abordagem de plataforma compartilhada descobriu que o modelo de desenvolvimento de produtos mais eficiente e a interoperabilidade aprimorada geraram retornos significativamente mais altos da venda cruzada. Tanto quanto possível, o trabalho deve ser executado de maneira modular e independente, com cada grupo focado no desenvolvimento específico de produtos ou na atualização de tarefas com interações claramente definidas entre as equipes de desenvolvimento. Isso ajuda a garantir que o progresso seja compartilhado e novas idéias proliferam. A Amazon abraçou esse conceito com sua abordagem de “Two Pizza Team”, na qual unidades de trabalho são executadas e de propriedade de uma equipe de seis a oito engenheiros. Desenvolvimento qualificado e liderança de gestão.
Second, individual product development teams should be small, self-sufficient and, at the same time, collaborative and accountable for results. As much as possible, work should be executed in a modular and self-contained way with each group focused on specific product development or upgrading tasks with clearly defined interactions among development teams. This helps ensure that progress is shared, and new ideas proliferate. Amazon embraced this concept with its “two pizza team” approach, in which units of work are executed and owned by a team of six to eight engineers.
How to scale large product teams effectively? Skilled development and management leadership.
Por fim, as empresas devem investir em recursos de gerenciamento de produtos e portfólio de classe mundial. Possivelmente, o aspecto mais importante, mas muitas vezes esquecido, de retornos crescentes da liderança de P&D, produtos e portfólio, não apenas preenche as equipes de produtos entre si, mas também conecta essas equipes a outras funções, como marketing de produtos, vendas e suporte ao cliente. Os líderes de gerenciamento de produtos ajudam as equipes de desenvolvimento de produtos a se concentrarem, priorizam as tarefas e medem o desempenho e os resultados. De fato, o desenvolvimento qualificado de desenvolvimento de produtos e liderança de gerenciamento é o maior determinante em ajudar as grandes equipes de produtos a escalar de maneira eficaz.
Invest in product scale multipliers. Para se proteger contra a fluência da complexidade, as empresas precisam ser proativas adotando o que nos referimos como multiplicadores de escala. Estes são essencialmente recursos projetados apenas para manter continuamente as melhorias de escala e se destacarem em possíveis problemas que os impediriam. Os multiplicadores de escala vêm de várias formas, mas, em nossa opinião, a adoção precoce de automação, análise de produtos e engenharia de produtividade de desenvolvedores (DPE) é um bom ponto de partida.
As empresas tendem a ser reativas ao implementar a automação, adicionando-a ao desenvolvimento de produtos atrasadas ou somente quando uma ineficiência em larga escala é descoberta. Mas quando a automação é incorporada em todo o processo de desenvolvimento de produtos - as funções do ACROSS da qualidade e dos testes para liberar engenharia, segurança e operações - o escala se torna onipresente. Isso significa impactos positivos para a qualidade do produto, desempenho, satisfação do cliente e retenção. As empresas decidem sobre os novos recursos do produto e até novos produtos, e às vezes fazem investimentos mal pensados em melhorias incrementais, sem entender completamente as preferências e os padrões de uso de seus clientes. Investir em tecnologias de captura de dados e na construção de uma equipe dedicada de análise de análise de produtos ajuda a superar isso, apoiando o desenvolvimento de produtos que melhor atendem às necessidades do cliente e que melhorem a experiência do cliente enquanto sofrem de produtos e gerenciamento de portfólio orientados a dados. O DPE enfrenta esses problemas, ajudando a ajustar o desenvolvimento, colocando um holofote sobre custos e ineficiências excedentes e exigindo pequenas melhorias no processo e as ferramentas que, em escala, podem ter um impacto substancial no desempenho da organização. Muitas empresas de software de sucesso - recentemente Dropbox e Netflix, entre elas - construíram equipes DPE dedicadas para gerenciar melhor os tempos do ciclo do produto e melhorar a eficiência do desenvolvedor. As empresas de software possuem vários grandes clientes que procuram recursos únicos ou não estão preparados para alterar suas pilhas de tecnologia ou adotar novas plataformas em suas organizações. Nos dois casos, muitas empresas de software desviam seus recursos para manter um ou alguns clientes felizes e não conseguem entender completamente o custo de oportunidade e o impacto a longo prazo de fazê-lo na eficiência de P&D e vantagem competitiva.
Similarly, product analytics is usually an after-thought at many enterprise software companies. Companies decide on new product features and even new products, and sometimes make poorly thought-out investments in incremental improvements, without fully understanding their customers’ preferences and usage patterns. Investing in data capture technologies and building a dedicated product analytics team helps overcome this, supporting the development of products that best address customer needs and that improve the customer experience while undergirding data-driven product and portfolio management across the organization.
DPE targets complexity seeping into the code base and product development tooling and processes that tends to occur when engineering companies’ portfolios expand, and new features are added on more frequently. DPE confronts these issues by helping to fine-tune development, placing a spotlight on excess costs and inefficiencies and calling for even minor improvements in process and tooling that, at scale, can have a substantial impact on the organization’s performance. Many successful software companies—recently Dropbox and Netflix, among them—have built dedicated DPE teams to better manage product cycle times and improve developer efficiency.
Manage customer change and be prepared to say no. It is imperative for software companies to avoid falling into a customer trap when building new product lines and features, and when upgrading their products to run on modern and more accessible platforms. Software companies have numerous large customers that are either looking for one-off bespoke features or are not prepared to change their technology stacks or to adopt new platforms across their organizations. In both cases, many software companies divert their resources to keep one or a few customers happy and fail to fully understand the opportunity cost and the longer-term impact of doing so on R&D efficiency and competitive advantage.
Nem toda receita é uma boa receita. Paradoxalmente, vale a pena não ouvir os clientes às vezes.
Para evitar essa armadilha, as empresas de software devem fazer duas coisas. Primeiro, eles precisam de um processo claro para triagem solicitações de clientes recebidas e devem estar preparadas para dizer não. Isso significa evitar a alteração de roteiros de desenvolvimento de produtos com alterações personalizadas solicitadas por clientes individuais - não importa o quão valiosos esses clientes são. Em vez disso, do ponto de vista do crescimento da receita, eles precisam olhar além das demandas imediatas dos clientes e determinar se a solicitação de um cliente ajudará a expandir o TAM (mercado endereçável total) ou ajudar a impulsionar uma economia melhor para outros clientes. No lado do custo, eles precisam considerar a despesa total da construção de recursos personalizados, incluindo o custo recorrente para manter e apoiar esses recursos. Mais importante ainda, eles precisam entender o custo total de oportunidade e o risco comercial de desviar os recursos de outros itens no roteiro. Nem toda receita é uma boa receita e, portanto, paradoxalmente vale a pena não ouvir os clientes às vezes. Essa avaliação deve considerar, entre outras coisas, perda potencial de certos clientes e possíveis mudanças na influência do mercado, bem como impacto no pipeline e novas oportunidades. Armados com esse conhecimento, as empresas devem criar um modelo de incentivo para incentivar a captação dos novos modelos de software. Estes podem ser cenouras, como descontos nos novos produtos ou assistência de especialistas em empresas de software para ajudar um dos principais clientes a migrar, passo a passo. Em outros casos, esses podem ser bastões, penalizando os clientes que se recusam a mudar para o novo produto com preços mais altos para versões herdadas. Isso pode parecer excessivamente punitivo, mas as empresas não podem se dar ao luxo de escalar o desenvolvimento apenas a meio caminho; É muito caro manter versões híbridas de um produto, e o impacto negativo na RDI demonstra que reduzirá o crescimento futuro. Às vezes, deixar alguns clientes para trás como empresa adota a mudança é a única opção.
Second, when modernizing or releasing new architectures, software companies should clearly identify the revenue at risk for different migration and modernization scenarios and be open to leaving customers behind. This assessment should consider, among other things, potential loss of certain customers and possible shifts in market influence as well as impact on pipeline and new opportunities. Armed with this knowledge, companies should create an incentive model to encourage uptake of the new software models. These can be carrots, such as discounts on the new products or assistance from software company experts to help a top customer migrate, step by step. In other cases, these may be sticks, penalizing customers who refuse to shift to the new product with higher prices for legacy versions. That may sound overly punitive, but companies cannot afford to scale development only half-way; it is too costly to maintain hybrid versions of a product, and the negative impact on RDI demonstrates that it will reduce future growth. Sometimes, leaving some customers behind as a company embraces change is the only option.
Muitas empresas líderes de software-Adobe, Ariba e Salesforce, para citar alguns-fizeram a transição com sucesso de suas bases de clientes para produtos baseados em SaaS (ou no caso da Salesforce, a transição de parceiros e clientes para uma nova arquitetura) após a abordagem que descrevemos aqui. Todos os três assumiram uma posição agressiva, frequentemente se comunicando aos clientes que desejam seus negócios, mas apenas se estiverem dispostos a se mudar para as novas plataformas. Em essência, a mensagem deles foi: "Queremos resolver seus problemas, fornecer os recursos que você deseja e melhorar sua experiência com nossos produtos. Mas só podemos fazer isso com um produto mais moderno emergindo de uma iniciativa de P&D mais eficiente". É importante ressaltar que essas empresas planejaram cuidadosamente a mudança; Por exemplo, o Salesforce executou as versões antigas e novas de seu software durante uma linha do tempo de migração de três anos. Os gastos com P&D sempre foram vistos como uma maneira de superar alguns desses obstáculos e a liderança de mercado dependia dessas despesas. No entanto, embora a P&D ainda seja fundamental para o sucesso e a diferenciação, sabendo que a P&D não escala com o tamanho da empresa certamente será uma decepção para muitas empresas. rastrear e reembolsar a dívida técnica para impulsionar a modernização da arquitetura contínua; quebrar a organização Silos, investindo em serviços compartilhados e gerenciamento de produtos; investir em multiplicadores de escala de produto; e gerenciar a mudança do cliente, estar preparado para dizer não. Essas etapas não apenas gerarão novamente retornos significativos de P&D, mas fazem com que as empresas de software se sintam mais confiantes em sair do lado vencedor do Inovate Or Die. Pranay Ahlawat
Software companies face a host of challenges even in their most routine development efforts, and competition is more intense now than it has ever been. Spending on R&D has always been seen as a way to overcome some of these obstacles and market leadership was dependent on these expenditures. Yet, while R&D is still critical to success and differentiation, knowing that R&D doesn’t scale with company size will certainly come as a disappointment to many companies.
Fortunately, there are relatively straightforward answers to address the difficulty of scaling R&D: adopt a long-term product investment strategy while maintaining an effective portfolio in the short term; track and repay technical debt to drive continual architecture modernization; break organization silos, by investing in shared services and product management; invest in product scale multipliers; and manage customer change, being prepared to say no. These steps will not only generate again significant returns from R&D but make software companies feel more confident about coming out on the winning side of innovate or die.
