Asher's Blog

2012 was the year I launched my first product.

Back then, I didn’t know anything about “product” as a discipline. Product management wasn’t mainstream, and it certainly wasn’t the polished career path it is today. These days, product has become a popular entry point into tech for young people, and almost every week I get emails from folks looking to start their careers with us through internship roles. A big reason for this is the rise of product schools, training graduates to break into tech by positioning product management as a launchpad.

When I think back, my first real product experience was building a solution that worked on both legacy phones and early smartphones, using USSD to help users save data on their devices. At the time, I honestly didn’t understand why we were even marketing the product. We had secured partnerships with MTN and Etisalat, and the MTN integration was almost complete when the franchise owner suddenly pulled the plug. That journey took nearly two years during my first job, and I truly felt for my boss.

That experience shaped me deeply and it’s one of the reasons I tell my team today that I’m not emotionally attached to any product we build until I see results. Effort alone doesn’t count, outcomes do.

Unfortunately, I made another mistake years later when I started building Eazipay.

The first major error was trying to build everything at once. Before Eazipay, which was initially called Ripple Force, I had worked closely with thousands of SMEs who were distributors for a cement company. What I observed was consistent: these businesses struggled with tax compliance, employee management, and fragmented HR processes. Existing solutions were too complex for them. They needed something simple, something that helped them navigate HR and finance without feeling overwhelmed.

But instead of starting small, we tried to build a full HR suite immediately. The first year was a disaster – we shipped nothing.

Looking back, it was a classic failure of focus. After twelve painful months, we made a hard pivot and decided to focus on just one thing: payroll. At that point, I took the bull by the horns and became the product manager myself, even though I lacked formal experience. But desperation has a way of clarifying priorities – we needed a product, fast.

So we did crude things. The solution was largely manual in the beginning, even though we sold it as automated. Payments were processed manually for almost six months while we gradually built automation behind the scenes. It wasn’t elegant, but it worked. And it taught me a lesson I’ve never forgotten: progress beats perfection, especially early on.

In the last three to four months, we’ve grown significantly as a business. For a long time, product was isolated from sales and customer support, which created a lot of frustration across teams. Today, collaboration is much stronger, and the difference is night and day.

That’s why I feel compelled to share a few lessons, especially for founders and early product teams, so you don’t have to repeat the mistakes we made.

1. Structure and System Matter (Especially in Startups)

Early-stage companies often resist structure because it feels “corporate.” But the right structure actually creates speed, not bureaucracy.

People

At a minimum, a startup product team needs clarity around two roles:

• Product Manager: owns the problem, the roadmap, prioritisation, and alignment across teams.
• UI/UX Designer: owns usability, experience, and how the product feels to the user.

You don’t need a large team, but you do need clear ownership. I recommend that the CEO and the CTO work together as product leaders in the early stage. One person should not own that role.

System / Flow of Work

A simple, repeatable flow keeps everyone aligned:

1. BRD (Business Requirements Document): Covers the business problem, product vision, market research, and viability.
2. FRD (Functional Requirements Document): Translates business needs into functional expectations.
3. User Analysis (UA): Who is the user? What are their pains? What are they trying to achieve?
4. UX: How the user moves through the product.
5. UI: How the product looks and feels.
6. Update Documentation: Iterations must reflect in previous documents.
7. Handoff to Engineering: Engineering should receive a complete, coherent package, not scattered ideas.

This structure helps startups think clearly, move fast, and reduce rework.

2. Attributes of a Strong Product Leader

Tools and frameworks help, but people make products succeed. Over time, I’ve learned that great product leaders tend to share a few key traits.

Inquisitive: They ask questions constantly, about users, data, edge cases, and assumptions. Curiosity drives better products.

Great Communicator: Product sits at the intersection of business, engineering, design, sales, and support. Clear, open and responsive communication aren’t optional, that is the job. If teams complain about how badly responsive a product leader is, that’s not a good sign.

Strong Negotiator: When priorities change, and scope shifts and requests pile up, a product leader must negotiate trade-offs responsibly and help teams align on what matters most. This becomes even more important when the product lead doubles as a project coordinator.

High Energy: Product work can be draining because iterations fail, plans fall apart and momentum may slow down. But the product leader must inject energy into the team when fatigue sets in.

Optimistic and Positive: Things will go wrong, often. You don’t want your product leader to be the loudest complainer. You need someone who can manage change without being overwhelmed, who stays solution-oriented, and who keeps the team moving forward even when iterations feel endless.

If you’re building a product today, start small, stay close to the problem, and fall in love with results, not ideas.