Most people treat creative problem solving like it's a personality trait
It's not. It's a set of repeatable steps that anyone can follow once they stop waiting for inspiration to strike. I spent years watching teams stall out on identical problems because they were trying to think of the "right" answer instead of systematically exploring the problem space. The difference between a team that ships solutions and one that meets weekly to discuss how stuck they are usually comes down to which Strategies For Creative Problem Solving approach they default to. Start by writing down every constraint you think exists. Not the real ones — the perceived ones. The ones nobody has verified. This is where most people go wrong. They accept constraints at face value and spend their energy working within a box that was drawn by someone who wasn't even paying attention. I remember a project where the brief called for a mobile-first redesign with a three-week timeline and zero additional headcount. Everyone assumed those were hard limits. I spent Tuesday afternoon asking the product manager what would happen if we dropped the mobile requirement for the first release. Turns out the stakeholder who insisted on it had left the company six months prior and nobody had ever told the team. We cut two weeks off the timeline on the first question.
The method works like this. List every constraint. For each one, ask who set it, why, and whether it still matters. Then remove or relax the ones that don't survive scrutiny. You're left with a problem that's significantly smaller and almost always different from what you started with.
Reframing is not the same as brainstorming
Brainstorming is a social activity with well-documented flaws. Groupthink, production blocking, social loafing — the research is clear that unstructured group idea generation produces fewer and lower-quality ideas than structured individual work followed by synthesis. Reframing is different. It's a cognitive tool that changes how you represent the problem itself. Take the classic example of elevator speeds. People were complaining about slow elevators in an office building. The obvious solution was to install a new motor or reprogram the algorithm. That would cost thousands and require architectural changes. The actual problem wasn't speed. It was perception. The fix was a mirror in the lobby. People stopped complaining because they had something to look at while waiting. Same elevator. Different problem statement. To reframe on your own, try asking the question backwards. Instead of "how do we solve this," ask "what would make this problem impossible to have?" Then work from that inversion. It feels awkward at first because your brain is wired to approach problems head-on, but the inversion forces you out of the pattern you're already stuck in.
Get the Full Details

Working backwards from the solution
This is the pre-mortem technique adapted for creative work. Before you start generating solutions, assume you've already found the perfect one. Write it down in detail. What does it look like? How does it behave? Who uses it? What broke in the process of getting there? Then reverse-engineer the path. This sounds like nonsense until you've done it, but the exercise reveals assumptions you weren't aware you were carrying. More importantly, it shows you which intermediate states are actually required versus which ones you added yourself. I use this whenever a project feels impossibly complex. It usually cuts the approach down from something that looks like a year of work to something feasible in a few months because half the steps I had planned were ones I invented, not ones the problem demanded. There's a version of this I call the five-whitespace technique. When you state a problem, add five blank spaces where the real details should go. "_ is happening to _ because _, and we think _ would fix it." Fill in each blank with the most uncomfortable truth you can admit. Most problems dissolve into two or three honest sentences once you force yourself to fill those spaces without hedging.
When creative problem solving actually fails
These techniques require time and a certain amount of psychological safety. If your team is being measured on output per week and every hour spent reframing is seen as downtime, none of this will work. You'll go through the motions and produce nothing different from what you had before. The methods aren't magic. They're force multipliers, and force multipliers don't help when your base force is zero. They also break down under extreme time pressure. If you have 48 hours to ship something or the business loses money, stop trying to reframe the problem. Use pattern matching instead. Pull from solved problems in adjacent domains and adapt them directly. I've seen people waste two days on ideation frameworks when a quick trip to similar industry case studies would have given them a workable solution in four hours. Another hard limit: these strategies don't help when the problem is actually a resource gap. No amount of creative framing will give you more engineers, more budget, or more time. If you genuinely lack the inputs, the honest answer is to negotiate for more rather than pretend the constraint is intellectual. I've watched teams fall into this trap repeatedly. They treat a staffing shortage as a creativity challenge because admitting they need more people feels like failure.
A practical workflow that actually works
Here's what I use when I'm personally stuck. It takes about 90 minutes and produces better results than any meeting I've sat through about problem solving. First 20 minutes: write the problem statement on a blank page. Then rewrite it three more times, each time making it more specific and less emotional. The fourth version should be something a person who knows nothing about the project could read and immediately understand what needs to change. Next 20 minutes: list every constraint, then eliminate the ones that are actually perceived rather than real. This section usually shrinks the problem by half.

Then 20 minutes: work backwards from the ideal solution. Don't filter. Write the perfect outcome as if it already exists, then note what had to be true for it to happen. Next 20 minutes: find three analogous problems from completely different industries. How did they handle similar constraints? What solution would look absurd in your context but might contain a useful mechanism? Last 10 minutes: pick the single most promising path and commit to a small experiment. Not a plan. An experiment. Something you can run in 48 hours that will give you an answer, even if the answer is "this doesn't work."
The last step is the one most people skip. They stop at analysis because it feels productive. It isn't. A bad experiment run this week is worth infinitely more than a perfect plan written next month. The data from a failed attempt tells you what the problem actually is. Most problems reveal themselves differently than they appeared at the start. If you want a tool to track this process, I've used simple spreadsheets and notional whiteboards interchangeably. The medium doesn't matter. What matters is that you force yourself through each step rather than jumping between them based on whatever feels most interesting at the moment. The structure is what makes the method reliable. The creativity comes from what you discover inside it, not from waiting for it to appear spontaneously.