If you’ve been following along, we have covered a lot of ground. We named the Hamster Wheel, exposed the Whack-a-Mole trap, dove into the Iceberg to see why we reward failure, and dismantled the Happy Path delusion.

Today, we tackle the final enemy. The reason why smart teams panic, pivot, and burn cash. We are going to talk about Delay, and a phenomenon I call The Executive Twitch.

An industry acquaintance once shared a story with me about a high-growth fintech that was scaling fast. The CEO was a brilliant, high-energy founder who treated his company like a Ferrari. He wanted instant feedback. If he turned the steering wheel, he expected the car to turn now.

But a company with millions of transactions is not a Ferrari. It is an oil tanker.

Every Monday, the “Risk Dashboard” was projected on the screen. The drama always unfolded the same way.

One week, the CEO would scream that fraud loss was up. “We are bleeding money!” he’d say. “Tighten the risk rules immediately!” The Risk VP, under pressure, would block any transaction over $50 from a new device.

Three weeks later, the dashboard would show that transaction volume had crashed. Support was drowning in tickets from angry users who couldn’t pay. “We are killing growth!” the CEO would yell. “Loosen the rules!” The Risk VP would loosen the rules.

Two weeks after that, chargebacks would skyrocket again. The order would come down: “Tighten the rules!”

The Risk team was getting whiplash. The problem wasn’t their competence; it was System Delay.

They didn’t realize that Chargebacks have a 30-day lag. The fraud occurring in Week 1 doesn’t show up in the bank data until Week 5. By tightening the rules in Week 1, they killed the good volume immediately (Instant Feedback). By loosening them in Week 3, they invited the fraudsters back in, but wouldn’t see the damage until Week 7.

They were driving the car by looking out the rear-view window, swerving wildly to avoid obstacles they had already passed.

The Physics of Oscillation

To understand why entire organizations oscillate, panic, pivot, panic again, we have to look at the physics of feedback loops. The classic metaphor is the Hotel Shower.

Imagine you are in an old hotel. You step into the shower and turn the knob. The water is freezing cold.

Naturally, you turn the knob to HOT. But the hot water has to travel through 50 feet of rusty pipes. For ten seconds, nothing happens. The water remains freezing.

Your perception is that you didn’t turn it enough. So, you react. You turn the knob all the way to SCALDING.

Five seconds later, the hot water finally arrives. It is 150 degrees. You scream. You panic. You slam the knob back to COLD. Five seconds later, you are freezing again.

This is System Oscillation. It occurs mathematically when your Reaction Time is faster than the system’s Response Time.

If you react to the data faster than the system can process your previous action, you become the source of the instability. In Product Management, we call this “Agile,” but it is often just “Twitching.”

The Three Zones of Lag

A System Architect does not treat delay as a vague annoyance. They map it. In any product delivery loop, there are three distinct zones where time is stolen from you.

The Perception Delay

Management loves “Real-Time Dashboards.” They are a lie. Almost all significant metrics are lagging indicators. A user rarely wakes up and churns on a whim. The “decision to churn” usually happens 30 to 60 days before the “act of churn.”

If you manage your team based on today’s Churn Rate, you are reacting to ghosts. You are trying to fix a relationship that died eight weeks ago. The veteran move is to stop steering by lagging indicators like Revenue and Churn, and start steering by leading indicators like Login Frequency and Support Sentiment.

The Response Delay

You probably think your “Turning Radius” is your two-week sprint. It isn’t.

Audit the real chain. You prioritize a feature on Day 1. The sprint ends on Day 14. QA kicks it back on Day 17. It merges to Staging on Day 21. App Store Review holds it until Day 24. It goes live on Day 26.

Your turning radius is roughly a month. If the market shifts every two weeks, and it takes you four weeks to turn the ship, you are mathematically incapable of catching up.

The Impact Delay

This is where the “Flatline Panic” happens. You ship a new feature. You check the stats on Day 2. Zero growth. You check on Day 5. Zero growth. The PM concludes, “It’s a dud. Roll it back.”

This is the most common error in product. Humans suffer from Inertia. When you change an interface, the first reaction is confusion, not adoption. It takes multiple exposures to a new feature before a user builds the neural pathway to use it. If you kill a feature on Day 14, you are aborting the baby. You are turning the shower handle back to cold before the hot water has arrived.

The “Worse-Before-Better” Phenomenon

There is a sinister variant of delay that veterans know well: the Worse-Before-Better curve. In complex systems, the most effective long-term solutions almost always degrade performance in the short term.

Think about Refactoring Code. To speed up velocity in the long run, you have to stop building features today. Velocity drops to zero. Bugs increase as you break the monolith. Stakeholders get angry. But eventually, velocity doubles.

Think about Moving Upmarket. To sell to the Enterprise, you have to stop feeding the SMB quick-wins. Revenue drops because Enterprise deals take six months to close. You enter the “Valley of Death.” But eventually, revenue 10x’s.

The “Everyday Product Person” sees the dip, panics, and reverts to the old way. The “System Thinker” anticipates the dip. They warn the stakeholders: “We are entering the tunnel. It will get dark before it gets light. Do not grab the wheel.”

The Discipline of Strategic Patience

So, how do you operationalize this? You cannot simply tell your CEO to “chill out.” You need a protocol.

First, Define the “Time to Impact” (TTI). Never launch a feature without defining its Gestation Period. Do not say, “We are launching on Monday.” Say, “We are launching on Monday. The TTI is 45 days. We expect metrics to be volatile for the first two weeks. We will not draw any conclusions until Day 46.”

Second, enforce a “Pact of Silence.” Before a high-stakes release, make your stakeholders sign a verbal contract. Agree that between Launch Day and TTI Day, you are in the Observation Zone. You will fix critical bugs, but you will not change the strategy, you will not change the copy, and you will not pivot based on Day 3 data. You bind their hands to the mast so they can’t steer the ship during the storm.

Finally, Dampen the Feedback. If your system is oscillating, like the pricing or ad-spend examples, the solution is not to react faster. It is to react slower. If metrics are reported Weekly, move the strategy meeting to Monthly. Force the team to look at the trend (Stock) rather than the blip (Flow).

The Monday Morning Exercise: The Graveyard Audit

Take 20 minutes to look at your “Graveyard”, the list of features you killed in the last year because they “didn’t work.”

For each failed initiative, write down two numbers.

1. The Duration: How long was it live before we killed it?

2. The User Cycle: How often does a user naturally use this part of the product? (e.g., Monthly invoicing = 4 weeks).

The Verdict: If the Duration was shorter than the User Cycle, you didn’t run a test. You ran a panic drill.

Is there an initiative in the graveyard that was technically sound but killed by impatience? Resurrect it. But this time, set the TTI. Give it the time it needs to travel through the pipes.

The Golden Rule:

In a complex system, patience is not a virtue. It is a physics requirement. You cannot make a baby in one month by getting nine women pregnant. Stop trying to rush the lag.

We started by naming the problem: The Hamster Wheel (Episode 1). Then, we exposed the Whack-a-Mole trap (Episode 2) to show how we confuse motion with progress. Finally, we dove into The Iceberg (Episode 3) to understand why organizations reward firefighting instead of fire prevention.

Today, we are moving from the organization to the product execution. We are going to talk about why your product looks great in the demo but breaks the moment a real human touches it.

We are going to talk about The Happy Path Delusion.

Let’s play this scenario about an imaginary mobile payments company you are working for. They were preparing for the biggest launch in their history. The design team had spent six months polishing the “Send Money” flow.

It was breathtaking. The animations were 60fps liquid butter. The transitions were seamless. The “Success” screen exploded with delightful confetti, triggering a haptic vibration that felt like pure victory.

When the VP of Product demoed it on stage at the company All-Hands, using the high-speed office WiFi and a test account populated with perfect, sanitized data, the room erupted in applause. It looked like the future. It felt like magic.

You launched it to 10% of the user base on Monday. By Tuesday, the support queue wasn’t just busy; it was a crime scene.

• “You stole my money! The recipient didn’t get it and my balance is zero!”

• “The app freezes when I try to select a contact.”

• “I got an error message that just says ‘Object Null’. What does that mean? Did I break it?”

What happened?

You had built a product for the Happy Path.

You assumed the user had a stable 5G connection. In reality, they are using a Tecno device from 2015, standing in a concrete stairwell with one bar of Edge network. You assumed the user had friends with valid bank accounts. In reality, they were sending money to a phone number (Mobile Money) that hasn’t been verified in three years. You assumed the user would wait for the animation to finish. In reality, they are anxious and in a hurry, so they rage-tapped the button four times because the UI was slow to respond.

The polished demo was a hallucination. You had designed an F1 racing car with millimeter-perfect clearance, intending it to travel the Old Lagos-Abeokuta Expressway. The moment it hit the potholes of the real world, the axles snapped, and the engine exploded.

The Myth of the “Perfect User”

If you look at most Product Requirements Documents (PRDs) or Figma files, they feature a protagonist I call The Perfect User. The Perfect User is a convenient fiction we tell ourselves to make the job easier.

The Perfect User always reads the onboarding text and understands every nuance. They grant all permissions (Location, Camera, Contacts) immediately and without suspicion. They input their name correctly (no emojis, no special characters, proper capitalization). They never hit the “Back” button in the middle of a transaction to check their balance. They have a fully charged battery, 20/20 vision, and the patience of a saint.

The Perfect User does not exist.

This belief in the Perfect User is a flawed Mental Model (Level 4 from our Iceberg framework). It assumes order in an unpredictable universe of chaos.

Real users are chaotic agents of entropy. They are drunk at 2 AM trying to unlock a scooter with greasy fingers. They are stressed parents trying to pay an electric bill with a screaming toddler in one arm and 1% battery life on their phone. They are skeptical boomers who deny every permission request out of fear of being tracked. They are distracted commuters whose thumbs slip and hit “Cancel” instead of “Confirm.”

When you design for the Perfect User, you are creating a Fragile System. A Fragile System works only under ideal conditions. It breaks under volatility.

A Resilient System assumes the user is distracted, the network is hostile, the database is on fire, and the input is malicious. It expects the user to click a WhatsApp notification popup in the middle of a transaction, switch apps, and return 20 minutes later expecting their cart to still be there.

The Three Zones of Entropy

To cure the Happy Path Delusion, you must stop designing for the “Success State”, that’s the easy part and start designing for the Variance. There are three specific zones where entropy will attack your product.

1. Input Variance

The Happy Path assumes the user enters “John Smith.” The Reality is the user enters “J@hn $mith 💀”, or pastes a string of 5,000 characters from a PDF, or uses an emoji as their last name.

The consequence is severe. If your backend isn’t sanitized, this garbage data crashes the database or creates “ghost” records that can’t be retrieved. If your UI doesn’t handle text wrapping, the layout breaks, buttons get pushed off-screen, and the app becomes unusable.

The fix is Defensive Design. You don’t just “design the input field.” You design the validation logic, the error masking, and the character limit feedback before you design the success state. You assume the input is guilty until proven innocent.

2. Context Variance

The Happy Path assumes a linear flow: User clicks “Buy.” A spinner appears for 0.5 seconds. “Success!” The Reality is the user clicks “Buy” just as their vehicle reaches the Third Mainland Bridge. The signal drops from 4G to “Lie-Fi” (connected but no data). The request times out. The user, thinking nothing happened, clicks “Buy” again. And again.

Does the system charge them three times? Does the app hang forever on a spinning wheel of death, forcing them to force-quit?

The fix is Idempotency (ensuring that clicking the button ten times results in only one charge) and Optimistic UI. Optimistic UI means the app assumes success and updates the screen immediately, but silently handles the rollback if the network fails, presenting a polite “Message failed to send, tap to retry” option instead of a crash.

3. Behavioral Variance

The Happy Path assumes a straight line: Step 1 → Step 2 → Step 3 → Finish. The Reality is a mess: Step 1 → Step 2 → User gets a WhatsApp notification → Switches apps → Android OS kills your app background process (common on Transsion devices) → User reopens app → The app restarts from Step 1.

Does the system remember the data from the first attempt? Or does it clear the form, infuriating the user and causing them to abandon the cart?

The fix is State Persistence. The system must be “stateless” enough to handle non-linear navigation without losing the user’s progress. The user should be able to wander through your flow like a garden, not a hallway.

Design Inversion

While many design the Success State first because it feels good and sells the vision. Veterans design the Failure State alongside the Success State because it saves the product.

They apply the oldest rule of survival to software: Hope for the best, prepare for the worst.

This is a principle I call Design Inversion. It is the discipline that separates the Firefighter (who reacts to the error) from the Architect (who designs for the error).

When I kick off a new feature, I forbid the designers from showing me only the “Success Confetti” screen. Honestly, I could care less about it. What I truly long to see and what I obsess over are the edge cases. Show me the “404,” the “500 Error,” the “Timeout,” and the “Empty State.”

Why? Because the Failure State is where Trust is won or lost.

• When the app works, the user feels nothing. They expect it to work. It’s a hygiene factor. (Neutral Trust).

• When the app breaks and gives a cryptic error (”Error 503: Bad Gateway”), the user feels stupid and angry. They blame themselves, then they blame you. (High Trust Drain).

• When the app breaks but handles it gracefully (”We’re having trouble connecting to the bank. Don’t worry, your money hasn’t left your account. We saved your details. Try again in 5 seconds.”), the user feels safe. They feel looked after. (Trust Preservation).

The Monday Morning Exercise: The Chaos Monkey

Meeting: Design Review / Desk Check
Time: 20 Minutes

The next time a designer or engineer presents a flow to you, stop nodding along. Instead, play the role of the Chaos Monkey. This is sometimes called Red Teaming, they are actively trying to break the system before a user does.

Ask these questions to break the illusion:

1. The Tunnel Test: “What happens to this screen if the internet cuts out exactly when I tap the button?” (Does it freeze? Do I lose my data? Do I get a retry button?)

2. The Grandma Test: “What happens if I have my font size set to 200% for accessibility?” (Does the ‘Submit’ button disappear off the bottom of the screen? Does the text overlap?)

3. The Spam Test: “What happens if I paste the entire script of Bee Movie into this text box?” (Does the backend reject it gracefully, or does the app crash?)

4. The Fatigue Test: “What happens if I rage-click this button 10 times in one second?” (Do we fire 10 API calls, or do we debounce the button?)

