My Experience Using the LNO Framework : A young PM’s Perspective

My Experience Using the LNO Framework : A young PM’s Perspective

Some time ago, I came across a prioritizing framework that was very well suited for product managers. It was explained brilliantly by Shreyas Doshi in this twitter thread.

According to Shreyas, there are three kinds of tasks a PM can have-

  1. Leverage Tasks - Tasks that will move you towards your goal if you do them extremely well. The outcome of these tasks has a high positive correlation to the effort put in.
  2. Neutral Tasks - Tasks that do not offer an upside if you execute them well but have a big downside of not doing them well enough. A lot of neutral tasks have a baseline that needs to be fulfilled for smooth functioning.
  3. Overhead Task - Tasks that neither have an apparent upside or that will have a consequence of not being deliver in time and at a baseline of quality. These tasks are usually more common in larger teams/orgs that might have many stakeholders, not all of whom are aligned.

Aakash Gupta builds on this thesis by helping readers identify tasks that are leverage, neutral or overhead in nature. You can read about that here.

He nests several other frameworks within the LNO framework to help identify the nature of the task. According to Aakash, the way to classify leverage tasks is by first identifying what is important to you. He uses the Shape of a PM framework for that. Once identified, you can pursue your leverage tasks with all your attention. Similarly, you can identify your medium and overhead tasks based on your shape

Shape of a PM
Shape of a PM

Reading these articles was great and I indeed learnt how to improve my workload by focusing on leverage tasks. The problem I ran into was that the nature of my job is fundamentally different than what Aakash and Shreyas talk about. As a newbie PM in my org, I lack the following things that prevent me from defining my shape →

  1. Lack of control over the adjacent products that are dependent on mine. This push and pull of prioritizations generally changes the nature of my responsibilities from feature to feature. For example while working on a release that is primarily a feature my product, I take on the Feature Specification, Product Delivery, Quality Assurance, Data Analytics and UX of the project. But while working on a release, where my portion is a supporting component, my duties are diluted to just product delivery. The tasks are equally important but focus on different areas of responsibilities.
  2. Owning a pseudo product that is actually a component of a larger “actual” product. I think a lot of young PMs can relate with me. In any sufficiently large organization, you will likely own a piece of a product which itself might be a part of a larger suite of products packaged together. For products like these, the basics of product management like roadmapping become quite muddied and you have to align with other PMs about the approach, no matter the individual priority - in-fact there might not be an individual priority of the product.
  3. Lacking the context of what is it the product group is trying to achieve. This might be unique to me but I feel like whenever you have a huge business team working with its own set of priorities and a sufficiently large product team trying to align internally, align globally with business objectives, but also aligning locally with their individual business stakeholders → it becomes easy for one to lose context. I am aware of our top level business goals, I also know our product goals that will facilitate the business goals. I also know my specific business stakeholders and what they are trying to achieve so that we as an org meet our goals. Finally, I know my own goals and OKRs that I must deliver in service of all of that. But when I am in execution mode- all of this fades into the background and all I have is a task board and things that need to get done. These blinders are necessary to actually focus on the day to day job but the rich context makes it difficult to know what tasks is an L, an N or an O. Also all of these goals are moving and evolving over time - and keeping up to date with each is a hard task in itself.
If you cannot decide your shape, you cannot decide your LNO and then how do you apply it to your job.

Defining My Own Leverage

  • Focus on roadmap > Focus on backlog → Write more, better thought out and easier to read PRDs, → Stay one step ahead of the dev sprints (not always an easy task for me) → Prioritize smaller roadmap items for spare bandwidth rather than allocating it to backlog (which is always the easier thing to do)
  • Alignment with Business and other Products → Routine update calls with all business stakeholders about current and future requests → PRD peer review with PMs in my own product group but specially with PMs that have dependencies on me → Better thought out and clear release emails, product documentation and release notes → Call summaries and key deliverables being communicated after every call.
  • Increasing my undestading of Ad-tech and our products → Read documentation about industry standards, subscribe to industry newsletters and read articles shared internally → Read our internal tech and product documentation to understand how different systems work and interact → Write better communication and documentation about my own releases

These goals broadly define what I want to do in my job and maybe they define the shape of my priorities but the overlapping nature of various goals makes the shape unclear to me. However I know that as long as my tasks belong to these categories then they are my L tasks and I better do them well.

What I Consider Neutral Tasks

The main tasks that I consider neutral are:

  • Requests from stakeholders (outside our roadmap and planned activities) that might have more context than me like the Group Product Manager, Business Leads. Generally I drop in a message to ask for context in such chases.
  • Data related tasks where i need to help some business/product teams with data they might need
  • Support tasks for other products for which we need to build BE support, compatibility layer, UI changes, etc.

These are my neutral tasks and they might not move the needle forward but they ensure smooth functioning. So I try to do a good enough job in these tasks. The problem is the sheer volume of these tasks mean that they take up more than half of my working hours.


The main tasks I consider overhead are:

  • Data requests that could have been fetched from the analytics dashboard
  • Attending calls that didn’t need my input or keep in the loop in anyway
  • Beautifying already clear and well structured communication like presentations, spreadsheets, emails, etc.
  • Coordination and getting up-to speed due to my own leaves or other team-members taking leaves.

These tasks, while not completely useless - have absolutely no returns beyond the bare minimum effort. There is also generally low risk if you don’t do them particularly well or in some instances, not at all.

Applying LNO

  • First, I just classified my tasks without really changing my attitude towards them becuase that happened inherently. Any PM can intuitively gage the relative importance and urgency of different tasks after a few months on the job.
  • Then I started recording how much time I spent on each category of tasks. For this, I used the app Sessions. This showed me that while I intended to spend >50% of my working hours on Leverage tasks, the reality was close to 20-25%. Most days I was spending >50% time on neutral tasks and around 30% on overhead tasks.
  • I tried to change this b chry setting up my calendar and blocking time for my leverage tasks. Initially it was tough as I left little gaps between tasks. I overcame that by allotting far more time for leverage tasks (around 200%) than what I felt I would need.
  • I also set a fixed amount of time for overhead tasks and would carry them over to the next day if I couldn’t complete them in whatever time.

This is where I am at currently, but there are a few learnings I can share from my process.


  • Don’t focus on adding more time for your leverage tasks. Focus on reducing your overhead time. This is because leverage tasks are usually deep work and can be interrupted easily by messages, calls and small but “urgent” requests. By allocating them a limited time, you make it harder for them to spill over,
  • Calendars are better than task managers. They allocate time and make any overlaps difficult. The visual representation also makes you question if you have packed your day and are actually going to be able to meet your deadlines. Lastly, they also let other people who might want to allocate your time aware about what you are working on.
  • The definition of LNO tasks is always evolving, sometimes weekly. I wrote the way I decide tasks but sometimes there are things I want to focus on which don’t adhere to my framework and that’s fine. The evolving nature of managing a product means there are new things on my plate constantly and I have to decide priority in real time.

To be continued