#533 The Problem-First Method: Why Serious Leadership Begins Before The Solution | Interview with Kevin Dias

The Problem-First Method: Why Serious Leadership Begins Before The Solution

A high-level leadership article based on the interview between Kevin Dias and Niels Brabandt on product decisions, customer pressure, AI hype, sales urgency and the discipline of defining the right problem first.

Executive Summary

In a business environment obsessed with speed, features, artificial intelligence, competitor moves and quarterly pressure, the most expensive mistake is often hidden in plain sight: teams solve before they understand. In this interview with Niels Brabandt, Kevin Dias explains why even highly capable organisations still build solutions that do not stick. The reason is rarely a lack of intelligence. It is a lack of disciplined problem definition.

The Problem-First Method challenges a seductive habit in modern management: treating a customer request, a sales promise, a board-level trend or a competitor feature as sufficient evidence for action. It is not. A request may be valuable, but it is not yet a problem statement. A solution may be technically feasible, but it is not yet strategically justified. The leadership task is to slow down enough to identify the real problem, then move with greater precision, confidence and commercial relevance.

Why The Word Problem Deserves Its Reputation Back

Many organisations prefer softer language. They speak about challenges, opportunities, initiatives and transformation journeys. That language may sound positive, but it can also conceal the very thing leadership must confront. A problem is not a negative attitude. A problem is the reality that a decision-maker must understand before allocating talent, money, technology and trust.

Kevin Dias takes the opposite route from much of the motivational business literature. He places the problem at the beginning, not as an obstacle to optimism, but as the foundation of intelligent execution. In the interview, he explains that teams often know, in principle, that they should start with the problem. Yet they still release features that fail to gain traction because the original problem was weak, invented or misunderstood.

This is a crucial distinction for decision-makers. The failure does not always occur during delivery. It often occurs before delivery starts. The team may execute well, build professionally, communicate clearly and ship on time. Yet if the underlying problem was never real, the organisation has merely delivered the wrong thing efficiently.

The Hidden Forces That Push Teams Into Solutions

The interview identifies a pattern that many executive teams will recognise immediately. Customers arrive with requests that already sound like solutions. They ask for an export button, SMS messaging, an integration, a dashboard or, in today's market, an artificial intelligence feature. Sales teams hear revenue potential. Product teams see feasibility. Executives see competitive momentum. Suddenly, the organisation is already discussing implementation before it has understood the problem.

This is not incompetence. It is pressure. Customers are more sophisticated than they were ten or fifteen years ago. They know what good software looks like. They use hundreds of applications. They have seen strong and weak user experiences. Consequently, they arrive not only with pain points, but with proposed answers. Their sophistication is valuable, but it also creates a trap: the customer's requested feature can be mistaken for the customer's actual need.

The disciplined response is not to dismiss the customer. It is to ask better questions. What will happen after the Excel file is exported? Which workflow does SMS messaging support? Which decision will a dashboard improve? What bottleneck is the integration meant to remove? The point is not to resist the request. The point is to earn the right to build the right version of it.

Competitor Pressure Is Not Strategy

One of the most damaging sentences in leadership is deceptively simple: the competitor has it. It sounds commercially alert, but it is rarely a sufficient reason for investment. Competitors build features for their own context, customer base, maturity, investor narrative, technical architecture and strategic constraints. Copying a competitor without understanding the problem behind the feature is not strategy. It is anxiety disguised as strategy.

Kevin Dias illustrates this with the example of application programming interfaces. A team may hear that serious healthcare technology companies have APIs and conclude that it cannot be a real company without one. The more important question is different: what would our current ideal customers use an API for, and is that use case central enough to justify investment now?

The same logic applies to artificial intelligence. The board may ask why the organisation is not AI-first because other companies claim to be. A serious leadership response is not to reject AI. A serious response is to ask which customer problem AI will solve, what measurable improvement it will create and whether that improvement matters more than alternative uses of scarce organisational capacity.

The Sales Pressure Trap

Few situations test leadership discipline more severely than the moment when a customer wants a feature, sales believes the deal depends on it and the technical team knows it can be built. On paper, everything appears aligned. In practice, this may be the moment when the organisation most urgently needs to pause.

The commercial argument is powerful: why would anyone block revenue when the customer has already named the solution? Yet this is precisely where problem-first leadership matters. A feature built for a misunderstood problem may close a short-term conversation while creating long-term product debt, support complexity, misaligned expectations and strategic distraction.

The problem-first approach does not make sales weaker. It makes sales more credible. Instead of saying yes to a surface request, the organisation can say: we understand what you are asking for, and we want to understand the workflow behind it so that we solve the right issue. That response is not resistance. It is professional seriousness.

