<aside> 🔗
Source: https://www.ryansinger.co/framing/
</aside>
<aside> 🤖
Framing is a new step introduced before Shaping in the Shape Up process. It focuses on identifying and evaluating problems to determine if they are worth solving and have business value. This ensures proper justification for shaping efforts, avoiding underdeveloped pitches and improving prioritization. Framing sessions involve narrowing down problems, assessing their impact, and aligning on whether to proceed with shaping, without committing to a build cycle yet.
</aside>
Framing is all about the problem and the business value. It's the work we do to challenge a problem, to narrow it down, and to find out if the business has interest and urgency to solve it.
The framing session is where a feature request or complaint gets evaluated to judge what it really means, who's really affected, and whether now is the time to try and shape a solution.
When I describe this to product managers, their eyes light up with recognition. "Yes, that's what I do!" They know that prioritization is not just dragging things up and down a list. It's digging in and trying to understand and define the problem. It's work that takes time.
Communicating this — that framing takes time and effort — can improve the dynamics around the backlog. When PMs feel there are too many things in the "suggestion box" to prioritize, I advise them to hold regular office-hours where anyone can bring in their top issues for conversation. The language of framing helps everyone to understand that deciding what to do involves doing follow-up work and digging in, not just saying yes or no.
What happens in a framing session? In a typical framing session, a shaper and a product manager or business person are digging into what they know about the business and the customer to narrow down the problem. Which customer segment is affected? How valuable is this segment compared to the others? What other things are going on in the business that need our attention? You'll sometimes see live SQL queries and people pulling up past customer research data in a framing session to answer a question or narrow down the opportunity.
[See also: We did all this discovery... now how do we decide?]
The output of a framing session is a well-framed problem: something where the business says "if we can shape this into something doable and execute within X weeks, that will be meaningful to us." There's a commitment to spend time shaping, but not yet a commitment to go into a build cycle. That final bet still needs to be made based on how the shaping goes
📌 Tip from Ryan: Don’t mix shaping into the framing doc. Keep framing focused on the why and what, not the how.