5. The Multitask Test: “What happens if I minimize the app to answer a text, then come back 10 minutes later?” (Is my form data still there?)

6. The Low-End Test: “What happens if I run this on a low-memory device that forces a refresh?”

The Deliverable:
For every “It breaks” or “I don’t know” answer, create a Jira ticket. Label it “Resilience.” Do not ship the feature until the resilience tickets are closed.

Even better? Do User Testing. Get a click-through prototype in the hands of a real user (not a colleague) and watch them fail. It is the fastest way to mitigate your assumptions and learn the chaos of the real world.

The Golden Rule:

A product is only as strong as its error states. If you design for the 1% perfect journey, you are building a product that is broken 99% of the time for the 99% of users who live in the messy, chaotic real world.

The Recap

• The Happy Path is a Myth: Real users are chaotic. Design for them.

• The 3 Zones of Entropy: Prepare for bad data (Input), bad networks (Context), and bad focus (Behavior).

• Design Inversion: Design the failure states (404s, Timeouts, Empty States) with as much love as the success states.

• Be the Chaos Monkey: Break your own product before the market does.

In the last episode, we talked about Whack-a-Mole and the danger of confusing motion with progress. Today, we are going to go deeper. We are going to talk about The Iceberg.

But first, let me take you back to my time as a Head of Product at a very large organization.

My team shared a workspace with the product team that managed the organization’s flagship consumer product. We interacted very often. This was the crown jewel of the portfolio. And looking at that team, you would think they were at war.

They always looked worn out. They were the “first in, last out” crew. Every other week, there was a “Critical Severity” bug or a massive outage. The team was constantly scrambling, patching, and apologizing. They were often called into executive meetings to explain why the “Flagship” didn’t feel like a flagship.

But here is the crazy part.

At the end of the year, during the keynote session, that team was called out. They were generously hyped as the organisation saviour. They were praised for their “resilience,” their “hard work,” and their “dedication to putting out fires.”

I sat there clapping, but in my head, I realized the truth: We were rewarding them for bailing water out of a boat they forgot to plug.

They were slaving away on surface issues, ignoring the deep structural fractures. And because the business didn’t understand Systems Thinking, it rewarded Effort instead of Results.

A mature business does not reward you for sweating. It rewards you for fixing the system so you don’t have to sweat.

To understand this, you need to understand the Iceberg Model.

The 4 Levels of Reality

Most Product Managers live their entire careers at the tip of the iceberg. They see what happens, and they react. But Systems Thinkers dive to the bottom.

Level 1: Events (The Firefighter)

• The Question: What just happened?

• The Behavior: Reacting.

• The Trap: This is the domain of the “Hero.” It feels good to save the day. But if you are saving the day every day, you aren’t a hero; you are a hostage. This is where the “Flagship Team” lived, addicted to the adrenaline of the fix but blind to the cause.

  • “The site crashed.” → Reboot it and high-five.

  • “A customer complained.” → Offer a discount and apologize.

  • “Sales missed quota.” → Yell at Sales and demand “more intensity.”

• The Outcome: You survive the day, but you are doomed to repeat it forever. You are running on a treadmill, sweating profusely, but going nowhere.

Level 2: Patterns (The Analyst)

• The Question: What has been happening over time?

• The Behavior: Anticipating.

• The Shift: You stop reacting to the noise and start looking at the signal. You move from “What happened?” to “What always happens?” You become a weather reporter; you can predict the storm, but you can’t stop it.

  • “The site crashes every time Marketing sends a push notification greater than 50k users.”

  • “Users churn exactly 3 months after onboarding when their trial expires.”

• The Outcome: You can predict the failure, but you are powerless to prevent it. You just buy better umbrellas and brace for impact.

Level 3: Structures (The Architect)

• The Question: What is causing the pattern?

• The Behavior: Designing.

• The Shift: This is where the Product Architect lives. You stop blaming “bad luck” or “dumb users” and look at the physics of the system. Structures are the rules of the game—both physical (code/servers) and intangible (incentives/org charts).

  • Physical Structure: “The site crashes because the marketing server and the production database share the same load balancer. They are structurally fighting for the same resource.”

  • Incentive Structure: “Sales misses quota because they are paid commission on ‘booked revenue’ regardless of retention. The structure incentivizes them to sell bad deals that churn.”

• The Outcome: You change the structure (Rewrite the Org chart, decouple the Tech stack, Change the Compensation plan). The pattern stops immediately. The fire goes out forever because the fuel is gone.

Level 4: Mental Models (The Visionary)

• The Question: What beliefs hold the structure in place?

• The Behavior: Transforming.

• The Shift: This is the bedrock. This is the water we swim in. Structures don’t appear out of thin air; they are built by people with specific beliefs. If you change the structure but not the belief, the structure will eventually grow back.

  • “We believe that ‘Move Fast and Break Things’ is better than ‘Reliability’.” (This belief built the shared load balancer).

  • “We believe that Sales owns the customer relationship, and Product is just a factory.” (This belief built the commission structure).

• The Outcome: The entire organization shifts its identity. You don’t just solve the problem; you change the DNA of the company so that problem cannot exist here.

The Descent: A Case Study in Retention

Let’s watch a product team try to solve a Retention Crisis (Churn spikes to 15%) at these different levels.

The Level 1 Manager (The Firefighter):

• Reaction: “Call the customers! Offer them a 20% discount to stay! Quick, send an email blast!”

• Result: They save 5% of customers this month. Next month, churn is 15% again. They are stuck.

The Level 2 Manager (The Analyst):

• Reaction: “I looked at the data. Churn spikes specifically with ‘Small Business’ clients who sign up via ‘Self-Serve’. Large Enterprises are fine.”

• Result: They stop panicking about Enterprise clients. They adjust their revenue forecast down for Small Biz. They are “data-driven,” but they are still losing money.

The Level 3 Manager (The Architect):

• Reaction: “Why do Small Businesses churn? Let’s look at the structure. Ah, our onboarding requires a dedicated ‘Customer Success Manager’ to configure the API. Small Business plans don’t get a Success Manager. Therefore, they are structurally doomed to fail.”

• Result: They change the structure. They build a “Self-Serve Wizard” that automates the API setup.

• The Impact: Churn drops permanently.

The Level 4 Leader (The Visionary):

• Reaction: “Why did we build a product that requires a human to set it up in the first place? It’s because we view ourselves as a ‘Service Company’ that happens to sell software. We need to shift our Mental Model. We are a Product-Led Growth company.”

• The Impact: They don’t just fix churn; they change the trajectory of the company for the next 5 years.

The Veteran’s Discipline: Managing the Waterline

The hardest part of Systems Thinking is not understanding the Iceberg; it is the discipline to dive when everyone else is screaming at the surface.

When a crisis hits, the pressure to “Do Something!” (Level 1) is immense. Your CEO wants a status update. Sales wants a fix. If you say, “I am analyzing the Mental Models that caused this,” you will get fired.

The Veteran Product Leader knows how to manage the Waterline.

1. Contain the Event: Apply the tourniquet. Fix the bug. Pacify the CEO. (Level 1).

2. Don’t Celebrate: Refuse to call the hotfix a “win.” It is a failure of the system that we had to fix it at all.

3. Schedule the Dive: Once the smoke clears, book the meeting that matters. “The Incident Review.”

The Monday Morning Exercise

Meeting: The Post-Mortem (or “Incident Review”)

Time: 30 Minutes

Take the last “Crisis” your team faced (a bug, a missed deadline, a bad release). Draw an Iceberg on the whiteboard.

1. The Event: Write down what happened. (”The mobile app crashed on launch.”)

2. The Pattern: Has this happened before? (”Yes, every time we update the library dependencies.”)

3. The Structure: What in our system allows this? (”We don’t have automated regression tests. We rely on manual QA, and manual QA is incentivized to check ‘New Features’, not ‘Old Code’.”)

4. The Mental Model: What belief defends this structure? (”We believe that ‘Automated Testing slows us down’.”)

The Verdict:

If you leave that room promising to “Test harder next time,” you have failed.

You only succeed if you change the Structure (Invest in CI/CD pipeline) or the Mental Model (Redefine “Speed” to mean “Speed without crashing”).

Stop fighting the fire. Re-wire the building.

In the last Episode, we discussed the Hamster Wheel - that sinking feeling that you are moving fast but going nowhere.

Today, we address why you stay on the wheel. We need to confront the most dangerous drug in product management: The Illusion of Progress.

Let me tell you a story a friend of mine shared recently. Let’s call him David.

David managed a Product Team obsessed with “Bug Bashes.” Every Friday afternoon, they would gather in a dedicated space full of pizza drinks and they will blast music, and spend long hours crushing bugs. They even went the extra mile to gamify the process with leaderboards, everyone will high-five at 5:00 PM, and they’ll end the week feeling productive. They had “cleaned the house.”

But David noticed a disturbing pattern in the data.

In Week 1, they fixed 50 bugs. By Week 2, the backlog had filled up with 50 new ones. By Week 4, despite their “record-breaking velocity,” the backlog had actually grown to 60 bugs.

They weren’t cleaning the house. They were bailing water out of a sinking boat with a teaspoon.

When David finally canceled the TGIF pizza parties, the team was furious. They pointed to their velocity metrics as proof of their success. David’s response was harsh but necessary:

“We aren’t fixing anything. We are playing Whack-a-Mole. And the moles are winning.”

The Dopamine Trap

Why did the team fight so hard to keep the Bug Bash?

Because fixing a bug provides an immediate dopamine hit. It is a discrete, solvable task: Identify -> Code -> Deploy -> Done.

It feels like work. It feels like progress. But unless you locate the nest where the moles are breeding, you are wasting your life hitting them one by one.

In Systems Thinking, this behavior is known as getting trapped in the Event Level.

This is the very top of the Iceberg. As humans, we are evolutionarily wired to respond to immediate events. A saber-toothed tiger appears; we run. A server crashes; we reboot it. A customer complains about a typo; we fix the typo.

The problem is that your product is not a saber-toothed tiger. It is a complex machine.

If you have a typo on the landing page, fixing the typo is the wrong move. That is just hitting the mole. The real question is: “How did our Content Management System allow a typo to go to production without review?” That is finding the nest.

The Ratio: Are You a Junior or a System Architect?

So how do we stop hitting moles and start pouring concrete into the holes?

I judge Product Managers by a simple equation: Time Spent Fixing vs. Time Spent Preventing.

• The Junior PM spends 90% of their time fixing. They are busy, stressed, and feel “essential.”

• The Senior PM splits their time 50/50.

• The System Architect spends 90% of their time preventing. They often look bored, but their product never breaks.

If you want to move from Junior to Architect, you have to find the source. If you are trapped in a cycle of Whack-a-Mole, the issues are likely originating from one of three specific “nests.”

Nest 1. The Process Nest (The “Hero” Culture)

• The Scenario: A deployment fails and takes down the site. “Dave” jumps in, manually rolls back the database, and saves the day. Everyone claps for Dave.

• The System Flaw: Why does a deployment require manual intervention at all? Why isn’t there an automated rollback script?

• The Fix: Automate the rollback. Fire “Dave” from his role as Hero and make him the Architect of the pipeline.

Nest 2. The Quality Nest (The “Tech Debt” Interest)

• The Scenario: A user reports that the “Save” button is broken on Mobile. Engineers rush to hotfix the CSS.

• The System Flaw: The issue isn’t the CSS; it’s the fact that you shipped it. Why do you have no automated mobile testing suite?

• The Fix: Stop building features for two weeks. Build a Cypress test suite for Mobile.

Nest 3. The Communication Nest (The “Game of Telephone”)

• The Scenario: Engineering builds the feature, but it’s slightly wrong. Product writes a new spec to “clarify,” and Engineering rebuilds it.

• The System Flaw: The Designer and the Engineer sit on different floors (or different Slack channels) and never talk.

• The Fix: Move their desks. Force the conversation before the code is written.

The Weapon: The “5-Why” Interrogation

To find the nest, you need a weapon. That weapon is the 5 Whys.

This is a standard Lean manufacturing tool, but most teams use it incorrectly. They stop at “Human Error.”

• Problem: The site crashed.

• Why? The database locked up.

• Why? A bad query was deployed.

• Why? The engineer made a mistake.

STOP.

If you stop here, you just blame the engineer. You say “Be more careful next time.” That is Whack-a-Mole. You must keep going until you hit the System.

• Why did the engineer make a mistake? Because they were tired.

• Why were they tired? Because they were working overtime to hit an arbitrary deadline set by Sales.

• Why did Sales set the deadline? Because they are incentivized on quarterly quotas, not successful deployments.

The Nest: The Sales Commission Structure.

You can’t fix that with code. But until you fix it, the site will keep crashing.

The Monday Morning Exercise: The “Stop Doing” List

Here is your homework. Look at your calendar for the last week and identify the “Firefighting” blocks, urgent Slacks, emergency calls, apologies to customers.

Pick the biggest fire you fought last week and ask the team:

“What would we have to build so that this specific fire cannot physically happen again?”

If it’s a customer question, build a self-serve tool. If it’s a bug, write a test case that runs on every deploy.

The Rule: You are not allowed to close a bug ticket until you have linked it to a Prevention Ticket.

If you fix the mole without filling the hole, you haven’t finished the job. You’ve just set the stage for the sequel.

Welcome to 2026.

This year, we are doing something different. We are taking “Systems Thinking”, Yes, that massive, academic buzzword and breaking it down into the smallest, most relatable pieces possible.

We aren’t starting with complex diagrams. We are starting with a feeling. You know the one.

It’s 6:00 PM on a Friday.

You are standing in the office kitchen (or staring at a Zoom grid of tired faces). There is cheap pizza. There is warm pepsi. The CEO is raising a toast.

“Great job, everyone,” she says. “We did it. We shipped Project Falcon on time. This is going to be a game-changer.”

You clap. You smile. You take a sip of your drink. But deep down, in the pit of your stomach, you feel... nothing. Or maybe you feel a vague sense of dread.

Because you know the truth.

You know Project Falcon was rushed. You know the “Sales Integration” is actually just a CSV export a junior support agent has to run manually every morning. And, most terrifying of all, you know that next week, the roadmap resets. The CEO will come in with a new “game-changer.”

