Mistakes PMs should avoid while building internal products
Internal products are tools and applications that are used by the employees of the company/department(s) and are not customer-facing.
Their primary aim is to help the employees function more effectively. By making it easier for the employees to discharge their responsibilities, they help improve productivity significantly. They cover a wide range: internal tool for inter-department allocation of tickets, account manager’s dashboard, live support tool for customer service, field sales app etc.
During the first year of my PM career, I got a chance to work on two exciting internal products. There was an Account Manager’s dashboard to help Account Managers. And there was a field sales app to help the sales team.
I made a lot of mistakes with both these products. The result being that neither of them turned out to be game-changers as we had perceived them to be. Some of the mistakes could be attributed to inexperience and some to simply not taking internal products “seriously” enough.
But every past mistake offers a valuable lesson for the future. Avoiding those can help build internal products which deliver a good user experience and deep impact.
Here goes the list of mistakes (not in any specific order) and tips to avoid them:
1. Not exploring solutions available in the market
Unless you are building something really specific to your company, chances are you might find something off the shelves.
The two main arguments for building internally are lower cost and greater customisability.
However, both these arguments might be incorrect. In terms of cost, we often focus on only the cost of spending on the solution. What about ‘hidden’ internal costs — the time engineers and PMs spend on building and maintaining the product? What if they had spent the time building customer-facing products. In terms of customisability, external solutions usually provide a reasonable degree of customisation. Is that not enough?
Tip: It is important to thoroughly test your assumptions regarding external solutions before starting to build internally.
2. Not focusing on the users
The demand for an internal tool usually comes from a CXO/department head or someone senior. They have an idea of the problem and given their ‘seniority’ they also know the solution.
If we jump into building without understanding the users of the product, we run the risk of building something that’s not useful at all.
Tip: You must interview the end-users before building. Understand their wording of the problem and the challenges they face. Also, understand how does their typical workday look like and what are their key responsibilities.
3. Not thinking long term
For internal products, we often focus only on solving the immediate problem. Since that gives us the highest return on effort. Due to this the product becomes just a marginal improvement over the existing scenario.
Tip: As PMs, it is our job to zoom out and see the bigger picture. The end goal is to make employees more efficient in doing their job. Thus, we should bring a strategic vision to the tool rather than making it a potpourri of random features.
4. Not linking to a business metric
Every tool that employees use is meant to make them more efficient. Usage of the tool should directly translate to improvement in some business metric such as NPS, turnaround time, total sales etc.
With an internal tool, usually, there are no weekly meetings/ OKRs to discuss its impact. This might make the PM building them complacent.
Tip: Before starting, be very clear on what business metric the product will move. Post-release, religiously track those metrics. Focusing on these metrics, helps decide whether the tool is working or not and prioritise the most important features to build. Besides, its easier to get support and resources for a business-metric moving tool.
5. Little focus on user experience
Internal products are often badly designed with little regard to User experience. And since their users are “captive”, improvements on this front are completely ignored.
This leads to products that are: 1)buggy 2)non-intuitive 3) frustrating to use. As a result, they fall short on their promise of bringing in more efficiency.
At best, they are seen as “necessary evils”. Worse, they may permeate a culture of cutting corners among employees using them.
Tip: As PMs, we should ensure that internal products have a minimum bar for user experience. We should also remember that the time saved by engineers in building a non-intuitive product usually leads to time lost by users navigating through the product.
6. Not championing the use of the product
It is easy to look at internal products as “gifts” to the employees. After all, its solving their problem. And helping them do their job better.
Further, since management is involved, usage of these products would usually be enforced. However, that’s not the correct approach. Users should genuinely feel that the product is adding value. If that’s not the case, something definitely needs to change with the product.
Tip: If we build an internal product, we have to be the most vocal ambassadors for it. Directly talk to end-users about your product’s benefits. Personally give demos of your product. Conduct regular 1–1 feedback sessions. Make users feel that you care about their experience of using the product. This would do wonders for the product’s adoption.
7. Not tracking the usage
It’s important to quantitatively track the usage of your product: number of logins, daily average time for which the product was used, features that were used/not used. This is very critical in uncovering problems faced by users.
For instance, I released my first internal product without putting any tracking in place. After explaining everything to the team, I felt confident that this would be used extensively. During regular follow-ups, they never mentioned any issue with the product. A month later, when the department head individually asked the team members to explain the functioning of the product, 90% of them were clueless.
Turns out that they just kept the tool open in another tab but were still carrying on with their older methods. Had I put analytics in place, the truth would have come out much earlier.
Tip: Analytics is your best friend. Don’t ignore it.
Internal products are the lifeblood of any organisation. Yet, the requisite rigour is often missing while building these products. In smaller organisations, where the same engineers work on internal and external products, the internal tools tend to be even more patchy.
If PMs become cautious about the above-mentioned mistakes, the process of building internal products becomes quite enriching. Moreover, these products actually stand a chance of becoming game changers in ushering in employee productivity.
