Beyond the First Why: Toddler Tactics for Deeper Insights

Am I an expert in parenting? Definitely not.

Am I an expert in software design and engineering? Probably not.

Am I well versed in being asked "Why" over, and over, and over again by my 3 year old? Absolutely.

Introduction

For a long time I thought my old man was the most persistent and stubborn person I knew. Then I grew older and I become the most persistent and stubborn person I knew (ask my wife). Then... I had kids.

This won't be a story about parenting with deep personal insights but I've come to realise that kids are smarter than we give them credit for from a very young age and if we followed their lead sometimes, we might realise just how effective their methods are.

Asking "Why"?

From a very early stage I knew that the software platform we wanted to build must be designed in collaboration with people who are experts in the fields we are solving problems for. Astalty itself literally stands for A Solution That Actually Listen To You.

One thing I learned very early in this journey is that while business owners grappling with software issues might not be the best at designing solutions, they are experts in understanding the business problems. We had to learn how to extract the root problem which can often be hidden under several layers.

This can be achieved by asking "Why". Not just once or twice and not just 5 times as described by Taiichi Ohno at Toyota.

You must ask "Why?" obsessively until you truly understand the problem. Even then, just ask a few more times for safe measure - this is the toddler way.

Why is the problem hidden under layers?

This is not the fault of the domain expert you're talking to. There's several reasons why the problem expert themselves can't articulate what it is they want to achieve using software. Here are 3 that I commonly see.

1. Preconceived Solution Bias

This arises when individuals are influenced by their current systems or processes, leading them to believe that a new solution should mimic some existing offering, albeit with minor improvements. It's a form of tunnel vision, where the familiarity with what already exists hampers the ability to envision innovative or more effective alternatives.

Example

"It would be nice if the software could automatically sort and filter the values in a spreadsheet when it's exported so we don't have to do that once it's exported."

It's likely that right now they can export the data in Excel, without the filters. But does the data need to be exported in the first place? If we're storing and filtering, is the whole dataset even required? Without asking "why", we don't even know what the problem is that requires sorting and filtering.

2. Limited Software Possibilities Awareness

Often, non-technical stakeholders may not fully grasp the extent of what's achievable with modern software solutions. This lack of understanding about the capabilities and potential innovations that software can bring to the table limits their vision.

Example

"It takes so long to reformat the invoices spreadsheet into a format that allows us to import them into Xero."

A direct integration is not overly complicated - trust me, I've built it twice. Most modern cloud platforms these day offers integrations and even if you're not using a software platform, having a bespoke integration with your existing systems is possible.

3. Symptom-Focused Solutions

There's a common tendency to address the immediate, visible issues without delving into the underlying causes. This approach leads to solutions that are akin to putting a band-aid on a wound without treating the infection beneath. It provides temporary relief but fails to solve the core problem, potentially causing recurring issues.

Example

"It would be great if we could export or print a list of all current complaints or incidents in Excel format each week so we can review it in a team meeting."

The symptom: the data can't be exported.

The problem: the team needs to be able to conduct timely reviews of complaints and incidents so they can identify operational challenges.

Bad solution: make data exportable.

Good solution: implement real time notifications, introduce a dashboard within the software so that the team can collaborate and review complaints whenever, make filters available within real time reports in the software.Having exportable data is good for data security, backups and transferring to other software. But having exportable data for the sake of business decisions is bad - once exported, the data is immediately outdated.

How does asking "Why" solve this problem?

It may seem like asking "Why?" is just to give yourself (as the problem solver) a better understanding of the problem, but the reality is it's to give yourself AND the person with the problem a better understanding of it. With enough "Whys", you can come up with a good solution, but if you keep asking you will get the best solution.

Here's a real example of how my son asked me "why" over and over when fixing our roof last weekend. Not only did he then understand (maybe) the problem, he actually made me think even harder about the problem myself. This example may seem trivial but the concept scales to the most complex problems.

This little chart shows only 5 why's from him but trust me, there were more like 500. It comes in different forms;

• Why Dad?
• What are you doing Dad?
• Mum, what's Dad doing?
• Where's Dad gone?
• What's that Dad?

There are different ways to ask "Why?".

It may get annoying for both parties but I'm yet to see a scenario in parenting, business or otherwise where asking "Why?" relentlessly has created an outcome that is less optimal than after just asking "Why?" once.

What if we stopped after the first "Why?"

Often stopping after the first "Why?", particularly if you end up treating a symptom, the pain will come back soon enough - either in the same place, or somewhere new.

If we did just fix the symptom (hole in the ceiling), sure enough in 3 months when it rained, we'd have another hole.

If we did Bad Solution #2 (waterproof ceiling), the water would just pool and leak somewhere else.

If we could do Bad Solution #3 (stop the rain), that could work but we'd still have a hole in the ceiling and my newly laid turf would be dead.

If we did the Good Solution (fix the roof), we'd have no more rain coming through the roof for now. But what about in 5 years when the leaves still get caught in the same spot and the roof eventually rusts again... and yet again another hole in the ceiling.

It's not until you ask so many "Whys" that you can really come up with the best solution for that problem (fix the roof, clean gutters, trim trees etc).

So, you have a 3 year old that can now fix a hole in a ceiling?

So, you're probably thinking, does my son now know how to fix every hole in every ceiling? Nope. But he knows how we had to fix this one, and that's exactly the point. You don't need to know how to fix every problem every time as the chances are, each case will be slightly different.

The secondary benefit of asking "Why" so much is that you're also disproving what the root problem might be.

Next time we have a leaky ceiling, he will hopefully wonder to himself "I wonder if that hole in the ceiling was caused by a hole in the roof" and he's 1 step closer to working out the root cause of the hole.

So, now what?

I'm a big believer in being able to give actionable advice that is relatable and here are some ways I try to ask "Why?" relentlessly and ways you could too;

• any time we have a feature request at Astalty, 99% of the time I ask my first "Why?" by saying "What problem are you trying to solve? As in, in your business, what is it that is making you look for <insert feature> in the first place?"
• next time someone asks you "Why did you do it this way?", get in first and just ask yourself "why?" - it helps you understand your own thinking
• next time your kid doesn't want to put pants on just ask "why" and don't stop until you fully understand that the red shirt does not get worn with the blue shorts on Tuesdays after lunchtime ??