How I Inherited a Product With No Problem to Solve

It was a busy afternoon at the office in Falomo when I got called over to my Senior Manager’s desk. He was on a call, so there wasn’t much room for conversation. Still, within a few minutes, I understood one thing clearly:

I was being pulled into a product project that had been stalled for… well, only God knows how long.

Strangely, very little was said about the product itself. Instead, most of the excitement in the room revolved around something else entirely; that a “competent” graduate trainee would now be taking over the project.

That trainee was me.

The Opportunity (and the Unease)

I walked away from that desk feeling two things at once: uneasy, but hopeful.

At the time, I had been in the team for about seven months, and there had been quiet conversations about how little I had been involved in major projects. So, this felt like my shot; an opportunity to finally prove myself and make a name within the unit.

My manager promised to send over materials to help me get started.

Now, here’s the irony.

The closest I had ever come to product management wasn’t even in a corporate setting. It was in my “previous life,” where I built websites, wrote content, monetized them through ad networks like Ezoic and Mediavine, and eventually sold them.

But no one in the company knew that.

So when I was handed a major product, an app, no less, it wasn’t because of proven experience. It was… luck? Timing? Or something else entirely?

The 7-Slide Reality

The materials eventually came in: a PowerPoint deck.

Seven slides.

That was it.

I went through it carefully. Line by line, everything seemed to make sense. By the time I finished, I felt surprisingly confident. I understood the assignment well enough that I was already eager to speak with the engineer and kick things off.

For a moment, it felt like everything was aligning.

But Here’s the Twist

If the only problem I had inherited was a stalled product, this would have been a very different story.

In fact, I like to imagine that eight months from now (as of writing this), I’d be confidently walking up to receive the “Best App of the Year” award at the company’s end-of-year dinner.

But reality had other plans.

Because almost a year into development, I stumbled on something deeply unsettling:

I had inherited a product that might never have needed to exist in the first place.

The Question That Changed Everything

How does a graduate trainee end up managing the development of an app that has no clearly defined problem?

Looking back, I’ll take a small share of the blame.

I stepped into a product already in development and never stopped to question its origins. I didn’t go back to investigate its conception.

But then again, would you really blame a graduate trainee who was simply following instructions?

At the time, I didn’t even fully understand what product management truly meant, let alone the rigor required to build something that solves a real-world problem.

And that 7-slide deck?

It only contained a “solution description,” product objectives, and a list of features. But that was all. There was no problem statement, no evidence of research, no documentation of problem validation, and no explanation of why this app was the right solution.

What Should Have Happened

Months into the project, I began to fall in love with product management. I became obsessed with the idea of building products that could directly impact a company’s performance.

So I decided to learn it properly.

I enrolled in a Professional Certification Course, hoping it would sharpen my approach and help me build a better product.

But something unexpected happened.

The more I learned, the more uncomfortable I became.

Because the clearer product management became to me, the less sense my own product made.

I had a troubling realization:

I couldn’t confidently explain the problem my app was solving.

Not clearly. Not convincingly.

At best, I could guess.

And that’s dangerous.

Because if you don’t understand the problem, you can’t validate the solution.

The Product (On Paper)

The app I was building was a referral platform, a growth engine meant to drive adoption for other apps within the company.

The idea was simple:

Product owners would list their apps on the platform
Agents would promote these apps
Agents would earn rewards for successful referrals

On the surface, it sounded brilliant. Everyone liked it.

But as I now understood, liking an idea is not the same as validating it.

The Broken Product Lifecycle & The Search for Answers

A proper product should follow a clear lifecycle:

Conceive: Identify and validate the problem
Plan: Define scope and roadmap
Develop: Build the solution
Qualify: Test and validate
Launch: Release to users
Deliver: Maintain and improve
Retire: Sunset when necessary

If any stage must never be skipped, it’s the first one.

Conception.

And that was exactly what seemed to be missing.

Soon… I went looking for the origin story.

I tried to reach out to the former product owner; he had left the company.

I contacted another stakeholder; it took weeks to even get a response, and when I did, there was little to gain.

I kept digging.

Nothing.

At some point, it hit me:

There was no deep product discovery phase.

No thorough investigation.

No solid foundation.

The “problem” was likely defined in a war‑room session, someone said “referral app,” everyone agreed, and development started.

And now, I had inherited it.

Working Backwards

At this point, development was already far advanced. The web app was even live.

Stopping everything wasn’t an option.

But neither was continuing blindly.

So I made a decision:

I would go back to Phase 1, without stopping Phase 3.

I would validate the problem while development continued.

Thankfully, there was at least one thing I could start with.

The obvious statistics:

“Despite the company’s large user base, it struggles to gain adoption of its utility and fintech apps.”

After thinking deeply about the facts, I realized there were only two possible root causes, and they’re not mutually exclusive:

Product Problem (Poor Product-Market Fit): The apps themselves don’t deliver enough value.
Distribution Problem: People don’t know, don’t trust, or can’t easily discover the apps.

Or, of course, both.

Why This Matters

If the issue is product quality, then a referral app won’t fix it.

It would be like putting a wig on a bald head, the underlying issue remains.

But if the problem is distribution?

Then a referral engine might be exactly what’s needed.

The Plan

With time running out and pressure building, I know I have to move fast, but accurately.

Here’s how I’m approaching it:

1. Funnel Analysis

I’m working with product teams to analyze user behavior across each app:

Are people seeing ads but not downloading? → Awareness problem
Visiting app stores but not installing? → Weak value proposition
Installing but not signing up? → Onboarding friction
Signing up but not engaging or returning back? → Product value issue

Each stage tells a different story.

2. Customer Interviews

I’m speaking directly with users to understand why they’re not adopting these apps:

Do they lack awareness?
Do they distrust the brand?
Do they see no value?

Because the answer determines everything:

If it’s trust → referrals might help

If it’s value → referrals won’t fix it

Where I Am Now

That’s where I am today.

In between development timelines and discovery work.

Trying to uncover the truth behind a product that may, or may not have been built on the right foundation.

I’m already collaborating with product teams and gathering data.

And hopefully, in the next phase, the insights will begin to tell a clearer story.

To Be Continued…

Bunu