Good Technology Starts With a Clear Problem

Every digital initiative begins with a series of decisions. Some define what the business is trying to achieve. Others determine how that objective will ultimately be delivered. The strongest initiatives I've participated in shared one characteristic from the very beginning: everyone developed a clear understanding of the problem before anyone became attached to a particular solution.

That may sound surprising coming from someone who spends most of his time working alongside technology teams, but I believe there is an important distinction between discussing technology and defining the problem technology is meant to solve.

I've occasionally seen projects where conversations move quickly toward platforms, architectures, frameworks, or specific features before everyone has developed a shared understanding of the challenge itself. It's an understandable instinct. Every discipline naturally approaches problems through the lens of its own expertise, and that expertise is precisely what makes each perspective valuable.

Business leaders think about strategy, priorities, investment, and measurable outcomes. Product and UX teams seek to understand the people who will ultimately use the solution, the journeys they will experience, the operational realities that shape those journeys, and the processes required to support them successfully. UI Designers translate those insights into intuitive, cohesive interfaces that bring the intended experience to life. Technology leaders evaluate architecture, scalability, security, integrations, and long-term maintainability. Quality Assurance focuses on reliability, validation, and ensuring the final product performs as intended.

Each discipline is solving a different part of the same challenge.

The projects that leave the strongest impression are rarely the ones where every discipline participates equally in every decision. More often, they are the ones where every discipline contributes its expertise at the appropriate moment while respecting the responsibilities and accountability of the others.

That distinction may seem subtle, but I believe it fundamentally changes the quality of the decisions that follow.

Business objectives should shape requirements, but they should not dictate technical architecture. Technology should determine how those requirements can be delivered responsibly, but it should not lose sight of the business outcomes those decisions are intended to support. User Experience should help define not only how a product looks or behaves, but also how people interact with it, how information flows through the organization, and how supporting processes contribute to the overall experience. Each perspective strengthens the outcome without replacing another.

One aspect of User Experience that I think is often overlooked is that great experiences are not created exclusively through screens and interfaces.

Many of the most meaningful improvements happen long before a designer begins creating wireframes or an engineer starts writing code. They emerge from understanding how people work, identifying unnecessary friction, simplifying decision-making, clarifying ownership, improving communication, and designing operating models that allow both employees and customers to navigate processes more naturally.

Sometimes the experience improves because an interface becomes simpler. Other times it improves because the underlying process becomes simpler. In many cases, both evolve together.

I've participated in initiatives where the most significant improvement wasn't a redesigned screen, but a redesigned workflow. Clarifying ownership between teams, simplifying approval processes, or establishing more consistent operating procedures often reduced delays and frustration long before a new interface was introduced. Customers never saw those internal changes directly, yet they benefited from them every time the organization responded more quickly or delivered a more consistent experience.

This is one of the reasons I believe discovery deserves far more attention than it often receives.

Discovery is not simply gathering requirements or documenting features. At its best, discovery creates a shared understanding of the business objectives, the people involved, the operational environment, the constraints, and the desired outcomes before anyone begins debating implementation approaches.

When discovery is approached thoughtfully, technology teams are not handed a predefined solution. They receive something far more valuable: a clearly articulated problem, supported by business objectives, user needs, operational context, and success criteria. That foundation allows engineering teams to evaluate tradeoffs and determine the most appropriate technical approach rather than spending valuable time redefining the problem itself.

I've also seen the opposite happen. Teams become excited about a particular platform or capability, only to discover later that everyone had been solving slightly different versions of the same problem. None of the work was wasted, but valuable time was spent aligning assumptions that could have been established much earlier through a more disciplined discovery process.

Determining how those requirements should be implemented is ultimately the responsibility of technology leadership. At the same time, even the strongest technical decisions depend on the quality of the discovery, planning, and collaboration that precede them. Expertise matters, but so does the environment that allows each discipline to apply that expertise effectively.

Respecting expertise does not mean every discipline operates independently. Successful initiatives still require someone to orchestrate the conversation, ensuring information flows between teams, dependencies are understood, and decisions happen in the right sequence. One of the most valuable contributions a Project Manager or Delivery Lead makes is not making technical, business, or design decisions on behalf of others. It is creating the structure that allows each discipline to contribute its expertise at the moment it creates the greatest value.

Some of the best Project Managers I've worked with rarely became the loudest voice in the room. Their contribution came from asking the right questions, bringing the right people together, recognizing when a decision depended on another discipline, and ensuring those conversations happened before small uncertainties evolved into costly rework.

Looking back, I've come to believe that this orchestration is often one of the least visible yet most valuable contributors to successful delivery. When projects progress smoothly, it's easy to focus on the technology that was implemented or the product that was launched. Less attention is given to the countless conversations, decisions, dependencies, and alignment efforts that made those outcomes possible.

The longer I work alongside business leaders, designers, engineers, quality specialists, and project managers, the more convinced I become that successful digital initiatives are built on mutual respect for expertise. Not because every discipline participates in every decision, but because every discipline understands when its expertise should lead, when it should support, and when it should trust the expertise of others.

Technology deserves thoughtful business direction, and business deserves responsible technical leadership. The strongest digital initiatives emerge when both respect each other's expertise while remaining aligned around a shared understanding of the problem they're trying to solve.