The Problem Solving Method

Solving Valuable Business Problems

The Problem Solving Process

The Problem Solving Process 2026 BGs Square MAIN UserTypes User Types InterviewLog Interviews & Observations OrgChart Org Chart ValueMetrics Value Metrics ThematicInsights Thematic Insights UseCases Services & Use Cases EPaRM EPaRM UserJourneys User Journeys (AS-IS/ TO-BE) InformationArch Information Architecture Prototype Functional Prototype UsabilityTesting Usability Testing AgileEpics Agreed Epics AgileStubUserStories Agreed Stub User Stories AgileUserStories Functional User Stories & Acceptance Criteria/Tests AgileDevelopment Agile Backlog or waterfall delivery LiveContImp CONTINUAL IMPROVEMENT (Brownfield UX/ CX) RiskLog RISK LOG PostAnalysis POST-ANALYSIS Testing iteration loop Tasks & Artefacts ProblemStatementValidation Problem Statement Validation SDBluePrint Service Design (blueprint) CommsPlan Comms Plan CaseStudies Case Studies Sean McSharry 2026 ADVANCED DataJourneyMapping Data Journey Mapping UserStories Functional User Story Maps PreDisco Pre- Discovery Pitch & Win work Lifecycle PhaseFuncArch Functional Architecture (Pre-Agile) PhaseBuild Dev PhaseDiscoResearch Discovery & Research PhaseLive Live PhasePreDisco Pre-Disco Project Lifecycle

This interactive diagram shows all the phases of a project lifecycle, and the consistent, related steps required to gather and use data to build and test the solution prototype, and ultimately guide the delivery team to deliver the best product (right-first-time). It reduces the unknowns, defines scope around the required value, and gives clarity and optimal lead time to the whole project team. All whilst reducing errors, cost and delivery time.

Important: This is the pure Problem Solving process – this diagram (there is a more comprehensive one) doesn’t show the integration of collaboration, sign-off or deliverables to/with the Stakeholders, nor the collaboration touch points with the other project disciplines (Devs, UI designers, Systems Architects, stakeholders, product owners etc). It doesn’t make it immediately obvious when and where all 3 business domains are researched and understood, but they are. It doesn’t show the associated tasks required to create and deliver the steps outlined here, nor the AI tools or activities that empower some of them.

* Comprehensive explanation and examples in my upcoming book – Super Solver


The Value of the Problem Solving Process

This is a repeatable, consistent and scalable method for:

  • Winning work
  • Identifying and leveraging the relevant data and scope of a project in order that it delivers value, not just ends
  • Exposing the pain points of users/customers and the business
  • Collaborating with and empowering project teams early (not shown here) giving them maximum lead time and allowing them to make the most accurate resource estimates (team size, expertise, tools, time and cost)
  • Communicating clearly and giving visibility to the whole project team, from senior stakeholders to engineers, ensuring we’re all on the same page and trust is built
  • Clarifying the opportunities for valuable new technology and innovation that genuinely improves the solution – it isn’t just shoehorned in
  • Guaranteeingprovingsuccess, before (I’ll say that again ‘before‘) a line of code is written or a service is restructured – that means no more “the client changed their mind
  • Delivering projects that are optimal, impossible to beat and right-first-time
  • Delivering solutions that your users will want to pay for and brands that your users will never want to leave


Organisation Problem Domains

If you’re going to be a good, valuable, problem solver for any organisation, it’s not enough to just know research, or service design, or Agile, or AI, or systems architecture, or revenue goals, or governance requirements or user psychology or a hundred other business, technology and user domain related factors, variables and intricacies.

If you’re going to be a good, valuable, problem solver you have to have a working knowledge of all 3 domains, because business and user problems do not live in just one domain in isolation – they are effected by and affect each other. Trying to fix a user pain point without at least conversational level of knowledge of the business, technology and user domains is like trying to fix a watch with only the knowledge of what time it is. It means you won’t understand the impact (or disaster) of your decisions – you will rely on others, who work in only one of these domains, to join some of the dots – and they won’t.

As a good problem solver, you don’t live in one of these domains, you walk confidently through all of them, connect all the dots and can learn and see the cause and effect ripples. You speak their language (business, technology, user) and mediate between them all, using data as the currency of value to all.


