Speed and questioning are not enemies. But without a way to know which one you need right now, you will eventually crash
Three Questions Every Product Team Should Answer Honestly
There is no single right answer to how much questioning a product team should do. A pre-revenue startup with six weeks of runway needs a different culture than a post-Series B fintech with fifty engineers.
But every team, regardless of stage, should be able to answer three questions honestly:
1. When was the last time you killed a feature because you learned it was not valuable, before building it?
2. How many of your last five launches shipped with a clear, measurable business outcome that you can defend today?
3. Would a junior PM feel safe saying "why are we building this?" in sprint planning without fear of being labelled difficult?
If you cannot answer those, or the answers make you uncomfortable, your current balance of speed and questioning may be drifting.
Not because speed is bad. Because speed without steering eventually crashes.
This post is not an argument against execution culture. It is an argument against not knowing whether your execution culture is still serving you.
The Case for "Ship or Die" Because It Built This Ecosystem
Before we critique execution culture, we should respect what it has done.
African tech grew up under scarcity. Runways were short. Investors wanted traction, not theory. Competitors could copy overnight. In that environment, the company that shipped first often won, even if the first version was ugly.
Successful companies, from Paystack to Flutterwave to Moniepoint, all had a bias for action. They shipped, learned, and fixed under fire. That speed bought them the runway to later ask better questions.
Note: This is an observed pattern, not a proven causal claim. These companies succeeded for many reasons, execution culture being one factor among many.
Execution culture saved lives. It kept doors open. It paid salaries. And for many early-stage teams today, it is still the right default.
So if you are reading this and thinking, "You don't understand my runway", this post is not for you if you are still in survival mode and speed is your only advantage. Keep shipping.
But if you have grown past that point, not because you feel like it, but because the evidence says so, then read on.
How to Know When Execution Culture Starts Working Against You
Execution culture does not fail suddenly. It fails gradually. Most teams do not notice until they are already drowning in technical debt, churned users, and firefighting.
Here are concrete diagnostic signs, not vague feelings.
Warning Sign 1: You Cannot Remember the Last Feature You Killed
If every idea that gets approved eventually ships, no matter what, you have lost the ability to say no. That is not speed. That is a feature factory.
Ask yourself: When did we last run an experiment, learn it failed, and walk away? If the answer is "never" or "over a year ago," your execution culture is no longer learning. It is just producing.
Warning Sign 2: Post-Mortems Focus on Blame, Not Assumptions
After a failed launch, does the conversation start with "who approved this?" or "what assumption were we wrong about?"
Blame cultures kill psychological safety. Without safety, people stop asking pre-emptive questions. They just ship and hope. And hope is not a strategy.
Warning Sign 3: Your Roadmap Changes Direction Every Time a Founder Has an Idea
One Monday morning call, a new feature request lands. By Tuesday, the sprint is reprioritised. No validation. No user call. No "what problem are we solving?" Just execution.
This is not agility. This is chaos. And it produces a specific outcome: half-built features that nobody uses, and a team that stops believing in the roadmap.
Warning Sign 4: Your Support Tickets and Technical Debt Are Growing Faster Than Your User Base
If every new feature adds 10 support tickets and 5 bugs, you are not shipping value. You are shipping liabilities.
A healthy execution culture keeps debt manageable. An unhealthy one treats debt as a future problem. Future teams always pay with interest.
Conditional Playbook: How to Dial Up Questioning Without Losing Speed
The fix depends entirely on your stage. Here are three different playbooks.
Important caveat on causal claims: No framework guarantees you will not build the wrong thing. Discovery-heavy teams still ship failures. The goal of structured questioning is not prevention. It is reducing the probability of persisting in failure. Teams that ask better questions and attach falsifiable kill criteria are less likely to keep betting on a losing feature for months. That is a risk-reduction play, not a prevention play.
For Early-Stage Teams (0 to 18 months / pre-product-market fit)
Default: Bias to ship. Your job is survival. Heavy questioning will kill you.
But even early-stage teams can do lightweight questioning without slowing down:
Before building anything, ask one question only: Can we test the riskiest assumption in 3 days or less?
If yes, test cheaply (landing page, manual workflow, five user calls). If no, ship and learn from real usage.
Do not run full discovery. Do not require business cases. Do not hold 15-minute outcome checks for everything.
Example: A pre-revenue EdTech startup wants to build a group study feature. Instead of asking "what is the business case?" they ask "can we run a WhatsApp group for 20 users for a week?" They learn what matters in 7 days, then decide to build or not.
For Scaling Teams (post-fit, 18+ months, 10+ employees)
Default: Introduce structured questioning gradually. You now have room to pause without dying.
Add one ritual per month:
Week 1: Before any sprint, ask one question as a team: "What business outcome are we certain this delivers?" If you hear "probably" or "we think," pause and define a cheap test first.
Week 2: Add a weekly "stop-doing" review. Ask: "What would we stop if we had to explain every feature's business case in five minutes?"
Structural fix: The kill criterion is only as good as the person enforcing it. If the same PM who championed the feature controls the stop decision, expect drift. Assign a separate reviewer, another PM, a product leader, or a weekly kill review where someone else owns the stop decision.
Week 3: Introduce a "best question of the week" award. Reward the person who asked something that saved time or revealed a false assumption.
Week 4: Run a post-mortem without blame. Focus only on assumptions and what you would do differently.
Do not implement all four at once. Add one, run it for a month, then add another.
Example: A fintech with 20 engineers and 15,000 active users introduces the weekly outcome check. Within two months, they kill three features that had no defensible business case. Engineering time frees up. Support tickets drop.
For Mature Teams (post-Series A / enterprise / 50+ employees)
Default: Strategy-first culture is now a competitive advantage. You can afford rigorous questioning.
Institutionalise these practices:
Customer interviews as a weekly ritual, not a one-off.
Quarterly portfolio reviews of all active features. Kill ones that do not deliver measurable outcomes.
A clear career path that rewards strategic thinking, not just ticket closure.
A public lessons-learned document that celebrates failed experiments.
But even here, keep one foot in execution culture. When a regulatory mandate or competitive emergency appears, you can still ship fast. The difference is that you choose to ship fast, rather than being stuck there permanently.
Simple Decision Rule: When to Pause vs When to Ship
Caveat on authority: This table assumes sufficient PM authority to act on each recommendation. In practice, founder override, board pressure, and political capital constraints will shift outcomes. Use the table as a guide for advocating your position, not as a map of decisions you will always control.
Situation
Default Action
Questioning Level
Regulatory compliance (hard deadline, e.g., CBN circular with Friday cutoff)
Ship, no questions
None
Competitive catch-up (copy a feature your competitor just launched)
Ship a minimal version, audit after
Light: Can we test the core flow in a week?
Feature for existing users in a known problem area
Ask the outcome check first
Moderate: 15-minute outcome check
New feature for a new user segment or market
Discovery before code
Heavy: user calls, prototypes, cheap tests
Runway emergency (less than 6 months of cash)
Ship only revenue-testable bets, with a 2-week kill criterion
Light: focused on falsifiability. What would prove this is not working within 2 weeks?
Realistic caveat for runway emergency: In practice, during a runway emergency, the kill criterion is often aspirational. The best you can do is document it, raise the risk visibly, and if you are overridden, run a post-mortem that captures the cost. Survival overrides method, but knowing that trade-off happened is still valuable.
Note on regulatory responses: The table's "ship, no questions" row applies to reactive mandates with fixed deadlines. Proactive regulatory discovery, for example monitoring NIBSS announcements ahead of the CBN's 2024 open banking framework release, is a separate muscle that a future post in this series will cover. Distinguish between urgent compliance (ship) and strategic foresight (question ahead of time).
The rule is simple: The higher the uncertainty, the more you question. The higher the time pressure, the more you ship.
Your job as a PM is to know where on that map you are standing today.
Psychological Safety: The Real Enabler
None of this works if your team is afraid to speak.
You can have the perfect framework. You can ask the outcome check. But if a junior PM thinks "if I question this, I will look slow," they will stay silent. And you will ship the wrong thing.
What psychological safety is not: It is not "everyone feels comfortable all the time." It is a structural condition where people believe that speaking up with questions or dissent will not lead to punishment or humiliation (Edmondson, 1999; Google Project Aristotle, 2016).
What it requires, concretely:
8. Leader modelling. When you, as a PM or founder, are wrong about an assumption, say so publicly. "I thought X would work. The test showed Y. I was wrong. Let's pivot."
9. Consistent response to failure. After a failed launch, the first question must be "what did we assume?" not "who approved this?" Blame kills safety.
10. Structural protection for dissenting voices. A junior PM who questions a founder's pet feature needs more than a thank-you. They need to see that the question led to a real decision change, or at minimum a public acknowledgement that the question was valid even if overridden.
A concrete weekly ritual (add to your retros):
Did anyone hesitate to speak up this week? What stopped them?
Ask it anonymously (via Google Form) if your team is not yet safe enough to answer aloud. Then act on the answers.
For junior PMs specifically: Use the decision table in Part 4 to structure your recommendations, even when you lack final authority. Over time, consistent, evidence-backed advocacy builds the political capital the table assumes. That is not theory. That is how you grow from executor to strategist.
Run the Three Questions Every Quarter
You do not need to abandon execution culture. You need to know whether it is still serving you.
Once a quarter, gather your team and ask the three questions from the opening:
11. When did we last kill a feature we learned was not valuable?
12. How many of our last five launches shipped with a clear, measurable business outcome?
13. Would a junior PM feel safe asking "why are we building this?"
If the answers start to hurt, you know what to dial up.
If you are still in survival mode and the answers do not matter, keep shipping. That is the right call.
But if you are past that point and you have not noticed, this post is your signal. Not because you are behind. Because every growing team eventually needs to add steering to its speed.
That is not bias. That is adaptive product leadership.