Nahom Mekonen

Product manager and founder who loves building things people actually rely on. I co-founded Kabba, a transportation technology company now moving more than a million trips, and before that bootstrapped Radium Media to $30M+ in sales with no outside funding. I come from product, growth, and the technical side, and I'm at my best on hard problems that real people feel every day. Based in Minneapolis, open to offers.

I came to the US from Ethiopia to study computer science, sure I would end up an engineer. Growth marketing pulled me sideways in college, and I started building small direct to consumer brands out of my dorm room.

That turned into Radium Media. Over three years it did $30M in sales with no outside money. It taught me more than my classes did: how to sell, how people actually decide and behave, and how to build a team and scale a product. I graduated with offers from good companies. I kept thinking about a problem back home instead.

So I went back to Ethiopia. Some of the fastest growing countries on earth run on transportation that was built decades ago, when it was built at all. Fixing that changes how millions of people live and work. I wanted to put my energy there.

That became Kabba. We are building public transit in a place that had almost none. I rode the minibuses for weeks as an ordinary commuter before I wrote anything down, because I would rather live a problem than guess at it. LinQ came later and closer to home. I saw the same struggle in my own community here in the US, small transportation companies moving thousands of kids with paper and phone calls, so I spent my weekends building them a tool to run their cars and routes, and gave it to them for free.

I am a builder before I am anything else. I am drawn to problems you can actually touch, the kind a real person feels on a real morning, and I like staying with one long enough to move it. That thread runs through everything I have done, from selling products out of a dorm room to owning product for a transit company. The domain keeps changing. The way I approach it does not.

How I work is easy to say and hard to do. I go to where the problem lives before I write anything down. I look for the job people are actually trying to get done, which is almost never the feature they asked for. Then I put the smallest useful version in their hands, watch what really happens, and let the evidence decide what comes next.

• Live the problem before I build. I will spend two weeks as a user before I spend two months guessing. I rode the minibuses and I sat with the dispatchers.
• Find the real job. People rarely want the feature they name. They want the outcome underneath it, and that is what I design toward.
• Ship small and let reality vote. A rough version in someone's hands teaches me more than a flawless spec ever has.
• Measure what changes a decision. If a number will not change what we do next, I leave it alone.

Most of this I learned the hard way, building in a market where I could not take card payments or reliable maps for granted. It left me allergic to assumptions. I hold my own ideas loosely and the problem tightly, and getting corrected early by a real user beats defending a tidy plan that was wrong all along. That is the kind of product person I am, and the kind of team I want to build with.

Three things I have built. For each: the problem, the hardest call I made and what I traded for it, what happened, and what I would do differently. The metrics are here, but the calls are the point.

Kabba Transport

Mass transit startup · Addis Ababa

KB-021

status: shipped, live

role: co-founder & head of product

timeline: 2021 to present

surface: rider · driver · operator

Kabba is the company I care about most. We build shared mass transit for Addis Ababa, a city where about five million people move every day with no system built for them. Think of it as a subway that happens to run on minibuses, not another ride hailing app. Fixed routes, monthly subscriptions, and prices that do not move on you.

# the problem

I rode the informal minibuses for weeks before writing a single requirement, living the problem instead of studying it. The reframe that reorganized everything: people were not buying a ride. They were buying the confidence that they would clock in on time tomorrow, and the day after that. Once the job read that way, most of the product decisions answered themselves.

Ride hailing had already arrived. It fixed reliability, then priced itself out of a working person's daily commute. The minibuses were the opposite: cheap, but you could not count on them for anything. Nobody had built the middle, so we did.

# the call

Decision record

chose

Fix the reconciliation bottleneck no one could see before we added a single new fleet.

over

Chasing the growth number the whole room wanted to watch climb next quarter.

the bet

We held roughly flat for a quarter while I defended a still dashboard to people who wanted it moving. When we did expand, operations held instead of buckling. It is the call I am proudest of, because it was the least popular one in the room.

1M+

trips served

400%

YoY growth

95%

platform retention

40+

enterprise clients

# how I worked

I owned the product end to end, from discovery to specs an engineer could build without coming back to ask what I meant. I worked with a team of ten engineers, and together we shipped for 40+ enterprise clients and 30 school partners.

