The ASE Product Framework

A product manager introducing an internal product.

I’ve written extensively in the past about the importance of product managers focusing on impact. In fact, your goal as a product manager is to maximize impact for your company and users/customers via product development.

This statement is quite straightforward and many will agree with it. However, those who are extra perceptive will ask me – “wait… what is your definition for ‘impact’?”

And that is a really good question.

Luckily, I’ve already addressed this question more than once through the CAF Product Framework I developed (if you’re still unfamiliar with it, you can read about it here).

Essentially, what I suggest is to invest an effort to properly define the north star for your organization or business unit and then this north star can serve as a compass guiding your success and impact.

So far so good. Except, when you drill down to the definition of the north star, you can see it needs to fulfill 3 conditions:

  1. A leading indicator for revenues (e.g. – if it goes up the revenues will go up and vice versa)
  2. A leading indicator for market share
  3. An indicator for the value your product delivers to the world

Now, if you are managing one of the main products of the company, then it should be very feasible to find a north star which fulfills these 3 conditions. However, if you are responsible for an internal product of the company (a product which serves only internal stakeholders, such as a tool for making the operational team work faster) – then the first condition, which is focused on your impact on revenues, will be quite challenging to fulfill. That is because it’d be challenging to correlate the efficiency of your internal product with the impact on the companies’ revenues.

Overview of internal products

Let’s clarify exactly what I mean when I refer to internal products/tools. 

There are plenty of examples of internal products. Here are some:

  1. An internal monitoring tool
  2. An A/B testing platform developed in-house (such as Netflix Test Studio)
  3. An internal CRM system catering to the organization’s special needs
  4. An AI agent for the internal stakeholders used for querying the knowledge base of the company
  5. Workflows automation tools for the operational teams
  6. A tactical command & control system for special forces, built in-house due to confidentiality of the information displayed
  7. Customers’ contracts management tool for the finance team

And many more.

There are two main characteristics to internal tools, which are different from external users/customers facing products:

  1. It’s hard to correlate them to generated revenues
  2. Your users (the internal stakeholders using your product) most likely have no choice but to use your product.

These two characteristics significantly impact how you measure success.

You see, the problem which now arises is that two of the requirements we set up for the north star are no longer valid. We said that, ideally, the north star needs to be both a leading indicator for revenues and for market growth. Alas, with internal products it’d be nearly impossible to correlate our product’s performance to the organization’s revenues and in most cases, we don’t have a ‘market’ that can demonstrate growth. Our market is pretty much stable, and it relies on the organization’s own employees.

This naturally leads us to the question of how you measure impact when your team is building internal products?

Tuning your work for impact with internal products

With customers facing products, the north star is a very good proxy for measuring our efforts and whether they lead to true impact. The assumption behind this is that if your revenue, market share and value you deliver to customers are growing – then you are creating a positive impact with your efforts.

As we just noted, two out of three metrics aren’t readily available for internal products, significantly weakening our north star.

An intuitive approach would be to adjust our definition of a north star metric specifically for internal products. This works only to some extent, and only for a specific set of products. Let’s understand why.

Let’s take an AI agent developed in-house for answering ad-hoc queries by various internal stakeholders, based on an internal knowledge base that was built over the years.

In such a case – we can narrow the definition of the north star to focus purely on the volume of usage, which can keep growing as users extract more and more value from this agent.

Hence, a reasonable north star could be ‘the accumulated amount of inquiries made by internal stakeholders within a given week, excluding follow-up or clarification questions’.

If this metric keeps growing, it’d be reasonable to assume that this agent is providing more and more value to the organization.

That is relatively easy.

 

Now, let’s take a different internal product, from the list above. Let’s focus on the military system that provides your forces with a tactical map of everything that’s going on around them.

What should be the north star of such a product?

In this case, and after giving it a lot of thought – I don’t see how a north star metric can be defined in a way which will be useful for measuring the health of our product.

This is due to a couple of reasons:

  1. Usage can’t really explode or grow indefinitely (except maybe for the early days of the system), as the amount of tactical teams is known and final, as well as the amount of operations. 
  2. Because the users are forced to use your product, it’s challenging to find a single metric that will tell us how much value users are extracting from the system.

These limitations apply to many internal products, such as internal CRM, testing infrastructure, monitoring infrastructure and more.

For such cases, and again, after investing quite a long period of thought and experimenting with various concepts, I came up with the ‘ASE Product Framework’, where ASE stands for ‘Adoption-Satisfaction-Expansion’.

