Part 2: Building the Roadmap and What I Got Wrong

By the time I finished the prioritization section, I had a clear view of what the problems were and roughly what order they needed to be addressed. What I had not yet done was turn that into something a team could actually execute against.

That is what a roadmap is supposed to do. It is the translation layer between strategic decisions and operational reality.

Why I Used Now-Next-Later Instead of a Timeline

The most common roadmap format is a timeline; I chose however not to use that method for some reasons.

The problem with timeline-based roadmaps is that they imply a level of certainty that almost never exists. When you put a feature in “Month 3,” you are making a claim about what your team will have learned, what dependencies will have resolved, and what the product will look like at that point. In most cases, you do not know those things. You are guessing and dressing the guess up as a plan.

Now-Next-Later is more honest. It says: here is what we are committed to shipping (Now), here is what we are highly likely to build after that (Next), and here is the direction we are heading longer term (Later). Only the first category represents a real commitment. The others are informed intentions that might change as you learn.

For a consumer health product with multiple interconnected problems, this framing also communicates something important to stakeholders: we are not trying to fix everything at once. We are sequencing deliberately.

How I Structured the Six Months

Now => Months one and two; was about stopping revenue leakage.

Two things were costing the business money in real time. Checkout abandonment meant that people who had decided to buy were leaving before completing payment. Forgotten renewals meant that existing members were letting their coverage lapse not because they wanted to leave but because nobody reminded them.

Both of these are fixable without fundamentally changing the product. Renewal reminders and autorenewal are standard in any subscription product. Checkout optimization is a process of diagnosing the specific friction point, whether that is payment method limitations, mobile UX issues, or something else, and removing it.

The hospital finder ran alongside these, not after them. It required less engineering effort than checkout, which meant I could allocate resources to both in parallel without one blocking the other.

Next => Months three and four; was about building the foundation for sustainable retention.

The biggest single source of support tickets was members who did not understand what their plan covered. That is a product failure, but it is also a content and communication failure. The solution required an interactive coverage tool, plain-language documentation, and a self-service pre-authorization flow not just engineering work but clinical validation and content production.

I put this second because fixing it requires time that cannot be shortened, and because it addresses the root cause of the largest complaint category. Get this right and a significant portion of inbound support traffic disappears.

Later — Months five and six — was directional.

I identified three options for strategic growth initiatives: preventive health incentives, chronic care with medication delivery, and mental health and nutrition services. A key piece of research I found on this ideation process was this.

According to Nigerian Journal of Clinical Pharmacy and Therapeutics, a type 2 Diabetics who takes medications regularly costs ₦70,000 to ₦163,000 vs One who doesn't and has Severe complications requiring surgery or intensive care can reach ₦5 Million.

I had points like this which meant each initiative had genuine profitability logic, reducing claims costs by improving health outcomes before they become expensive clinical events.

I did not commit to a specific one. I outlined the decision criteria: which pharmacy partnership had been secured, what we had learned from the earlier phases, which initiative the clinical team could support within the timeframe. Later on, a Now-Next-Later roadmap means we know where we are going; we do not yet know the exact route.

The Release Guide

The final part of the case study asked me to write a user-facing release guide for one feature from my roadmap.

I chose the renewal reminders and auto-renewal feature because it is the kind of thing that sounds simple and is easy to get wrong in the writing.

The challenge with release guides is always trying to grab the attention of the reader. You are writing for someone who does not know what an API is, does not care about the implementation, and is not reading carefully. They are scanning. They want to know what is changing, why should I care, and what do I need to do.

Every word that exists to make the writer sound thorough rather than to help the reader understand is a word that should be cut.

The final guide write-up explained it the way a member experiences it — “you will get a message before your plan expires,” “you can set it to renew automatically if you do not want to think about it,” “if you miss the deadline, you have seven days before your coverage stops.”

What I Got Wrong

When calculating the revenue impact of reducing checkout abandonment, I made an error in how I averaged the plan pricing. The product had two payment options, a quarterly plan and an annual plan. I treated them as equivalent and averaged the two prices directly.

That is wrong. The quarterly price covers three months. The annual price covers twelve. Averaging them without converting to the same unit gives you a meaningless number.

The correct approach is to convert both to a monthly equivalent first, divide the quarterly price by three, divide the annual price by twelve and then average those figures. The number I should have used was substantially higher than what I had calculated, which meant the revenue opportunity I presented in the roadmap was understated.

I caught this just before submitting.

What I would do next time to avoid this in the future: build a simple calculation document alongside any analysis that involves financial projections. Show the working. Not just the result. When you show the working, the errors surface before you submit rather than after.

What the Whole Process Taught Me

1. Frameworks are starting points, not answers.

RICE gave me a structure for comparing problems. It did not tell me what to prioritize. That required knowing the business goals, understanding the resource constraints, and making judgment calls that the framework could not make for me. Anyone who uses RICE and reports the scores as if they are objective truth is outsourcing their thinking to a formula.

2. The questions matter as much as the analysis.

The section of the case study where I listed what I would ask stakeholders before touching the roadmap was not decorative. Those questions would have changed my scores if the answers had been different. A different cost per support ticket changes the value of operational efficiency improvements. A different understanding of why users abandon checkout changes what you build to fix it. Analysis built on unexamined assumptions is fragile.

3. Writing for users is a separate skill from thinking about users.

I knew what the renewal feature needed to do. Writing about it in a way that an actual subscriber could act on required a different kind of attention. The discipline of stripping out internal language, the terminology that makes sense inside the product team and means nothing to the person using the product is harder than it looks. It is worth practicing deliberately.

4. Structured thinking does not require a perfect process.

At Bvida, we do not have formal sprint ceremonies. Requirements are written in Notion. Decisions happen in conversation. For a long time, I worried that this made my PM experience somehow less legitimate than if I had been running two-week sprints with daily standups and a proper backlog.

The case study clarified something. The value of structured thinking is not the structure itself. It is what the structure forces you to do: be explicit about your reasoning, connect decisions to outcomes, acknowledge what you do not know. You can do all of that without Jira.

What I am still developing is the formal execution layer, running sprints properly, writing PRDs that engineering teams can actually build from, managing stakeholder communication at scale. Those are skills that come with practice and with working on a team large enough to require them. I am working on that deliberately.

Why I Am Writing About This

This case study was part of an interview process. I did not get the role.

I am writing about it because the work was real regardless of the outcome, and because the things I learned from it were genuinely useful, not just as interview preparation but as a clearer way of thinking about product problems.

If you are an aspiring PM preparing for a case study, I hope the specific decisions here are more useful than a generic framework walkthrough. The interesting parts are not the frameworks. They are the moments where the framework does not tell you what to do and you have to think for yourself.

If you have done a similar exercise and approached it differently, different prioritization logic, different sequencing, a different way of structuring the roadmap. I would genuinely like to hear about it. Find me on X or LinkedIn.

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