• Led product strategy and roadmap across rider, driver, and operator surfaces. Used RICE scoring to force sequencing when engineering bandwidth and operational urgency collided.
• Interviewed more than 100 companies and ran discovery with commuters and drivers. It turned out a driver's real job was steady income, not navigation, so I rebuilt the driver app around that.
• Mapped the operator workflow end to end and traced the money. That is where I found the reconciliation problem, invisible from the outside, that became the call above.
• Specified and owned the payment gateway and government API integrations, managing external technical and compliance stakeholders from brief to go live.
• Built the B2B corporate tier from user stories up. HR directors did not want transportation. They wanted liability off their desk, and that reframe made it our highest margin product.
• Built the analytics layer behind real time operating decisions and used it to test routes and pricing before committing to full rollout.

Retro · open questions

Instrument earlier, decide later. I was calling product decisions directionally well after we had the usage to be precise. Directional is fine before product market fit. After it, that is just an excuse.

Run B2B discovery in month 2, not month 18. Corporate HR turned out to be our most rational, highest value buyer. Running that discovery earlier would have reshaped the roadmap.

Make the driver feedback loop a standing channel. Driver sessions kept handing me critical insight. I treated them as lucky finds. They should have been a fixed input from day one.

★Recognitionresolved

Nominated, Africa Startup of the Year, for innovation in urban mobility.

comment · resolved

LinQ

Student transportation · side project

LQ-024

type: built solo, on weekends

status: shipped, live

cost to operators: free

market: Minnesota, North Carolina

LinQ started as a side project because the problem would not leave me alone. I kept seeing it in my own community here: small transportation companies moving thousands of kids with paper and phone calls. The big yellow school buses have plenty of software. The seven-seater vans that carry those kids every day have almost none. So I spent my weekends building the tool they were missing, routing, dispatch, and live tracking to run their cars and routes, and I gave it to them for free.

10+

transport companies

10K+

students routed

2

US states

live

parent tracking

# the call

Decision record

chose

Build only the dispatcher's daily screen and a live map for parents.

over

Matching the feature lists of the big school bus software.

the constraint

I had weekends and nothing else, so I cut everything that was not the job the day revolved around. Billing and reporting waited. Operators adopted it anyway, because it did the one thing they could not do on paper.

# the build

• Gave dispatchers one screen for drivers, routes, and student assignments, the kind of visibility the big bus software never bothered to build for type 3 fleets.
• Put a live map in parents' hands, so they can see where their child is on the way to school. That was the part I cared about most.
• Routed 10,000+ students for 10+ operators across Minnesota and North Carolina, turning spreadsheets and phone calls into a real system.

The part that stays with me is simple. We can track a package across an ocean. A kid on the way to school should not be harder to find than that.

NMNahomnote

I built this for operators in my own community, family included, running real businesses on paper. It meant a lot to make something useful for them.

comment · open

Radium Media

Creator commerce · bootstrapped

RD-019

status: shipped

role: founder, product & growth

timeline: 2019 to 2023

funding: none

Where it started. A creator commerce company I built on one bet: creator audiences are the most loyal, high intent buyers in e-commerce, and almost nobody was building brands for them on purpose.

$30M+

sales in 3 years

200K+

customers

0

outside funding

5+

brands launched

# the insight

Most companies saw a creator's audience as ad inventory. I read it as a product brief. A mid tier creator with 200,000 engaged followers has the one thing brands spend millions trying to manufacture: trust. So I built the brands backwards, audience first and product second, with the creator as proof the market was already there.

• Built the audience persona before the product, down to how they buy and what earns their trust.
• Validated fit before spending, A/B testing the message with each audience before scaling a dollar.
• Turned it into a playbook that worked on the fifth brand as well as the first.

# the call

Decision record

chose

Pick the audience and the creator first, then build the product to fit them.

over

Building a product I liked and buying attention for it later.

the bet

I passed on product ideas with no audience I could reach honestly, which made us slower to launch. In return, every brand had demand before it had inventory.

Retro · what I learned

Build retention from day one. I optimized hard for acquisition. The brands that lasted had a real repeat purchase loop, and I learned that a few brands too late.

NMNahomnote

$30M with no funding, mostly while I was still in college. It taught me how much distribution matters, and how much I still had to learn.

comment · open

The numbers, across everything I have built. No rounding up.

What I actually do day to day, grouped by surface.

A spec is honest about what it is not. So I will be too.

• I am not leaving Kabba because it failed. It works, and I am proud of it. I want my next chapter to be hands on, inside a mission I can really pour into.
• I am not looking to start another company right now. I have loved building from zero, but what I want next is to go deep on one product with a team I can learn from.
• I am not chasing a title. I would rather own a real problem than sit higher on an org chart.
• I try not to track numbers that do not change a decision. I would rather measure less and actually act on it.