From Product Requirement Documents To Feature Alignment

Dias describes a practical intervention that is valuable far beyond product management: change the artefact that frames the decision. Traditional product requirement documents often begin when the feature already exists in someone's mind. They then formalise requirements around a presumed solution. The danger is that documentation becomes a method of legitimising the answer before the question has been properly examined.

At Ambiki, the team introduced a feature alignment document as a step before the traditional requirement process. Its purpose was to explore the problem space before committing to the solution space. The decisive improvement was simple: the problem moved to the top of the document. It became the first thing the author had to write and the first thing the reader had to confront.

This design choice matters because documents shape behaviour. If the problem is buried at the bottom, it becomes an appendix to the solution. If the problem is at the top, it becomes the standard against which every proposed feature must justify itself. Leaders should not underestimate the cultural power of such small structural changes.

Remove Solution Language From The Problem Statement

One of the most practical insights from the interview is also one of the most difficult to apply: remove solution language from the problem statement. Teams often smuggle the answer into the wording. They say the customer needs an export button, an SMS function or an AI assistant. That is not yet a problem. It is a proposed intervention.

A stronger problem statement describes the customer's situation without naming the solution. For example, the issue may be that users need to transfer structured data into an external reporting workflow, notify stakeholders at a specific point in a process or reduce the time required to identify patterns across large volumes of information. These statements leave room for better thinking.

This discipline improves decision quality. Once the problem is stated without a preselected answer, the team can compare possible solutions. The result might still be an export button, SMS messaging or AI. However, it will be selected because it solves the problem, not because it was the first idea spoken aloud.

The System Must Protect The Discipline

The interview makes clear that individual courage is not enough. A single product leader, consultant or executive can ask better questions, but if the operating system of the organisation rewards speed to solution, the old pattern will return. Culture, incentives, documents, meeting agendas and approval mechanisms must all support the discipline of problem-first thinking.

This is where leadership becomes practical. If every roadmap meeting begins with features, the organisation will think in features. If every sales escalation rewards instant commitment, the organisation will optimise for promises rather than outcomes. If every board discussion turns trends into mandates, the organisation will chase headlines instead of customer value.

A problem-first organisation designs friction at the right point. Not bureaucratic friction. Intelligent friction. The pause that asks: what problem are we solving, for whom, why now, how do we know, and what would prove that we were wrong? Those questions reduce waste, sharpen priorities and protect strategic attention.

Why This Matters For Leadership Beyond Product Teams

Although the conversation is rooted in product and software work, the leadership implications are wider. Organisations repeatedly make the same mistake in transformation, HR, customer experience, compliance, artificial intelligence, restructuring and culture programmes. They begin with the initiative before naming the problem clearly.

A company launches leadership training without defining the behavioural gap. It introduces new software without understanding the workflow failure. It restructures reporting lines without diagnosing decision bottlenecks. It announces an AI strategy without identifying the customer or employee problem that AI is meant to solve. The vocabulary changes, but the error remains the same.

For decision-makers, the Problem-First Method is therefore not merely a product management technique. It is a leadership discipline. It asks executives to resist performative action and demand problem clarity before resources are committed.

The Book And Its Value For Decision-Makers

Kevin Dias describes the book as story-driven and practical. It includes examples of teams getting the problem wrong, teams getting it right, templates and frameworks used at Ambiki, and guidance for difficult moments when sales pressure, customer urgency, board expectations or competitive anxiety push the team towards premature solutions.

That structure matters because leaders do not only need a theory. They need language, tools and examples that can survive a tense meeting. The decisive moment often arrives when someone asks why the team is not building the requested feature by tomorrow, why the competitor has already launched something or why the organisation is not moving faster on AI. The method helps leaders answer without sounding obstructive.

The best business books do not merely add concepts. They improve conversations. The Problem-First Method appears designed for precisely that purpose: to help teams ask the questions that prevent expensive enthusiasm from becoming avoidable waste.

A Practical Problem-First Leadership Checklist

Before approving a feature, initiative or transformation project, leaders should require a clear problem statement without solution language. If the problem cannot be described without naming the proposed feature, the team is not yet ready to build.

Leaders should then ask who experiences the problem, how often it occurs, what evidence supports its importance, what happens if it remains unsolved and which alternatives have been considered. These questions are not academic. They protect capital allocation and customer trust.

Finally, every proposed solution should be tested against the original problem. If the solution has drifted away from the problem, the organisation should stop, reassess and decide whether the investment still makes sense. Mature leadership does not confuse motion with progress.

The Strategic Conclusion

The interview between Kevin Dias and Niels Brabandt captures a central leadership challenge of modern business: organisations are under pressure to move quickly, but speed without problem clarity produces waste at scale. The most capable teams are not those that build first. They are those that understand first, then build with discipline.

