It doesn’t matter whether you are a product manager or not, if you have ever tried building a product, there are three keywords that you would have come across for sure; Strategy, Roadmap and Prioritization. In all organizations, these three keywords are used in every context whenever there is ambiguity and decision making is hard. For every product manager, preparing for prioritization meeting is a nightmare. There is always a laundry list of features sent by different teams. Whether its the commercial teams or the account management or support teams, everyone has a list that is the highest priority blocking revenue and growth. There is not a single salesperson whose next major deal closure is NOT dependent on that one particular feature which you have been postponing for a long time.

In the last few years, I have come across so many product managers peddling so many frameworks. and on top of that, people ask for templates for those frameworks. There is RICE, JTBD, OKRs, Kano model, MoSCoW method, Opportunity Scoring and a lot more. These are just frameworks. There are hundreds of tools and templates based on all these frameworks interpreting their own way of building product strategy and roadmap to help product managers prioritize the features for development.

I have also read through all these frameworks. but interestingly, I found one thing hidden behind all these frameworks and that thing can be called as “common sense”. So, I thought of putting that common sense in the front. If you apply first principles, then there is always a base theory. With that base theory, a few people will develop certain frameworks, and then for the mass application, the rest of the world starts asking for templates. Ideally, if you can understand the base theory then you can develop your own framework without trying to fit your product needs into those hundreds of templates.

This article is my attempt to put that base “common-sense” theory upfront. But like all other product managers, I wanted to sound cool and knowledgable so I have given this “common sense” understanding a name calling it as “The GL(c) model”.

First thing first - The Theory ( a.k.a. Common Sense)

Every organization (lets consider for-profits product companies only in this article) exists to solve a large problem and in turn, generate revenue. and the aspiration of all these organizations is to have hockey-stick (exponential) growth over a period of time so that all shareholders can make money multi-fold. Its a rolling goal year or year for every organization. The revenue can be less in some years and some years can be magical with revenue growth beyond expectations. To achieve this revenue year on year, every product company builds a product strategy that needs to answer 3 basic questions.

1. What is that one single KPI that’ll change the odds in company’s favour ? ( Answer to this question results in product strategy )
2. To achieve that one single KPI, what are the key things that we need to work on ? ( Answer to this question results in product roadmap )
3. From those list of things to be done, what should be done first ? ( Answer to this question results in feature prioritization )

Now, if you look at all the frameworks, each of them is trying to answer either all or a combination of above questions. but as a product manager, when you learn to apply a framework without understanding the theory behind it, the outcome is a slide deck that you cannot defend easily. or the other outcome is a failed product.

The GL(c) Model

If you read the above questions again, you’ll able to guess the meaning of GL(c). Let me re-iterate it here.

Goal ( G ) - What is that one single KPI that’ll change the odds in company’s favour ?

Every product is built over years and decades. In the beginning, there is a vision and mission. Then, there is an MVP. Then you get to version 2 or 3 before getting to product market fit (PMF). Once you get the PMF, you need to scale. After the scale, you need to diversify and build multiple associated product lines. This cycle evolves over a number of years but no one can build a strategy that can last for even 5 years. The vision and mission can largely remain unchanged but what changes is the strategy. And the strategy is generally always is to execute “successfully” in the expected direction.

The “Goal” in the GL(c) model is the statement (or KPI) valid for a pre-defined period that can define “success”.

Let’s take the example of twitter (I still find it hard to call it X). What do you think can be the product goal of twitter in 2024 ? is it to grow the subscribers of premium plan or premium plus plan or will it be to grow the ad revenue ? Also, isn’t it contradictory to their own product strategy. if they want to grow premium subscribers, then their ad revenue will decline. and if ad revenue increases, then they can’t focus on getting premium subscribers. So, how do you think they should define their goal and build product strategy ?

The answer can be (and this is my imagination) that in all cases, they need user growth on their platform. For user growth, they need to drive a lot more engagement on their platform.

so, the fundamental goal can be “Drive Daily Active User growth to greater than 20% MoM by EOY “.

This goal is directly linked to total revenue without worrying about paid users or ad revenue. Once they define this as a goal for 2024 ( or for next 2 years), their product and business strategy will get defined across sub-product lines (subscriptions, feed algorithm, ads, engagement, SSO etc). Each product line can now build their own roadmap based on the goal.

Don’t worry, I’ll shortly talk about levers and contribution and it’ll all start making sense.

Levers ( L ) - To achieve that one single KPI, what are the key things that we need to work on ?

Levers can be simply defined as one or more features that are required to achieve the goal. This is the actual work done by the engineers as part of product development. But then, I am calling them levers and not features or epics. The difference is subtle but important. Feature or Epic is the actual definition of work to be done. but it becomes a lever when it has a KPI that moves the needle towards the goal. Lets say you are able to acquire 10 clients for your product through sales effort. Now, out of those 10 clients, only 2 actually spent USD 10k or above every month, rest of them actually spent only USD 2k or less in a quarter. So, by “definition of done” given in the epic, that epic is still complete as it is working and clients are using it. but is it really moving the needle towards the goal?

