Category Archives: PM Fundamentals

Picture two product managers mid-conversation: “We’ve frozen the PRD, the MVP ships next sprint, UAT is clean, and GTM kicks off a phased rollout once we’re closer to PMF.” If that read like a foreign language, you’re in exactly the right place — because this is your product management 101, and the real question we’re going to answer is a simple one: what is product management, and how does a product actually get built?

Product management is loaded with buzzwords and frameworks that feel daunting from the outside — and honestly, even in your first few months on the inside. So instead of throwing definitions at you one by one, we’ll do something more useful: we’ll follow a single product all the way from a rough idea to a live launch, and define each term exactly where it shows up. By the end, that jargon-filled sentence above will read like plain English.

What is a product — and what is product management?

Let’s start at the very beginning. A product is any application or service that gives a user some value. Every app on your phone is a product — Amazon, Netflix, Uber, all products. But here’s the part beginners miss: it’s not just the whole app. Any feature within the app is a product too. Amazon’s product-listing page is a product. Browsing the catalogue on Netflix is a product. When you search on Google, the search itself is a product.

And, put very simply, the person who manages a product is a product manager — and that whole practice is product management. But “manage” is a vague word, isn’t it? So the honest answer to “what is product management” isn’t a one-line definition — it’s everything that happens between an idea and a living, breathing product that users actually use. What you’re really learning here is the software development lifecycle (SDLC), seen from the product manager’s seat. Let’s walk it.

It starts with a backlog and a roadmap

Everything begins with a backlog — an exhaustive laundry list of every product idea you have. These come from all over: your own ideas, user feedback, requests from internal teams like sales, marketing or finance, and yes, things you simply want to copy from a competitor. No shame in copying good ideas, right? The one thing to remember is that not everything in the backlog will get built. It’s a wish list, not a plan.

The plan is the roadmap — the items from the backlog you’ve decided to work on in the short term, say the next three or six months. You might have 50 things in the backlog and choose just 10 for this quarter’s roadmap. So how do you pick those 10? A handful of factors help you decide:

• Problem validation — is the problem actually worth solving?
• TAM (total addressable market) — how many users will this reach? If it touches only 0.1% of your base, maybe it waits.
• Impact estimation — what’s the end result? Revenue up 5%, churn down 10%, conversion up 2%?
• Important vs urgent — sometimes you need it now: social-media backlash over a missing feature, a feature needed to close a client, or a regulatory deadline.
• Complexity — a quick, easy build might earn a slot even without huge expected impact.

Once the roadmap is set, it usually gets a sign-off from all the stakeholders — Product, Design, Engineering, Sales, Marketing. (If you want to go deeper here, I’ve written a full guide on how to create a product roadmap without any fancy tools.) With the roadmap agreed, we start picking up individual items.

The PRD, wireframes, and UX vs UI

Each item on the roadmap gets a PRD — a Product Requirements Document. This is “the” most important document in product management: it lists all the features of a product in as much detail as possible, answering what are we building and how. It’s the single go-to reference for Product, Design and Tech. Writing one is iterative — you draft it, discuss with engineering and design, take their feedback, update, and go back and forth a couple of times before it’s final. (I’ve broken this down fully in how to write a PRD.)

Part of the PRD is wireframes — simplified visual sketches of how the user journey will look. Because the PRD is iterative, the designs have to be too, so the design team doesn’t sink hours into pixel-perfect screens that will only change. Depending on how settled the PRD is, wireframes can be low fidelity (rough) or high fidelity (finer, detailed, close to the final designs).

And while we’re on design, let’s clear up something that trips up almost every first-time PM: UX vs UI. UI (user interface) is about the look — the colour theme, the shape and size of buttons, the spacing, the overall layout. UX (user experience) is far broader: it’s the whole experience of using the product, how easy and intuitive it is to get things done. In other words, UI is a subset of UX.

MVP: building the smallest thing that works

Your PRD is ready — but for which version of the product? When you’re building something brand new, you start with an MVP (minimum viable product): the most basic version you can get into the market quickly, with just enough features to test, validate and iterate on the core hypothesis behind the problem you’re solving.

Say you’re launching an ecommerce platform. Your MVP should focus on the core action — purchasing an item. So you build search and discovery, the product-listing page, and payment checkout. Everything after the sale — order tracking, customer-care queries, refunds — can be handled off-platform for now, over email. Because what’s the point of building refund flows if there are no orders yet? Those come in a later version. Which tells you something important: just like the PRD and the designs, the actual build is iterative too. A huge part of product management is simply iterating quickly — build something, get feedback, incorporate it, iterate.

Into execution: sprints, stand-ups, tech debt and APIs