The ASE Product Framework

Internal products such as the ones mentioned before, can be referred to as ‘mission-driven products’, in the sense that they were invented in order to solve the organization a very clear, internal, pain, that an off-shelf product – couldn’t.

It usually means that your organization has some clear restrictions and requirements as for what it needs. At least at the beginning.

Hence, as a product manager, owning such a product, the pain you need to address is very clear, as well as the restrictions, compliance and other rules you need to adhere to. Your mission is clear (again, at least at the beginning):

You need to build a product that addresses the pain, under the given restrictions, and once the first version is ready – internal users will start onboarding and using it. Once it passes a certain quality bar (determined by some authority in your organization) – it becomes the status-quo, and all internal users suffering from the same pain must use it.

At this stage, it doesn’t necessarily mean they’re happy with it or even like it. It could even be that they hate your product, and yet, they must use it. You have a captive audience, but not necessarily a satisfied one.

As a product manager, you begin to wonder what your next step should be. Which brings us back to the question of impact. 

Should you add more features? Or should you focus on the satisfaction of your users with the existing features?

And if you decide to add more features – what should be your criteria for determining those? What should you base your roadmap on?

My suggested ASE Product Framework addresses this by outlining the lifecycle of internal products. Here are the 3 stages I’d recommend following:

Adoption

Once your product passes the initial quality bar, and you have an approved V1, you should focus next on onboarding all potential users.

Yes, as we discussed before, your ‘market’ is capped and known. But this is why this step is very feasible. Since you were given a clear monopoly on this specific pain, you need to make sure that all the relevant internal stakeholders stir away from any other method they used before for solving the problem, and switch to your solution. Use any official channels at your disposal (such as shutting down access to other legacy systems, forcing ‘updates’ or just pure marketing via emails, Slack or other channels which are available to you).

It may sound a bit aggressive, but it’s really not. If your product is the new standard in your organization – let’s kick out all other systems/solutions that existed before, clear the table, and make sure everyone is on the same page.

It will result in a great amount of feedback flowing your way. Ideally, most of it would be positive, especially if the quality bar was set high enough, though some of it will probably be negative. Many people just don’t like changes.

Satisfaction

Once you have acquired the whole market (or most of it), it’s time to make sure your audience is happy with your solution, and hence you should focus on measuring the satisfaction from your product.

Whatever problem you were tasked with solving, you need to solve it very well.

It’s true that your users have no choice but to use your product at this stage, but let me tell you a secret – nobody likes to be captive.

If your audience won’t feel that you are making huge efforts to make them happy, your organization can either replace you, or your product. 

I’ve seen cases where internal stakeholders weren’t happy with an in-house solution that was developed for them, and eventually the company hired a contractor to develop a system to replace it. Essentially, it borrowed its product team from someone external.

Hence, you always have a competition, even if you don’t ‘feel’ it on the day-2-day.

I’d therefore regularly measure the satisfaction from your users. There are plenty of quantitative ways to do it, but maybe the easiest approach would be to simply ask your users to rate their satisfaction every few months, from 1 to 10.

Your goal is to get above 8.5 (average score from all respondents) and consistently stay there. You also need to make sure that at least 20% of your target users rate you each quarter.

Now, it could take you a year or two to get there and sometimes even more. That’s fine. As long as you are constantly climbing with your score you are on the right path.

Expansion

Once your product solves the original pain it was tasked to solve in a satisfying manner, it’s time to ask yourself ‘what’s next?’

Let’s take a metaphor that will help you identify this point in time more precisely:

Did you ever prepare a popcorn in the microwave?

Popcorn packages used in a microwave come with instructions: You should put them in your microwave at the highest temperature. For how long? Well, the popcorn manufacturer doesn’t know your microwave model, so the instructions say:

“After the first 1-2 minutes you should start hearing a lot of popping noises. When the popping noises start to tune down so you have a single pop-up noise each second – your popcorn is ready”

Let’s apply this metaphor in your product:

At the beginning there is a lot of appetite for features, so your roadmap should be quite clear and packed with work items. As time goes by and you’re progressing towards achieving your mission, the feature requests from the various internal stakeholders will tune down the same way your popcorn in your microwave does. Once you are getting to the stage when the features coming your way are less frequent and they seem less meaningful, it should signal you that your product is ready for the next stage.

However, from my experience, this is where many product managers begin to lose focus and fall into the routine of simply implementing random backlog features.

