For product and engineering teams, building a competitive moat is one of the most critical aspects of your work. But in the age of AI, that moat can evaporate overnight.
When AI upends your product roadmap, you might realize that you need to start from scratch. Your original solution is no longer viable, so you need to build a new, AI-native product that can compete over the long term in the new technology environment.
This realization puts organizations in a tough position, particularly if they have contractual obligations with their existing customers. How do you balance your engineering resources to pursue AI innovation while also supporting your existing product? How do you decide when to pull the plug and go all in on an AI solution?
One year ago, my engineering team faced this exact challenge. We knew that we needed to build a new AI product to replace our existing platform, but we also had to maintain our commitments to a customer base to maintain our existing revenue.
Here’s how we managed it, what I would do differently if I could do it over, and what businesses can learn from our experience.
Maintaining your product while building into the fog
We should clarify two ideas up front:
- When we talk about building a new AI product, we’re not talking about bolting AI features onto a legacy solution. AI is a transformational technology, and companies that try to hedge their bets by updating their existing products with AI capabilities are doomed to fail. Products and features that are truly AI native will inevitably win out over those that still have one foot stuck in the past.
- It’s also worth acknowledging that the best possible strategy is to rip the Band-Aid off, sunset your previous product immediately and start from scratch with the AI solution. However, this isn’t a viable option for many companies, either because they have a legal obligation to continue serving their customers, or because they can’t afford the drop in revenue that would result from sunsetting their original solution.
Once we realized that we needed to build an AI product, we bifurcated our engineering organization. Instead of having engineers split their time between supporting the old product and building the new one, we broke into two teams: one that would focus entirely on innovation, and one that would focus on keeping the lights on for our customers.
Both teams had a clear vision. For the AI team, the goals were obvious, even if the steps to achieve them were anything but. We needed to “build into the fog,” working to create an AI solution that would replace and improve on our previous tool. The team that stayed behind also had an important mission: they needed to determine how far we could reduce our resources while continuing to run the existing product. We expected to eventually move every engineer over to the new product, so we needed to understand how much we could pare down the stay-behind team and how quickly we could build up the innovation team.
We looked for key characteristics when deciding how to staff each team. For the innovation team, we looked for employees who were AI-forward and showed that they could be comfortable working in ambiguity. We pulled over employees with skills in UI design as well to help us reach a minimum viable product.
On the other side, we recognized that some employees were far more comfortable in their existing SaaS environment. Those employees had specific skillsets that helped them operate in the legacy environment, and they were far less comfortable working without a clear spec and expectations. There are also certain employees that had to stay back because their knowledge was vital to operating the existing product — those who understood the big data pipeline and integrations with key partners.
As far as our customers were concerned, it was business as usual even as we were making radical engineering changes. We reached out to our customers once it was clear there would be no new feature development on the legacy product; by that point, the innovation team had made enough progress that we were confident we could shift customers to the new solution.
Communication is crucial
Breaking an engineering organization in two isn’t easy, and you have to take time to communicate the rationale behind your staffing decisions. When we split into two teams, there were some on the stay-behind team that felt like they were being sent on a one-way mission to the sun — building a product that’s already dead.
For many of our engineers, their work is more than just a paycheck, and they struggled with the idea that they wouldn’t be working right away on the product that represented the future of the company. We made sure to explain the value of the work they would continue doing: the business had a vital need to maintain its contractual obligations; equally important, if the stay-behind team did their job well, our existing customer base should serve as our largest lead source as we moved into the new product.
We also made sure to explain the vision upfront for bringing the two teams back together while providing regular updates on when that transition could take place. That light at the end of the tunnel was critical for maintaining morale throughout the organization.
Best practices for an AI pivot
Our pivot to AI has been successful, but it wasn’t without challenges along the way. Here are four best practices we learned from the experience, including a couple of mistakes we wouldn’t want to repeat:
- Start by identifying who absolutely needs to move and who absolutely needs to stay: It can feel overwhelming to look at an organization with dozens of engineers and decide how to divide them into two teams. You don’t need to make every decision immediately. You’ll be better served by identifying the engineers who absolutely need to move to the new product and then sending them out as a tiger team to lay the groundwork. You should also identify the employees who absolutely need to stay to keep the original product running. That way, you can take a bit more time on some of the less clear-cut decisions, and you’ll be confident knowing that any mistakes you make won’t have catastrophic consequences for the legacy product.
- Break up existing teams: It can be tempting to lift and shift entire teams within your engineering organization from the old product to the new product, but I strongly advise against it. Don’t underestimate the scope of the change you’re making. If people are staying in the environments and structures that they find comfortable, and if they’re maintaining their existing rituals, they’re going to find it much harder to let go of what they know and embrace a new way of working. If I could do it over, I would break up teams by default and move them individually into new teams.
- Communicate, communicate, communicate: I mentioned this above, but it bears repeating. Not everyone is equipped to thrive in a period of transformation. Providing regular updates on where the organization is going and how it’s performing helps your employees find stability when things feel chaotic.
- Not everyone will embrace the new vision — that’s OK: Some people are exceptional at performing specific roles in legacy SaaS environments. Is it fair to expect those people to embrace a new role in a world they didn’t sign up for? We lost a few employees who weren’t excited about our new vision and who wanted to find work they were comfortable with. That’s completely understandable, and there were no hard feelings. But it’s important for those people to recognize their situation and look elsewhere — in this competitive, fast-moving market, there’s no room for someone who isn’t willing to run full speed in the new direction.
Companies around the world are coming up against an AI breaking point, realizing that their existing product won’t be competitive in the new technology environment. That’s a scary moment. To survive, you need to take a leap of faith and trust that your engineers will be able to build into the fog and come out on the other side. The only way to guarantee failure is by refusing to adapt.