You will run faster. You will ship more. But the business won’t grow. The retention graph will stay flat.

This is the Product Hamster Wheel.

It is the defining condition of the modern tech worker. We have Jira, Slack, CI/CD pipelines, and AI copilots. We ship code at a velocity that would have melted a server in 1999.

So why do 80% of venture-backed products fail?

Why do Product Managers burn out very easily?

Let’s be honest. It’s not because we aren’t working hard enough. It’s because we are working with a broken map.

The Linear Delusion

We are all children of the Assembly Line. Our MBAs and “Agile” certifications are built on the philosophy of the Industrial Revolution. We are taught to view the world as a machine.

Think of it like a factory line:

• Input: Raw materials (Ideas/Code).

• Process: The Factory (The Engineering Team).

• Output: The Product (The Feature).

• Result: Profit.

In a factory, like building a Innoson G40, this logic holds up. If you speed up the assembly line, you get more cars. If you get more cars, you get more money. Cause and Effect are linear. Inputs equal Outputs.

But software is not a car. Your product is not a machine; it is an ecosystem.

It is a biological system. It is a complex web of users, algorithms, incentives, and competitors all interacting simultaneously.

In an ecosystem, 1 + 1 rarely equals 2

• Sometimes 1 + 1 = 0 (Two great features cancel each other out by creating clutter).

• Sometimes 1 + 1 = -5 (A new pricing tier causes a revolt that destroys your brand reputation).

The reason you feel like you are on a Hamster Wheel is that you are applying Linear Management to a Circular Reality.

You think: “If users are churning, we need to add more features to make them stay.”
The Reality: Adding more features increases complexity, which makes the product harder to learn, which increases churn.

The Cult of Velocity

When we don’t understand the system, we fall back on the only thing we can control: Speed.

We obsess over “Hamster Wheel Metrics”: Velocity, Cycle Time, Throughput. These measure how fast the wheel is spinning, but they do not measure if the cage is moving.

I‘ve worked with founders that are obsessed with shipping multiple features daily. With the assistance of AI, it was achieved. Everyone high-fived over the “Elite Team Performance.” Meanwhile, the Support team were in tears because every time the code changed, something breaks including documentation and the customers who hated sporadic change were furious.

The engine was perfect, but it was shaking the car apart.

From Feature Factory to System Architect

This series is an invitation to step off the wheel. To do that, you have to undergo a shift in identity.

You are probably currently operating as a Project Manager of Features.
Your question is: “When can we ship this?”

You need to become a System Architect of Outcomes.
Your question is: “What happens to the equilibrium of the system after we ship this?”

Now, you might be thinking: “But Jose, we can’t just stop shipping. We have burn rates. We have investors.”

You are right. We aren’t looking for Slowness; we are looking for Sustainable Pace.

The balance relies on understanding the difference between Motion and Progress.

• Linear Efficiency is measured by Velocity (how fast you run).

• System Efficiency is measured by Velocity minus Drag.

If you ship fast (High Velocity) but create bugs, confusion, and churn (High Drag), your net movement is zero.

Linear thinking is fast and satisfying in the short term. “We built the thing!” feels good.
Systems thinking feels slower initially. “If we build the thing, we might break the ecosystem,” is a buzzkill.

But here is the secret: Systems thinking is actually faster. By slowing down to clear the drag (technical debt, user confusion), the wheel stops spinning freely, and the cage finally starts to move.

The Monday Morning Reality Check

Let’s start small. Before you log into Slack next week, try this 10-minute audit.

Open your Jira or Linear history. Look at the last 5 Features you shipped. For each one, ask the “So What?” question.

1. The Promise: Why did we build it? (e.g., “To increase retention.”)

2. The Reality: Did it work? Do you have data to prove it? Or did you just ship it and move to the next ticket?

3. The Cost: What is the maintenance tax? Who is fixing the bugs for it today?

The Verdict:
If you find that 4 out of 5 features are “Shipped but Unverified” or “Shipped and Ignored,” you are on the Wheel.

Admit it. That is the first step.

Welcome to 2026. Let’s figure out how to open the cage.

That’s what my friend, a brilliant product manager, told me over drinks a while back. He wasn’t just tired; he was furious. He’d just quit a job he was once passionate about, and the story came tumbling out of him.

"We were building a monster, man," he said, leaning forward. "A soulless feature factory, and I couldn't stand by and watch the train go off the cliff."

It had all started so well, with the team on the ground, talking to real people and solving real problems. But then the call came down from above. The mandate shifted overnight. Discovery was dead. The new mission? Write a massive, sprawling, end-to-end requirements document for a product that didn't even exist yet.

He threw his hands up in the air. "We were guessing! Guessing at problems our customers might have years from now. I remember yelling in a meeting, 'This 'MVP' is already version 5.20.3!'"

He knew exactly where that train was heading: a burned-out, cynical team, a bloated and confusing product, and a sea of disappointed customers. His team was so obsessed with the flashy what that they were completely ignoring the foundational how.

His story hit me hard because it’s a truth that sits at the very core of the disconnect in our industry. It’s the chasm between product managers and their engineering counterparts. We see a list of features. They see a system. And until you learn to see the system, too, you’ll always be speaking a different language.

Forget Software. Let’s Cook.

To understand what your engineers see, let's forget about code and think about something more fundamental: making a perfect pot of Jollof rice.

If you’ve never had it, Jollof is a beloved West African one-pot meal. Making it isn't a single action; it's a system at play.

• Inputs: You gather your raw materials rice, fresh tomatoes and peppers for the base, onions, oil, spices, and heat from the stove.

• Processes: You execute a series of steps. You blend the base, fry it to develop its flavor, wash the rice, add it to the pot, and manage the heat to cook it through without it getting mushy.

• Outputs: You get your finished pot of Jollof rice. But you also get other outputs, like the incredible aroma that fills the kitchen and the steam rising from the pot.

  

This is a system full of dependencies and feedback loops. You can't cook the rice without water (a dependency). A great cook doesn't just follow a recipe blindly; they use feedback to guide the process. They taste the stew base for seasoning before adding the rice. They check the texture of the rice to see if it needs more water. The smell is another feedback loop it tells you if the rice is cooking well or starting to burn.

If the rice comes out mushy, you don't blame the rice. You think like a systems operator. Was there too much water (input)? Was the heat too high for too long (process)?

You understand that changing one part of the system affects the entire output.

From Jollof Rice to Your Product

Your digital product is no different. It’s a system of inputs, processes, and outputs.

• Inputs: User clicks, data from an API, keyboard entries, a webhook from another service.

• Processes: The "black box" of the backend. This is the business logic, the algorithms, and the data transformations that turn inputs into something useful.

• Outputs: A new screen loading in the UI, an email sent to a user, a record saved in the database, a response sent back to an API.

This is why the "simple feature" you requested can sometimes get a hesitant look from your tech lead. You're seeing the output ("we need a button that exports a CSV"). They are seeing the entire system.

They’re thinking: Where does the data for the CSV come from (input)? What process needs to run to gather and format it? Is that process so intensive it could slow down the whole system for other users? What are the dependencies?

When your engineers seem to be overcomplicating a "simple" request, they're often just doing their job: thinking about the system. They’re making sure the Jollof doesn't burn.

How Does This Impact Product Management?

So, how does seeing your product as a system actually change your day-to-day job? It’s a fundamental shift. You stop being a feature manager and start becoming a true product leader.

• Your prioritization changes. Instead of just asking, "What feature has the highest business value?" you start asking, "What part of our system, if improved, would unlock the most future value?" You might find yourself championing a technical debt sprint not as a chore, but as a strategic investment in the health of your product.

• You become a translator. You can now explain to stakeholders why a "simple" request has deep, system wide implications. You can articulate trade-offs with more confidence, building a bridge of understanding between the business goals and the technical reality.

• Your partnership with engineering deepens. You’re no longer just handing off requirements; you're co-creating solutions. You start asking questions like, "How can we evolve the system to achieve this customer outcome?" This is how you earn their trust and become the strategic partner your tech lead has always wanted.

This isn't just about sounding smarter in meetings. It's about making better decisions, building more resilient products, and transforming your relationship with the people who build them.

Someone, somewhere, told you that you're the "CEO of the product." You swallowed it hook, line, and sinker because it felt good. It was a shot of fake empowerment, a title that sounded important.

But it's a trap. And it's the reason you feel like an imposter in your own team.

That title crumbles the second you're in a room with an engineering team that doesn't report to you. Your real job isn't giving orders; it's earning trust. It's building influence.

It’s been a minute since I last wrote here. I hit pause because I needed to take a step back and take a peep into why so many product teams are struggling. To figure out what's missing, what's inadequate, and how we can build better products beyond the well crafted LinkedIn post.

The best teams I've ever seen run on a simple, powerful idea: a balanced partnership between a Product Manager (that's you), a Designer, and a Tech Lead. You bring the customer. The designer brings the user. The tech lead brings the reality of how to build the thing.

When that partnership clicks, it’s magic. But what happens when it doesn't?

You know the moment. The conversation shifts. The language changes. You start hearing about microservices, API contracts, and tech debt. And you start nodding, hoping no one asks for your opinion on the trade-offs.

That right there? That’s the gap. It’s the space between knowing what the user needs and understanding how it gets built.

My time away wasn't a vacation. It was a revelation. Closing this gap is the most important work we can do.

So, I'm back. And this is our project now: to forge that link, together.

Don’t worry, I’m not going to teach you how to code. I’m going to do something more important: teach you how to think like an engineer. We'll pull back the curtain and give you the vocabulary to not just follow along, but to contribute. To be the strategic partner your tech lead has always wanted.

Let's start here. I want to know what you've been nodding along to.

What's the one technical thing you're tired of pretending to understand?

Drop it in the comments. The real work starts now.

I remembered him telling me what he told both the design team and leadership, “Look, I told them straight up—design isn’t here to just ‘make things pretty.’ If we’re not influencing strategy, we’re failing the product.” And honestly, that hit me. Because he wasn’t wrong. Too often, designers are treated as execution support rather than strategic drivers of product success. And yet, the best product teams—the ones that build experiences people love—don’t just bolt on design at the end. They bake it in from the start.

Design Is Not Just About UI—It’s About Thinking

Tim Brown, in Change by Design, talks about how design isn’t a department, it’s a mindset. He writes:

“Design thinking is a discipline that uses the designer’s sensibility and methods to match people’s needs with what is technologically feasible and what a viable business strategy can convert into customer value and market opportunity.”

That right there? That’s the missing link in so many product teams.

Too many companies still think of design in narrow terms—as if it’s just about pushing pixels, refining UI, or making sure the typography looks nice. But real design isn’t about decoration—it’s about problem-solving. It’s about reducing friction, shaping user behavior, and aligning business goals with human psychology.

This is where Nir Eyal’s Hooked comes in. He emphasizes that:

“User experience designers are the unsung heroes of habit-forming technology.”

And yet, so many teams still treat them like afterthoughts.

Think about your own experience with apps and platforms. The ones that feel seamless, effortless, and intuitive? Those aren’t accidents. They’re the result of deeply intentional design decisions, often made long before the first screen was ever mocked up.

What Happens When Design Isn’t at the Table?

I won’t pretend that every product team out there ignores design, but I’ve seen enough of them sideline it in ways that are… let’s just say, counterproductive.

One time, I learnt from a product design team in a company where product managers would shape the roadmap, engineers would scope feasibility, and only after everything was locked in, the designers were brought in to make it “look good.” By then, the key decisions had already been made—sometimes in ways that made zero sense for the user experience.

The result?

• Confusing workflows – When design isn’t involved early, user flows often become complex and unintuitive, forcing users to take unnecessary steps or struggle to complete key actions. This leads to frustration, inefficiency, and a higher likelihood of drop-offs.

• Bloated, feature-heavy products – Without proper design input, teams tend to over-prioritize features instead of refining core functionality, resulting in products packed with unnecessary elements that overwhelm users rather than providing real value.

• Users bouncing because nothing felt intuitive – If a product’s navigation, interactions, or layout don’t align with natural user behavior, people quickly lose patience and abandon it in favor of something simpler and easier to use.

And here’s the frustrating part—it wasn’t because the designers weren’t talented. It was because they weren’t brought in when it mattered most.

Tim Brown nails this in Change by Design when he says:

“Too many organizations are structured to accommodate efficiency rather than innovation.”

Meaning? If your design team is only operating within the rigid boundaries of “what’s already been decided”, you’re setting yourself up for mediocre experiences.

How Design Should Operate in a Product Team

The best teams don’t separate design from strategy—they embed it.

In a solid product operating model:

1. Designers work alongside PMs and engineers from day one. Not after strategy is set, not after dev starts, but before any big decisions are made.

2. Designers are not just advocates for “good UI” but for usability, accessibility, and behavior change. (Again, shoutout to Hooked—if you’re designing a product that needs engagement, you’d better be talking to your design team early.)

3. Design isn’t just about execution—it’s about shaping business outcomes. If designers are only measured on how fast they push screens, something is wrong.

Nir Eyal puts it this way:

“Products that successfully create habits benefit from designers who understand their users' behaviors better than the users themselves.”

This means that design isn’t just about aesthetics—it’s about how people interact with your product, how they experience value, and how they build habits around it.

Making Design an Equal Partner in Product Success

The senior designer I mentioned at the beginning? He didn’t just complain about design being undervalued. He actively worked to change the dynamic. He started looping himself into meetings that weren’t “design-related.” He challenged leadership on why designers weren’t part of early discovery. He worked to reshape the company’s operating model so that design had a voice at the decision-making table.

And that’s really the takeaway here.

If your product operating model treats design as a support function rather than a strategic driver, your product will never reach its full potential. Design needs to be in the mix before the roadmap is finalized, before features are scoped, before decisions become irreversible.

Because at the end of the day, design is not just about making things pretty—it’s about making products work for the people who use them. And that? That’s the real measure of product success.

In the first part of this article, I discussed about enterprise A that have their product teams buried under sales, forced to chase every high-value customer request like a waiter at a fancy restaurant. I also shared about a specifict startup where the CEO wakes up, has a lightbulb moment, and before anyone blinks, the engineers are scrambling to build it—no research, no validation, just pure instinct. And then there’s the classic setup where PMs act like project managers, engineers are treated like order-takers, and designers are invited to the party last minute to “make it look good.”

