Internal product management: What’s the best way to build an internal tool?

Internal product management is a common discussion among companies that have internal developers, specifically startups, is whether they should have a team, a squad, or borrow developers for the internal product development. Somes startups don’t know what is internal product management and believe they should always use shelf software to solve problems when possible and others believe they should internalize everything. So, should I internalize internal tool building?

We’ll go through the different companies’ strategies and efficiency matrix of internal product management to know what is the best way to build an internal tool.

What is Internal Product Management?

Internal product management is a category under Product Management focusing on the development and support of internal tools. 

Its aims to make sure that employees have all the tools to do their job efficiently. Internal Product Managers need to cut costs (developer’s time, money, etc) and maximize operational efficiency (delivering products faster, scaling operations, increasing conversion rates, increasing NPS, reducing churn, reducing burn, and others).

What’s the best way to build an internal tool?

Internal product managers face the problem of choosing between: 

1. Internal development (proprietary code): coding 100% of the solution using their developers.
2. Subscribe to off-the-shelf software: SaaS companies such as Zendesk for customer support, HubSpot for sales, and Slack for internal communication.
3. Hiring an agency: agencies will also code the solution tailor-made for you, but they will use their engineers and charge a service fee. 

More recently, a new option has been introduced to companies: 

4. Low-code development: your engineers will be able to code internal tools faster (Ex: Retool and Jestor). 
5. No-code development: anyone on your team will be able to build internal tools and automation for your company (Ex: Jestor and Zapier).

Pros and cons of internal tool development

There are many pros and cons of internal tool development and many ways to test these different strategies, we’ve classified them and created a simple score to rank them:

	Consumption of internal developers	Maintenance cost	Customization	Control over code	Time to deliver solution	Automatic Upgrades
Internal development(Proprietary code)	High	High	High	High	High	Zero/Low
Off-the-shelf software	Zero/Low	Zero/Low	Zero/Low	Zero/Low	Zero/Low	High
Hiring an agency	Zero/Low	High	High	Medium	High	Zero/Low
Low-code development	Medium	Medium	High	Medium	Medium	High
No-code development	Zero/Low	Zero/Low	High	Zero/Low	Zero/Low	High

We’re using the -1, 0, and 1 to weigh different options for the pros and cons of internal development, but you could customize it per item. For example,” having the maintenance costs is extremely important to me”,-you can change the weighting here to 10. 

	-1	0	1
	Red	Yellow	Green	Score
Internal development(Proprietary code)	4	0	2	-1
Off-the-shelf software	2	0	4	3
Hiring an agency	3	1	2	0
Low-code development	0	4	2	3
No-code development	1	0	5	5

Considering all topics and factors to weigh, when ranked, the best to worst strategies for the internal products managers would be: 

1. No-code Development.
2. Low-code Development.
3. Off-of-the-shelf software.
4. Hiring an agency.
5. Internal Development (Proprietary code).

No-code/Low-code vs Internal Development

Coding your own internal software is a widespread strategy, much more popular than no-code for example. If no-code is so good, then why do so many companies still develop everything from scratch? There are a few reasons:

1. No-code and low-code are new: No-code and Low-code development is a new solution for internal product development, it’s common to encounter companies that don’t even know it’s an option for development. 
2. MVP stigma: In the past, no-code tools were mostly used for MVPs, but nowadays, the new tools have evolved to become your final solution. They are highly scalable and robust. But a few developers still have a prejudiced view towards these tools, – probably caused by bad experiences in the past. 
3. Owning the source code: Internal product development could be a highly strategic approach. You have full control over the code, you could even sell this solution to other companies. AWS and GCP were internal products/services that became hugely profitable revenue streams. 

The default strategy for the largest companies in the world is building it in-house: Amazon, Apple, Facebook, and  Microsoft. If the most successful companies in the world do it, should I do it as well? No. The causal relationship is inverted under this rationale: they need to build their own internal software because they are huge, they are not huge because they did it. They control huge amounts of data and need extreme performance. They also don’t trust their “peers” (Google would never use AWS to run all its searches). 

There is a great story about Uber building its own “Slack”. They’ve spent a huge amount of hours building it. Nowadays, they use Slack. In an ideal world with infinite resources and time, all companies should build all their internal tools. However, everything has an opportunity cost. The time you spend building it is the time that you don’t invest in your core business.

Decision-making matrix: When is it efficient to allocate developers to build products?

We’re taking into consideration 4 different variables: efficiency, professional type, strategy, and product type.

	Core product	Internal process optimization	Execution
Developers	Proprietary code	Low-code tools	No-code tools
Builders	Proprietary code	No-code tools	No-code tools
Members	Proprietary code	No-code tools	No-code tools

• Developers: Engineers.

• Builders: Product Managers and people that dominate processes.

• Members: professionals that execute the strategy.

• Core product: the service or product that you sell to your customer. It’s usually the client-facing tools built by your team. Ex: Uber’s iOS app. 

• Internal process optimization: internal software building. Tools that will be used internally, the main objective here is efficiency. Ex: Uber’s internal messaging app. 

• Efficiency: time, cost of opportunity, and money. 

Should I build an internal tool?

The best strategy is a combination of internal development and no-code tools. Internal development only for building the core product (leveraging all your development talent for the growth of the business) and no-code tools for building (fast and scalable development completely customizable by Product Managers, COOs, founders, and members).