Problem-first leadership is not pessimism. It is respect for customers, employees, investors and organisational capacity. It protects teams from trend-chasing, competitor anxiety, sales-driven overcommitment and technology theatre. Most importantly, it restores the purpose of leadership: to make better decisions before the cost of poor decisions becomes visible.

For executives and decision-makers, the message is direct. Do not ask first whether your organisation can build it. Ask first whether you have understood the problem well enough to deserve the build.

Niels Brabandt

---

Mehr zu diesem Thema im dieswöchtigen Podcast und Videocast: mit Niels Brabandt: Videocast / Apple Podcasts / Spotify

Das Transkript zum Podcast und Videocast befindet sich unter diesem Artikel.

Ihnen ist exzellente Führungsarbeit wichtig?

Lassen Sie uns sprechen: NB@NB-Networks.com

Kontakt: Niels Brabandt on LinkedIn

Webseite: www.NB-Networks.biz

Podcast and Videocast Transcript

Niels Brabandt EMBA MBA MSc

You know, problems exist. The question is, how do you deal with them? And of course, which problem actually to define and which problem to define first and in which order? And are you actually dealing with the right aspect here? We have an expert on the matter with us here today. Hello and welcome, Kevin Diaz.

Kevin Dias

Hello. Thanks for having me. Glad to be here.

Niels Brabandt EMBA MBA MSc

Thanks for taking the time. And we get straight into it. You wrote the book, The Problem Method First, The Problem First Method. And my question, of course, in the beginning is, What motivated you to write this book right now? Because let's face it, most, most books, especially these motivational books, do not like to use the word problem. They say, oh, you have to solve a challenge and don't be so problem-focused. You go the other way around. What was your motivation to do so?

Kevin Dias

Yeah, so I was struggling a little bit in my professional career where I was feeling these forces at work that were pushing our team to jump to solutions. And at first I was having a hard time articulating what made it uncomfortable for me. And so a lot of the book was actually finally being able to articulate that, get it out, get into words. And what I found in the process of writing was these kind of hidden forces that, you know, every team knows that they should be problem first. It's like Captain Obvious, start with the problem. You could go around to any product team on the planet. But, you know, these really smart, capable teams, you know, still ended up releasing these features that didn't stick. And we could trace that back to they had started with a problem that the user didn't have or was invented. And a lot of the themes I saw were themes that I was feeling in my daily work of there were these forces that were pushing teams to skip over this step.

Niels Brabandt EMBA MBA MSc

So, I mean, let's face it, there are usually very educated people in these kinds of task forces, groups, and you wonder, How is it still possible in today's times that any kind of team starts with a problem where you say, hey, I think we got it and here's the solution and no one cares? Actually, no one cares. How can this still happen?

Kevin Dias

So I'll talk about a few things. So one, I think customers are much more sophisticated today than they were 10 or 15 years ago when I started in software. So 10 or 15 years ago, a customer would come to you with some ambiguous problem. They didn't even know if technology could help you. And that made it very easy to do that discovery step.

Kevin Dias

Today, customers are much more sophisticated. They're using hundreds of apps daily. They, they've seen good UX, they've seen bad UX. So they're coming to you with feature requests, with solutions, like we want to export to Excel button here. We want SMS messaging. And it can be very easy for teams to kind of just fall into that and want to please them and jump to that. Instead of stepping back and asking like, well, what are you going to do with that Excel file once you export it? How does it fit into your workflow?

Kevin Dias

At the end of the day, that Excel button or SMS might be the answer, but if you don't really get to the discovery of understanding what's the problem, what's driving them to ask for that, teams can skip that. Other things, competitive pressure. It can be often the CEO or the board is saying like, hey, this company just launched this feature. Why don't we have it? Or, you know, today with AI, you know, we're on a board of 20 other companies and they're all AI first now. Why don't you guys be AI first? Well, we could adopt AI, but like, what is that going to do for our customer base? What problem is that solving? So there are these forces that are pushing teams to jump to that before they've really stepped back and understood that initial step.

Niels Brabandt EMBA MBA MSc

Excellent. And especially this one point, because I mean, we probably all heard the statement, look, why do you want it? Competitor has it. CEO read something in an industry magazine, saw something on a trade fair, saw a speech there. Oh, they have it. So we need it because they have it. Why do you think that this competitor has it is never a good enough reason to actually go for it?

Kevin Dias

You know, one example that we saw, you know, in our own world at Ambiqi was, you know, they came and they said, you know, we're not going to be a real company until we have APIs, because big healthcare tech companies always have APIs. And so, you know, the whole team immediately kind of thought like, all right, well, we need an API. And we didn't, like, then it was like, oh, can we step back? And can we ask, well, what do we need an API for? And do our customers right now, like our ideal customer profile, do they need an API? And what would they use that for? So again, like these forces are pushing you to kind of jump to those solutions really early.