Now the PRD is handed to engineering and the real coding begins. That period of building and then testing is a sprint. Its length varies by organisation, but typically it’s anywhere from two to six weeks.

During the sprint you’ll have stand-ups — quick status-update meetings, held daily or weekly depending on your sprint length. They don’t need to be detailed; the point is to flag significant milestones (“dev complete on the payments module”), any blockers, and red flags like a flaw in the plan or a timeline slip.

You’ll also hear about technical debt — think of it as engineering’s own backlog: code optimisation, API documentation, updating libraries to their latest versions. As a PM you don’t need to go deep into it, but do accept that it’ll eat some of your sprint bandwidth, because good engineering teams pick up a few tech-debt tasks every sprint. My honest advice from years of doing this: don’t argue or interrogate it too much. A lot of it is genuinely technical, the benefits aren’t always visible to us, and trusting your engineering leaders here buys you far more than nickel-and-diming their debt ever will.

One more term worth truly understanding is the API (application programming interface). Simply put, an API is a communication layer that lets different services talk to each other — it takes a request from one service, tells another what to do, and brings the response back. Almost every product you’ll ever work on relies on a bunch of APIs. Take something as ordinary as updating your email in an app. The moment you tap “View Profile”, one API fetches your current details from the backend so the front end can display them. You type the new email, the front end hands it to another API, which passes it to the backend database to update it. That API’s response confirms success back to the front end — and only then do you see “Profile updated successfully”. That’s a chain of APIs, working in the background of the simplest action.

Testing and release

Once the code is written, it has to be tested against the expectations set in the PRD. The testing process itself is called QA (quality assurance), and you’ll meet a few flavours of it. They’re all testing — the difference is who tests and at what stage:

• Alpha testing — done by the internal testing team; as a PM you have little role here.
• UAT (user acceptance testing) — done by whoever raised the feature, i.e. you (the PM) and maybe stakeholders like sales or finance. Only once UAT gets a green light does the product go live.
• Beta testing — early access for a select set of real users, so they can surface feedback. Often they don’t even report it explicitly; it’s tracked through data — crashes, load time, API success ratio.

Then comes the release. You’ll hear it called go-live, shipping, deployment, “pushed to production”, rollout — all the same thing. On the web it’s always a 100% release: whoever opens the site gets the latest version. In the app world, though, both the Google Play Store and Apple App Store let you do a phased rollout — release to a small set of users first, watch for crashes or major issues, then gradually ramp to 100%. (That’s exactly how beta testing on real users is achieved.)

After release, it’s good practice to send out release notes — a brief summary of what just went to production. They do two jobs: they act as lightweight documentation of what shipped and when (handy for later debugging), and they make sure non-technical stakeholders know the release happened, which quietly builds accountability. On that note — a heads-up that surprises newcomers: sometimes a stakeholder will push hard, with real management pressure, to ship a feature “we absolutely need”… and then never touch it once it’s live. It’s frustrating. I won’t get into why here — just know it happens.

Go-to-market, scale and A/B testing

Release done, notes sent — job finished, right? Not yet. Next comes the GTM (go-to-market) plan. Who owns it varies — sometimes product, sometimes marketing — but what it is matters more than who owns it. A release only means the product is available; whether users actually show up and use it is still a question mark.

A lucky few brands have such loyal fans that users pull the product towards themselves — a “pull” strategy. Apple is the classic example. Most products, though, rely on a push strategy: you actively push the product to users, get them to try it once, and hope the ones who like it stick while the rest churn. That’s what a GTM plan is for — making sure the product doesn’t fail simply because nobody knew it existed. It usually covers your marketing strategy, push notifications (to whom, how often, when), launch emails, a landing page highlighting the release, any internal training for sales or customer-care teams, the metrics you’ll watch, and any A/B tests you’ll run at launch. The goal of all of it is scale — more and more people using the product. (You’ll hear it called adoption, traction, momentum too — same thing.)

A/B testing deserves its own mention. It’s an experiment: you show two variations of your product to two comparable sets of users, changing just one or two things between them — a page layout, two different home-page banners, or the classic example, the way OTT platforms like Netflix test thumbnails to see which drives the most clicks. Even tiny things — a button’s colour, square corners vs rounded. Whichever version converts best becomes the default going forward.

Measuring success: KPIs, product-market fit and sunset

Once your product is live and has some scale, you track a set of KPIs (key performance indicators) — the metrics that tell you whether it’s doing its job. Common ones include DAU/MAU (daily/monthly active users), CTR (click-through rate), engagement metrics like average session time or sessions per DAU, and funnel analysis — starting from how many users open the app, down through how many searched, clicked a result, and finally converted (bought, watched, booked — whatever your product’s core action is).

