Doug Seven

A Framework for Strategic Product Thinking

As Product Managers, we’re constantly navigating a sea of good ideas. But how do we decide which ideas are truly great—and which ones we should act on now? Welcome to the second installment of my new Product Craft series. This series is all about the essential skills we, as Product Managers, use to create amazing customer experiences and deliver real impact. For this installment, I want to talk about a foundational framework that can guide how we identify and answer the case: the “Would, Could, Should” framework.

Thanks for reading! Subscribe for free to
receive new posts and support my work.

The “Would, Could, Should“ framework is a strategic planning and prioritization tool we use to help teams make great decisions. It encourages a structured way of thinking by asking three key questions about any potential solution or feature:

• Would we do this? Is this a good idea? Does it align with our product vision and business goals? This question focuses on the strategic value and desirability of the solution. It’s about whether the idea is a worthwhile pursuit in the first place.
• Could we do this? Can we actually build this? Do we have the resources, technical capabilities, and time to implement it? This question assesses the feasibility of the solution. It’s about the practical constraints and whether the idea is even possible for the team to execute.
• Should we do this? Based on the “Would” and “Could,” is this the best thing we can do right now? This question is about prioritization and impact. It forces a comparison against other potential solutions and considers factors like customer needs, market trends, and business impact to determine if this is the most valuable use of the team’s time and effort.

It’s helpful to think of “Would, Could, Should” as a strategic framework we use at the very beginning of the planning process to define the vision itself. This makes it different from many tactical prioritization frameworks that help you sort a pre-existing list of features. “Would, Could, Should” helps you create that list in the first place by starting with the customer’s core problem and working your way toward the single most impactful thing you can do next.

By systematically answering these three questions, we can move beyond simply brainstorming ideas and instead focus on solutions that are not only desirable and feasible but also have the highest strategic value and impact. This helps to ensure that our product development is aligned with business goals and customer needs, leading to more successful and well-crafted products.

Would – The Answer to the Case

The “Would” question is all about what our product would ideally achieve, and I call it the “Answer to the Case.” This framework begins with the customer’s perspective; the “Case” is the main problem or need our customer has—not just a surface-level issue, but a deeper, underlying challenge that, if solved, would truly transform their experience. “The Answer” is our ultimate solution, defining success from the customer’s point of view. This forces us to work backward from their ideal outcome, envisioning a breakthrough solution without being limited by today’s constraints. The “Would” is our North Star—inspiring us to innovate and create game-changing impact.

• What it’s about: Our long-term vision, coming up with totally new ideas, dreaming big, and the core “why” behind our product. It’s always focused on solving the customer’s main problem in the best way possible.
• Example: The “Case” is that developers spend too much time on setup, troubleshooting, and other manual tasks instead of coding. Our product would be “the Answer” by providing a single, intelligent AI agent that acts as a developer’s partner throughout the entire software lifecycle. This agent would assist with writing code, automatically generating test suites, troubleshooting deployment errors, and even providing first-line monitoring and issue remediation. This would free them up to focus on innovation rather than friction!

Could – Is This Possible and Feasible?

After we define the vision, we then explore the “Could.” This looks at what our product could potentially achieve with the resources, tech, industry trends, and team we have now or expect to have soon. It’s about checking out all the possibilities without committing to anything just yet, casting a wide net to find all the good options that fit our “Would” vision. This stage encourages broad thinking and helps us understand the full landscape of potential solutions, assessing their technical viability, resource requirements, and, importantly, whether we actually have the skills and abilities within our teams to pull it off. Sometimes, this also means considering if we need to acquire new talent, new technology, or even new businesses to bridge any capability gaps and truly achieve our “Would.” It’s about asking, “What’s within our reach, or what could be with a bit of effort, and could we actually do this if we wanted to?”

• What it’s about: Exploring ideas, brainstorming, checking if the tech is doable, finding market opportunities, seeing what resources are available, thinking about potential partnerships, and evaluating our team’s capabilities and expertise. It considers all the ways we could get closer to the “Answer to the Case.”
• Example: Given our team’s established skills with generative AI, the success of several proofs-of-concept in automated code analysis, and the recent availability of agentic AI models and workflows, we could realistically build this agent. The new models significantly accelerate our development timeline.

Should – Is Now the Right Time?

