Part 1: The Problem and How I Thought Through It

There is a difference between knowing how to think about a product problem and actually doing it under pressure.

I had read about RICE scoring. I understood what a roadmap was supposed to communicate. I had taken courses on product-led growth and product analytics. I thought I had a reasonable grasp of how product managers approach decisions.

Then I got a take-home case study with a five-day deadline, and I realized I had been practicing product management the way you practice swimming on dry land 🤣.

What I Was Given

The brief was for a consumer health insurance product — a digital plan offering telemedicine, hospital access, and pharmacy benefits to individual subscribers in Nigeria.

The company had given me three things:

1. Customer complaints => Real quotes from users, organized into themes.

A. People who did not understand what their plan covered.

B. People who could not find hospitals in the network or found that the hospitals listed had stopped accepting the plan.

C. People whose coverage lapsed because nobody told them it was about to expire.

2. Performance data =>

A. Conversion rates

B. App engagement figures

C. Support ticket volumes broken down by category.

The kind of data that tells you where the product is failing even before users articulate it directly.

3. Internal team suggestions => Four ideas the team had already proposed;

A. a family discount

B. a wellness rewards program

C. a referral scheme and

D. an expansion of telemedicine to include mental health and nutrition services.

My job was to prioritize the existing problems, evaluate the new opportunities, build a six-month roadmap, and write a customer-facing release guide for one feature I chose to prioritize.

Five days.

The First Thing I Did Wrong

I almost started with the solutions.

That is the instinct. You read the customer complaints, and your brain immediately jumps to what you would build to fix them. You see “customers don’t understand their plan” and you think: better onboarding. You see “forgot to renew” and you think: reminder notifications.

The problem with starting there is that you skip the diagnostic step. You do not know which problem to solve first. You do not know which solution will actually move the business. You end up with a list of reasonable-sounding features that are not connected to anything concrete.

I stopped and asked myself: what questions would I ask the team before I touched the roadmap?

That reframe changed everything.

The Questions Before the Answers

I divided my questions by team. Engineering, customer support, marketing, clinical services, provider relations, finance.

Some of the questions that shaped my thinking most:

What is the actual cost of a support ticket? I did not have this number. But the answer changes how you value any solution that reduces ticket volume. If a ticket costs very little to resolve, operational efficiency becomes a lower priority. If it costs significantly, reducing tickets is a direct profitability lever.

Why are users abandoning checkout? The data showed a large percentage of users reaching the payment page and not completing the purchase. But that could mean different things;

1. Price shock

2. Payment method limitations

3. Mobile UX issues

4. Trust concerns about entering card details.

Each of those requires a different solution. Building without knowing which one is the actual cause is expensive guessing.

How often does the provider list actually change? One of the biggest complaints was that the hospital finder showed facilities that were no longer in the network. The severity of the engineering solution depends entirely on how frequently that data changes. If the provider list changes daily, you need a real-time sync. If it changes monthly, a weekly batch update might be enough.

These questions are not decoration. They determine whether your solution addresses the actual problem or an assumption about the problem.

Why I Chose RICE

The brief asked me to use any prioritization framework I was comfortable with.

I chose RICE — Reach, Impact, Confidence, Effort — because the data I had been given mapped cleanly onto it. Support ticket volumes told me how many people were experiencing each problem. The nature of each problem told me how much fixing it would move the metrics that mattered to the business. The availability of proven solutions told me how confident I could be that my proposed fix would work.

The formula is straightforward: multiply Reach by Impact by Confidence, then divide by Effort. Higher scores get prioritized.

But applying it honestly is harder than it looks.

The Most Interesting Scoring Decision

Halfway through scoring, I hit a question I had not anticipated.

One of the problems, an outdated hospital finder, affected a large portion of users because every subscriber uses the provider search at some point. But the number of people who had actually complained about it was much smaller. A fraction of the total user base had contacted support about this.

So, what do I use as my Reach figure? The number of people who complained? Or the number of people who encountered the problem?

These give very different scores.

If I use complaint volume, the problem looks moderate. If I use the total affected population, it becomes the highest-priority item in the entire analysis.

I thought about what Reach is actually supposed to measure. The RICE framework asks: how many people does this affect? Not: how many people were frustrated enough to contact support about it. Silence is not the same as satisfaction. A user who could not find their hospital and quietly gave up is still a user who was harmed by the problem, they just did not create a ticket about it.

I used the broader figure. And I flagged in my assumptions section that I was making that choice and why.

That kind of explicit reasoning is what separates a framework from a crutch. The framework gives you structure. The thinking is still yours.

RICE Score and Execution Order Are Not the Same Thing

This is the insight I want to spend time on because it is not obvious until you have to confront it directly.

After scoring all the problems, the hospital finder came out with the highest RICE score. By the logic of the framework, it should be the first thing we build.

But I did not put it first on the roadmap.

Here is why.

The business had listed its priorities in order: profitability first, then revenue growth, then customer satisfaction, then operational efficiency. The hospital finder affects customer satisfaction and operational efficiency which are important, but not the top two.

Meanwhile, checkout abandonment and forgotten renewals were both directly destroying revenue. People who wanted to buy were not completing the purchase. People who wanted to renew were letting their plans lapse because nobody reminded them. Both of those problems were costing the business money every single day.

And the hospital finder fix, once I dug into it, was actually achievable in parallel. It required relatively little engineering effort because the underlying data infrastructure already existed. I could run it alongside the other two without choosing between them.

The roadmap I built put revenue protection first, checkout and renewal, with the hospital finder running in parallel, not in sequence. The plan clarity work came in the following phase because it required content production and clinical validation that could not be rushed.

RICE told me what the most impactful problems were. Business priorities told me what to build first. Those are two different questions.

Evaluating the Internal Suggestions

The four ideas the team had proposed were not bad ideas. They were just not the right ideas to prioritize right now.

The wellness rewards program and the mental health and nutrition expansion both had genuine long-term value, specifically around reducing claims costs by encouraging preventive care. If you can get members to take better care of themselves, they use expensive services less frequently. That directly improves the ratio of claims to premiums, which is the central profitability metric in health insurance.

But these are medium-to-long-term investments. They do not fix a user who cannot find a hospital today. They do not recover revenue from a member who forgot to renew last month.

I recommended them but sequenced after the foundational problems were resolved.

The referral program and family discount I flagged as needing validation before investment. A referral program only makes sense if the cost of the incentive is lower than your current cost of acquiring a customer through other means. Without knowing that number, you cannot justify the spend.

That is not a rejection. It is a question that needs an answer before you commit engineering and marketing resources.

Before You Can Build a Roadmap, You Have to Know What You Are Optimizing For

The case study gave me a ranked list of business goals. That ranking was not incidental; it was the instruction manual for every trade-off I had to make afterward. When two problems scored similarly on RICE, the business priorities broke the tie. When a high-scoring problem conflicted with a low-effort quick win, the priorities told me which one to ship first.

If you go into a prioritization exercise without knowing what the business is actually optimizing for, you will produce a technically correct list that is strategically useless.

Feel free to reach out to me on X (formerly twitter), LinkedIn and medium.

Visit Bvida to shop for your drugs from a licensed pharmacy near you