Say the numbers are excellent — revenue up, engagement off the charts, an obvious success. Congratulations: you’ve reached product-market fit (PMF). The name says it — the product and the market simply fit; it’s genuinely solving the problem it was built for. But there’s no single metric or milestone that declares it. PMF is a journey — consistent strong performance and growth over time that, in hindsight, confirms you got there. And if the product didn’t perform? Then, as ever, product management is about iteration: analyse the data, gather feedback, build a better next version, and run the loop again. Nobody hits PMF on the first try. It takes time.

And finally, every product’s story can end in deprecation — shutting down, or “sunsetting”. Sometimes it’s a failure: despite several attempts, it never found scale or revenue, so it’s retired (remember YouTube Stories, launched in 2019 to chase Snapchat, and quietly shut down?). Sometimes even hugely successful products get sunset — they ruled for years, but tastes and trends moved on and they couldn’t adapt (remember MySpace?). And sometimes it’s pure external bad luck — new regulation, or an event like COVID, which took out plenty of perfectly good travel startups. A shutdown doesn’t always mean a bad product. Not every launch can be a success, and that’s just the reality of building software.

And that’s the whole journey — from a line in a backlog to a live product, and everything in between. That, in practice, is what product management actually is.

Frequently Asked Questions

If this cleared the fog and you’re serious about building a career in product, the fastest way to accelerate is with someone who’s already walked the path. I’ve mentored 50+ people into and up through PM roles at Google, Microsoft and Amazon. Book a free 1:1 mentorship session and let’s map out your next step.

Want to keep going? Read up on the top 10 product management skills, see what a day in the life of a product manager really looks like, and if you’re trying to get in, start with how to break into product management.

Roadmaps. The word alone is enough to give a first-time product manager a few sleepless nights. The moment someone senior asks you to create a product roadmap, it suddenly feels like you’ve been handed a giant, important, slightly terrifying blank canvas — with no idea where to start. If that’s you, take a breath: learning how to create a product roadmap is far simpler than it looks.

So let’s take the fear out of it. In this piece I’ll walk you through how to actually create a product roadmap — and I’ll do it without any fancy roadmapping tools. No Aha, no Productboard, no expensive subscription. Just your thinking and a plain spreadsheet.

What a product roadmap actually is (and why it’s not scary)

Here’s the reframe that makes the whole thing click. A roadmap is simply a list of the things you’ve planned to work on over a defined period of time. That’s it. If I’m being honest — and slightly cheeky — a roadmap is just a fancy name for a to-do list. A to-do list with a deadline and a bit of strategy behind it.

It also helps to know when this lands on your plate. As a junior PM, you probably won’t be asked to build a roadmap at all — at that stage your world is execution, sprints, and shipping. But as you grow, the strategic responsibilities grow with you, and owning the roadmap is one of the biggest of them. So if this feels intimidating, that’s usually a sign you’re levelling up, not that you’re out of your depth.

The catch is that your backlog is a never-ending list of tasks, ideas and requests. The product roadmap is the curated, time-bound version of that list. Turning one into the other is where the real work happens — and it has nothing to do with which tool you use.

The hard part isn’t the tool — it’s prioritisation

To pull a roadmap out of a messy backlog, you weigh each item against a handful of factors. These are the questions I run every candidate item through.

Is the problem even worth solving?

Before anything else: does this problem align with your business strategy, and does it genuinely add value for your users? Say someone at Amazon pitches, “let’s start selling cars on Amazon.” The PM has to judge whether that’s a problem worth solving. Intuitively you might think — probably not. But good practice is to back the call with a bit of logic: do people actually want to buy cars online? Are those buyers part of Amazon’s existing base, or a brand-new segment? The answer may still be “no,” but now it’s a reasoned no, supported by a quick survey, a few interviews, or some data.

Now, you can’t run a full analysis on every oddball request — that would eat your entire week, and you’d be right to push back. But in my experience, the requests that reach you are rarely so bizarre that you can dismiss them on gut alone. Take the cars example: someone can fairly counter with “why not?” — eBay and Taobao already sell cars, and eBay has even sold aeroplanes; one of the priciest things ever sold on it was a private jet worth around $5M. Rejecting ideas purely on intuition quietly risks missing the next big thing. History is littered with it — HP passing on the Apple 1, Intel sitting out the early AI wave. Validate, don’t just react.

How big is the prize? (TAM)

Total Addressable Market is the size of the opportunity — either in users or in rupees/dollars. If you owned 100% of the market, how many people could this product reach, or how much revenue could it unlock? As a rule, the bigger the TAM, the higher the priority.

What will it actually move? (Impact estimation)