But let’s be real—this isn’t how great products are built.

At the heart of every successful product team is the Product Trio, or what I like to call the Triplets—Product Managers, Engineering Managers, and Designers. They’re not a chain of command. They’re not a hierarchy. They are the “Product Trinity” co-owners of the product, each bringing a different strength to the table.

Let’s Talk About the Reality of the Trio

For some reason, a lot of companies still think of the Product Manager as the “boss” of the team. But a good PM isn’t a CEO of the product (and honestly, can we retire that phrase already?). They don’t walk into a room dictating what gets built. Their job isn’t to tell engineers and designers what to do—it’s to define the problem space, ensure alignment, and facilitate smart decisions.

The Engineering Manager isn’t just responsible for execution. If all they’re doing is making sure Jira tickets get closed, something’s broken. They are technical strategists, not just builders. They’re there to ask: How do we scale this? What are the trade-offs? Is there a better way? A strong engineering lead doesn’t just build—they shape the solution.

And then there’s the Designer—often misunderstood, sometimes tragically underutilized. A lot of teams still bring in designers at the end, treating them like decorators. But design isn’t just about how something looks—it’s about how it works. A great designer ensures the product isn’t just functional but also usable, intuitive, and frictionless. They ask, Does this experience make sense? How can we simplify this?

When these three roles are treated as equal partners, you get magic. The best product decisions don’t come from one person leading and others following—they come from the tension, debate, and collaboration between these three perspectives.

Why Trying to Establish a Hierarchy is a Huge Mistake

The minute you try to put one of these roles “above” the others, you’re asking for trouble.

If a PM dominates, engineers disengage and start treating their work like a ticket system. If an Engineering Manager calls all the shots, technical decisions can override user needs. If design is sidelined, you end up with a feature-heavy, clunky product that no one wants to use.

Great teams don’t operate on hierarchy—they operate on trust and shared accountability.

In high-performing teams, the Trio works together like this:

• PMs own the “why.” Why is this problem important? Why should we prioritize this?

• EMs own the “how.” How do we build this in a scalable and efficient way?

• Designers own the “what” and “experience.” What should the product feel like? What’s the best way for users to interact with it?

They push back on each other. They challenge each other’s assumptions. They make sure the end result isn’t just built, but built well, for the right reasons, with the right experience in mind.

What Happens When the Trio is Misaligned?

I’ve seen what happens when this balance is off, and it’s not pretty.

When PMs and Engineers don’t align, roadmaps turn into wish lists. The product backlog grows endlessly, engineering debt piles up, and execution slows down.

When Design is an afterthought, you get products that function technically but frustrate users at every turn. The UI feels clunky, the onboarding sucks, and nobody knows why adoption is low.

When the Trio falls into feature factory mode, the team focuses on shipping, shipping, shipping—without asking if any of it actually makes a difference. The measure of success isn’t impact; it’s output. And that’s how you get products filled with features that no one really needed.

Lessons I learnt from the book “Team Topologies”

One of the biggest insights from the book Team Topologies by Mathew Skelpton and Manuel Pais is that teams work best when they are structured around value streams—not traditional department lines​.

This means:

• The Trio must be embedded within a single team, not split across different departments. PMs, EMs, and Designers need to be working together daily—not just meeting for roadmap discussions every quarter.

• They should co-own decisions from the start. This isn’t about PMs coming up with a plan and handing it off to engineers and designers—it’s about collaborative decision-making.

• The Trio should focus on outcomes, not just output. This means measuring success by how much value they create—not how many tickets they close.

How to Build a Stronger Product Trio

If your Trio isn’t working the way it should, here are a few things to fix it:

1. Stop treating PMs as the “boss.” Instead, encourage shared ownership.

   This is where so many teams fall into the trap of corporate hierarchy creeping into product teams. I can’t count how many times I’ve seen companies treat PMs like mini-CEOs, sitting at the top of a pyramid, handing down instructions for engineers and designers to follow. And every time that happens, the team starts to break down.

   When PMs act as decision dictators instead of facilitators, you end up with:

   1. Engineers who stop challenging ideas and just build whatever they’re told (even if it doesn’t make sense).

   2. Designers who aren’t brought in early enough, so they’re left trying to fix broken experiences at the last minute.

   3. A culture of compliance instead of collaboration—which means worse products, slower execution, and way more frustration.

   A healthy product team distributes ownership. It’s not about who has final say—it’s about who brings what to the table. The PM owns the why, the Engineer owns the how, and the Designer owns the what. But the only way that works is if decisions happen as a team, not in a vacuum.

   If your PM is the only one driving the roadmap while engineers and designers are just "brought in later", you’ve already lost. Break the hierarchy, start co-owning decisions, and trust that your engineers and designers have just as much of a say as your PMs

1. Make sure incentives are aligned, or the Trio will pull in different directions.

   Here’s a scenario I see way too often:

   1. The Product Manager is measured on business impact (e.g., revenue, retention, activation rates).

   2. The Engineering Manager is measured on delivery speed, uptime, and system performance.

   3. The Designer is measured on UI improvements, usability scores, or subjective aesthetic appeal.

   At first glance, this seems fine. But if you think about it, these are totally different goals that push people in opposite directions.

   A PM might push for a highly experimental feature to test user engagement, but the Engineering Manager might resist because it could introduce technical debt and instability. Meanwhile, the Designer might be focused on making a beautiful, intuitive experience, while the Engineer is saying, "We don’t have time for this level of detail right now."

   This tension isn’t just frustrating—it slows the team down.

   The fix? Make sure all three roles are aligned on a shared set of success metrics. That means:

   1. PMs, EMs, and Designers should all care about product success, not just their individual functions.

   2. If the PM is rewarded for business success, but the Engineer is rewarded for shipping fast, you’ve already created a conflict.

   3. The Trio should set shared goals together—for example, instead of measuring each role separately, tie everyone to something like "Increase activation rate by 15%" or "Improve conversion by 20%". That way, everyone is working toward the same outcome instead of optimizing for their own KPIs.

2. Prioritize deep collaboration: If the Trio isn’t working together from day one, it’s too late.

Let’s be real—a lot of teams still work in silos. I’ve worked with teams where:

• The PM creates the roadmap alone, then presents it to engineering and design.

• The engineers get requirements late, build what they’re told, and don’t feel like they’re part of the decision-making.

• The designers are only looped in at the end, which means they’re forced to “paint over” bad UX instead of fixing it at the core.

When teams work like this, they’re always playing catch-up. Designers are fixing problems they didn’t get a say in, engineers are questioning why they’re building certain things, and the PM is stressed trying to manage it all.

Instead, the Trio should be working together from the very start of a product decision. This means:

• PMs, Engineers, and Designers should all be part of discovery—user research, customer feedback, and strategic discussions.

• Engineers should be giving input on what’s feasible and scalable before a feature gets planned.

• Designers should be part of shaping the problem space instead of just designing screens after decisions are made.

This isn’t about meetings for the sake of meetings—it’s about making sure decisions are made together, not handed down in a sequence.

The Product Trio isn’t a reporting structure—it’s a partnership. If you’re still running things like a command-and-control system, you’re slowing your team down.

Great products aren’t built by one person calling the shots—they’re built by a group of equals pushing each other to make the best decisions possible. If your team is stuck in a top-down approach, it’s time to rethink how the Trio operates.

Because when the Product Manager, Engineering Manager, and Designer truly work as partners, everyone wins—your team, your product, and most importantly, your users.

Take this one company and call it Company A. Big brand. Huge name, known to own dozens of products than their competitions. They talk a big game about being “product-led,” but their org structure? An absolute trainwreck. A recent restructure got their product team—at least, what was meant to be a product team—tucked under Sales. Yep, Sales. The entire product team reports directly to the Sales Boss, who hasn’t just have them chasing every customer request like a dog after a tennis ball, also sets a sales target for each and every product person. While fingers are pointed to the the engineering team, truthfully, these engineers are beyond frustrated, building random features that don’t connect to any real strategy. The product managers have become glorified account managers, trying to keep the big boss happy instead of, you know, actually thinking about long-term product growth. And then leadership in the next few months will be sitting around wondering why they’re struggling to innovate.

And then you’ve got the other extreme Company B—my dear startup where the CEO wakes up with a “brilliant” idea, storms into the office (or Teams group, let’s be real), and tells the engineers to drop everything to build it. No research. No validation. Just pure CEO gut feeling. In Nigeria we call it “Oga Driven Development”(ODD) the synonyms for HiPPO (Highest Paid Person Opinion) in the product Zoo. And of course, the product managers are expected to “make it happen,” which is corporate speak for write some PRDs and pretend this was all part of the plan. Maybe this approach works if you’re some once-in-a-generation visionary, but for the rest of us? It’s a disaster.

Org Charts Don’t Build Great Products—Team Structures Do

There’s this weird myth that if you hire enough product managers, designers, and engineers, poof, you become a product-driven company. Spoiler: you don’t. I’ve lost count of how many PMs have vented to me about feeling like glorified project managers — Last weekend, it took myself and a couple of other product people a few human hours to explain to someone why product managers are not project managers (it wasn’t the fela’s fault, it’s because of how the organisation have been running product) — stuck pushing Jira tickets instead of solving actual problems. And engineers? Half the time, they don’t even know why they’re building what they’re building. They just get a spec and are told to “make it happen.” No context. No ownership. No connection to the user. Just a feature factory grinding out things no one asked for.

And every time leadership sees things stalling, their solution? More process.
"We just need better execution!"
No. You need better decisions. Because if PMs aren’t empowered to make real calls, and engineers aren’t part of shaping solutions, it doesn’t matter how smooth your sprints are. You’re still shipping garbage.

The Core Team: Three Siblings, Not a Hierarchy

Forget neat little reporting structures in PowerPoint decks—real product teams don’t work like that. The best ones aren’t built on rigid hierarchies; they’re built on partnerships. A PM, an Engineering Lead, and a Designer, working as equals. Not a PM calling all the shots while the others execute. Not an engineer acting as a passive builder. Real collaboration.

I was added to this WhatsApp group with a bunch of product folks in a major enterprise and their senior leadership, and there’s this one guy—senior leadership at this major enterprise—who constantly complains about how their competitors “have more features.”
"Look at what Competitor X just launched! Why don’t we have that?"
And just like that, his PMs are scrambling to copy whatever feature he just saw or even start building out a brand new product on this same premise. No conversation about whether it even makes sense for their customers. No thought about whether it aligns with their strategy. Just blind, panic-driven execution. And this is what happens when PMs aren’t given the right to critical thinking.

And engineers? Oh man. I’ve seen way too many teams treat engineers like human API endpoints.
"Here’s the spec. Just build it."
That’s not engineering. That’s assembly-line work. A great engineering lead isn’t just someone who writes clean code. They’re a technical partner—someone who thinks about feasibility, scalability, and why something should (or shouldn’t) be built. They should be challenging ideas, proposing better solutions, and helping shape the roadmap. Not just waiting for tasks to be assigned.

Same goes for design. People love to quote Steve Jobs on design, but half of them don’t actually understand what he meant.

"Design is how it works."

Yet, somehow, designers are still treated like the “make it pretty” team. No. Design isn’t just UI. It’s the entire experience—information architecture, user flows, interaction patterns, system thinking. Half of great design is invisible to the user, but if it’s done wrong, they feel it immediately. A great designer isn’t just decorating the product—they’re making sure it actually makes sense for real people.

The Extended Team: The “Cousins” Who Enable, Not Block

Beyond this core trio, you’ve got the supporting roles—the cousins of the product team. Super valuable. But the moment they start creating roadblocks instead of momentum, you’ve got a problem.

• Data Analysts & Data Scientists – Helping teams make decisions based on actual insights, not gut feelings.

• User Researchers – Making sure teams aren’t just guessing what users want, but actually validating it.

• QA Engineers – Not just gatekeepers, but integrated into the process so quality isn’t a last-minute panic.

• Product Marketing Managers (PMMs) – Not just launch managers, but bridging the gap between product and market fit.

And let’s be real—some roles just shouldn’t exist in empowered teams. Case in point: Product Owners. I know, some people swear by them, but let’s be honest. Splitting discovery and delivery into two separate jobs is a recipe for dysfunction. When PMs focus only on “strategy” and POs are left to “execute,” teams end up shipping things no one actually needs.

The Best Product Teams Don’t Wait for Instructions

A great product team doesn’t sit around waiting for a backlog to be handed to them. They figure it out. They push back when something doesn’t make sense. They pivot when things aren’t working. And they measure success not by how many features they ship, but by whether what they built actually mattered.

But for that to happen, they need:

• Ownership – Real accountability, not just marching orders.

• Context – Understanding the why, not just the what.

• The ability to challenge and shape ideas – Not just follow directives from the top.

When those elements are missing, teams default to safe, incremental shipping. No big bets. No meaningful impact. Just endless features piling up in Jira that no one actually cares about.

Most companies don’t have a product problem. They have a team structure problem. You can’t expect groundbreaking products to come out of teams that are just executing top-down orders. If PMs don’t own their problems, if engineers aren’t part of decision-making, if designers are sidelined, you don’t have a product team—you have a feature factory.

So yeah. If you want great products, fix the team first. Not just by hiring smart people, but by actually giving them the space, trust, and autonomy to do what they were hired to do. Otherwise? You’ll keep playing the same broken game—frustrated teams, meaningless features, and a never-ending backlog of things no one actually asked for.

Take, for example, a recruiter reaching out to me on LinkedIn, asking for referrals for a Senior Product Manager role. Upon reviewing the job description, it was clear that the position resembled more of a Vice President of Product role than an actual senior product manager. In another case, a startup hiring an Associate Product Manager (APM) - They called it “Product Management Trainee” to independently drive an entire product without any senior Product Manager to guide or mentor them—a setup bound to fail both the APM and the product.

This confusion about roles isn’t just a matter of titles. It impacts how product professionals grow in their careers and how organizations support their development. Building a clear and structured product career path ensures individuals know how to progress, what competencies to develop, and how their roles fit into the bigger picture of delivering user and business value.

In this article, we’ll break down the typical product career path, the competencies required at each stage, and how individuals can grow into more senior roles while driving success.

The Controversial Product Owner Title

