Discover Your Future in Tech · Beginner · ~6 hours
Critical Thinking & Problem-Solving
Use structured reasoning to investigate problems, weigh evidence and communicate recommendations.
Status: Catalogue ready. This lesson version is available in review mode while subject-matter, accessibility and assessment checks are completed.
Structured problem-solving
Problem framing and scope
By the end of this lesson
- Write a problem statement that describes an outcome and affected people.
- Separate symptoms, causes and constraints.
- Set a scope boundary that keeps an investigation useful.
Build a clear mental model
Many workplace problems arrive as solutions: “We need a new CRM”, “we need automation” or “we need more leads”. A solution may be appropriate, but accepting it too early can hide the actual outcome and create cost without improvement. Start with the situation, the people affected, the observable symptom and the consequence. Ask what would be different if the problem were reduced. Then record constraints such as time, access, policy, skills and dependencies. Scope is a kindness to the investigation. It states what is included, what is excluded for now and when the boundary will be reviewed. A narrow problem can be tested. A broad statement such as “communication is bad” needs to become “customer handovers lack an owner, so implementation questions wait for several days”. The second statement may still be incomplete, but it gives the team something to observe and improve. Evidence makes learning and commercial work safer. In a busy workplace, people often move quickly from an observation to a conclusion: a team has grown, therefore its process must be failing; a person asked a question, therefore they are ready to buy; a learner used a spreadsheet, therefore they can manage a CRM. A better habit is to name the observation, the interpretation and the question that would test it. This does not slow every decision down. It directs attention to the assumptions that could create the most harm if they are wrong. It also helps a colleague continue the work without having to guess what was meant. Use a simple evidence note: context, observable detail, impact or desired change, uncertainty and next action. Context describes the setting without exposing personal or confidential information. Observable detail records what someone did, said or published, using their own words where that is appropriate. Impact describes a consequence without inventing a number. Uncertainty names what has not yet been checked. The next action should have an owner and should be easy to accept, decline or revise. This pattern works for a learning reflection, a customer conversation, a process review and a career example. Good evidence is also proportionate. A small practice task does not require a research report, and a complex business decision should not rest on a single enthusiastic comment. Label sources and dates, keep the minimum information needed, and be honest about the limits of the conclusion. When a learner cannot share a workplace example, a fictional case can demonstrate the reasoning without disclosing private information. The aim is dependable judgement, not a performance of certainty.
Apply the method in a real conversation
Use a frame with five prompts: current situation, desired outcome, affected people, evidence and constraints. Write one version from the user's perspective and one from the team's perspective, then compare them. Identify the most important assumption and choose an observation or question that can test it. Do not call an assumption a fact because it appears in a request. Review the frame with someone close to the work and change the wording when their evidence is stronger. A repeatable method turns a concept into behaviour. First, define the outcome in plain language: what should be easier, safer, clearer or more measurable after this work? Second, identify the people, systems and constraints involved. Third, choose the smallest useful action that will create new information. Fourth, review what happened and decide whether to continue, change direction or stop. This sequence avoids the common trap of producing activity without learning. It also makes it easier to explain why a particular message, spreadsheet, call, meeting or system change was chosen. When applying the method, use inclusive language and make room for different communication styles. A person may need extra processing time, a written alternative to a live role-play, captions, a transcript or a clear agenda. Accessibility is not a separate favour; it improves the quality of information available to everyone. Ask what format helps, avoid assuming confidence from speed of speech, and record only relevant support needs through approved processes. Review the work against the original outcome rather than against a vague idea of being busy. Did the note help another person act? Did the question invite a useful answer? Did the process reduce avoidable effort? Did the learner protect confidential information? If not, revise the method and try again. A respectful correction is a sign of professional maturity, not evidence that the first attempt was worthless.
Use judgement and leave a useful record
A problem frame should not erase the person's experience. The same delay may have different consequences for a customer, a support agent and a manager. Include the voices needed to understand impact, while minimising personal information. If the frame points to a sensitive issue, use the appropriate owner and avoid collecting details that are not needed. A good frame can conclude that no new tool is required; a process, training or ownership change may be the better answer. Professional judgement includes deciding what not to do. A request may be outside scope, a data source may be unreliable, a buyer may not have a current need, or a learner may need more practice before taking on a complex task. Saying “not yet”, “I do not know” or “this is not the right fit” can protect trust. It is especially important in technology sales, where optimistic language can create expectations about product capability, implementation, security or career outcomes that no one has verified. Pressure-free practice means giving people a clear choice and enough context to make it. Do not use manufactured scarcity, fear, personal vulnerability or hidden follow-up. Explain what will happen next, what information is required and how a person can pause or opt out. In a learning context, feedback should describe the work and the next improvement rather than label the person. In a customer context, the same principle appears as accurate notes, transparent limits and a willingness to recommend a safer alternative. Finally, make the work reviewable. Keep a short record of the decision, the evidence used, the uncertainty that remains and the date to revisit it. Never put real personal data, credentials, private contact details or confidential employer information into a practice exercise. These habits build trust gradually and create evidence that can be improved, audited and shared with the right people.
Workplace example
At fictional Mapleline Services, a leader asks for an AI tool because customer replies are slow. Interviews show that requests wait in an unowned shared inbox. The learner frames the problem around routing and response visibility before discussing technology.
Try this walkthrough
- 1.Rewrite a solution request as a situation, symptom and desired outcome.
- 2.Name affected people, evidence and constraints.
- 3.Choose one assumption and one safe test.
- 4.Set an inclusion and exclusion boundary with a review date.
Watch for these traps
- Accepting the requested solution as the problem definition.
- Using a vague label that cannot be observed.
- Ignoring constraints and affected people.
- Collecting sensitive details before deciding they are needed.
Knowledge check
Choose the response you think is strongest. These checks are practice until the course version has passed subject-matter review; graded attempts will be handled server-side.
For the reviewed pilot, answers are checked on the server. This draft result is not yet added to your official learning record.
Practice studio
Make a decision. Test a response. Leave evidence.
Use the case from this lesson to practise judgement without creating a score or changing your course record.
Scenario decision
At fictional Mapleline Services, a leader asks for an AI tool because customer replies are slow. Interviews show that requests wait in an unowned shared inbox. The learner frame…
Choose a response
Branching roleplay
A colleague asks you to move this situation forward. What do you say next?
Evidence workspace
Draft a short known / assumed / next note from the fictional case. Use fictional details only.
This is a session-only practice draft. It is not saved, graded or added to your learning record. Never enter real personal or confidential information.
Practical assignment
Turn a fictional request for a new tool into a problem frame. Include current situation, desired outcome, affected people, three evidence points, two constraints, one assumption and a scope boundary.
Pass this lesson's knowledge check before recording it as complete.
Portfolio evidence
Practical portfolio project
Investigate a fictional business problem, document the evidence and present a prioritised recommendation.
Turn the practical project into a bounded evidence record. Save a draft while you work, then submit it for human review when it is ready.
Sign in to save practical evidence. Sign in