This is the expected effect on the specific business metric you’re trying to shift — “increase revenue by 10%,” or “lift D1 retention by 5%.” Tie every item to a number you care about; it forces honesty about whether something is worth the slot.

Important vs urgent

These two get muddled constantly, and they’re not the same thing. Launching a new business vertical or entering a new geography is important but usually not urgent — if being thorough means taking an extra few weeks of research, take them. On the other hand, if your company changes its registered business address, you urgently need to update it across your website and app for compliance — but it won’t touch your DAU or sales at all. That’s urgent but not important. A good roadmap makes room for both without letting the urgent crowd out the important.

Complexity

Sometimes a simple, quick-to-build feature earns a spot even if its impact is modest, purely because it’s cheap to ship. Effort is a real input, not an afterthought — a small win you can land this month can be worth more than a giant bet that slips for two quarters.

No duration, no product roadmap

Here’s the factor people skip, and it’s the one that makes a roadmap real: the time period you’re planning for. Without a defined duration, a roadmap is just daydreaming. It’s like saying Tesla has “flying cars” on its roadmap — there’s a decent chance we get there eventually, but the duration is what turns a wish into a plan. One year? Ten? A hundred?

People build everything from one-month to five-year roadmaps, but given how fast the tech landscape moves, anything beyond a certain horizon stops being useful. Honestly, a five-year roadmap is close to useless for most of us today. A few industries — manufacturing, healthcare — can justify it because of the heavy upfront R&D in both time and money. For the rest of us, I prefer a one-year product roadmap for long-term strategic goals and a three-month roadmap for short-term execution. That pairing has served me well across very different teams.

Long-term vs short-term roadmap (a worked example)

The long-term (one-year) product roadmap is about themes, not fine detail. It holds the strategic, business-goal-driven projects, and it’s expected to evolve through the year as things change. What it gives you is a clear sense of what you’re focused on. If this year’s business goal is profitability, your themes might be lifting ARPU (average revenue per user), cutting customer acquisition cost, or reducing returns and refunds. If the goal is growth, you’d lean into increasing DAU/MAU, a referral programme, or building a coupon and discount flow.

The short-term (three-month) roadmap is where the detail lives — TAM, effort estimation, impact estimation, all of it. Let’s take the ARPU theme from above and go one level down. You can raise ARPU by getting users to order more often, or by increasing the average order value. And you can lift average order value in more than one way — nudging users towards a higher-priced item by highlighting its quality and service USPs, or recommending associated products (“if you bought X, you might want Y”).

All three are legitimate paths to the same goal. Deciding which one earns the next quarter is exactly where you pull out TAM, effort and impact estimation. That’s the whole point — the long-term roadmap tells you the direction, the short-term roadmap tells you which specific bet you’re making first, and the prioritisation factors settle the argument.

Breaking it down into sprints

The projects in your three-month roadmap then get broken into sprints. And your ideal sprint length isn’t something you copy from a blog — it’s something you work out for your own situation. A few things shape it:

• Your team size.
• Your user base — a few thousand users or millions? B2B or B2C?
• Your release cycle — one major release a month, or shipping every week?
• The complexity of what you’re building.
• And occasionally, the sheer urgency of a specific product.

In software, there is no single right answer here. I’ve worked in organisations that shipped a release every week, and others that preferred far less frequent ones. Based on my own experience, I like one major release a month, plus smaller bug-fix releases as and when the severity demands it. Find the combination that fits your team — and don’t let anyone tell you there’s a universal “correct” cadence.

Putting it together — no fancy tools required

Zoom out and a clean, sensible structure falls out of all this: a one-year strategic roadmap, split into four three-month roadmaps, each of which breaks into roughly three one-month sprints. Strategy at the top, execution at the bottom, and a clear line connecting them.

Once you have a rich backlog and you run it through the criteria above — is the problem worth solving, how big is the TAM, what’s the impact, is it important or merely urgent, how complex is it, and over what duration — laying those tasks into a roadmap is a genuinely straightforward exercise. And you’ll have noticed you didn’t need a single fancy roadmapping tool to do any of it. Our good old Excel (or Google Sheets) gets the job done perfectly well. The tool was never the hard part. The thinking is.

Frequently Asked Questions

That’s really all a product roadmap is: a well-prioritised, time-bound to-do list. Get the thinking right and the tool becomes an afterthought.

If building the roadmap is the point where your PM role starts feeling genuinely strategic, and you’d like a sounding board as you step up, that’s exactly what I do. I’ve mentored 50+ people into and up through PM roles at Google, Microsoft and Amazon. Book a free 1:1 mentorship session and let’s work through your roadmap — and your career — together.

Want to go deeper on the craft? Have a look at the top 10 product management skills, and once your roadmap picks a project, turn it into a solid product requirements document (PRD).