Before diving into the Associate Product Manager role, it’s essential to address the Product Owner title—a frequent point of confusion. In many organizations, the Product Owner and Product Manager roles are treated as separate entities, but this split can often create more problems than it solves.

Why the Product Owner Role Is Problematic

In an effective product team structure, it’s counterintuitive to separate the person responsible for discovery from the person responsible for delivery. Yet, this is the common division of labor:

• Product Manager: Focuses on customer and business needs, strategy, and user research.

• Product Owner: Engages the engineering team and handles execution.

This setup creates a disconnect that undermines the principles of an empowered team. Discovery and delivery are intertwined processes, not separate ones. When you split responsibilities between a Product Manager and a Product Owner, you risk:

1. Fragmented Decision-Making: A lack of alignment between strategy and execution.

2. Inefficiency: Engineers working without a clear understanding of the problem they’re solving.

3. Disempowerment: Teams feeling disconnected from the larger purpose of their work.

The Ideal Approach

In empowered teams, the Product Manager is responsible for both discovery and delivery. They are the central figure connecting user needs, business goals, and engineering execution. By keeping these responsibilities unified, the team can align around shared goals and deliver meaningful outcomes.

Associate Product Manager

The Associate Product Manager (APM) role is a foundational entry point into product management, designed to help individuals learn the fundamentals while contributing meaningfully to their teams. APMs handle smaller projects or specific features within larger initiatives, ensuring these efforts address user needs effectively. They engage in tasks such as understanding customer pain points, analyzing market trends, writing user stories, and collaborating with cross-functional teams to deliver solutions. Far from owning entire products, APMs work under the guidance of experienced Product Managers who mentor and prepare them for more significant responsibilities.

Success in this role hinges on competencies like execution, curiosity, collaboration, data-driven thinking, and problem-solving. APMs are not just tasked with delivering features but are also encouraged to learn strategic thinking through mentorship. This guidance ensures they understand the broader context of their work while gaining exposure to the complexities of product management. In an empowered team, APMs contribute by managing specific deliverables, freeing senior members to focus on high-level strategy.

When structured effectively, the APM role becomes an essential component of a strong product team, serving as a pipeline for future product leaders. Organizations that avoid overloading APMs with responsibilities beyond their level, while providing clear guidance and opportunities to grow, set both the individual and the team up for long-term success.

Product Manager

A Product Manager (PM) is the linchpin of a product team, balancing user needs, business goals, and technical feasibility to deliver impactful solutions. They work with designers and engineers to define and execute features aligned with the broader product vision. While their responsibilities often center on shorter-term deliverables, such as managing roadmaps and feature execution, their role extends beyond operational tasks. A PM must strategically shape the vision for features while tactically ensuring smooth delivery, avoiding the pitfall of becoming overly focused on day-to-day execution at the expense of long-term strategy.

Effective PMs bridge the gap between tactical execution and strategic vision, ensuring alignment across teams and feeding insights into broader product strategies. Splitting responsibilities between a Product Manager and a Product Owner can create disconnection and inefficiencies, as discovery and delivery are inseparable. Consolidating these roles under the Product Manager title enables professionals to develop both strategic and operational expertise, creating meaningful career growth opportunities and ensuring cohesive product development.

Senior Product Manager (SPM)

A Senior Product Manager (SPM) oversees more complex products or broader product scopes, representing the pinnacle of the individual contributor track in product management. Unlike roles involving people management, the SPM focuses entirely on solving challenging product problems and driving innovation. They must balance strategic responsibilities, like defining long-term product direction, with operational execution, ensuring smooth delivery of impactful solutions. This role is especially suited for those who thrive on tackling difficult problems and charting new territory within their organization.

SPMs are critical to a company’s success, as they operate with greater independence and often lay the groundwork for new product lines or innovations. Their entrepreneurial mindset and ability to align product initiatives with business goals make them indispensable. Much like an architect in software development, the SPM’s role involves creating the structure for product scalability and success rather than managing others. With their unique blend of strategic vision and operational execution, Senior Product Managers help organizations grow by focusing on impactful, forward-looking initiatives.

Director of Product

A Director of Product is a critical role in scaling organizations, typically found in larger companies where the product scope and team size demand additional layers of leadership. As a company grows, the Head of Product may become overburdened by the sheer number of direct reports and the increasing complexity of managing multiple products or features. The Director of Product steps in to provide the strategic alignment and operational efficiency needed to connect their product group back to the overarching portfolio vision.

This role marks the first level of people management in the product career path. Directors oversee a group of Product Managers, often aligned around a specific product line or portfolio. They are responsible for crafting the strategic roadmap, typically with a year-long time horizon, while ensuring that their team is operationally effective. By aligning Product Managers around clear goals and priorities, the Director ensures that the team focuses on the most impactful initiatives, driving both business outcomes and team performance. This balance of strategic oversight and operational coordination makes the Director of Product a vital architect in scaling successful product organizations.

VP of Product

The Vice President of Product is a key executive role that oversees the strategy and operations for an entire product line, bridging company goals with the growth of their product portfolio. This position involves setting the vision and goals for the overall product, informed by insights and data from their teams. In large enterprises, VPs are responsible not only for the delivery of product features but also for the financial success of their product lines. Alignment across all VPs within a company is critical to ensuring a cohesive and successful portfolio of products.

In smaller companies, the VP of Product is often the highest product role, overseeing one or a few product lines. They may take on more tactical responsibilities to ensure the product grows and launches effectively. However, a successful VP must primarily focus on strategy, driving growth plans and aligning product efforts with broader business objectives. To scale effectively, they hire leaders to manage tactical and operational tasks, allowing them to focus on long-term innovation and organizational alignment. This strategic focus positions them for potential growth into the Chief Product Officer role, which is predominantly strategic.

Chief Product Officer (CPO)

The Chief Product Officer (CPO) is a transformative executive role responsible for overseeing an organization’s entire product portfolio. As companies grow, expand into new markets, or manage increasingly complex product lines, the need for a dedicated leader to align product strategy with business objectives becomes essential. The CPO ensures that all products contribute to the company’s vision and financial goals, making them instrumental in scaling product teams and fostering cross-functional alignment. Unlike VPs of Product, who focus on individual product lines, the CPO operates at a macro level, crafting strategies that drive portfolio-wide success and long-term business growth.

The CPO also serves as the primary advocate for product strategy at the executive level, frequently engaging with the board of directors and other C-suite leaders. This requires translating product decisions and outcomes into financial and operational terms that resonate across departments. By leveraging strong communication skills, the CPO aligns leadership around a shared vision and fosters organizational cohesion. Empathy and resilience are vital for navigating the challenges of cross-departmental collaboration, while the ability to inspire confidence enables them to unify teams under a common purpose. Their strategic influence is rooted in building trust and effectively managing competing priorities across a growing organization.

Beyond aligning the organization, the CPO is relentlessly focused on data-driven decision-making and market responsiveness. They monitor the performance of the product portfolio, identifying opportunities for innovation and improvement while holding teams accountable for measurable results. In a rapidly evolving market, the CPO’s ability to adapt strategies ensures the organization stays competitive. As the pinnacle of the product career path, the CPO sets the standard for creating a product-led culture, driving innovation, and positioning the company for sustained growth and market leadership.

Core Competencies That Drive Product Career Growth

Success in a product management career is built on a foundation of core competencies that remain relevant at every stage, regardless of role or level of seniority. These competencies not only enable effective performance but also position individuals for continuous growth and leadership opportunities.

• Collaboration is essential for working seamlessly with cross-functional teams, including designers, engineers, and stakeholders. Building strong partnerships ensures alignment and fosters a shared sense of purpose, enabling teams to deliver impactful results.

• Communication is the backbone of product management. The ability to clearly articulate ideas, strategies, and decisions to diverse audiences—ranging from engineering teams to executive stakeholders—is critical for gaining buy-in and maintaining alignment.

• Adaptability is vital in navigating the dynamic nature of product development. Whether responding to shifting market trends, user needs, or organizational priorities, successful product managers remain flexible and proactive in their approach.

• Outcome Orientation ensures a focus on delivering measurable results rather than getting bogged down by tasks. Prioritizing business and user impact allows product professionals to consistently drive value and achieve strategic goals.

• Empathy underpins every aspect of product management, from understanding user needs to fostering healthy team dynamics. By seeing through the lens of customers and colleagues alike, product managers can build solutions that truly resonate and inspire collaboration.

Avoiding Career Path Pitfalls

Navigating a product management career comes with its challenges, many of which stem from misaligned expectations and organizational practices. One common pitfall is misaligned titles, where roles do not match their responsibilities. For instance, hiring for a Senior Product Manager but expecting them to take on the strategic responsibilities of a VP creates confusion and sets the individual up for failure. Clear alignment between job titles and responsibilities is essential for both the individual and the organization to thrive.

Another challenge is overloading junior roles. Associate Product Managers (APMs) and Product Managers (PMs) are often tasked with responsibilities beyond their scope, such as leading major product initiatives without sufficient support. This not only risks burnout but also hinders the development of foundational skills critical for their growth. Organizations must ensure these roles are given appropriate challenges and guidance, creating an environment where learning can flourish.

A significant yet often overlooked factor in product career growth is the lack of mentorship. Every stage of the product career path benefits from mentorship and coaching, providing the guidance necessary to navigate challenges and build strategic thinking. A mentorship-rich environment not only accelerates individual growth but also ensures the organization nurtures a strong pipeline of future leaders.

Conclusion: Building a Meaningful Product Career

A product management career is more than a ladder to climb—it’s a journey of growth, learning, and delivering increasing value. Understanding the unique responsibilities and competencies required at each stage empowers professionals to chart a clear path to success while enabling organizations to structure roles that foster growth and impact.

Whether beginning as an APM or aspiring to become a CPO, success lies in consistently aligning efforts with user needs and business goals. For organizations, the key to building meaningful product careers is offering well-defined roles, appropriate support, and opportunities for mentorship. When an organisation cultivates this balance, both individuals and teams will thrive, creating products that matter while advancing the field of product management.

This distinction between treating products as marathons rather than sprints isn’t just theoretical—it’s a practical lens through which to examine how teams can align around user needs, iterate purposefully, and deliver lasting impact. Reflecting on the discussions from my previous articles—about the costs of building products, the challenges of over-engineered processes, and the pitfalls of middle layers—this piece dives deeper into the critical role of clarity and focus in enabling empowered, outcome-driven product teams. As we begin 2025, it’s a timely moment to revisit how leaders can nurture these qualities for long-term success.

Fragmentation Pitfall

When teams operate without clarity, they inadvertently slip into fragmentation — This is when products does not align with business goals and/or user needs. Features are developed in silos, often disconnected from user needs or overarching business objectives. Engineers may overcomplicate a feature with unnecessary elements, while designers focus on aesthetics that users might not even notice. The result is a product riddled with competing priorities, misaligned efforts, and, ultimately, a diminished ability to deliver meaningful outcomes.

Breaking this cycle requires intentional leadership that fosters trust and empowers teams to challenge the status quo. In successful teams, honest conversations about what’s working—and what isn’t—happen regularly, enabling everyone to align around a shared purpose. This alignment is anchored by a compelling product vision. Teams rallied around such a vision don’t just build features; they craft solutions that resonate deeply with users, leveraging outcome-driven goals to harmonize their diverse talents and efforts.

The Power of Vision in Empowering Teams

The power of a clear vision lies in its ability to unify diverse teams under a shared purpose. When everyone understands not just what they’re building but why it matters, the entire organization moves with a sense of alignment and urgency. This clarity isn’t just about crafting an inspiring vision statement—it’s about connecting the product’s direction to real user needs and measurable outcomes. For instance, revisiting user feedback on a product revealed that while certain features were heavily used, they didn’t align with the overarching vision. This disconnect prompted a recalibration, ensuring that our efforts were focused on delivering genuine value to users.

A well-defined vision becomes a compass, helping teams make faster, more informed decisions. Instead of endless debates over priorities, a clear vision simplifies the process: Does this decision serve the user and align with our goals? When measurable outcomes replace vague aspirations like "improve usability" with tangible targets such as "reduce transaction time by 20%," focus naturally follows. Teams can confidently align their efforts, knowing that each step directly contributes to solving meaningful problems.

This level of clarity also fosters empowerment within teams. When engineers, designers, and product managers clearly see how their contributions fit into the broader picture, they work with a greater sense of ownership and purpose. The result isn’t just faster delivery; it’s the creation of products that resonate deeply with users while driving the organization forward. Vision, when paired with focused execution, becomes the foundation for building products that are not only impactful but also enduring.

How Product Leaders can drivem Focus

Product leaders are the architects of clarity and focus, playing a pivotal role in shaping how teams navigate the complexities of product development. Their responsibility isn’t just to craft an inspiring vision but to translate that vision into clear, actionable roadmaps that align every team member around shared goals. This requires more than strategic thinking; it demands a continuous commitment to maintaining alignment through every iteration, ensuring that the team’s energy remains centered on solving user problems.

Leadership in this context calls for a delicate balance—engaging deeply with the team while directly addressing misalignments. Imagine a roadmap review where a designer proposes an idea that, while creative, doesn’t solve a pressing user need. An effective product leader steps in, not to dismiss the idea outright but to guide the conversation back to the user’s pain points and the product’s broader objectives. By fostering a culture of honest yet constructive dialogue, leaders empower their teams to stay focused without stifling creativity.

Processes, too, must reflect this ethos of clarity. While frameworks and methodologies can provide structure, they should never overwhelm the team with unnecessary complexity. Product leaders must advocate for lightweight processes that prioritize decision-making and encourage swift iterations. When processes are streamlined to focus on outcomes rather than outputs, teams are free to innovate, adapt, and deliver meaningful solutions with agility. True leadership lies in building systems that enhance creativity and collaboration, not ones that slow them down.

Building Alignment

Building alignment within teams requires more than processes and protocols—it demands trust, openness, and a shared understanding of purpose. I know of a team where alignment was a constant struggle. Engineering, design, and product teams seemed to be working toward different goals, each with valid priorities but no cohesive direction. To address this, they initiated an open dialogue, creating a space where everyone could express concerns without fear of blame. The atmosphere shifted as trust grew, and deeper issues surfaced—ones that had previously gone unspoken but were critical to the product’s success.

