The product lifecycle for internal products

Back in 2019, I was part of team charged with rebuilding a pricing app for an agriscience company. We started our effort with a six week period of discovery sessions. Everyone on the team was new to the company and the industry, so those sessions helped us understand the business process, business rules, and data involved.

Alongside doing those discovery sessions, we also started building out the infrastructure we were going to build on. We were taking an app built 20 years before in PowerBuilder and moving it to Azure.

Due to the nature of the system we were replacing, it didn’t make sense to have both old and new live at the same time. We were in a situation where we had to turn the old system off and turn the new one on at the same time. The date for the cutover – April 1, 2020.

So even though we weren’t actively moving things to production, we released changes to a pre-prod environment so that our users could look things over and provide feedback.

Although I would have preferred to establish outcome metrics to use to guide decisions, we weren’t able to identify meaningful ones for a couple of reasons. Had I to do it all over again, I probably would push harder to establish metrics. Nonetheless, we did use a couple decision filters to determine what features we needed in place for the cutover.

That’s not how you “do product”

I’ll admit, as we started that effort out, I felt guilty about not doing things the way you’re supposed to. I repeatedly looked for ways to shoehorn “doing product the right way” into our approach, but it didn’t always seem to work.

Then I realized the articles that describe “doing product” as establishing a metric and then doing a bunch of small experiments to get closer to that metric fail to mention a key thing. They assume you’re optimizing a product you sell.

Yes, optimization is a key part of product management. When you’re at a specific point in the product lifecycle. To be more specific, optimization is the appropriate action when you in the growth stage (where you’re optimizing for attraction) or the maturity stage (where you’re optimizing for retention).

In the scenario above, we were working on an internal product, and we weren’t in the growth or maturity stages. So it stands to reason that we probably needed a different approach.

My guess is if you’ve ever worked on internal products, you may have experienced a similar situation. So I thought it’d be helpful to describe what the product lifecycle looks like for internal products.

If you’re not familiar with the product lifecycle of products for sale, I’ll point you to an article I wrote for airfocus, How Product Managers Navigate the Product Lifecycle, and the ProductPlan glossary item on the Product Life Cycle.

What is the product lifecycle?

The product lifecycle is the journey your product takes from the inception of an idea through to your product’s retirement.

The lifecycle consists of the following stages:

Development
Introduction
Growth
Maturity
Decline

The lifecycle stage your product is currently in is probably one of the biggest sources of context that influences your approach.

Development stage

The goal of the development stage is to move from concept to solution. This stage starts with an assignment to solve a problem, usually involving a business process or operational inefficiency.

During this stage your product team performs discovery to understand the needs of internal stakeholders who will use the product. You then use that understanding to craft a valuable, viable, usable and feasible solution.

The stage ends when you’ve crafted an initial version of the solution that you can get in the hands of users and stakeholders to get feedback. This version is certainly not ready for regular use, but it does give users and stakeholders something to react to.

And what ever you do, don’t call it a MVP.

As a product person in the development stage, you work with your product team to conduct user research, identify a potential solution estimate the impact your solution will have and the investment necessary to reach that solution. Along the way, you’ll want to ensure that solving the problem and the solution you identify align with your organization’s strategy.

The discovery and initial development work you do represents a significant investment, but you won’t generate any impact in this stage. That’s because your users aren’t in a position to incorporate the product in their day to day work.

Don’t let the negative results dissuade you from some thought out discovery. A small amount of time spent understanding the process and identifying assumptions and risk early will pay off down the road with more focused development of the right features in your product.

Finding those “right features” requires some intentional prioritization decisions focused on determining the appropriate features to include in your initial version. You may find that decision filters in the form of “will this help us do [x]” extremely helpful, especially since you won’t have anything to measure, yet. Keep only the things that pass the decision filter, and then move the items earlier on in the sequence that help you mitigate risks and validate assumptions.

In the case of the pricing app I mentioned earlier, we spent about three months in the development stage. During that time we kicked the effort off, held the discovery sessions and did sufficient development work to get an initial version in a pre prod environment so that we could get feedback.

Introduction stage

The goal of the introduction stage is initial deployment and adoption. This stage starts with the initial version and carries through to when your product has sufficient functionality that an initial group of users can use the product for their day to day work.

The stage ends when your product reaches the internal product version of product-market-fit. That means it meets the needs of the initial department or use case intended for the product.

This is the first point when your product delivers and impact and can start paying back the investment that got it to this point. That investment comes in the form of completing development work of the initial functionality as well costs related to training and onboarding users.

