What is Product Management?

What is Product Management?

Product management is the job of deciding what a team should build, why it matters, and whether it worked. A product manager (PM) sits between the people who use a product, the people who build it, and the people who pay for it, and makes sure all three are pointed at the same goal.

A PM does not write the code, draw the screens, or sign the cheques. Instead, a PM makes sure the right problem is being solved, that the team understands it, and that the solution actually helps real people. If engineers answer "how do we build it?" and designers answer "how should it look and feel?", the PM answers "what should we build, and why?"

---

A Real-World Example

Imagine a fintech company in a fast-growing city such as Lagos, Nairobi, or London whose customers keep complaining that transfers "hang" during peak hours, such as salary week or the days before Christmas. Everyone has an opinion:

• Customer support says: "Add a bigger warning banner so people stop panicking."
• Engineers say: "We need to rebuild the transaction queue."
• The CEO says: "Competitors are launching savings features. Why aren't we?"

The PM's job is to cut through the noise. They talk to customers, look at how many transfers fail and when, estimate the cost of losing users, and then make a call: fix reliability first, ship the savings feature next quarter. They then explain that decision so clearly that support, engineering, design, and the CEO can all get behind it.

That is product management: turning a messy pile of problems, opinions, and ideas into a clear plan, and then seeing it through.

---

The Three Circles

Great products live where three things overlap:

If a feature is desirable and feasible but does not make business sense, the company will run out of money. If it is viable and feasible but nobody wants it, nobody will use it. A PM is the person who keeps checking all three.

---

Core Responsibilities

• Discover problems. Talk to users, study data, and watch how people really behave.
• Define the direction. Write down the vision, goals, and priorities so the team knows what matters most.
• Prioritise. There is always more to do than time allows. The PM decides what goes first and, just as importantly, what does not get built.
• Work with the team. Write requirements, answer questions, remove blockers, and keep designers and engineers moving.
• Launch and learn. Ship, measure the results, and use what was learned to decide what comes next.

---

Types of Product Managers

The title "PM" covers several different jobs. The company and product decide which one you do.

Core (or Feature) PM

Owns a specific product area, such as "onboarding" or "checkout". Focuses on making that area better through research, experiments, and steady releases. This is the most common entry point.

Technical PM

Works on products where the users are developers or where the product is deeply technical, such as a payments API, a cloud platform, or an SDK. Needs to be comfortable reading API documentation and discussing architecture with engineers.

Growth PM

Focuses on acquiring, activating, and retaining users. Runs many small experiments on signup flows, referral programmes, and notifications. Very common in consumer fintech, e-commerce, and betting/gaming companies.

Platform PM

Builds internal tools and shared services that other product teams rely on, such as an identity system or a payments engine. The "customers" are other teams inside the company.

Data PM

Owns data products such as recommendation engines, fraud detection, or analytics dashboards. Works closely with data scientists and needs a strong feel for metrics.

Associate PM (APM) and Senior/Lead roles

An APM is an early-career PM paired with mentors. As you progress you take on bigger products, then multiple products, then a team of PMs as a Group PM or Head of Product.

---

A Day in the Life

No two days look the same, but here is a realistic day for a PM at an e-commerce company in a city like Lagos, Nairobi, or London:

• 9:00 – Stand-up. A 15-minute check-in with engineers and designers. What shipped yesterday? What is blocked today? The PM notices that the delivery-tracking work is waiting on a courier API and takes the action to chase it.
• 9:30 – Metrics check. Opens the dashboard. Cart abandonment on mobile rose after last week's release. Makes a note to investigate.
• 10:30 – Customer call. Speaks to a seller who says uploading product photos on a slow network keeps failing. This is the third seller to say so, which suggests a real pattern.
• 12:00 – Lunch and reading. Catches up on competitor announcements.
• 1:00 – Requirements review. Walks the engineers through a new spec for pay-on-delivery confirmation and answers their questions about edge cases.
• 2:30 – Stakeholder meeting. The logistics head is worried the new feature will overload riders. The PM listens, adjusts the rollout plan, and agrees to a small pilot in one city first.
• 4:00 – Prioritisation. Reviews the backlog and decides the photo-upload issue should jump ahead of a planned redesign.
• 5:00 – Write-up. Sends a short update to leadership: what shipped, what was learned, and what is next.

Notice how little of the day is spent "building". Most of it is listening, deciding, and communicating.

---

Do You Need to Be Technical?

Not necessarily. You do need to understand how software gets built well enough to ask good questions and respect trade-offs. You can learn that on the job. What you cannot skip is curiosity about users, clear communication, and good judgement.

---

Where PMs Come From

There is no single path. PMs come from engineering, design, customer support, operations, marketing, banking, and consulting. In growing tech scenes from Lagos to Nairobi to London, many first-time PMs move over from customer success, business analysis, or operations roles in banks and telecoms (or at firms like Barclays and Vodafone), because they already understand customers and business processes. The skills in this course are designed to help you make that move.