why being a toddler can help you be a better product manager

Spend enough time around a toddler and you’ll discover how difficult it is to explain something you thought you understood.

“Why?”

You give an answer.

“Why?”

You give a slightly less confident answer.

“Why?”

Suddenly, you’re questioning a rule you’ve followed for years, and someone who needs help putting their shoes on has exposed a hole in your logic.

Product managers could learn something from this.

We spend much of our working lives surrounded by answers. Stakeholders arrive with feature requests. Customers suggest improvements. Teams have roadmaps, deadlines and strong opinions about what should happen next.

A useful contribution is often a question that slows the conversation down:

“Why do we need this?”

And then, once someone answers, enough curiosity to keep going.

The first answer is often where discovery should begin

Imagine a stakeholder approaches you with a request:

“We need an export-to-Excel button.”

It sounds straightforward. You could clarify the file format, agree which fields to include and get it into the backlog. The team might deliver it beautifully.

But you still wouldn’t know why someone needs it.

Perhaps customers need to share information with people who don’t have access to your product. Perhaps they don’t trust your reporting. Perhaps an accountant requires a spreadsheet.

Each explanation could lead to a different product decision.

The request tells you what someone has imagined as a solution. Understanding the circumstances behind it helps you judge whether that solution is worth building.

That is where the 5 Whys can help.

What are the 5 Whys?

The Lean Enterprise Institute describes the 5 Whys as repeatedly asking why to move beyond the obvious symptoms of a problem and investigate its root cause.

The method comes from lean problem-solving. For product managers, it can also provide a useful structure for exploring a request before committing to a solution.

You start with a specific problem or observation, ask why it happens, then use the answer to guide the next question.

Five is a prompt to dig deeper, rather than a number you must hit. You might reach something useful sooner. You might need to keep going. You might discover several explanations that need investigating separately.

The important part is following the answers rather than racing through a checklist.

Five questions behind one feature request

Let’s return to that export button. Here’s a hypothetical discovery conversation.

1. Why do customers want to export their data?

Because account managers copy it into a spreadsheet before their weekly customer review.

2. Why do they need a spreadsheet for that review?

Because they need to show which accounts require attention, and our dashboard doesn’t give them that view.

3. Why doesn’t the dashboard show which accounts require attention?

Because it displays recent activity, but doesn’t show whether that activity meets each customer’s agreed service commitments.

4. Why can’t they compare activity with those commitments?

Because the commitments aren’t recorded in the product.

5. Why aren’t the commitments recorded there?

Because they’re captured during sales and handed over in documents, with no structured place for the account team to maintain them.

Now we have a much more useful problem statement:

“Account managers cannot easily identify which customers are at risk of missing their agreed service commitments.”

An export button might still be the right short-term fix. It could save people time while you investigate a more complete solution.

But you would make that decision knowing what the spreadsheet is doing for them. You could also explore whether recording commitments and highlighting at-risk accounts would remove some of the manual work.

That changes both the options you consider and how you measure success. Export usage tells you whether people clicked the button. Time spent preparing reviews and the ability to spot at-risk accounts tell you whether you helped.

When AI helps you build faster, ask why more often

AI-assisted tools can make it quicker to turn an idea into a prototype or implement a well-defined feature. The gains depend on the task, the codebase and the review needed, but the product-management implication is worth taking seriously: when building gets easier, deciding what deserves to be built needs more attention.

A feature request can become a working demo before anyone has properly questioned the problem behind it. Once people can click through something polished, the conversation can drift towards colours, edge cases and release dates. The original assumption quietly becomes an agreed requirement.

In our export-button example, AI might help the team produce a prototype quickly. That still wouldn’t tell us why account managers need a spreadsheet or whether the export would help them spot customers at risk.

This is why product managers should practise the 5 Whys more often as teams adopt faster building tools. Make that curiosity a routine part of evaluating requests, rather than an exercise you reserve for major failures. Faster delivery gives weak assumptions less time to be challenged before they become software someone has to support.

Even a cheap feature carries ongoing costs: testing, maintenance, documentation and another choice for users to understand. Building the wrong thing faster can leave you with more of those costs without improving the customer’s work.

There is a better use for the speed. Investigate the need, identify the assumption you’re least confident about, then use AI to help build a small test of it.

For the account managers, that might mean a disposable prototype showing a few accounts against their service commitments. Watch someone use it to prepare a review. Can they identify the accounts that need attention? What information is missing? Does it change what they do next?

You can learn from a rough prototype without committing to a production feature. Agree beforehand what evidence would justify further investment, and be willing to discard the prototype if the need doesn’t hold up.

The aim is to shorten the time between a question and useful evidence. Use the time AI saves to understand customers better, rather than automatically filling it with more features.

Borrow the curiosity, not the interrogation style

There is a reason toddlers can get away with conversations that would go badly in a stakeholder meeting.

Repeatedly saying “why?” can sound dismissive. People may feel that you’re challenging their competence or forcing them to justify a perfectly reasonable request.

You can keep the curiosity while changing the wording:

• “What are you trying to achieve with that?”
• “Can you walk me through the last time this happened?”
• “What makes that step necessary?”
• “What happens if you can’t do it?”
• “How are you handling it today?”

These questions give people room to explain their circumstances.

It also helps to explain your intent:

“I want to understand what the export helps you do so we can make sure we solve the right problem.”

You’re asking someone to help you understand their work. Treat the conversation accordingly.

A convincing explanation still needs evidence

The biggest danger with the 5 Whys is that a tidy chain of answers can feel like proof.

Someone offers a plausible explanation. The next person builds on it. Soon the team has agreed on a root cause without watching a customer use the product.

In the export example, every answer would need checking. You could observe someone preparing a weekly review, inspect the spreadsheet they use, and ask where the commitments come from. You should also speak to other customers: some may export data for entirely different reasons.

Keep track of what you know, what someone has reported and what you’re assuming. An AI-generated explanation belongs in the assumptions column until you have evidence for it.

If an answer is “we think customers find it confusing,” the next step may be observation rather than another why.

Product problems also have multiple causes. People might abandon onboarding because of confusing instructions, missing permissions or a lack of immediate need. Forcing all of them into one chain can hide the differences that matter.

Use the method to develop explanations you can test. Be willing to branch, revisit an answer or admit that you don’t know yet.

Don’t let “why” become “who”

Another warning sign is a chain that ends with somebody being blamed.

“Why did the release go wrong?”

“Because someone didn’t test it properly.”

That answer leaves plenty unexplained. Were the requirements clear? Was there a realistic test environment? Did anyone own the final check? Was the team under pressure to ship despite a known risk?

The same applies to customers.

“The user didn’t understand it” is a reason to investigate the experience, not close the discussion.

Curiosity becomes much less useful when people are busy defending themselves. Focus on the conditions that produced the problem and what your team can change.

Try it before your next backlog addition

Choose one request that already sounds obvious.

Before discussing scope or estimates, ask the person who raised it to walk you through the last time they needed it. Follow the answers until you can describe the problem without naming the requested feature.

Then write down:

• What the person is trying to accomplish.
• What gets in their way.
• What evidence supports your explanation.
• What you still need to check.

Use that to decide your next step, whether it’s a small fix, more discovery or a different solution. If AI can help you test the idea faster, decide what you need to learn before you start generating it.

Toddlers have very little embarrassment about asking a basic question. In a room full of people confidently discussing what to build, that is a useful habit to recover.

Keep the curiosity. You can leave the tantrums out of sprint planning.