This is not where you want to be, as it means that in this stage, you are merely taking features to production, which makes you and your team a ‘feature team’, rather than a ‘product team’ (a term coined by Marty Cagan here).

If you recall, the question of ‘what’s next?’ is usually resolved by following the CAF product framework, by coming up and later reviewing our product strategy.

The same applies here.

In fact, at this stage you should follow the CAF Product Framework as we discussed many times in the past. There is only one component you need to change – the north star. It won’t exist. You replace it with your extended mission.

 The original steps were:

  1. Mission
  2. North star
  3. Product strategy
  4. Product roadmap
  5. Quarterly plan
  6. Hands-on (execution)

When you are dealing with internal products, at the point in time where you reach the ‘Expansion’ phase you are actually ‘rebooting’ the pyramid by setting a new, extended mission.

By now, the original mission you were tasked with is already accomplished in a satisfying manner. Hence, you need to refine your mission in an ‘extended’ manner. It means that your product still needs to provide a strong solution to the original problem, while its scope extends to solve other problems ‘in the neighbourhood’. 

Your pyramid looks exactly as in the CAF Product Framework, with one main change – the ‘mission’ and the ‘north star’ layers are replaced with your new ‘extended mission’.

And once you set the new, extended mission – the framework restarts. Yes, you start the A-S-E stages from scratch:

Adoption – you need to make sure your users adopt the extended capabilities you are introducing in your product. Ideally, the adoption will happen naturally, because you identified real pains. But sometimes you’ll need to market your work a bit and make sure they try it.

 

Satisfaction – once they try your new features, they need to become satisfied with them and confirm that you have actually accomplished your extended mission. Again, this can sometimes even take a couple of years, and maybe more.

 

Expansion – and once you are convinced you accomplished your extended mission, it’s time to rephrase your mission again, by providing your product with new areas of responsibilities and capabilities.

ASE Product Framework
ASE Product Framework

Examples

Let’s take a couple of examples.

Example #1

Your product: An internal A/B testing platform for mobile gaming marketing teams. The platform supports creative management and tracks historical performance.

Original mission: Provide the marketing team with a reliable, comprehensive tool for managing, executing, and analyzing A/B tests for marketing creatives. The tool captures, stores, and provides easy access to historical data to help optimize marketing campaigns.

Challenges: Building a robust testing infrastructure capable of handling multiple simultaneous A/B tests, integrating analytics to measure key marketing metrics (CTR, CPI, ROAS, etc.), efficiently managing and storing creative assets, ensuring data accuracy and real-time results, and establishing workflows that streamline the marketing team’s operations. Achieving initial adoption and satisfaction among marketing analysts and campaign managers.

Extended mission: Creative Insights and Recommendations.
Once your product consistently handles A/B tests smoothly, you might extend your mission to become more proactive rather than reactive.

Specifically, evolve your platform into an insights-driven system that automatically analyzes historical performance data to recommend new creative concepts or variations that are statistically more likely to succeed.

This would involve integrating predictive analytics, AI & machine learning, and deep analysis of creative elements (colors, layouts, messaging), helping marketers make smarter and faster creative decisions.

Example #2

Your product: A real time mobile tactical map for military forces.

Original mission: Provide a reliable and comprehensive tactical map that includes all friendly & hostile forces in a designated area.

Challenges: Connecting to multiple sensors, delivering the information in real time, syncing information between devices, delivering 100% accurate information and more. These challenges can take you years to overcome, depending on the complexity of integrating all the sensors, networking challenges and collaboration from other partners.

Extended mission: Provide full command & control capabilities to the officers in the field and in HQ over the deployed forcers.

 

Once your product delivers a reliable map, and users show great satisfaction, you need to stop and ask yourself ‘what’s next?’

Your extended mission can now be to upgrade your tactical map to a fully fledged command & control system. Meaning – officers can now control their troops via this map, send them instructions and get feedback. This is a huge upgrade to your current product.

Summary

Managing internal products presents unique challenges. Unlike customer-facing products, you can’t rely on typical north star metrics like revenue or market share to measure impact. That’s why I developed the ASE Product Framework – Adoption, Satisfaction, Expansion – to guide product managers through a continuous, cyclic process of ensuring impact.

By embracing the ASE Framework, you can systematically guide your internal products through phases of adoption, improving satisfaction, and expanding their scope to tackle new challenges. This ensures your product remains relevant and impactful, even if its audience is limited and captive.

Liked it? Why not share it?
Scroll to Top