Learn 80% in 6 Months

My rule of thumb for PMs: learn 80% of a new domain within six months—enough to make good decisions and know when to ask an expert.

TL;DR: As a PM, you will keep landing in places you don’t know. You need to learn enough, fast enough, to make good decisions, spot weak assumptions, and know where your understanding ends.

When I explained why this site looks like docs, I dropped this theory in as a single line and moved on. It deserves more than a line, because I think it is one of the most underrated skills a PM can have. This page is my attempt to explain what I mean, why I believe it, and how I actually do it.

What I mean by 80%

80% is not a score you can measure, or a claim that I know most of everything there is to know. For me, it is the point where I can follow a conversation with engineers, sales or customers, ask the questions that matter, and tell when something doesn’t add up. I can explain the choices in front of us and recommend one with reasons I can defend.

The remaining 20% is shorthand for the specialist depth I may not need for the decision at hand. Chasing every detail can delay useful work. But if a detail could change the decision or its consequences, I need to go deeper or bring in someone who already understands it. The skill is knowing which gaps matter.

Why a PM needs this

The context and the market never stay still

Every new company, domain or customer gives you something new to learn. That part is obvious. What is less obvious is that even if you stay in the same role, the market keeps moving under you. A new customer need or a competitor’s feature can change what people expect from your product.

I have said this before: if you want to retain product-market fit, you need to keep learning. PMF is not something you find once and keep. What fit your market last year may not fit it now. You need to keep learning about the market you are already in.

The job changes as you grow

The PM job you start with can look very different five years later. You might move from owning a feature to managing other PMs, or take on the mission, vision and strategy of a larger product. Each change brings something new to learn, even when you already know the domain.

You are the one connecting everyone

You don’t need to code like an engineer or sell like a sales rep. But you do need enough of their world to ask good questions, push back when something sounds wrong, and make trade-offs that everyone can live with. Generalists only work if they can pick up the basics of each function quickly.

Your contribution needs to grow

When you join a new team or move into a new space, people expect basic questions. As you learn, your contribution should change. You should be asking more informed questions, connecting what you hear across teams, and bringing a point of view you can explain. The questions don’t stop; they get better.

AI raises another learning question

AI is already writing code for me. That gives me another question to work through: what do I still need to understand to judge the result? Getting to an answer faster is useful, but I still need enough knowledge to tell whether that answer makes sense.

How I learn

Here is what I actually do when I land in something new.

Vocabulary first

Every industry has its own language. Until I speak it, people simplify things for me, and I end up learning the simplified version. So the first thing I do is collect the terms people use and make sure I understand what each one really means. Once I can use the vocabulary correctly, conversations go deeper much faster.

Read competitors’ blogs and docs

I start with the competitors customers actually compare us with, then look at products taking a different approach to the same problem. I read their blogs and docs. Docs explain what a product supports and how it expects to be used. Blogs show how a company wants to position itself and what it says is changing. Both are useful, but they are the company’s version of the story.

This is a big part of tracking the market, and if you are new to a space it is the quickest crash course I know.

Use the products in the space

If possible, I try the main products customers consider and work through a task they would actually do. Using it helps me see where it is great, where it hurts, and what I should ask customers about. If I can’t get access to it, I try to watch demos on YouTube.

Before AI started writing code for me, I used to do the same thing with programming languages. Whenever I picked up a new language, I built a static blog builder with it. It was a small enough project to actually finish, but it forced me to deal with the parts of a language that tutorials skipped.

Sit with the people who live it

I spend time with the people who do the work every day: sales calls, support queues, engineering reviews. I ask “why” a lot more than “what”, because the why is where the context lives.

Talk to customers early

Customers are the fastest way to find out which 80% actually matters. A lot of what I read in the first few weeks turns out to be noise, and talking to customers is how I separate the two.

This belongs alongside the reading and product exploration from the start. A conversation can change what is worth reading next.

How to tell if you are making progress

These activities overlap. You don’t need to finish reading before you talk to customers, or understand the whole industry before you make a useful decision. If you want to put the six-month rule into practice, here are three checkpoints:

By the end of month one: Can you explain the vocabulary, the main customer problem, and the alternatives people use today? Write a short explanation and ask a colleague close to the work to correct it.
By months two and three: Can you connect what customers say to what you have seen in the products? Pick a real decision, set out the options, and ask customers and colleagues to challenge your assumptions.
By months four to six: Can you recommend a course of action, explain the trade-offs, and identify what you still need help with? Revisit earlier decisions as evidence comes in and note where your understanding was wrong.

The test is whether your learning improves your judgment. A growing reading list alone won’t tell you that.

Why six months?

There is no science behind the number. Six months is a rule of thumb from my experience: enough time to build a useful understanding of a new space, with a deadline that keeps the learning purposeful. Some spaces take less time and some take more.

By then, I want to be able to make decisions I can defend, spot assumptions that need checking, and know who to ask about the gaps. Six months is a checkpoint, not a reason to wait before contributing or to stop learning afterward.

Your job is not to become the expert

The goal of all this is not to become the smartest person in the room on any one topic. It is to learn enough, fast enough, to make the call and to know who to ask about the remaining 20%.

What is the 20% you keep chasing that you could let go of? And what is the 80% you have been putting off learning?

Contributors

Ravi Vyas

Want to Contribute?