There are multiple ways of categorizing the product management role: by the stage the product is in (growth PM, startup PM, scale-up PM, etc.), by function (such as the technical PM role), or also by the type of product (B2C, B2B, B2B2C, Enterprise).
There’s also another breed of PM, the internal PM. This is the product manager responsible for internal products. To start, let’s look a bit at the differences:
| B2C | B2B | Internal product | |
|---|---|---|---|
| Goals | Increase transactions (revenue) |
Increase attention | Increase productivity (feature adoption) |
| Customers | Many (mass market) | Few | One (the organization) |
| Users | Many | Few | Captive users (they have to use the tool |
| Competition | Many | Few | None |
| Level of complexity | Low | Moderate | High |
| Iteration speed | Fast | Moderate | Slow |
| Development cycles | Short | Long | Long |
When it comes to internal products, the product manager does not have to focus on getting to market fit or growth, but has other hurdles to navigate, such as internal stakeholders and company politics, as well as change management and adoption.
In this article, you will learn what product management for internal products looks like, as well as the common challenges that accompany the role.
To better understand the internal products role, let’s look at an example of the product development process and see what specific challenges may arise.
Imagine the following scenario:
The HR manager has come to you asking for support in developing a new onboarding platform for the employees. The company has grown exponentially over the last couple of years, reaching almost 1,500 employees, and the current manual processes cannot keep up with the growth pace. The HR team is overwhelmed by the many new colleagues joining, so they need support with the onboarding process.
Now let’s break the process down into five distinct stages:
The main advantage of internal products is that you have your users at your fingertips. Your colleagues are your primary users, which allows you to easily gather insights to help with product direction.
Even if you don’t have a formal discovery process, you can start small. Send out a survey, talk to a few colleagues by the water cooler, and learn more about their needs and pains.
Conduct a kickoff workshop with all relevant stakeholders:
The goal is to understand the current process and its challenges, as well as to define the problem and the vision for the solution. This way, you make sure everyone’s voices are heard.
It’s also crucial to get feedback about the current onboarding process from the employees who have recently gone through it and the HR team. Create a survey and get the HR team to help you to send it to the employees who have joined the company in the past six months.
Once the results are in, you want to look for insights and repeating patterns. Additionally, do some desk research to find out about trends in the onboarding market, relevant studies, and competition.
To wrap the initial discovery phase up, you want to put together a report showcasing the main findings of the research:
You want to share the results with your main stakeholders and get their buy-in.
Now that the first phase is over, you want to gather the same team for another workshop.
Start with a summary of the research phase to ensure you’re all on the same page.
Then you want to articulate the two-year goal, define the challenge, and the success metrics.
The next step is to define the user journey and brainstorm a solution. From these sessions, getting a clear list of business and user requirements from employees and HR is important.
You also want to have an initial idea of priorities — at this stage, it is enough to use the MoSCoW technique to gauge the stakeholder’s opinions. The final prioritization will happen later.
One more important aspect of this workshop is the constraints — budget, timelines, accessibility requirements, performance requirements, scalability requirements and any other non-functional requirements you may want to prioritize.
After the workshop, you want to consolidate the requirements list, think about other non-functional requirements that may have been missed, and do another check with key stakeholders to ensure you did not leave anything crucial out.
As a product manager, you want to consider options and identify whether building this in-house or going for something out of the box makes more sense. To make this decision, you must understand all important aspects and constraints.
Yay, you got the green light to develop this onboarding tool. And since it is built by the employees, for the employees, you want to involve the employees in the process as well.
You’ll need to run an ideation workshop. You want to gather your key stakeholders and a few employees from various functions and HR, as covering all areas of interest is important.
Run the ideation workshop with the following steps:
Once the workshop is over, the product team can analyze the results, which they can take to the next stage.
To ensure you are not wasting any valuable resources on building something your colleagues will end up complaining about later, this is when you want to do a quick prototype and give everyone the chance to test it.
You can use a user testing platform such as Useberry and send them a link with the prototype and a feedback survey. If you don’t want to be that democratic, you can also choose to test with a few users, but make sure you choose people with various backgrounds and functions.
You will get valuable insight into the solution and ensure you’re moving in the right direction. It will also indicate any usability issues you can address before development work starts.
Remember that you must test the onboarding platform’s high-level concept at this stage. While the development team starts working, you want to conduct continuous discovery for subsequent features and concepts to ensure you are still on track.
The next step is to prepare your outcome-based roadmap for the development team and plan your next discovery activities.
In the development phase, it’s rather straightforward — you want to manage the teams’ backlog, address any questions and be involved in both reviews and acceptance of the developed features, while in parallel, you keep performing your continuous discovery activities where you research, prototype, and test new concepts.
Yay, congrats! Your first version of the onboarding tool is ready to be rolled out and used by your colleagues.
But, you can’t just email them the link and let them enjoy it. You need to make your change management plan together with HR.
Consider the following aspects:
Make sure to update this plan continuously as the product evolves.
As with any role, internal product management comes with its own set of challenges. The following tend to come up the most:
Most of the time, when it comes to internal tooling, the stakeholders have the impression that they already know what the employees need and want, and they jump directly to building the solution.
It’s your job as the PM to bring in the product designer and advocate together for the users. Be prepared to fight for gaining access to the users, and find some quick wins which you could implement without too much fuss.
Not all stakeholders are equal. Do the stakeholder mapping exercises at the beginning of your endeavor and create a power/interest grid to help you devise strategies on how to best manage your stakeholders.
As companies tend to move slowly, and it’s hard to get all relevant stakeholders together, make sure you find allies. It is not easy to go against everyone, so finding an ally who believes in your process can go a long way.
If you want to get buy-in from various stakeholders, try talking to each of them in private and get their buy-in, and only then address the whole group. It will be harder for them to go back on their word once you have already discussed the ideas.
Humans resist change by nature. It’s about navigating this resistance to change and planning ahead.
Think about providing comprehensive training and support for your users. Highlight the benefits and improvements the platform brings and address concerns and feedback proactively.
You can also think about finding your super users, a group of friendly employees who can help you in evangelizing the new tool to the company.
When it comes to internal systems, this also means integrating with already existing tools and applications. Most of the time, companies don’t have an ESB, so the architect is your best friend when defining the solution.
He will be able to help you identify the best ways to integrate into the existing landscape and devise the right kind of technical setup that will support the product’s success.
While you’re not dealing with go-to-market plans, and revenue targets, internal products face their own set of specific challenges. From navigating corporate politics, getting stakeholder alignment and change management, internal tools provide a great way to build user-centered, valuable internal tools.
And the best part about it is the fact that you have your users at your disposal. They are your co-workers, so why not make use of that proximity?
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Sowmya Sundararagavan shares best practices for maintaining a strong long-term vision while also remaining flexible.
A feasibility study template is a document that serves as a guide to evaluate whether a project or initiative is practical and worth pursuing.
Julie Swanke talks about the importance of prioritizing intuition and user-friendliness while building internal tools.
A feasibility study aims to determine whether a proposed opportunity is financially and technically viable and commercially profitable.
Learn more →