As a product person in the introductory stage, you make decisions about what functionality you need to include to reach that internal product-market-fit, quickly address bugs, training and onboarding users and encouraging adoption. You’ll also need to start measuring impact as people start using your product in their day to day work.

Your prioritization decisions in this stage center around what you need to add to make the product a viable solution for your initial use cases and users. You also need to determine what changes you need to make based on feedback from users who’ve tried out your product in the pre prod environment.

With the pricing app, we were in the introduction stage for about eight months. We had to get a considerable chunk of functionality in place for it to be a working solution, especially since we were in a turn off old/turn on new situation.

During this time I constantly had to make decisions about what things were included in the product on April 1st and which things we could introduce afterward. Again the decision filters we set up helped us determine what made that initial cut.

Growth stage

The goal of the growth stage is expansion and enhancement. This stage starts when your product reaches the internal product version of product-market-fit. At that point your product team works to increase your product’s reach to more departments, increasing integration with other internal systems, and grow the feature set based on user feedback.

The stage ends when you’ve rolled your product out to all the relevant departments in your organization and you’ve covered all the main use cases.

The impact your product delivers increases as you roll out to more departments and use cases. At the same time, your investment should be lower than the previous stage since you’re making smaller changes than you were before.

As a product person in the growth stage your main concerns are scaling the solution across the organization, developing integrations with other internal tools, and implementing feature enhancements based on feedback.

To make prioritization decisions at this stage, you select from a set of possible changes to address new use cases and departments, as well as respond to user feedback. Your guide for making those decisions is alignment with your organizational strategy. You may also use an engagement metric to track progress in getting people to use your product.

The pricing app I mentioned earlier served a very specific use case, so it appeared that we wouldn’t spend a considerable amount of time in the growth stage. Then we found out that a business unit outside of North America was interested in using the app. The time the team spent getting the app ready for that other geography related to being in the growth stage. The majority of effort spent on the app was to prepare it for use in the new geography.

Maturity stage

The goal of the maturity stage is optimization and refinement. This is the stage where the “make changes to meet a metric” nature of most product management articles apply.

This stage starts when you’ve rolled your product to all the relevant departments and have covered all the necessary use cases. Changes you make during this stage center around optimization and gaining efficiency in the process. The stage ends when those changes no longer influence impact.

As you may expect, the impact your product provides plateaus at it’s maximum point. Meanwhile your investment during this stage is lower than previous stages because you’re making tweaks rather than substantial changes.

Your role during this stage is to optimize your product to improve process efficiency, reliability, and the user experience. As a result, your main prioritization approach is to set a small number of metrics that measures those characteristics and select the changes you make based on what optimizes those metrics.

The pricing app moved into the maturity stage once work was done preparing for the second geography and as far as I know is still there. It’s normal for internal products to spend a majority of their time in the maturity stage, especially if they enable a stable process.

Decline stage

The goal of the decline stage is transition planning and legacy support. This stage starts when the impact your product delivers starts to decrease. This usually happens due to changing business needs or when new technologies emerge as alternatives.

The main activities that occur during this stage are deciding whether to revitalize or replace the product and make any necessary transitions based on that decision.

The stage ends when you’ve implemented the decision. If you decide to revitalize your product, you can think of it as moving back to the maturity stage, although the efforts to revitalize your product may represent a higher investment than what you had been spending.

If you decide to replace your product with a new product, you launch a new product lifecycle for that new solution. In the meantime, you limit work on your product to the necessary effort to maintain critical functionality until the new solution was ready and transition data to the new solution.

This is what happened with the pricing app I’ve mentioned throughout this article. The original pricing app was in the decline stage when the company decided to rebuild it. So while we built the new product, work on the old one was limited to only necessary bug fixes and minimal maintenance. There was also work needed to transition the necessary data to our product when were getting ready to go live.

As a product person, you have to make the critical decision to revitalize or replace your product. Then you have to take the appropriate actions based on that decision to ensure the process you were enabling continues to receive the necessary support.

The key guide for that decision is whether your product still fits in with organizational strategy. You may use your product’s performance against your chosen impact metric as a signal that you need to make that bigger decision.

More helpful than “it depends”?

Hopefully you found this exploration of the product lifecycle for internal products (should I just call it the internal product lifecycle?) helpful. As I dug into the topic more, I found it’s a good starting point to provide more useful answers than “it depends.” It also provides some backup as to why you shouldn’t get overly worried about looking for the one right way to do product, or to go on the futile hunt for best practices.

But I’d like to hear from you. Was this exploration helpful? Does it make sense? Does it align with your experience, or have you experienced things that would shoot big holes in this description?