My Approach

How I Think
About Product.

An operating philosophy, not a framework — built from shipping under real-world constraints, validated with users in the hardest moments, and refined across every product I touch.

— 01

The Premise

"If a product works for the user in the hardest situation, it works for everyone else."

— Operating Philosophy

— 02

Five Rules I Build By

Frame the User Under Pressure

Who is the user when constraints are highest? What are they trying to do in 30 seconds or less? What would make them stop using your product? Start here. Everything else is details.

Quantify Every Assumption

Every assumption gets a number. 'Users want real-time earnings' becomes '82.3% of interviewed staff said earnings visibility motivates them.' 'We need a payment gateway' becomes 'What % of SMEs actually use automated payment systems?' (Answer: 0%). No vibes. No intuition. Numbers.

Cut Ruthlessly

For every feature you add, ask: 'Would the user under pressure miss this?' If the answer is 'no,' it's deferred. Payroll automation? Nice. Earnings visibility? Essential. Feature fatigue kills adoption faster than missing features.

Ship to Learn, Not to Finish

Shipping a working MVP in 2-3 weeks teaches you more than 3 months of spec debates. Real users on real phones in real contexts reveal what matters. Prototypes are questions. Shipped products are answers.

Measure What Matters

Not adoption. Not features shipped. Adoption WITH retention. Is the user coming back? Does the product reduce the problem it was supposed to solve? Define success metrics before launch. Then be honest about what the data says.

— 03

PM Frameworks I Use

North Star Metric

WEAVE: Weekly active managers using app to manage shifts SafeSignal: Incident reports submitted with automatic telemetry

Problem Framing

Jobs to Be Done (understand the actual job, not the feature request) User Under Pressure framework (my own: design for the hardest moment)

Prioritization

RICE (Reach, Impact, Confidence, Effort) MoSCoW (Must have, Should have, Could have, Won't have) Constraint-driven (What fits in the timeline?)

Execution

Agile sprints (2-3 week cycles) Ruthless scope discipline (MVP only) Daily standups with stakeholders

— 04

Research Methodologies

Discovery & Validation

Structured interviews (50+ participants for WEAVE problem validation) Ethnographic observation (shadowed managers during their day for WEAVE; interviewed people who experienced unsafe incidents for SafeSignal) User testing with prototypes (3 rounds per feature) Focus groups (staff feedback sessions for WEAVE)

Sample Diversity

WEAVE: Restaurant owners, retail managers, supervisors, frontline staff, accountants SafeSignal: University students, business owners, community workers, delivery drivers, people with lived experience

Research Tools

Google Forms (structured surveys) In-person interviews (recorded with consent) Figma/Canva (journey mapping, user flows) Direct observation (no interruption)

— 05

Metrics & Measurement

Before Building (Define Success)

North Star Metric (what represents real value?) Leading indicators (daily/weekly signals) Retention metric (are they coming back?) Kill criteria (if X happens, we pivot)

During Testing

Completion rate (can users finish the core action?) Time to complete (how much friction?) Qualitative feedback (what surprised them?) Feature adoption (which features matter vs. which are noise?)

After Launch

30-day retention (do they stay?) Weekly active users (is it actually used?) Task completion rate (does it solve the problem?) User quotes (what are people actually saying?)

— 06

Tools I Use

Product Building

Lovable.ai (rapid prototyping, no-code acceleration) Claude AI (research synthesis, writing, ideation, problem-solving)

Research & Data

Google Forms (surveys) Notion (research notes)

Organization & Execution

Notion (product roadmap, feature tracking) Google Docs (PRDs, strategy docs) Figma (user flows, wireframes)

Prioritization

RICE framework (Reach, Impact, Confidence, Effort) MoSCoW matrix (Must/Should/Could/Won't have)

— 07

Design Philosophy

Mobile-First (Not desktop-first)

95% of users in emerging markets access via phone Touch targets 44px+ Simplified navigation

Offline-First (When relevant)

Networks are unreliable; design for that reality Data syncs when connection returns Works in low-connectivity contexts

Constraint-Driven Design (Not feature maximalism)

Limited scope = ruthless prioritization Every pixel serves the core job Simplicity is harder than complexity

Nigerian/Emerging Market Context (When applicable)

SMS-first, not email-first Naira pricing, not USD WhatsApp-native, not LinkedIn-native Offline functionality, not cloud-only

— 08

Why This Approach Works

It's Grounded in Reality

Products fail when they're designed for ideal users under ideal conditions. Real users don't have perfect circumstances. Mine are built for that gap. WEAVE works for managers dealing with actual operational chaos. SafeSignal works for people in actual danger. Design for the messy moment, not the perfect scenario.

It's Data-Driven, Not Intuition-Driven

Every assumption gets tested. Every feature decision is backed by research, not vibes. Numbers beat opinions.

It's Fast Enough to Learn

2-3 week timelines force ruthlessness. You ship what matters. Users teach you what you got wrong. Iterate.

It Respects the User's Actual Moment

The user under pressure reveals the truth. Build for them, and everyone else is easy.

I'm ready, are you?

Let's turn pressure into product.

Let's talk →See the proof →

How I ThinkAbout Product.