Product management for internal products

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.

Internal product development example

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:

• Discovery
• Ideation
• Prototype and test
• Development
• Delivery

Discovery

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:

• HR manager
• Representatives from the HR team
• One or two people managers
• The product team (UX, product, engineering)

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:

• What is the vision for the onboarding process?
• What does the market look like for onboarding? What are current trends?
• What are the users’ goals, pains and needs of the onboarding process?
• What does the current onboarding journey look like?
• What opportunities have we identified?
• What assumptions do we have? And which ones are worth validating?
• What are the next steps?

You want to share the results with your main stakeholders and get their buy-in.

Design

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.

Ideation

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:

• Introduction to the challenge
• Summary of research findings and key points
• Lightning demos
• Note and sketch — this is where each workshop participant gets to define their concept for the solution
• Gallery walkthrough and heatmap voting

Once the workshop is over, the product team can analyze the results, which they can take to the next stage.

Prototype and test

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.

Development

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.

Delivery

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:

• Who do you start with? Choose a group of 20-30 employees to pilot the tool
• What learning materials do you need?
• How do you communicate the new tool to the company?
• Do you need training sessions? What’s the best way to deliver them? In-person? Pre-recorded?
• Who owns which part of this plan?
• How do you gather feedback from the users?
• How do you handle support?
• Where do your bugs get reported?
• What problems may arise? How do you address them?

Make sure to update this plan continuously as the product evolves.

Common challenges for internal product management

As with any role, internal product management comes with its own set of challenges. The following tend to come up the most:

• Avoiding scope creep and feature factories
• Getting stakeholder alignment and buy-in
• Resistance to change
• Technical challenges and integration with existing systems

Avoiding scope creep and feature factories

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.

Getting stakeholder alignment and buy-in

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.

Resistance to change

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.

Technical challenges and integration with existing systems

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.

Final thoughts

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