A turning point came when they began reframing discussions through the lens of user stories. This subtle shift moved conversations away from technical debates or subjective design opinions and toward a focus on how their choices would impact users. Engineers became more empathetic, viewing their work through the eyes of the people using the product. Designers transitioned from emphasizing aesthetics to prioritizing usability. Anchoring their alignment efforts to the user’s perspective, helped them deliver an iteration that not only met expectations but exceeded them, transforming a fragmented team into a unified force driven by a clear, shared vision.

Purposeful Agility

True agility isn’t about speed; it’s about responsiveness and intentionality. It’s the ability to adapt swiftly to user feedback without losing sight of the broader vision. Too often, agility is reduced to a checklist of rituals, detached from meaningful outcomes. As I’ve discussed previously, unnecessary complexity and over-engineered processes can derail teams, turning flexibility into bureaucracy. The lesson remains clear: simplify to amplify. Agile practices only deliver real value when they are tethered to clarity and purpose, empowering teams to make decisions and take actions that resonate with user needs and long-term goals. For product leaders, the challenge is to ensure that processes enable progress, not slow it down, by fostering an environment where collaboration and experimentation thrive within a unified vision..

Products are marathons, not sprints. They require vision, alignment, and relentless focus on solving real problems for users. The next step in this journey is exploring how teams can nurture clarity while embracing the challenges of collaboration—a topic we’ll dive deeper into in the next episode. Stay tuned.

Here’s to building meaningful, impactful products in 2025!

Happy New Year!
As we kick off 2025, I want to express my gratitude to every one of you—readers, subscribers, and supporters—who have engaged with my articles over the past year. Your feedback, insights, and shared experiences have made this journey incredibly rewarding. To those marking the holidays, Merry Christmas, and to everyone, here’s to a year filled with impactful product building and innovation.

A Moment of Reflection

As I wrapped up my last articles for 2024, my mind began to shift toward the new year. What could be done differently, across multiple fronts, to build better products, deliver value faster, and meet the dynamic user needs? While reflecting on this, I found myself revisiting a conversation from earlier last year—one that had prompted me to write the last sets of articles about the cost of using a product, the cost of building a product, and the cost of middlemen.

In that conversation, I noticed a recurring pattern among many participants: they approached product development as though it were project execution. That realization became a pivotal moment for me. This misconception—the tendency to treat products like projects—sets the stage for a fundamental misalignment in goals, strategies, and outcomes.

Where one approach prioritizes outputs, the other focuses on outcomes. Where one is concerned with finishing a sprint, the other is about meeting user needs. These differences don’t just affect delivery timelines—they shape the entire process, from ideation to execution, and ultimately define the value delivered to customers.

The Project Mentality: Running Sprints Toward Short-Term Goals

The traditional project-based mindset is deeply ingrained in many organizations. Projects are scoped with clear deliverables, timelines, and milestones. Once the final task is completed, the project is deemed successful, and the team moves on. This approach works perfectly for finite initiatives, like building a bridge, organizing an event, or deploying a patch.

However, when applied to products, this mindset becomes limiting. Products are not one-and-done—they’re ongoing relationships with users. Treating them as projects turns development into a series of disconnected sprints, where the primary focus is checking off tasks rather than solving real problems.

In such setups, teams are often celebrated for shipping features rather than evaluating whether those features addressed customer pain points. This output-first mentality can lead to missed opportunities for innovation, customer dissatisfaction, and products that fail to evolve with user needs.

The Product Mindset: Running Marathons Toward Long-Term Value

In contrast, a product mindset views development as a marathon—a long-term endeavor that requires focus, adaptability, and continuous iteration. Products aren’t measured by what’s delivered in a single sprint but by the cumulative impact they have over time.

Operating with a product mindset means:

• Delivering Outcomes, Not Just Outputs: Success is defined by whether the product solves a meaningful user problem, improves satisfaction, or drives engagement—not simply by meeting deadlines or shipping features.

• Embracing Iteration: Products evolve with user feedback, market changes, and technological advancements. There’s no definitive "end"; the work is ongoing, guided by a commitment to continuous improvement.

• Aligning with Strategy: Products are built with long-term organizational goals in mind. Every decision ties back to the bigger picture, ensuring that user needs and business objectives move in harmony.

This shift in perspective isn’t easy—it requires cultural change, leadership buy-in, and a commitment to user-centricity. But the rewards are worth it: stronger products, deeper customer loyalty, and greater alignment across teams.

Reflecting on Missed Opportunities

In the conversation that sparked this reflection, I recall asking why delivery timelines were consistently lagging. The answers revolved around process perfection, approvals, and a heavy reliance on roles and frameworks. While these seemed necessary on paper, they ultimately led to inefficiency and delays. Even when opportunities were recognized early, the organization moved too slowly to act.

The problem wasn’t a lack of talent or ideas—it was the project mindset driving the approach. This mindset created a focus on execution over exploration, deadlines over discovery, and structure over adaptability. The result? Outputs were delivered, but outcomes remained elusive.

Breaking Free from the Build Trap

This isn’t a unique story. Many organizations fall into the trap, where the focus shifts to delivering features rather than delivering value. Escaping this trap requires rethinking the way we approach product development:

• Focus on Outcomes: Ask not what was delivered but whether it made a difference. Did the feature reduce churn? Improve satisfaction? Drive engagement? These questions must guide every decision.

• Empower Teams to Iterate: Build processes that prioritize agility and learning. Experimentation and adaptability should be celebrated, not hindered by unnecessary layers of approval or documentation.

• Create Space for Discovery: Products thrive when teams are given time to explore user needs, validate assumptions, and refine solutions. Rushing to deliver often sacrifices these critical steps.

Agility: The Foundation of the Product Mindset

True agility isn’t about frameworks or buzzwords—it’s about adaptability. Agile organizations empower teams to collaborate directly with users, experiment with solutions, and pivot quickly based on feedback.

In my article on the cost of building a product, I discussed how over-engineered processes often masquerade as agility, creating more friction than flexibility. Real agility removes barriers, fosters collaboration, and keeps teams focused on solving user problems rather than navigating bureaucracy.

From Projects to Products: A Practical Example

Consider a payment gateway. A project-based approach might involve deploying the gateway, customizing features, and marking the task "complete" upon launch. The team would move on to the next project, leaving the gateway stagnant.

A product-centric approach, however, sees the gateway as a living entity. The team gathers feedback from users, identifies pain points like transaction speed or interface clarity, and iterates based on these insights. Success isn’t the launch—it’s the gateway’s ability to continuously render value (grow adoption, reduce churn, and empower businesses).

Moving Forward: Building with Purpose

As we step into 2025, let’s challenge ourselves to rethink how we approach product development. Great products aren’t built by sprinting toward deadlines—they’re nurtured through sustained focus, adaptability, and a relentless commitment to solving user problems.

Products are marathons, not sprints. They require teams to move with intention, iterate with purpose, and deliver solutions that resonate deeply with users. By shifting from output to outcome, from projects to products, we can create experiences that drive real impact.

This year, I’ll be diving deeper into the nuances of this transition, exploring practical strategies for organizations to align their structures, processes, and cultures with the demands of product development. Let’s build better—together.

As we wrap up the year, I want to take a moment to thank you—my readers and subscribers. Your engagement, feedback, and shared insights have deeply fulfilled this journey. For those celebrating, Merry Christmas, and to all, I wish you a restful and joyful holiday season. Episode 18 is the final episode of Product with JnrJose for 2024, and it feels only fitting to end with a topic close to my heart: simplifying product delivery by addressing the cost of middlemen.

In this final piece of the year, I want to address a critical truth that gets overlooked far too often: “It’s impossible to deliver great solutions to customers by building around processes. Great solutions come from focusing on solving customer problems.” This article is inspired by my experience working in two organizations that favored process over problem-solving, and explores how over-engineered processes can hinder product discovery and delivery.

Processes Don’t Solve Problems—People Do

Earlier this year, I engaged with a team in a large organization renowned for its process-heavy approach to product delivery. During a conversation about users not adopting what is built, I asked, “How fast do we identify and respond to users’ needs?” The responses varied, but one stood out: “Our processes are here to ensure quality.”

That explanation, though well-meaning, revealed a deeper issue. The organization was building around processes rather than around customers. These processes were seen as the ultimate path to success, yet they had become bottlenecks. This led me to a crucial realization:

Processes are tools, not goals. They should support problem-solving, not become the focal point.

When we prioritize processes over customers, we lose sight of what truly matters—delivering solutions that make a difference. Processes, no matter how sophisticated, don’t solve problems. It’s the teams, empowered and focused on solving real customer pain points, that deliver impactful products.

The Illusion of Efficiency in Over-Engineered Processes

Over the years, I’ve seen countless organizations add layers of roles and approval steps to "streamline" delivery. Instead of streamlining and create more focused product teams, they would rather create new roles around processes with fancy names. While these roles can be invaluable in project management, they are less effective in product-focused environments where adaptability, creativity, and speed are essential.

The belief that these layers improve efficiency is often misguided. Instead of fostering collaboration, they create:

• Fragmentation of Understanding: When engineers and designers are separated from customers by layers of reporting, critical insights are diluted or lost entirely. Solving real problems becomes harder because the people building the solution lack direct exposure to the problem.

• Delays in Decision-Making: Each additional layer adds approvals and documentation, turning what should be quick iterations into long cycles of back-and-forth.

• A Lack of Accountability: With responsibilities spread across multiple layers, no one owns the product’s success. This leads to misaligned priorities and a diluted focus on the customer.

I’ve learned this lesson firsthand. While working on an API product that was growing in scope, I initially managed the product with a single product manager overseeing all moving parts—partnerships, reporting, and core functionality. However, as the product scaled, it became clear that one person couldn’t manage the depth required for each area without losing focus. Instead of introducing middle layers, I split the team into specialized product teams. Each team, led by a dedicated product manager, focused on specific user problems: one on partnerships, another on tools for operational efficiency, and a third on the Public API.

This decision allowed us to maintain clarity and deliver value without adding unnecessary bureaucracy. Focus replaced complexity, and the product’s growth accelerated as a result.

Processes designed to manage complexity often end up creating it. Instead of solving inefficiencies, they exacerbate them. True efficiency comes from empowering teams to act with focus and clarity, ensuring every decision is driven by user needs and business goals.

A Story About Engineers, Customers, and Problem-Solving

One of the most eye-opening moments of my career came during a particularly frustrating customer complaint. Instead of funneling the issue through multiple teams, I decided to bring the customer into the same room with our engineers and designers. I asked the customer to use the product as they normally would, while the team observed.

The result was transformative. The engineers and designers immediately spotted where the problem lay. The issue wasn’t in the code or design but in how the feature’s functionality was communicated. Within hours, the team had simplified the feature, making it easier to use. By the next day, we released an update. The result? Higher adoption rates and overwhelmingly positive feedback from users.

This experience underscored a key truth: solutions emerge when teams understand the problem firsthand. No amount of process or documentation could have replicated the clarity and speed that came from direct interaction with the customer.

The Marathon Mindset: Products vs. Projects

Treating products like projects is one of the biggest contributors to over-engineered processes. Projects are finite—they have defined timelines and deliverables. Products, however, are living systems that require constant iteration, adaptation, and long-term thinking.

When organizations impose project-based thinking on products, they prioritize outputs over outcomes. They focus on ticking boxes—shipping features, and meeting deadlines—without ensuring that these outputs solve user problems. True product success requires a marathon mindset: clarity of vision, adaptability to change, and a relentless focus on the customer.

Next year, I’ll delve deeper into the difference between projects and products, exploring how organizations can align their processes with the unique demands of product development.

Building for Users, Not Bureaucracy

The essence of agility is not in its rituals or frameworks but in its ability to empower teams to adapt, collaborate, and deliver value quickly. True agility means creating processes that serve the team, not the other way around. It means fostering a culture where experimentation thrives and failure is seen as a stepping stone to success.

Building for users, not bureaucracy, requires organizations to ask hard questions:

• Are our processes helping or hindering problem-solving?

• Are we empowering teams to act decisively, or are we bogging them down with approvals?

• Are we solving real customer problems, or are we just delivering outputs?

By focusing on these questions, leaders can create environments where great products are born—not from bureaucracy but from clarity and collaboration.

2025 Call to Action

As we move into 2025, let’s commit to simplifying the way we build products. Let’s prioritize solving customer problems over perfecting processes. Let’s empower teams to experiment, fail, and learn quickly. And most importantly, let’s remember that great solutions are built not around processes but around the people they’re meant to serve.

Next year, I’ll start by addressing the difference between projects and products, exploring how this distinction shapes team structures, decision-making, and delivery.

To my readers, thank you for being part of this journey. Here’s to building products that matter—products that solve real problems and deliver true value. Happy holidays, and I’ll see you in 2025!

Let’s take a deep dive into the less obvious, but deeply impactful, costs of product development. The goal is to connect the challenges of building a product with the experience of using it.

Cost or Trade-ofs: Picking the Right Problems

Every feature added, every initiative prioritized, comes at the expense of something else. As leaders, the challenge is in ensuring these trade-offs maximize user value while advancing business goals. Misplaced priorities, like developing flashy features instead of solving core pain points, often result in wasted resources and frustrated users.

For example, a ride-hailing app could focus on building gamified driver ratings while ignoring user complaints about unreliable pickups. Instead, leaders must connect business goals to user needs, ensuring decisions align with long-term strategy. Regularly reassessing priorities and asking, “Is this solving our customer’s biggest problem?” can help avoid costly detours.

The Cost of Process Over-Engineering

We’ve all seen the effects of bloated internal processes—approvals stretching weeks, multiple layers of decision-making, and unnecessary role redundancies. These inefficiencies not only slow product delivery but also frustrate teams, leading to delayed features that users need today, not months down the line. Internally, over-engineered processes translate to missed opportunities; externally, they manifest as user frustration.

Rather than layering more process, leaders should streamline collaboration between product managers, engineers, and designers. When you empower teams to make decisions and focus on outcomes, you cut unnecessary delays. A lightweight, goal-driven process ensures timely delivery without sacrificing quality.

Misalignment: The Silent Cost

One of the greatest inefficiencies in product development is misalignment—when teams work toward conflicting goals. Imagine a fintech app marketed as intuitive but developed without onboarding tools. Users lose trust, churn increases, and the product underdelivers.