High Level Problem Solving Process

Problem solving isn’t a tick box – it’s a critical, foundational, golden thread through the business and every problem or project within it. It crystallises the data and empowers the organisation’s experts, proving the value and informing the solution, minimising the expense and time of delivery, and optimising the value of the solution and the organisation. It creates the single source of truth – the north star.

Good Problem Solving is the method by which:

  • businesses build successful, new products and services,
  • businesses achieve operational excellence, continual improvement and contingency planning.
  • businesses remove pain points, maximise profits and reduce operational expenditure.
  • businesses increase share price, please shareholders and customers/users, and leave their competitors in the dust.
  • businesses leverage the right innovation and technology,
  • development is quicker, cheaper and right-first-time.
  • individual promotions happen, leaders are born, bonuses get paid and organisations own their market.

And surprisingly, it’s very simple and successful – every time

Politics, opinions, ego, personal agendas, career goals and over-promising are all huge factors in failure, leading to hasty, assumption based assurances and a focus on the wrong KPIs – the KPIs that support the initial assumptions/promises, or hide the utility failures.
Tactical project goals, in line with poorly understood assurances, come into conflict with the more important business strategic goals, but still take priority, leading to project leaders wrongly celebrating:

We delivered (crap and mediocrity) on time and to budget!

The very purpose of business, and the projects it carries out, are user satisfaction, reputation, savings, efficiency, revenue and profit.

Delivering crap in a 6 week window for a minimum over-spend does nothing to achieve those goals – it makes it easier for our competitors to beat us and for our critics to condemn our work (and our jobs).

So over the years, sectors, countries, clients and projects I have learned, refined, created and integrated the best methods and steps to optimally solve business problems and deliver best in class solutions, using not one partisan method, but the best and most efficient from them all.
Leveraging expertise in the three domains of Business, Technology and User, this method had evolved and matured. I have used it successfully for many years and clients, including startups, public sector and Fortune 100 organisations. It works in every scenario and for every challenge – physical and/or digital.


How the Problem Solving Process Reflects User Needs and Informs Agile

Let’s look at a very simple conceptual example of how a real world requirement is addressed by the Problem Solving process as a seamless path of tasks, from research to functional Agile user stories. This ensures no additional work, no unnecessary tasks and no changes.

SIMPLE: User Research Outputs to User StoryMaps BG Build Research & Discovery Functional Architecture NOTES Agile Function description Testable functional prototype Specific, validated steps to carry out use case Service Functions Identify users/ needs Identify Services Required Agile Story dependencies Understand Problem Steps EG Secure Access Biometric ID Customer steps Digital twin what to build what order to build in Example main site image Service(s) Use Case(s) Use Case(s) User Types RESEARCH SD Blueprint User Journey(s) Prototype Usability Test User Stories User Story Map Process

We’ll use the simple example of “a customer needs to ‘Change Password’“. This is one of the Use Cases in the “Secure Access” service.

Below you will see an overview of the “a customer needs to ‘Change Password’” Use Case in the “Secure Access” Service. You can see how we identify the Epic, User Story and the elements of the story from the problem solving process very early on – we don’t need to wait until development (this accelerates the Agile development process):

Mapping PS Artefacts to Agile BG Main User Type Service Use Case User Journey Prototype Usability Test AGILE Example PS Artefacts Agile EPIC Functional User Story & Acceptance Test Examples Customer Secure Access Change Password Map all steps Create testable version of all steps Give user proto to try change password function LINES RESEARCH / DISCOVERY FUNCTIONAL ARCHITECTURE NOTES 2 Notes 1 . User Type : what kind of user does it affect? (proto-persona) 2 . Service : What is the nature or area of their need? What high level capability must we make available to the User Type? 3 . Use Case : What does the User Type need/want to be able to achieve within the Service? What’s their specific goal? 4 . User Journey : What are the individual steps that make up the complete scope of the Use Case. 5 . Prototype : Architect a functional version of the Use Case's and User Journey 6 . Usability Test : Test that the Prototype delivers an optimal, intuitive solution, Use Case and User Journey that fulfils the business and user needs. 3 4 1 6 5 As a Customer I need Secure Access So I can change my password Copyright Sean McSharry 2026

Follow me on