And that’s why levers are those features that have explicit one single KPI defined for themselves without being dependent on other factors outside of that feature. Ask a question while defining a feature: Will this feature on its own can deliver the expected value measured by the KPI you identified ? if yes, it is a lever. if not, its just a feature that might make a product look good but might not be contributing to the success of the product.

Again, let’s continue the twitter example: We have set a goal above. Lets build some imaginary levers. ( by the way, you can always group multiple levers to give the collection a logical name or define it as a sub-product like I mentioned in the goal).

Now that the goal is to drive active user growth by 20% MOM, we need to list a few development items across the board (don’t worry prioritization is the next step) on each sub-product.

If you look at the levers, each of the work item will have a very specific KPI that doesn’t not depend on any other feature. As a product manager, you’ll still need to write detailed specifications of each feature, but more than that, you need to define the KPI in such a way that it directly impacts the goal. Proxy metrics like Average Revenue per user, Average number of subscribers, Clicks on ads etc. try to create an impression that they affect the goal but actually they are psuedo metrics that help you justify your job, not the success of the product.

Contribution ( c ) - From those list of things to be done, what should be done first ?

Now that you have defined the goal and outlined the levers, how do you define what should be done first. One of the most important thing to understand is that levers don’t start working from day one. It takes time to see results. For example: in Jan 2024, when you’ll build you strategy and roadmap slide decks, you cannot expect the goal to be achieved in Feb or March 2024. Engineering needs time and effort. Then, the product hits the market. Clients start using it and then, you see the results. So, It can be even 6-9 months before you even see the first dot on the chart. Keeping that in mind, the formula of contribution is very simple. For each lever, check the impact (outcome) against the effort required. The idea of contribution is to do the things that require the lowest effort giving the maximum impact. Those are the best levers to be completed first. At the same time, things that need high effort also need to get kicked off in parallel and that’s why quantifying contribution of each lever in terms of percentage contribution towards the goal becomes all the more important. This contribution percentage will allow the teams to plan resource allocation, hiring, skill set mapping and all the other engineering and commercial activities like product marketing, commercial activations, partnership discussions etc.

Let’s continue the twitter example :

Disable Ads for premium plus subscribers.

Contribution : Let’s say we can gain 1 million users by end of year assuming DAU for premium plus is 50% of total premium plus users. Total twitter users are 100 million. Effort required is 3 engineers for 5 months. but Strategic value is “Very High” or 20 percent points. So, we get 20.5% contribution with an effort of 15 person months.

Reduce the number of ads to 1 per 8 items in the feed.

Contribution : Similar to above calculations (imaginary in this case, but some grounded calculations in real world), can help determine that contribution of this lever will be 30% with effort of just 10 person months

and similarly, for rest of 3 levers, contribution will be 10%, 15% and 40% with effort of 80, 20 and 15 person months respectively. Once the contribution is known, not only it helps in building the product prioritization chart, but it also helps in planning all company wide activities like marketing, sales, support, hiring, financials etc.

The Last Step

If you put this all together,

1. you can actually represent the product strategy and a prioritized roadmap in one single table that be embedded in a maximum of 1-2 slides.
2. You can easily say “No” to all feature requests that do not move the needle.
3. Across the organization, people can actually think through about their feature requests before reaching out to you.

Lastly, and the most important thing, Build a dashboard using all the KPIs associated with the levers and a chart for the goal. As the dashboard gets updated automatically, the strategic conversations become easy. A few things that can happen afterwards are

1. Strategy Evaluation : Are we moving in the right direction at the right speed ? Are we investing resources in the right place ?
2. Accountability : If all investments are as per strategy, is sales moving at the right pace ? are we pacing ahead or behind ? If we are behind, what are the levers that need to be changed?
3. Goal Audit : Did we pick a conservative goal or an ambitious goal ?
4. Market Analysis : if everything is great, what new markets we can enter or what new products we can innovate ? Can we change our product positioning ?

I strongly believe that if you follow this method and try to answer the 3 basic questions, you don’t need to learn any frameworks. Actually, believe it or not but first principles based approach works because it is just based on common sense and common sense doesn’t need a framework or template.

Seed references to know more

I strongly recommend the following 5 most important books to read if you want to understand the common sense behind product strategy, roadmap and prioritization.

1. Understanding Michael Porter by Joan Magretta
2. Thinking in Systems by Donella H. Meadows
3. The Goal by Eliyahu M. Goldratt
4. High Output Management by Andy Grove
5. The Subtle Art of not giving a Fck by Mark Manson

Actually the fifth book in the list has nothing to do with product planning. i just liked it and its a fun read.

Feel free to follow me on Twitter ( @amitgoel1287 ) if you like to discuss about product management.

Disclaimer : I am using Twitter as just an example and I neither have connection with Twitter(X) nor I have any information about their plans. The usecases listed are only for illustrative purposes based on my limited understanding of their product. I cannot use the real world examples from my past experiences as it can reveal confidential information and I do not want to risk myself to litigation. The last thing I want is to give away my hard earned money to “Suits”.