To prevent this, align all teams around a unified vision. As a leader, it’s your role to facilitate conversations that connect marketing promises to engineering deliverables and user outcomes. Regular cross-functional check-ins ensure every team understands not just what they’re building, but why it matters to the user.

The Cost of Skipping Discovery (most expensive)

Skipping the discovery phase is one of the costliest mistakes in product development. Without understanding root causes, teams often build features that miss the mark. For example, a payment app might add a budgeting feature when users are more concerned about transaction speed. By investing time in thorough discovery—customer interviews, data analysis, and prototyping—leaders can ensure their teams build what users truly need.

Discovery isn’t a one-off task; it’s a continuous process. Build-in mechanisms to revisit assumptions and validate solutions with real users at every stage. When leaders champion discovery, teams avoid the sunk costs of building the wrong things.

Engineering Debt: The Cost of Shortcuts

When deadlines loom, it’s tempting to cut corners in development, leading to engineering debt—those "fix it later" decisions that eventually cripple scalability and performance. This debt doesn’t just slow teams; it trickles down to users as buggy, unreliable experiences.

The solution isn’t to avoid debt entirely but to manage it smartly. Make intentional trade-offs, ensuring teams revisit and address debt before it grows unmanageable. Dedicated sprints for maintenance and scalability improvements can prevent the compounding costs of technical shortcuts.

The Hidden Emotional and Cultural Costs

Building a product isn’t just about the technology; it’s about the people. A toxic or high-pressure environment can lead to burnout, poor morale, and disengaged teams. This, in turn, reflects in the quality of the product. Users notice when a product feels inconsistent or unreliable—it’s often a symptom of internal struggles.

Fostering a psychologically safe workplace where teams can experiment, fail, and learn without fear is essential. Recognize and celebrate small wins to boost morale. Leaders who actively listen and address team concerns create environments where great products can thrive.

Share

Balancing Value and Risk

Ultimately, the cost of building a product must balance with the value it delivers to users. This is where value risk—the risk of building something users don’t need—becomes critical. Adding features no one uses or failing to address the core problem results in wasted resources and user dissatisfaction.

To mitigate value risk, shift focus from outputs (features shipped) to outcomes (problems solved). Tools like A/B testing and analytics can validate whether a feature resonates with users. As leaders, your ability to champion outcome-driven metrics over vanity metrics ensures resources are spent where they matter most.

The Interplay of Costs and User Experience

The true cost of building a product doesn’t stop at your team—it ripples outward to your users. Every misstep in prioritization, misalignment in vision, or process inefficiency translates to higher cognitive, emotional, and opportunity costs for them. When users face these hidden costs, they often abandon your product.

When process is streamlined, teams is aligned, and discovery is championed, leaders can not only reduce the internal cost of building products but also lower the external cost for users. The result? Products that are faster to market, more relevant, and ultimately more valued by the people they serve.

Build Simply, Deliver Impactfully

Just as users weigh the costs of using a product against its value, product leaders must do the same during development. Every feature, process, and decision carries a cost—and these costs determine whether a product succeeds or fails in delivering user value.

For top stakeholders, the challenge is clear: foster collaboration, champion user-centered discovery, and streamline execution. When you align the cost of building a product with the value it delivers, you not only create a product that users love—you create a sustainable foundation for long-term success.

What’s Next?

In the next episode—the final one for 2024—we’ll dive into the cost of middlemen in product discovery and delivery. You’ll learn why introducing layers—irrespective of what fanciful names we call them—often causes more harm than good, and how empowering direct engagement between teams and customers leads to better products.

Also, mark your calendars! On December 20th at 6:00 PM WAT, I’ll be joining my friend for a practical session on goal-setting and creating a vision board for 2025. Don’t miss it—it’s going to be a game-changer for how you plan your next product milestones. Click here to register for free

Let’s keep building, learning, and delivering value together.

Share Product With JnrJose

I paused for a moment before responding. “The problem might not be price,” I said. “Have you considered the real cost of using your product?”

A long silence followed. It was clear the founder hadn’t thought beyond the monetary cost. This isn’t uncommon. Many builders assume that price is the primary barrier, but for users, the cost is far more nuanced it’s an interplay of time, effort, trust, and emotional energy.

That call got me reflecting on the deeper layers of product cost and how understanding these layers can make or break a product.

What Does a Product Truly Cost?

For the end user, the cost of a product isn’t just what they pay in cash or digital currency. It’s a mix of multiple factors that influence their decision to engage, stay, or churn:

1. Monetary Cost: This is the obvious one the price tag. While important, it’s rarely the sole determinant of a product’s value. A product can be free but still “costly” in other ways.

2. Time Cost: Users weigh how long it takes to achieve the desired outcome. Complex sign-ups, slow loading times, or lengthy processes are hidden costs that frustrate users and drive them away.

3. Cognitive Cost: Every product interaction demands mental energy. Is the product intuitive, or does it require users to decode its functionality? If your product feels like a puzzle, users will abandon it.

4. Emotional Cost: Does the product evoke trust, or does it spark frustration and anxiety? Unclear messaging, inconsistent design, or a lack of reliability increase the emotional cost.

5. Opportunity Cost: Users constantly weigh the alternatives. If your product doesn’t deliver faster, easier, or better value, instead of adopting yours, they’ll maintain the status quo with what they currently have or if they are currently using yours, they will switch to one that does.

6. User Data Cost: The world is becoming more data-conscious and users are more aware of the price they pay with their personal information. Products that require excessive permissions or collect unnecessary data raise red flags. If users perceive the data cost as too high or invasive, they may reject the product outright, regardless of its other merits. Balancing data collection with transparency and necessity is critical to gaining user trust.

Effort vs. Reward: The Ultimate Equation

Nir Eyal, in his book Hooked, discusses a principle that resonated deeply with me: action (adoption) only happens when the reward outweighs the effort i.e. Reward > Effort = Adoption. The probability of a user acting whether signing up, purchasing, or returning can be simplified to this equation:

Here:

• Pa: Probability of action

• M: Motivation (the perceived reward)

• E: Effort (the difficulty in achieving the reward)

• T: Trigger (the prompt to act)

For users, it’s a subconscious calculation. If effort outweighs reward, they’re gone. If triggers are missing, even high reward won’t move them.

The African Context: A Story of Mobile Payments

Let me ground this in a real-life example. A few years ago, I worked with a fintech startup, trying to build a mobile payment solution. The concept seemed perfect on paper simple transactions, low fees, and widespread agent availability. Yet, adoption stalled.

We dug deeper and discovered that while the monetary cost was low, the Effort was staggering. Users were condemned to learning a lot of imported concepts and terminologies that is not localised to them. The process though seem simpler was totally alien to the customers, increasing cognitive cost. Additionally, being a new introduction to the market, users didn’t trust the app fully, raising emotional cost.

To address this, we simplified the app’s interface, introduced common terminologies they already resonate with, optimized for speed, and introduced an instant notification (SMS & Email confirmation) to build trust. Adoption skyrocketed. The product became easier to use, the perceived reward grew, and the effort-reward balance tipped in the product’s favor.

Connecting Costs to Value

As product builders, we often talk about delivering value. But value doesn’t exist in isolation it’s perceived in relation to the costs users endure. Here’s how the different costs tie into value risk:

1. Monetary Cost vs. Affordability: If users can’t justify the price with the value they receive, they churn. Pricing must reflect the problem your product solves.

2. Time Cost vs. Speed: Faster products win. If your solution takes too long, users will move to alternatives.

3. Cognitive Cost vs. Simplicity: Simplify. Users shouldn’t need a manual to navigate your product. The less thinking required, the better.

4. Emotional Cost vs. Trust: Building trust is non-negotiable. Every touchpoint should reduce anxiety and inspire confidence.

5. Opportunity Cost vs. Differentiation: If your product doesn’t stand out, users will choose what feels more rewarding.

First Principles Thinking: Solving the Root Problem

When I think back to that fintech project, I realize how much first principles thinking played a role. Instead of patching superficial issues, we stripped the problem down to its basics:

• Why are users hesitant? (Distrust, complexity.)

• What barriers can we remove? (Streamlined UI, faster processing.)

• What motivates users? (Convenience, assurance.)

When we focused on the fundamentals, we created a product that aligned costs with perceived value. The result? A solution that felt effortless.

Build Products That Feel Worthwhile

The real cost of a product isn’t just in Naira, Shillings, Cedis or Rands. It’s in how much effort, time, and trust users invest to achieve their goals. As builders, our job is to minimize these hidden costs while maximizing the reward.

Great products aren’t just affordable; they’re intuitive, fast, and emotionally reassuring. They solve problems without creating new ones. And most importantly, they respect the user’s time, energy, and trust.

So, next time you think about what your product “costs,” look beyond the price tag. Ask yourself: is it truly worth the user’s investment? Because when the answer is yes, that’s when your product becomes invaluable.

It’s time we build with clarity, Let’s deliver solutions that are as rewarding as they are effortless.

What Does First Principles Thinking Mean?

At its core, first principles thinking is about stripping away assumptions and getting down to the basics. Instead of accepting the "how it’s always been done" mindset, this approach encourages asking, “What is fundamentally true about this problem?” and building upward from there.

Let’s take a cue from an everyday context—preparing jollof rice, a beloved dish across West Africa. The traditional approach might focus on improving your cooking tools, such as using a better pot or stove. First principles thinking, however, digs deeper and asks:

• Why does jollof rice preparation take so long? (It requires precise layering of ingredients, monitoring heat levels, and adequate stirring.)

• Can we optimize the preparation process or simplify ingredient integration without compromising taste?

Instead of just upgrading cookware, this thinking might lead to innovative pre-packaged spice blends tailored for Jollof or multi-compartment rice cookers that automate cooking stages. By focusing on the core process rather than the tools, you open the door to breakthroughs that redefine how the dish is made, saving time while preserving its authentic flavor.

Applying First Principles to Product Development

Now, let’s drive this concept home. How can first-principle thinking help us solve hard problems and design great products?

1. Define the Problem Clearly
   First principles of thinking start with a deep understanding of the problem. Ask:

   • What is the exact issue we’re trying to solve?

   • Who experiences this problem, and in what context?

   • Why does this problem exist?

   For example, a ride-hailing platform struggling with driver retention might not have its problem solved when you jump to offering bonuses (in fact, I am of the school of thought that throwing bonuses and freebies at customers is a pathetic way to learn about VALUE RISK in product). Instead, dig deeper: Are drivers frustrated with waiting times? Is the pay structure too complicated?

   Precise problem definition is the foundation for meaningful solutions.

2. Break the Problem Into Basics
   Once you’ve defined the problem, strip it down to its core truths. Ignore existing solutions and focus on fundamental components.
   Example:

   • Problem: Users abandon an app/platform during onboarding.

   • Assumptions: Onboarding needs multiple steps to explain features.

   • First Principles: Users need to understand the product's value immediately and feel compelled to continue.

   By discarding the assumption of lengthy onboarding, you might rethink the process entirely—delivering value upfront without overwhelming users.

3. Rebuild the Solution
   After breaking the problem into its fundamental parts, construct a solution that directly addresses those basics. Focus on:

   • Simplicity: Can this be done with fewer steps or less effort for the user?

   • Effectiveness: Does this solution solve the problem completely?

   • Alignment: Does this solution fit the user's context and your business goals?

   For Example: Uber didn’t just replicate taxi systems—they rebuilt ride-hailing by asking fundamental questions about location tracking, pricing transparency, and ride requests.

4. Validate Through Iteration
   First principles solutions aren’t guaranteed to be perfect on the first try. Test your solution in the real world, gather user feedback, and refine it. The iterative process ensures the solution works in theory and delivers value in practice.

Why Use First Principles for Wicked Problems?

Wicked problems are deeply complex challenges characterized by their interwoven layers, unclear solutions, and often contradictory requirements. Tackling such problems requires more than surface-level fixes or incremental changes—it demands a methodical and foundational approach. This is where first principles thinking excels, as it moves beyond assumptions and directly addresses the root causes.

Take financial inclusion in Africa, a classic wicked problem, as an example. While many solutions focus on providing loans or opening bank accounts, first principles thinking digs much deeper, stripping the issue down to its most fundamental truths. It asks:

Why Are People Excluded from Financial Systems?

Are systemic issues such as poor infrastructure or bureaucratic inefficiencies at play? Are there cultural norms or perceptions about formal financial institutions that alienate large portions of the population? By questioning the "why," we uncover systemic roadblocks that simple account-opening drives won’t resolve.

What Barriers Prevent Access?

• Financial Literacy: Is a lack of understanding about financial systems hindering adoption? Are users familiar with terms like interest rates or savings plans, or do they find these intimidating?

• Trust Issues: Do people distrust financial institutions due to past failures or fraud?

• Affordability and Accessibility: Are fees, minimum balances, or rigid requirements keeping low-income individuals out of the system? Is access to physical banking infrastructure a challenge in rural areas?

How Can These Barriers Be Removed in Scalable Ways?

First principles thinking moves from asking questions to exploring scalable and transformative solutions. Instead of expanding traditional banking infrastructure, it challenges the necessity of those structures entirely. For instance:

• Agency Banking Platforms: Moniepoint in Nigeria addressed financial inclusion by transforming local businesses into agents, offering banking services like deposits and bill payments. This decentralized model bypassed costly bank branches, making financial services accessible and affordable for underserved communities, especially in rural areas, while creating new income streams for agents.

• Community-Based Financial Solutions: Microfinance institutions that build trust through local partnerships and education programs.

• Innovative Payment Models: Pay-as-you-go solar systems, like those introduced by companies such as M-KOPA, doubled as financial inclusion tools by enabling users to build credit history through non-traditional means.

First Principles Enable Breakthrough Solutions

When applied to wicked problems, first principles thinking does more than find answers—it uncovers the questions that matter. Instead of merely tweaking existing systems, it redefines how we approach these challenges, creating solutions that are not just functional but transformative.

This approach isn’t just limited to financial inclusion. It can be applied to problems like healthcare accessibility, education reform, and even government policy change. By focusing on root causes, first principles thinking not only addresses immediate needs but also lays the groundwork for sustainable and scalable impact. In the case of financial inclusion, the result has been a paradigm shift—from building more banks to leveraging technology to meet people where they are.

