Reframe Unlocks

I was in a meeting with the engineering team, breaking down all the active work. Linear was open, my screen was shared (Collaborative Clarity), and the focus was to ensure all work was tracked. We just completed an extensive technical architecture diagram, visualizing the flow of functionality throughout the complex software application.

The problem? Mapping the functionality represented in the diagram into actual issues documented in Linear, our issue-tracking software.

The reason this is hard is because of those pesky unknowns—the units of work you know exist, but you can’t describe them (they’re unknown!).

The solution? Find a way to reframe the work. Even if you don’t know the solution yet, you can phrase the task as an open-ended question.

Sometimes a simple phrasing change can make all the difference. That’s what we’re going to explore today. How you can move from problems to possibilities; from solutions to discoveries; from uncertainty to action. You will move from Closed Statements that shut down creative thinking, to Open Questions that invite innovation and curiosity. Oh, and if you have a Thought Lab, this is the ideal place to explore these Reframe Unlocks to expand your thinking.

Let’s go!

From Problem to Possibility

How might we…?

The “How might we…” (HMW) statement dates back to the 1970s, credited to Min Basadur, a creative manager at Proctor & Gamble. The phrase was used to replace judgmental terms like “can” or “should” with “might,” fostering open-ended exploration.

The phrase has stuck around and gained further prominence, and it’s an excellent way to move from problem to possibility.

I like this reframe when we’re in a team retrospective, reviewing the work from the previous development cycle.

Here are example problems that often come up:

• “The deployment process is broken and causing issues.”
• “Communication between teams is poor and things slip through the cracks.”
• “Our code review process is too slow and bottlenecks development.”

Let’s reframe these using HMW statements:

• “How might we streamline our deployment process to increase reliability?”
• “How might we improve cross-team communication to ensure nothing is missed?”
• “How might we optimize our code review process while maintaining quality?”

See the difference? We move from problems as Closed Statements—shutting down any exploration, curiosity, or discovery—to Open Questions that invite creative thinking. We move from How do we fix this? to What is the opportunity here?

From Solution to Discovery

How will we…?

A variation of the HMW that works especially well in development is “How will we…” (HWW).

When we were reviewing the Linear issues to make sure they mapped to our architecture diagram, we were missing work. Why? The unknowns. It’s hard to write an execution-focused task when you’re not sure of the solution. So the work is either missed or written as an answer (and maybe the wrong one).

Here are some examples of solution statements:

• “Build a new API endpoint to handle user authentication”
• “Add Redis caching layer to improve performance”
• “Implement JWT token-based authentication system”

Let’s reframe these using HWW statements:

• “How will we handle user authentication in a secure and maintainable way?”
• “How will we optimize application performance through caching strategies?”
• “How will we implement a secure and scalable authentication mechanism?”

Again, the difference is clear. The solutions box us in with fixed thinking. The HWW statements open up discovery, allowing for experimentation and unconventional thinking to find the best solution. Start wide before getting narrow.

From Uncertainty to Action

What would need to be true…?

All development work starts from uncertainty. Even when you know the problem, and are reasonably confident in the solution, the countless variables are there to say Oh, yeah?

Certainty is confidence. And it’s natural to want to project confidence with your team. But living in the uncertainty, acknowledging it, and planning for it is how you thrive.

When we were discussing the functionality required to ship the product, it was easy to get lost in rabbit holes and edge-cases—pontificating on every scenario, no matter how rare the possibility. We were stuck.

To get us out, I asked a question:

What would need to be true to ship this product to production?

The conversation changed. Instead of staying stuck in perpetual contemplation, the conversation shifted to action. The team quickly called out what core functionality is needed to deliver the work. That’s action. While uncertainty is part of the work, don’t let it prevent you from finding The Next Step.

Here are some examples of uncertainty:

• “We’re not sure if the architecture can handle the load”
• “The security requirements are unclear”
• “We don’t know how users will interact with this feature”

Let’s reframe these:

• “What would need to be true for our architecture to handle 10,000 concurrent users?”
• “What would need to be true to meet our basic security compliance standards?”
• “What would need to be true to validate our core user experience assumptions?”

Find the Reframe

Language is powerful. Be mindful and intentional with the words you use, the tone, and the phrasing. Often, a simple reframe can unlock new perspectives and move you forward. There are three types here, and countless others you can add to your toolbox.

The core learning is to ask questions. Move out of Closed Statements and into Open Questions. Don’t get consumed by problems, create the wrong solutions, or let uncertainty paralyze you.

Find the Reframe Unlocks to open possibilities.