Sitemap
Ndi Anwanakak

Ndi Anwanakak

Data Product manager, speaking about metrics somewhere.

The Product Use Case Series

4 min readSep 25, 2026

--

Press enter or click to view image in full size

Product Management is one of those roles that can look very simple from the outside.

Talk to users.
Write requirements.
Prioritise features.
Work with engineering.
Launch products.

But anyone who has worked in Product for a while knows that the real challenge is rarely knowing the framework.

The harder part is knowing how to think when the situation is not obvious.

A customer asks for a feature.

Engineering says something will take three months.

Sales says a request is urgent.

A stakeholder wants a dashboard.

Users are dropping off during onboarding.

An AI feature works most of the time, but occasionally gives the wrong answer.

In situations like these, there is rarely one textbook answer.

You have to understand the problem, ask the right questions, consider the trade-offs, think through edge cases, and decide what makes the most sense for the user and the business.

That is why I am starting this series.

I want to write about practical Product Management use cases and break down how I would think through them.

Product Management Is More About Thinking Than Knowing Frameworks

When you are learning Product Management, you will come across many useful frameworks.

RICE.

Jobs To Be Done.

Opportunity Solution Trees.

User stories.

A/B testing.

North Star Metrics.

Prioritisation frameworks.

They are important, but knowing a framework does not automatically tell you when to use it.

Imagine a stakeholder tells you: “We need a dashboard.”

A Product Manager who focuses only on delivery may immediately start gathering dashboard requirements.

What metrics should we show?

What filters should we add?

What should the interface look like?

But a better starting point may be:

Why do you need the dashboard?

Maybe the stakeholder is actually struggling to identify customers likely to churn.

If that is the real problem, a dashboard might be one solution.

But an automated alert could be better.

A weekly report could be enough.

Get Ndi Anwanakak’s stories in your inbox

Join Medium for free to get updates from this writer.

Or the real problem could simply be that the underlying data is unreliable.

The skill I want younger Product Managers to develop is the ability to pause before jumping into a solution and ask:

What problem are we actually trying to solve?

Press enter or click to view image in full size
The Shift from Building Requests to Solving Problems

What I’ll Be Writing About

This series will focus mainly on use cases.

Instead of writing:

“5 ways to become a better Product Manager.”

I would rather explore a scenario like:

A fintech customer is debited, but the merchant says they have not received the money. How should the Product Manager think about the experience?

Or:

A bank wants to introduce AI into its loan approval process. Where should AI actually sit in the workflow?

Or:

Your onboarding completion rate is high, but very few customers make their first transaction. What should you investigate?

Or:

Finance, Operations, and your dashboard are showing three different revenue numbers. Is this really a dashboard problem?

From there, we can break the problem down.

What does the happy path look like?

What are the edge cases?

What questions should the PM ask?

What data would we need?

What are the possible solutions?

What are the trade-offs?

How would we know if the solution worked?

Some use cases will be around traditional Product Management. Others will cover Data Product Management, AI/ML products, fintech, APIs, workflow automation, experimentation, onboarding, fraud, lending, payments, and operating products in African markets.

Press enter or click to view image in full size

The objective is not necessarily to give one perfect answer. It is to develop the habit of thinking through the problem properly.

Conclusion

One of the biggest transitions in becoming a stronger Product Manager is moving from:

“What should I build?”

to:

“What is actually happening here?”

And eventually:

“What is the best way to solve this problem given the users, business, technology, data, and constraints involved?”

That kind of thinking develops with experience, but I also believe you can accelerate it by studying realistic scenarios and asking the right questions.

That is what I want this series to do.

If you are an upcoming Product Manager, I hope these use cases help you build your product instincts before you encounter similar problems in the real world.

And if you are already working in Product, I hope they create interesting conversations about how differently we might approach the same problem because Product Management is not simply about having the answer. It is about learning how to arrive at a good one.

--

--

Ndi Anwanakak
Ndi Anwanakak

Written by Ndi Anwanakak

Data Product manager, speaking about metrics somewhere.