The Takeaway: First Principles Lead to Breakthroughs

First principles thinking isn’t just a strategy—it’s a powerful tool. Whether you’re developing innovative products, addressing societal challenges, or even teaching complex concepts, breaking problems down to their fundamental truths enables you to craft solutions that are both impactful and straightforward.

Great products don’t just solve hard problems; they make those solutions feel effortless. By applying first principles, you can navigate complexity, deliver simplicity, and create solutions that truly matter.

Over the years, I’ve realized that building great products doesn’t mean simplifying problems or complicating things for the sake of it. It’s about tackling those "wicked" problems and creating seamless, user-friendly solutions. The truth is, while the problems may be complex, users want something that just works.

For the sake of this article, a "wicked" problem is a complex challenge without a straightforward solution—like issues in finance, healthcare, or mobility that impact daily lives. Tackling these problems means identifying messy pain points and saying, “Let’s solve this.”

Why Great Products Offer Simple Solutions

Users shouldn’t feel the complexity of the problem. Look at Piggyvest, for example, a digital savings app in Nigeria. It addresses a major human problem when it comes to building the financial discipline of saving, while this might sound simple, the most complex problems to solve are those that involve influencing human behavior. Piggyvest has been able to do that so well that many have testified to being able to build strong financial discipline through the use of the product, and many have even been able to maintain the same lifestyle outside of the product. This is possible because the product has been able to crack the ability to influence human behavior regarding financial discipline. Great products simplify complexity, creating solutions that “just work.”

Being Tough on Problems, Soft on Solutions

Solving wicked problems begins with understanding the problem itself, not rushing to solutions or cramming in features that don't address real needs. Early in my career, I fell into the "feature factory" trap, believing that more features meant a better product. Instead, I learned the hard way that this approach often dilutes a product's impact, making it less valuable to users. The key is to focus on the core problem while keeping the solution as simple and effective as possible.

To zero in on the right problem, you need to ask pointed questions that reveal its true nature:

• What is the core issue preventing users from achieving their goals?

• How are users currently addressing this problem, and where do these solutions fall short?

• How critical is this problem to users, and how many are affected by it?

• Does solving this problem align with our company’s strategic goals?

• What measurable impact will solving this problem have on our users’ lives?

Iterate, Simplify, and Stay Focused

Great products emerge from ruthless prioritization and relentless iteration. Each iteration should simplify the experience, peeling away unnecessary complexity to reveal the most efficient solution. Achieving this requires discipline—focusing on the problem’s core while resisting the urge to overbuild.

For instance, during one project, my team developed an operational API feature that, on paper, seemed beneficial. However, testing revealed that it added unnecessary complexity, confusing users rather than helping them. Letting go of that feature allowed us to refocus on what truly mattered to our users and their goals.

The takeaway here is simple yet profound: good products may impress the experts, but great products empower even the most inexperienced users. A truly exceptional product is intuitive enough for someone with no guide, manual, or expert assistance to navigate effortlessly.

Designing for simplicity doesn’t mean dumbing down a product; it means respecting your users' time and removing barriers to adoption. Great products don’t require explanations—they guide users seamlessly, solving their problems with minimal friction. That’s the benchmark of design excellence.

When to Pivot, When to Double Down

Knowing when to keep or drop a feature is key. For instance, we once developed an API feature for operational support, but testing showed it made our product more complicated. Letting go allowed us to refocus on what users truly needed.

for example, Uber tackled the complex problem of real-time ride-hailing but kept it simple for users with a straightforward interface, “Where are you going?”

Deliver Solutions That Feel Effortless

The hallmark of a great product is its ability to tackle complex problems while feeling effortless to use. Users don’t care about the sweat, iteration, and hard work that went into building the product; they care about how simple and effective it solves their problem.

To deliver this kind of simplicity:

• Focus relentlessly on fundamental user needs.

• Test, learn, and iterate until you’ve removed every unnecessary barrier.

• Be willing to let go of anything that doesn’t serve the core purpose.

In the end, great products are built on a simple principle: solve wicked problems but deliver solutions that respect users’ time and attention. Embrace the complexity behind the scenes, but let your users experience only the ease. That’s the art—and beauty—of a truly great product.

You hire product managers because the industry says you should. You bring on “designers” without a clear understanding of what design for a product entails. And what happens next? You turn a product manager into a project manager on steroids, saddling him with roles from sales and marketing to operations, sometimes even chief chauffeur duties. This may sound absurd to some readers outside Africa, but trust me, it’s the reality here.

Build Real Solutions, Not Just Digital Projects

Many of you may not want to hear this. Still, suppose you’re treating your business like a scattergun operation with no real strategy. In that case, you’re not in the business of building digital products for the 21st century—you’re in a modern-day version of a servitude cycle, wasting talent, time, and potential.

Before you venture any further, it’s time to go back to the drawing board, rethink your approach, and build with intention. Let’s talk about how to build a product that doesn’t just check the box for having a “product,” but actually meets a genuine need in Africa.

1. Start with the Problem, Not the Product

One of the biggest missteps I’ve seen many founders make is jumping straight into product development without a deep understanding of the problem they’re trying to solve. If you can’t articulate the problem your product will solve in one clear sentence, then you may need to rethink your starting point. Real digital product businesses focus on problems first because that’s what customers buy solutions for. Your shiny new app or service doesn’t matter if it doesn’t solve a real problem for your target audience.

Pro Tip: Conduct genuine market research. Spend time talking to people, immersing yourself in their experiences, and understanding their pain points. Get familiar with the realities of the people you’re building for—not from a boardroom, but from the field.

2. Understand What It Means to Build a Digital Product Business

Building a “digital product business” is a mindset shift. It means understanding that you’re not just producing a digital asset; you’re creating a valuable, scalable entity that should work on its own, provide genuine value, and adapt over time. Ask yourself, do you have a clear vision, a sustainable business model, and a focused strategy?

This isn’t about developing a bunch of random features because it sounds cool. It’s about a deep commitment to user-centricity—understanding and anticipating user needs, iterating based on feedback, and providing real, long-term solutions. The goal is not to have “a product,” but to build a business around a meaningful product.

3. Hire Talent with Clear Roles in Mind

Too often, founders bring on roles without a clear understanding of what they should do. You bring in product managers but quickly expect them to handle every possible operational task under the sun. You hire designers but lack clarity on whether they’re expected to design user experiences or brand logos. This lack of role clarity leads to confusion, demotivation, and ultimately, burnout.

What to Do Instead: Define each role clearly. Understand that product managers aren’t sales agents or social media managers. They are strategists, responsible for the product’s roadmap, user research, and feedback integration. Similarly, product designers focus on creating intuitive and meaningful user experiences, not just aesthetics.

4. Cultivate a Product-Driven Culture

Building a strong product isn’t just about hiring the right people; it’s about fostering a culture where product thinking is at the forefront. Your team should feel empowered to think about the product beyond just features and code. Encourage open discussions about user feedback, market shifts, and competitor moves. Cultivate a culture where everyone, from engineering to customer support, understands their role in delivering a unified product experience.

Tip: Make room for regular product review sessions. Let everyone have a voice, and make feedback a core part of your product evolution. Building a great product is rarely a one-person show.

5. Embrace Learning and Iteration

If there’s one thing that defines successful product businesses, it’s their commitment to learning and iteration. Your product will likely not be perfect at launch; in fact, it shouldn’t be. A good product business treats the initial release as a learning opportunity, not a finished product. It’s only through real user feedback that you’ll see what’s working, what’s not, and where you need to adapt.

Instead of fearing failure, embrace it. A pivot or change in strategy is not a failure; it’s part of the growth process. And in Africa’s dynamic markets, your willingness to adapt and iterate could be the very thing that sets you apart.

6. Measure Impact, Not Just Output

In a real product business, it’s not about how many features you ship, but about the impact those features have. Does your product save time, reduce costs, or improve user experiences in a meaningful way? Measure success not by vanity metrics but by how well your product meets user needs and drives business value.

Practical Step: Define clear KPIs that reflect value and impact, not just activity. Track user satisfaction, retention rates, and how many people actively use and benefit from your product. These insights will guide your growth and show you what matters most.

7. Build for Longevity, Not Quick Gains

Africa’s markets are vast and varied, and building a successful product in this landscape means thinking long-term. Yes, funding is important, but if you’re only building with the next round in mind, you risk losing sight of your core mission. Focus on creating sustainable value. Short-term wins may make headlines, but long-term impact builds a legacy.

Mindset Shift: Real success is about creating a product that withstands market changes, meets evolving customer needs, and becomes an essential part of your users’ lives.

Finally, Build Solutions, Not Just Products

Dear African founder, let’s change the narrative. Let’s move from building flashy products for the sake of it to building meaningful, problem-solving, and sustainable solutions. The continent has enough digital noise; what it needs are real solutions for real problems.

It’s time to build with purpose, focus, and a relentless commitment to solving the genuine challenges that affect people every day. The market is ripe with opportunity, but only for those who take the time to understand, strategize, and commit to creating value that matters. Africa deserves better than superficial digital offerings. Let’s rise to the occasion and create products that will stand the test of time and make a real difference.

With clarity, focus, and a bit of grit, you have the potential to lead the next wave of impactful African innovations. Are you ready to stop building private dev garages and start building real solutions? The choice is yours.

Recommended Resources

Books

1. Inspired: How to Create Tech Products Customers Love (Silicon Valley Product Group)

2. Escaping the Build Trap: How Effective Product Management Creates Real Value

3. Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value

Podcasts

1. Lenny's Podcast: Product | Growth | Career

2. Product Therapy

3. How I Built this

4. The product Experience

Blogs

1. Silicon Valley Product Group

2. Product Talk

3. Fashi Mindset by Chidi Afulezi

4. Mind the Product

5. Product Coallition

At some point, I mentioned a truth that had been simmering within me for a while: I’ve never been able to stick to any one product framework. Whether working full-time for a company or consulting, each organization seemed to require a unique approach to solving its specific challenges. It was surprising to hear this respected peer echo the same sentiment. Here was someone I’d looked up to for years, admitting that they too hadn’t found a single framework that worked across the board. That conversation lingered with me long after the conference wrapped up.

As I reflected more deeply on why frameworks haven’t always worked, I thought about the entire concept of product frameworks—those step-by-step guides created by highly respected product masters. Why don’t they translate seamlessly into real-world success? This line of thought led me to think about the product schools I’ve come across (though I’ve never attended one myself). Many product school graduates often share how lost they feel when they land their first product role, expressing that what they were taught in class didn't quite align with the realities of the job. I’m not here to discredit product schools but rather to explore why this gap exists.

In digging deeper, I noticed that many product school curriculums are heavily focused on frameworks rather than teaching the fundamental principles of product management. They often lack hands-on exercises in real-life scenarios that force you to adapt, think critically, and make tough calls. And this, I think, is where the disconnect lies. Frameworks offer structure, but they don’t always prepare you for the messy, unpredictable world of building products. They can guide, but they can also constrain if taken too literally.

The Reality Hits: Frameworks Aren’t a Magic Wand

My journey with frameworks began with enthusiasm. I eagerly embraced several popular frameworks—in fact, I know some of them so much that I quote them like a lawyer will quote the law before the judge—believing these frameworks would be my roadmap to success. And to be fair, they gave me a good jumpstart in my career. However, over time, I realized that rigidly adhering to any single framework instead of understanding the fundamental principles often created more problems than it solved.

I remember those early days clearly. My team prided itself on our framework knowledge. We often spent hours debating which framework was “better,” and once a decision was made, we’d go through every prescribed step—hypothesizing, validating, measuring—without stopping to consider whether we were actually solving the immediate issue. One such time, regulatory requirements pressed us to release a new feature in a tight window. Instead of focusing on how to meet these urgent needs, we got wrapped up in selecting and then following a framework to the letter. We spent more time in debate and ceremony than actively building a solution. By the time we realized, the deadline had slipped, and we’d missed what the regulator needed. The framework wasn’t speeding us up; it was holding us back.

This pattern became all too familiar—missing critical deadlines and failing to deliver on customer needs. Even Agile, our go-to for flexibility, couldn’t save us. Our sprints ran like clockwork, and our standups were impeccable, but real progress felt glacial. We were checking all the boxes but missing the bigger picture. Over time, I learned that frameworks, while helpful in creating structure, are just that: structures. Every market, product, and customer base is unique, and blindly following a framework can lead to wasted effort if it takes priority over understanding the problem at hand.

When I Decided to Write My Playbook

The turning point came during a challenging project when the company was shifting from a development shop to a single-product “aaS” business. I joined in the middle of this transition, with a large team and numerous moving parts guided by a “textbook” strategy. But after months of effort and substantial expenses, there was little to show. Then, one morning, I received a call from my new manager. He simply said, “Isaac, I need just four people on this.” He brought in two engineers (including himself), one designer, and me as the product manager. Together, we aligned on the company’s vision, engaged with potential customers, and dived deep into their problem areas. We then returned to map out a solution that fit both our customer needs and business goals.

In less than two weeks, we developed a strong prototype, validated our approach, and got to work on a functional solution. About three months later, we launched the minimum viable product (MVP), and a solid base of customers signed on from day one. Not only did we bring a viable product to market, but the pivot redefined the company’s identity. Internally and externally, everyone now recognized the business for what it truly was and the clear direction it was heading.

What I’ve Learned: Principles Over Process

Now, I’ve come to see frameworks as tools in a toolbox rather than a fixed set of rules to follow. They’re valuable, but only if you use them flexibly and adapt them to fit your situation. I’ve learned that it’s more important to understand the principles behind a framework than to follow it by the book. Product management is about solving real problems for real people, and no framework can fully prepare you for the complexities of the real world.

Reflecting on my journey and that conversation at the Inspire Africa Conference, I realize that the key isn’t rejecting frameworks entirely. It’s knowing when to use them and when to trust your instincts. It’s about blending the structure they offer with the adaptability that real-world product development demands. For me, that’s what has made the difference.

And while I’m still learning every day, I’m more confident than ever in my ability to create solutions that matter. Not because I’ve mastered a framework, but because I’ve learned when to bend the rules—and when to throw them out altogether. That’s the real lesson I’ve learned, and it’s one I wish I’d known when I first started.