Building the Blocks — Approaching Behind-the-Scenes Product Management
In larger tech organizations, a big chunk of the work done by the product and engineering teams are not directly visible to end customers. In e-commerce companies, vendor management, supply chain management and pricing are some of the core components of operations and these are run using internal facing products. But even in other types of companies, internal products increasingly contribute to a large part of tech work. As both consumer and enterprise software companies add more products or services to their suite, creating building blocks for common needs such as identity & access management, payment and support can be cheaper (lower development and maintenance effort) and better (higher expertise due to focus). Even manufacturers of physical products which have traditionally not been software focused have now started to build their own tools. As physical products become more IoT-ified and “smarter”, manufacturers are building tools for needs such as quality control during manufacturing, remote monitoring & upgrade of sold units and field service.
While the fundamentals of product management remain the same for both consumer facing products and internal products, there are some commonly faced challenges when building internal products. The challenges mostly are derived from organizational culture and they negatively impact the mindset of product managers and engineers building such products. By shifting the mindset a bit, building internal products can actually be rewarding and meaningful. We will discuss these in this article. But firstly, what are these internal products?
Types of Internal Products
One way of categorizing internal products is by the business function whose needs are solved. Some of the common functions are shown below.
Pretty much all business functions in both consumer and enterprise organizations need internal products for certain use cases particularly as the organizations become bigger and more complex.
Brief note on nomenclature
Tools developed for internal purposes are now being commonly referred in the industry as “platform products” even though true platforms are only a subset of such “internal products”. In this article, the term “platforms” refers to the subset of products which provide building blocks for creating other products (and so the end users of the platforms are typically developers) while the term “internal products” would be used to also include systems built for different internal functions such as marketing, sales, operations and support.
Types of Work Involved in Building Internal Products
There are a few specific types of work involved when building internal products. We discuss these and briefly cover some tips for each type of work.
Digitizing offline workflows
This is typically the first stage of tech intervention of any business process where spreadsheets are ditched to bring sanity. The goals here are primarily to gain better operational control and reduce manual errors. The process involved to build solutions here is typically more “consulting” in nature (mapping out existing people & processes and their problems) with minimal new problem & solution discovery involved. The major challenge here for a product manager is to quickly develop enough knowledge and use first principles thinking to question and rethink the business process rather than digitizing it as is.
Automating manual processes
This is the second stage where internal processes get automated. The goals here are cost reduction and higher speed. Parts of processes which do not involve human judgment or coordination are typically ripe for automation. Along with the automation, there is usually also a need to build a layer of monitoring to validate that the automation is running as per expectations and that the system is not performing poorly for certain inputs or scenarios. This is particularly relevant when using ML based automation. When automating manual processes, the major challenge that needs to be addressed upfront before diving much deeper into execution is the technical feasibility assessment.
Integrating multiple systems
Most internal products will involve integration with other products. Such integrations can take different forms — real-time, scheduled or event-driven — and will need to be designed to handle failures. The integrations can be with external systems (such as between payment aggregators and banks) or with internal systems (such as when a CRM pulls information from an Order Management System). Mechanisms to monitor the health of the integration, building in redundancies if possible and providing the ability to make anticipated changes in the future without completely rebuilding the integration are some aspects that need to be taken care of.
Creating core building blocks
This is the “platform product” work that becomes relevant in organizations with multiple but related customer facing products or services. As discussed in the table earlier, examples of these are identity & authentication services, access management services, checkout & payment services and common communication platform. The advantages of building such common blocks are that the teams working on these can develop specialized knowledge through better focus leading to higher overall quality at lower overall cost for the organization. However, the advantages do not always manifest themselves and you can end up with the building blocks becoming bottlenecks — particularly when the responsible teams, unlike direct customer facing product teams, do not face the competitive pressure or end customer feedback directly, and become complacent. Product leaders have a higher responsibility to then structure and steer such platform teams with the right goals that ensure alignment with the organizational objectives.
Democratizing data
Here, the work involves building data pipelines and data quality checks to create an easily accessible repository of all relevant data in the organization within a data warehouse or data lake. Scheduled reports, ad-hoc analytics and aggregation services are the typical “consumers” of the stored data. Creating such a system involves working across pretty much all other products in the organization, understanding how each dataset is likely to be used and building for scalability both in performance and cost. The key challenges for product managers here is to develop a combination of data orientation, deeper technical skills and stakeholder management as they have to constantly deal with “every team needing to generate whatever analytics they want whenever they please”.
Challenges in Convincing Leaders and Oneself
There is friction that product managers face from various influential stakeholders and more importantly, themselves, when building internal products. And the friction is usually there for good reasons. It makes sense to examine the forms the friction can take.
“Do we even need to build this? Can’t we just buy?”
There are enterprise products for addressing the common needs of most business functions including those of the engineering team. So, if you are in a relatively mature industry, chances are that you could buy a solution instead of trying to build it internally. A clear case might need to be made for deciding to build rather than buy and convince leaders so the organization does not end up doing undifferentiated heavy-lifting. Establishing such a case involves a lot of work. Product managers have to assess various factors — Is there any secret sauce involved in your company’s solution that can’t be solved by vendors? What’s the expected evolution of the problem you are solving vs the capabilities offered by off-the-shelf systems? What’s the implementation time & cost for both approaches? What about the maintenance & support costs? If it is a business critical system, will you get the responsiveness you need when things go down?
“Is this the right time to build this? We have other priorities.”
Timing internal product work is tricky. You don’t want to do productize or platformize things too early when the complexities that need to be solved for internal users are not yet clear or when the scaling problems are not likely to arise for some more time. Also, scaling resources (human or computing depending on the problem) can keep sub-optimally salvaging the situation until the problems become too big to ignore.
“Isn’t this only for internal folks? We are not going to put any designers on it.”
Design love is hard to get for internal products. A lot of times, product managers need to make do with their own low fidelity wireframes and convince grumbling engineers to start the development. Even when some design bandwidth is spared, it’s probably going to arrive only during the solution execution phase rather than the solution discovery or ideation phase.
“This is not going to be a “shiny new thing”. I don’t want to build it.”
Internal products are not going to get a press release or a funky marketing video that the builders can flaunt. They are unlikely to result in end customers raving about it on social media. And large companies can reach a structure where there are blind spots preventing important work which has solved a problem that would have arisen tomorrow to not be recognized by leaders. Product and engineering folks then do not have the motivation to identify and drive impactful but under-appreciated initiatives by themselves.
Mindset to take up Internal Product Work
When working on internal products, adopting a relevant mindset can help the product managers and engineers to be successful.
Get to know your business inside out
Building tools for different internal teams gives product folks a chance to develop a deeper understanding of the business. While understanding your users is the first principle of any product work, in internal products, this process is easier in many ways and PMs can really get to know their users intimately. Even from a personal growth perspective, it’s a way to make friendships with colleagues whose daily grind is very different from that of product folks.
Focus on the value created
Internal products can work hand-in-hand with external facing products in driving business outcomes. Being focused on this value creation rather than just the front-end glitz can go a long way in being successful when building such products. For example, almost everything that Amazon does to achieve its core value proposition of large selection, cheap price and fast delivery is through internal products.
A derivative of this mindset is to not really build for internal teams or look at them as your customers as fundamentally you are trying to solve a problem for the business and the best long-term solution might involve completely bypassing the team through automation. So, there is a balance product folks need to maintain between being close to the internal users and solving their needs while also being able to imagine and build towards a possible world without the same users.
Be open to external software
Once you are focused on the value created by solving a problem, you become less focused and less attached to the means by which it is solved. This includes buying and integrating with existing tools in the market rather than building your own, where it makes sense. Keeping track of enterprise tools and assessing them also provides insights to nuances that you might be overlooking but which have been thought through already by companies that make their living by identifying problems and their variations across different organizations. Also, if you think that as a product person, you want to spend your time on the “harder” challenge of building rather than buying, you will be surprised to find that the upfront work involved in evaluating options and buying a solution is actually much harder and developing that muscle can be useful. And integrations are always challenging and critical.
Be your own press
As a builder of internal products, while you won’t get external press, you can and should make yourself heard internally. This can be done by sharing release notes in relevant internal forums, regularly publishing your key metrics and soliciting feedback from relevant teams. Think of it as growing your own marketing skills.
Happy block building!
Further Reading
Product Work Beyond Product Market Fit — I have taken some ideas from this really good article on the different types of product work published by the folks at Reforge.
