Everything Is a Product

Everything Is a Product

Sat Oct 24, 2020 by Justin Fuller

Your internal tools may have more value than you think they do.

A Successful Internal Tool

Just look at AWS, the world's largest cloud provider; AWS started life as a set of internal tools that morphed into the cloud provider that many of us use today.

I'm sure that few people anticipated their internal file storage tool would become a multi-billion dollar business. Still, this line of thinking leads me to a few questions about how we can think differently about our work.

Value

First, if it has value to you, does that mean it has value to someone else? If your work is highly unique, perhaps not, but how many do genuinely innovative work? I'd be willing to bet that most software engineers are making CRUD apps or integrating with other services. This simple work isn't a bad thing; it's software engineering bread and butter.

Even if the application is unique, we may be using fairly common strategies and tools to accomplish it. If you can code those strategies into a functioning tool for yourself, does it make sense to clean it up a bit so that you can sell it to others as well?

Dependency

Next, does your company gain an advantage by making potential competitors depend on your tools and by linking your competitors’ profits to yours? Let's say some other companies do value your tools; some of them may even be in the same market as you. It may make sense that those who are trying to solve the same problem may value similar tools. As their company grows, their usage (and therefore, the amount they pay) for your tool may grow. So, if your competitor grows, it will increase your profits in at least one way.

Could this offset the loss of the competitive advantage your tool brings the company?

Quality

Finally, by selling your tool, you will want it to be of high quality. How many times have we all had to use a terrible internal tool? Offering your tool as a product requires you to make sure it looks good and works well for many different users.

The requirement of high-quality products could lead us to the reason that internal tools don't become products: the investment in a production-quality development may be too high to justify the ROI. But this leads to more questions. If the return isn't worth it for the production quality version, is the return there for the crappy internal version?

Example

I work at The Times, so a natural thought is to offer our news editing tools as a product. Some might be worried that it would hurt our competitive advantage, but I don't think that's a real problem. Our real competitive advantage is the investment we've made in our journalists. Since our journalists use and enjoy our tools, likely, others would too. Those other companies would likely pay us for our tools, which may be better because we can hire more engineers. We could also reinvest the profits back into the tool; which would continue to make our journalists’ job easier. It's a self-perpetuating cycle.

I think back to my time at Bank Of America, where they love internal tools. There are so many internal tools, so many that could become products. Yes, they would have to stop viewing them in the narrow scope they were built, and put a lot of TLC into them, and figure out how to handle PCI and security, but it can be done. Their competitive advantage surely isn't their internal tools, but their vast physical presence and consumer trust (queue complaints about the company).

Features

It's not just internal tools that can become standalone products. It can apply to features that you offer to end-users. Recently I've been working on gifting and referral programs. How common are those across websites? Why not either use a third-party product or, better yet, offer it as a product and make money on the feature and the product at the same time?

Open Source

Finally, if you don't want to offer it as a product, you could (and I think, should) offer it as an open-source project instead. I think there's little danger here because we're not talking about our core business products, and to get to this point, we've acknowledged that the tool isn't valued enough by others to create an ROI. There may still be value to others, just not enough to pay. If not, it could show other companies and potential future hires the quality of work your company produces. If some use it they may contribute to it, reducing the cost of fixing bugs and adding features.

Realistic

As I've mentioned, I don't think the most significant downside here is losing a competitive advantage. I suspect that the disadvantage is tarnishing the company's reputation with sub-par products. If the product isn't high-quality, it could very well embarrass the company; this increases the investment needed for these products compared to their cost as internal tools.

So, will it ever happen? Maybe. Will this become a broad practice in many companies? I predict not. But SAAS is very popular, and there is only more money to be made there. Many large companies already have a swoath of products, so maybe they should start selling them.

I'm not an MBA

So I'm excited to hear why I'm wrong wherever this get's posted. Thanks for reading!

Hi, I’m Justin Fuller. I’m so glad you read my post! I need to let you know that everything I’ve written here is my own opinion and is not intended to represent my employer. All code samples are my own.

I’d also love to hear from you, please feel free to follow me on Github or Twitter, or subscribe to my newsletter to get an update, once-per-month, about what I'm writing about. Thanks again for reading!