Productizing internal tools

5 anti-patterns and lessons on transforming internal tools into commercial products

If your company has invested heavily in developing internal tools, those efforts could be fertile grounds for a new commercial offering. 

Amazon AWS started as an internal shared IT platform. Meta’s Workplace began as an employees-only version of Facebook. Slack was a modern IRC platform for developers of the video game Glitch. All three went on to be highly successful products when transitioned from internal-only to public product. 

I have been lucky to work on several efforts to transform core internal tools to commercial products—including Workplace at Facebook and P2 at Automattic—and I became a firm believer that innovation used to solve your own problems can offer compelling solutions to other companies’ problems, too. 

At the same time, I have also witnessed five product building anti-patterns for crossing the internal-to-external “chasm”. Managing around these traps is critical to bringing an internal tool to market, or if you can’t, determining quickly that your efforts are better spent elsewhere.

Anti-pattern 1: Assume your customers look like you

The core hypothesis in transforming internal tools to public products is that other companies face the same problems that your tool solves. However, this can lead to a false assumption: that your ideal customer should look like your company, or to put a finer point on it, to misunderstand what you share in common.

When Facebook at Work was first introduced, we assumed tech startups would be our ideal customers: not only was their mode of working most similar to Facebook’s, but we felt we understood them best as we often partnered closely on other products. 

But the real breakthrough opportunity came from customers like Walmart and Starbucks who wanted to use the product (re-branded as Workplace) to connect their “frontline” employees. We assumed it would be used by desk-based tech folk with great Wi-Fi, but Workplace found market fit with companies where mobile workers used the product in a very different way. 

You still need to validate your ideal customer and it may not be you.

Anti-pattern 2: Rely on [your] culture

At Automattic we had the saying “P2 or it didn’t happen” which was the expectation that a representation of your work—whether code, designs, meetings, research etc.—would be posted to our WordPress-based collaboration platform so that everyone in the company could see it. This practice was a powerful cultural norm that has enabled Automattic to thrive as a fully-distributed, global company for more than 15 years.

Yet when we talked to potential customers of P2, many of them struggled with the idea of implementing a similar practice, even when the pandemic drove them to transform to a remote workplace like Automattic.  

In short, if your tool is an extension of your internal company culture, don’t rely on the practices of that culture to exist or be adopted by your customers. 

Anti-pattern 3: Not prioritizing between internal and external users

It’s common for the same team that’s working on transforming a tool into a product to also end up responsible for its internal use.

Given the internal needs for the tool are clear and support the existing business, in the early days they can outweigh the yet-to-be-known value of solving problems for external customers. It’s also easy to think that improving something for an internal user will translate to external customers as well. It often won’t.

The end result is a form of the Innovator’s Dilemma, where a disruptive innovation is smothered by a company’s traditional business, but in this case it’s the company’s internal needs that can smother a tool’s external market potential. 

Successful companies manage this trade-off intentionally, creating a decision-making framework for how improvements will be prioritized. Even better, they also build their tools as platforms to support both internal and external clients, much as Amazon did with their API Mandate. This practice made possible AWS, Fulfillment by Amazon, Alexa and other successful Amazon services. 

Anti-pattern 4: Focus on advanced capabilities vs. beginner problems

By nature, your company is already highly experienced using your internal tool. You may have developed advanced features that leverage the tool’s capabilities. But you have to be careful not to let your intimate familiarity with your internal tool blind you to the challenges that newcomers face. 

For example, a typical mistake is to prioritize development of an onboarding experience that demonstrates the advanced features of your product, “tool-tipping through the learning curve”. Instead you should be focused on discovering the core problems that beginner users want addressed, and evolve your product to capably satisfy those. 

No ones going to stick around for your advanced capabilities if the beginner problems are not compelling and clearly addressed.  

Anti-pattern 5: Overlook go-to-market alignment challenges

If your main business is a consumer offering, or if your go-to-market motion is primarily product-led and small-team focused, then you’re probably under equipped to tackle an enterprise or mid-market GTM motion. 

Likewise, if you’re primarily enterprise sales-driven, but your internal product aligns better with teams than whole organizations, then you may need to adopt a product-led growth strategy, which you may not have the staff and systems to support. 

Even if you’re used to selling to enterprise customers, your new product may require sign off from a whole different cohort of stakeholders: in my experience, marketing platforms, CRMs and internal collaboration systems all have different owners. 

This all could require developing systems or capabilities you didn’t have previously.  For example, with Workplace, Facebook quickly realized the need to build entirely new customer success teams that were experienced with enterprise software, focused on the support and training of internal champions for Workplace to gain a foothold in a prospective company.  We also needed to update the product to meet customers’ security and admin requirements. 

Ultimately, building new go-to-market capabilities can be time consuming and expensive. So you should first validate the level of alignment between your product, people and processes with what’s required of the new opportunity.

Not to mention validating whether or not all that effort would be worth it. 

Value is not what you already built

With internal products, you start with something that is already built, which already creates value for you.

If you want to launch an external product though, you need to focus extra hard on how it will be used by external customers. You need to internalize the problems they will use your product for, and how they will learn about it and adopt it. 

Set aside the value your internal tool creates from your company’s use, and instead envision it as a set of capabilities to solve problems for potential customers.

Use that as your north star.

You may find you can unlock incredible value for them and for you.

The value is in what gets used, not in what gets built. ​– Kris Gale