Finally, we arrive at the critical question of “Should”—this is where strategy meets the ground reality of execution. After defining our ideal state (”Would”) and exploring all feasible options (”Could”), this stage forces us to ask: Should we do this now? This question is all about prioritization and impact. It compels us to weigh the proposed solution against all other potential initiatives and determine if it is truly the best use of our team’s time and effort at this moment. To answer it, we must consider urgent customer needs, current industry trends, and the immediate business impact.

“Should” is the commitment step, where we decide not just what to do, but what to do next, ensuring we are always focused on the most valuable work.

• What it’s about: Making tough trade-offs, prioritizing initiatives, aligning with immediate business goals, analyzing ROI, and planning our roadmap. It’s about choosing the single most impactful thing we can deliver to customers right now to make progress toward the “Answer to the Case.”
• Example: While we could develop several AI-powered assistants, the most pressing developer feedback is the time wasted troubleshooting deployment errors. This is a major source of friction that directly impacts our ability to ship features quickly. Therefore, to provide the most immediate value, we should focus on building an AI agent that specializes in troubleshooting deployment failures. This agent should be able to analyze build logs, identify the root cause of an error, and suggest a specific fix, and enable a developer to approve the agents suggestion and dispatch the agent to implement it. This will dramatically reduce downtime and free up our engineering teams to focus on innovation. We should begin by focusing on the troubleshooting component, leveraging our existing PoCs, and then incrementally add capabilities for testing, coding assistance, and production monitoring. This phased approach makes the Answer to the Case achievable.

Making the final “Should” decision can be tough. To bring more objectivity to this step, especially when you have several strong options from the “Could” phase, you can use a quantitative scoring model like RICE (Reach, Impact, Confidence, Effort) or WSJF (Weighted Shortest Job First) or others. Scoring your top candidates can provide a data-informed gut check, helping ensure the team’s final decision is based on a balanced view of customer value and the effort required.

Measuring Customer Impact

Once we’ve launched something we “Should” do, our work isn’t done! This is where we measure the customer impact to see if we truly delivered on “the Answer to the Case.” It’s not enough to simply launch a feature—we need to know if it actually landed for our customers.

We do this in a few ways:

• Measuring Success with Metrics: We define clear success metrics (or KPIs) for every feature, tying them back to our business goals. For example, for a new SDK, a key metric might be a reduction in the time it takes for a customer to complete their first API call, or an increase in adoption by internal teams. Quantifying this helps us understand if we moved the needle.
• Measuring the User Experience: Metrics tell us what happened, but not why. We need to go deeper to measure how a product or feature improved the user experience. This means getting hands-on with feedback. We can run user interviews, conduct usability testing, and directly observe customers as they work. This qualitative feedback helps us understand if the new product is genuinely delightful, easy to use, and has a positive impact on their day-to-day workflow.
• Iterating and Learning from Feedback: All of this feedback and data isn’t the end of a project—it’s the start of the next one! We use what we learn to iterate on the current product, identify new problems to solve, and refine our understanding of “the Answer to the Case.” This continuous loop of building, shipping, and learning is at the heart of product craft.

So, basically, our product strategic planning is like a continuous loop:

1. Define the “Would” (The Answer to the Case): Clearly state the ultimate customer problem and our perfect solution. This is our bold vision, setting the direction for everything that follows.
2. Explore “Could”: Brainstorm all the possible ways to get to that vision, thinking about what we can do and what opportunities are out there. This widens our perspective and uncovers potential paths.
3. Decide “Should”: Pick the most practical and impactful actions to take right now, making sure they fit our business goals and resources, while always keeping “the Answer to the Case” in mind. This is where we make the tough, strategic calls to deliver real value.

This framework ensures that everything we do is customer-focused, innovative, and strategically smart. It helps us build products that truly matter and make a difference.

Beyond Planning: Using the Framework to Tell a Compelling Story

The “Would, Could, Should” framework isn’t just a great tool for making decisions—it’s also a powerful way to structure your communication and get buy-in from stakeholders and leadership. It naturally follows the “Why, How, What” storytelling model:

• Would is your “Why”: This is the inspiring, customer-centric vision. It answers the crucial question, “Why are we doing this?” and gets everyone excited about the mission.
• Could is your “How”: This demonstrates your diligence. By showing the landscape of possibilities you explored, you prove that your final recommendation is the result of rigorous strategic thinking.
• Should is your “What”: This is your concrete, actionable plan. It gives your team, stakeholders, and leadership clarity and confidence in what you are doing right now to move the vision forward.

I can’t wait to share more “Product Craft” insights in the next post!

…D7