The Problem Space Hasn't Changed (But Our Distractions Have)

As product managers, we are frequently caught in a tug-of-war between the steadfast realities of human behaviour and the rapid evolution of technology. In our daily cross-functional standups and roadmap planning sessions, it is incredibly easy to get swept up in the thrill of the new. We see a shiny new technology, and our immediate instinct is to find a way to plug it into our product.

However, over the last eight years of partnering with teams to build and scale digital products across FinTech, HealthTech, and enterprise SaaS, I have observed a recurring pattern that we often forget: The problem space remains remarkably consistent over time. It is only the solution space that evolves.

When we lose sight of this fundamental truth, we risk building incredibly complex, trendy solutions for problems that simply require a straightforward, usable answer. If the foundational knowledge around what the right thing is, why we are building it, and for whom is not in place, the risk of our entire solution collapsing under its own weight increases dramatically.

Here is how we can anchor our teams in reality, navigate the hype, and ensure we are solving human problems rather than just playing with new technology.

‍

The Problem Space is a Time Capsule

To truly understand product strategy, we have to look at our work through the lens of first principles. Human needs are stubbornly static. If we zoom out and look at various industries, the core problems we are solving today are the same problems our predecessors solved decades (even centuries) ago.

We have always needed a secure way to store, manage, and move our money. We have always needed a reliable method to travel from one place to another. We have always needed to buy essentials to feed our families, and we have always needed a way to budget and invest for our futures. These problem statements have not changed.

What has changed, and will continue to change dramatically, is how we navigate the solution space. A few decades ago, the solution for managing money involved walking into a physical brick-and-mortar branch and speaking with a representative. Today, we build fully digital, end-to-end banking experiences that people manage from the comfort of their homes. We used to wait on street corners for cabs; now we use apps to route cars directly to us.

Understanding this distinction is critical. We need a deep understanding of history to see how things have evolved, which in turn gives us the foresight to envision where we are headed. The goal is not to invent a new problem, but to find a more sustainable, usable, and commercially viable way to solve an old one.

TL;DR: The underlying human problem rarely changes; only the tools we use to solve it do. Anchor your vision in the enduring need, not the temporary tool.

‍

The Hidden Cost of the Shiny and New

We are currently living through a massive technological shift with the rise of generative AI and Large Language Models (LLMs). It is an exciting time, but it is also a time that requires intense product discipline. We have to be aware of the hype and think through things from a sustainability and scalability point of view.

In product management, there is always a cost to every decision, and transparency about those trade-offs is non-negotiable. If we blindly integrate the latest tech trend into our product without looking a few years down the line, we are setting a trap for ourselves. For example, if everyone starts using LLMs for arbitrary features and token consumption skyrockets, what happens when we realise this is a finite resource and API prices shoot up?

It is very much like buying a flashy sports car without checking if you can actually afford the premium gas it requires to run over the next five years. We must have the vision to look beyond the present novelty and ask how this weaves into a business model that scales sustainably.

TL;DR: Don't buy the flashy tech without checking if you can afford the operational fuel to run it sustainably. Always calculate the long-term cost of a trendy solution.

‍

In Defence of Intentional Friction

The tech industry has long worshipped at the altar of the frictionless user journey. We are taught that any bump in the road is a failure of design. But when applied blindly, this dogma is highly problematic.

During my time working in digital banking and lending, the technology allowed us to make onboarding incredibly fast. But banking regulations naturally evolve more slowly than the tech behind them. We had to have serious conversations about how seamless an experience should actually be. If you allow a user to open an account and immediately trigger the printing and mailing of a physical debit card before they are fully verified, you are exponentially increasing operational costs and fraud risk. Introducing a level of intentional friction (waiting until we were confident they were a legitimate, long-term customer before issuing physical assets) was a necessary guardrail.

We saw the same dynamic in HealthTech. We wanted users to easily access medical practitioners for guidance. However, practitioner time is expensive and limited. If the pipeline is completely frictionless, the system becomes overwhelmed. We needed intentional friction to filter and route users effectively, ensuring that those who truly required medical attention received it.

Sometimes, a well-placed speed bump is exactly what keeps the entire infrastructure from catching fire.

TL;DR: Friction isn't always the enemy; sometimes it is the necessary guardrail that keeps a system functional, secure, and financially viable.

‍

The Trap of Solutionism

Perhaps the most problematic notion in our industry today is the assumption that everything is a technical problem. It is easy to see why this happens; we work with brilliant engineers who can build practically anything. But framing product challenges purely as technology problems creates a dangerous precedent.

When we do this, we end up building something incredibly cool, technically complex, and possibly entirely useless. It is the equivalent of building a highly advanced warp drive for a bicycle; the engineering is magnificent, but the commuter just wanted a reliable way to get to the grocery store without sweating. We then sit around wondering why the feature isn't gaining adoption or generating revenue.

Feasibility is only one aspect of product management. A solution also needs to be viable and usable. At the end of the day, we are trying to find that sweet spot at the intersection of commercial viability and usability that allows an interesting, sustainable business to be built. All problems are, ultimately, human problems.

TL;DR: We are solving human problems at the intersection of commercial viability and usability. Do not let technical feasibility override human utility.

‍

Conclusion: Returning to First Principles

Just because a solution is technically feasible now does not mean it is the right thing to build. When we face pressure to adopt the latest trend or build out a highly complex feature, we need to take a step back and ground our teams in first principles.

Before we write a single line of code, we must ensure we have a shared, unshakeable alignment on four foundational pillars:

1. We must have a common understanding of the problem space.
2. We must have a common understanding of who we are solving for.
3. We must have a common understanding of when and why we want to solve it for them.
4. We must understand what sort of business we are building around this.

When all of these elements are firmly in place, then (and only then) do we have the safety to experiment within the solution space. Sometimes, that experimentation will lead us to a cutting-edge LLM integration. Other times, we will realise that all the user actually needed was a slightly better button.

Let us commit to focusing on the right thing to build, not just the coolest.

‍