Move Ahead With Possibility Thinking

The thing nobody tells you about this

Most teams I've worked with jump straight to solutions when presented with an open-ended problem. They have a week to figure out how to enter a new market, and by day two they're already building mockups. That's where the method called Move Ahead With Possibility Thinking comes in, and honestly, it's more useful than most people give it credit for. Here's what it actually is: before you commit to any single direction, you systematically map the full range of what could be done. Not what should be done. What could be done. Then, once you've exhausted the possibility space, you narrow down using real constraints instead of assumptions. I learned this the hard way around 2019. My team was building a logistics platform for a mid-market supply chain client. We spent three weeks designing what we thought was a brilliant real-time routing system. The client's operations lead looked at it and said, "This works great, but my drivers don't have reliable cellular coverage in the rural routes we cover most often." Three weeks. Gone. If we'd moved ahead with possibility thinking first, we would have listed offline-first architecture, edge computing, SMS-based tracking, and several other options before writing a single line of production code.

Move Ahead With Possibility Thinking

The method breaks down into three phases. Phase one is definition. You write out the problem statement in a single sentence that doesn't imply a solution. "How might we reduce customer onboarding friction" is decent. "How might we implement a chatbot for customer support" is terrible, because you've already solved the problem in your head. Phase two is expansion. You generate possibilities across at least four dimensions: technical feasibility, business viability, user experience impact, and organizational capacity. Each dimension should have at least five possibilities. The goal isn't quality at this stage. It's quantity and diversity. I usually time-box this to about ninety minutes for a medium-complexity project, which forces people to stop overthinking individual options. Phase three is constraint filtering. You take yourPossibility Matrix and score each option against hard constraints — budget, timeline, regulatory requirements, existing tech stack. Anything that violates a hard constraint gets eliminated immediately. What remains is your viable solution set.

Here's the counterintuitive part most people miss: the larger your possibility set, the faster your eventual convergence. Teams that generate eight to twelve viable possibilities typically make final decisions in half the time of teams that start with three. This feels wrong intuitively. More options should mean more debate, right? In practice, the opposite happens. When you've rigorously documented why most options were eliminated, the remaining choices feel obvious. The decision fatigue drops significantly. There's a practical trick I use during the expansion phase that saves a lot of time. Instead of asking "what are the possibilities," ask "what if the opposite were true?" If you're thinking about building a mobile app, the opposite might be a voice-only interface, a kiosk-based system, or no interface at all and just a manual process. This generates possibilities that pure brainstorming rarely surfaces because your brain has already filtered them out unconsciously. Now for where this method actually fails. Possibility thinking is expensive in terms of time. A thorough session for a complex product can take a full day of facilitated work. If you're a solo founder or a three-person team with a deadline next Friday, don't use this. You'll never finish. In those cases, just pick the most obvious solution and iterate after launch. The method is designed for organizational teams with enough stakeholders that premature convergence becomes a real risk.

Another scenario where it breaks down: regulatory or safety-critical domains. If you're designing medical devices or aerospace systems, possibility thinking can create a false sense of exhaustive exploration. The engineering standards in those fields require specific validation protocols that no amount of possibility mapping replaces. You still need the testing. You still need the compliance documentation. What this method does is help you choose between genuinely equivalent approaches before you commit resources. I ran into an edge case recently that illustrates both the power and the limitation. A client was trying to decide between building their own analytics dashboard or licensing a third-party tool. We went through the full possibility expansion — custom build, white-label, API integration, hybrid approach, no dashboard at all. The constraint filtering eliminated four of the six options quickly. But the final two — custom build versus API integration — were genuinely equivalent on every metric we had. We couldn't decide. The possibility thinking had gotten us to the true decision point, but the method itself doesn't resolve ties. We ended up using a small paid consultation with a product strategy firm, which cost them about eight thousand dollars and took two days. That consultation was cheaper than building the wrong option, which would have cost roughly two hundred thousand in development time and opportunity cost over eighteen months. The scoring system in phase three is where most teams screw up. They grade possibilities on a subjective five-point scale without calibration. I've seen teams give everything a four or a five and then wonder why they still couldn't decide. Here's the workaround: force a bell curve. If you have ten possibilities in a category, no more than two can score above a four. No more than one can score below a two. This artificial constraint removes the tendency to rate everything as "probably good enough."

Another subtlety people overlook: possibilities aren't independent. Some of them enable or disable others. A possibility that requires a specific technology your organization doesn't have and can't acquire in the next year should be flagged as a dependent possibility. Cross-reference your list and note these relationships. It prevents you from eliminating a good option because you forgot it was already invalidated by something else on the list. For smaller projects where a full session isn't practical, you can compress the method into a thirty-minute exercise. Write the problem statement. List three technical possibilities, three business possibilities, and three user-experience possibilities. Score each against your hardest constraint. Pick the top-scoring combination. This is the minimum viable version of the method, and it catches approximately sixty percent of the problems that a full session would catch, in about ten percent of the time. One more thing. After you make your decision and start executing, document the possibility matrix. Not for anyone else. For you. When the next similar problem comes up — and it always does — that documented matrix becomes your starting point instead of a blank page. The second time you run this for a comparable problem, it takes about twenty minutes instead of ninety because you're adapting previous work rather than generating from scratch. The compounding value over multiple projects is where this method really pays off.