Niels Brabandt EMBA MBA MSc

So one aspect, of course, we have to talk about. Let's say a customer tells you, I think this is the solution. And then sales probably tells you, look, when the customer says it, it's the easiest sale on planet Earth. We need the solution basically by tomorrow. If we're lucky, we can push to probably I'll give you 2 days. Customer wants it, sales pushes for it.

Niels Brabandt EMBA MBA MSc

However, how— and Pauli, of course, maybe your personal skill set tells you, I think we can build this. So you say we can do it, sales pushes for it, customer wants it. How to then remain resilient and say, let's ask a couple of more questions because sales will pressure you and say, you're just putting yourself in the way of us making money, having a happy customer. Why do you do that? How to remain, how to hold that discipline.

Kevin Dias

Yeah, that is a, a great point. And so part of the book is about how do you set up a system at your company to do that? And it can be some small changes that can, you know, really do that. But that was something that I found was it was the system, the culture was pushing us to, you know, to, to give into that immediate sales pressure or to give into that immediate customer request.

Kevin Dias

So as an example you know, PRDs, product requirement documents, those tend to be when you already have a feature or a solution in mind and then you're fleshing out what the requirements of that should be. We did something that was a step before that at Ambiki, which we called a feature alignment document, and which was really about exploring the problem space and the big change that we made.

Kevin Dias

So when we first released that document 4 years ago, it had the problem at the bottom of the page. And we were still kind of running into this. And then we moved it right to the top. So it was the first thing that you had to write. It was the first thing you had to think about. It was the first thing the reader of the document had to read. And just that small change there made a big difference.

Kevin Dias

Another small change, pulling solution language out of the problem. So if you can ask your team just in one sentence, like, what's the problem we're solving? Solving, a lot of times they'll try to sneak in solution language. Well, our customers ask for SMS, or our customer needs this export to Excel button. But can you describe that without talking about the solution at all? So forcing the team to make that small change can have a big impact.

Kevin Dias

So it really was about setting up a lot of these small changes as thinking about the system of that at the company. Because if you're in the, the typical kind of forces are going to be pushing you more towards solutions. So you have to change things a little bit at the system level, how you're operating.

Niels Brabandt EMBA MBA MSc

Excellent. And when now people say, I think this might be a good read for me, what kind of read can readers expect from your book? Is it a scientific dealing with theories, or how is the book organized? And what, what kind of read can people expect when they buy your book?

Kevin Dias

Yeah, I'm a very story-driven person. So the book is split into 4 parts. Part 1 is stories from my own experience, from large companies like Google and Air Canada, of times that teams got it wrong, where they skipped over the problem. Part 2 is when teams got it right, when they started with the problem and how that worked and led to. Then step 3, or Sorry, part 3 are different templates and frameworks that we found successful at Ambiki to, again, like, how can we set up a system that helps the team be problem first? And then step 4 is like where theory meets practice, like when it hits the road and when you get that tough question, as you said, like the sales team is ready to go if we just implement this one thing. The board is asking you like, you know, why does your team not have this AI feature yet?

Kevin Dias

Like, how do you deal with that? How do you get them to say no? But again, overall, it's a very story-driven book. I like to— I feel like stories stick with people. So if you like an easy story-driven read, I think it would be for you.

Niels Brabandt EMBA MBA MSc

Excellent. Perfect. So that means people can expect that when they read it, they get practical hands-on solutions right from the beginning, so they can implement that immediately after reading it.

Kevin Dias

Yes. Yeah.

Niels Brabandt EMBA MBA MSc

Brilliant. One last question, of course, when people now say, hmm, I think Kevin might actually be a good pick probably for our next conference as a keynote speaker or as a trainer or a coach for us. How can people get in touch to wrap this interview up?

Kevin Dias

So the book is at problemfirstmethod.com. I also have my own personal site, kevinsdiaz.com. You can find me on LinkedIn. I like to write there. I'm often writing, you know, posts and essays every week. So yeah, feel free to get in touch and say hi. I'm a friendly, easygoing guy.

Niels Brabandt EMBA MBA MSc

Brilliant. So we see when you say, I think we know this situation where sales is pressuring us to do it. The client actually wants it, the customer wants it, and we think we can build it. And suddenly we see it didn't work out too well. This book is for you.

Niels Brabandt EMBA MBA MSc

So at the end of this podcast, at the end of the videocast, there's only one thing left for me to say. Kevin, thank you very much for your time.

Kevin Dias

Thank you so much for having me.