Prioritizing Under Highly Variable Conditions

The Invalidation Prioritization Model

Before we decide to build something meaningfully large and strategically important (a discrete (proactive/planned) project, not an unplanned request/red alert (reactive/ticket work), that is budgeted with a minimum of 2 and a maximum of 6 weeks), we often need to Frame and Shape our ideas so we know what we are dealing with. It is important to remember that planning and prioritizing happen together (much like planning and building happen together).

The invalidation prioritization framework, covered in this article, contains in it a compelling set of thinking tools for deciding what new products or features to bet on in a stochastic world. Why is invalidation prioritization powerful? Because figuring out the right stuff to build is hard since what you can't automate is to know what you should be trying to do. So if you have a model that can correctly guide you to find success, you have something precious.

The physics of a problem/an opportunity

Ideas usually come to us in a very raw form. These ideas are either too concrete or too vague. They are unrefined. The mass and the purpose of a thing are not clear and specific.

To fix this, we need to get at what the tightly defined opportunity is (a customer's unmet or unrealized need, desire, or internal motivation) so we can make an informed decision.

One way to do this is to create a Frame.

(Problems/opportunities generally come from a keen observation or a good question.)

A Frame contains two key parts: The context and the desired outcome. This lets us spell out a specific problem case when if that thing gets better, then the solution works.

The context is about describing a specific situation in the past. It includes the social, emotional, and functional forces shaping the user’s task and objectives at a given point in time. It is critical to focus on the past to ensure we can feel the cause-and-effect relationship. The context ideally includes how the current way (the solution or workaround) is being used today and what baseline outcome is generated from it (progress being made and/or not being made). We must describe how the current way is broken or falls short of expectations.

The desired outcome is what we want the new world to look like. It is solution-agnostic. It is the weight loss, not the treadmill.

So, in summary, there are three things we use to define the physics of a problem/opportunity: The target situation (point-in-time context), the current solution and compensating behaviors, and the baseline output/outcome or result (SSR).

Below are some questions to ask to get at the context and desired outcome. We ask these questions once we have a target segment in mind and an understanding of what we want to know about what people (the high-level segment, e.g., teachers or students (or slightly more detailed like middle school students in Nigeria)) do today. This is about focus.

What we ask the world (and sometimes we ask ourselves, especially if we are scratching our itch/have a deep motivation for a topic):

1. What are you doing today (not what we think they need)?

2. When did you have the first thought that you might need something like Path X?

3. What were you doing in that period before adopting Path X?

4. Why did you not just continue with what you were doing before but instead adopt Path X, (especially if there was a time elapsed between the thought of the struggle and the adoption of Path X)?

5. What is bad about that (what you were doing before)?

6. Before you used/bought Path X, what were you picturing would be different after you used/bought Path X?

Mapping these events over a situational timeline can be very powerful in capturing technology-agnostic requirements. You can feed the target segment and their events through these five foliated steps below:

1. Initial thought (the struggle/spark of demand)

2. Passively looking

3. Actively looking

4. Deciding (making trade-offs)

5. Buying/Selecting

What we ask ourselves:

• Does this address a high-level focus area/theme of the business? If not, why do this now?

• Do we feel comfortable, or do we feel uncomfortable, about shaping this Frame?

Without a Frame, it is really hard to begin thinking about various design solutions to find one with good fit and prioritize that work with confidence.
This step is critical because it helps us falsify—it helps us to find out what to say no to, not by describing the good that will happen by solving XYZ problems/opportunities but by knowing what goes wrong when we don't do something about XYZ problems/opportunities.

Designing the hard edges and the soft middle

Shaping is conceptual design and means two things:

1. Generating multiple possible solution path ideas and 2. Getting to fewer unknowns about some solvable version.

Generating multiple possible solution paths means thinking of more than one way to address the Frame. To do this, we come up with the criteria we believe are important from the Frame so we can line up multiple solution paths (at least two) next to each other and see how different paths address each criterion and how well.

Getting to fewer unknowns means the proposed solution path selected is solvable — that some version of this idea can be generated from the directional "schematics" without having to directly start executing on the solution path itself. It is about understanding the key macro interactions of the proposed solution path needed to address the fitness function. The important thing is to not over or under Shape where it is not needed. That is, we do not want to go into a time-boxed project (something that has an appetite of 2 (small batch projects), 3 or 4 (medium batch projects), and 5 or 6 (large batch projects) weeks) with a lot of uncertainty about what to do. We also do not want to go in having painted ourselves into a corner (over-specifying), making it hard to leverage the discovered work we uncover when we are in the context of development/execution and cut scope by making trade-offs as needed.

Shapers can judge the configuration of the whole, at the right fidelity, component by component, to move fast and cover possible solution paths without getting dragged down into the wrong level of detail.

Intrinsic to the definition of Shaping is the notion that something can be executed from it in more than one specific way. The fact that there are many ways to implement a solvable design shows that we specified it at the right level of abstraction.

It's one thing to say: "Design a kitchen. (Vague sampling.)
"It's another thing to say: "Here are the specific and fixed scope specs of the kitchen, go build it.” (Too much concreteness.)
And it's yet another thing to say: "A good kitchen has windows giving light from two sides. The counters are long and generous along the south side to get the light. Place a big table in the middle and light it from above to create an eating atmosphere."

The latter is a very short example of what a better working description of shaping language looks like. Writing at the right level of abstraction (and using lightweight designs) means describing the relationships between elements rather than rigid forms, thus enabling a flexible, iterative approach to problem-solving. This means being vague when we can’t know enough (zooming out to macro interaction thinking) and being concrete when we can gain knowledge of a particular form (zooming into the details) before implementing a design.

This approach can enable Launch Teams to work within constraints while leaving the specifics open according to the realities of the project. This is why we want to keep time fixed and scope variable.

Enough latitude to enable breakthroughs. Firm boundaries to enable agreement. Specifics when hard-earned knowledge informs decisions. Trust when we know that capable people can work it out themselves.

A Shaping session for a specific Frame happens live and generally lasts between 2-3 hours.
These are working sessions, not meetings or brainstorms.
They consist of a small group of both technical and non-technical people working from a specific and narrow problem Frame. Sometimes a spike needs to happen and, e.g., the technical shaper requires an additional Shaping session, and other times that work happens live in the session itself.

Think of Shaping as solution investigation and not solution development. That is not to say that sometimes we need to, e.g., open up a code editor and carry out a spike. But this is all still pre-development work.

In other words, effective Shaping is done collaboratively when there is a well-defined Frame, the Frame has been selected as something valuable enough to Shape, and there is a time-budget value set to the problem/opportunity for constraint Shaping.

Without Shaped ideas, it is hard to compare and contrast what to build next, i.e., it's hard to prioritize which ideas to dispatch to development with confidence.

Prioritization is not only about the how but the when

The Hopper machine: Once we have raw ideas in a pool of options to consider; we can prioritize them if they are worth Framing. Once we have Framed ideas; we can prioritize them for Shaping. Once we have Shaped ideas; we can prioritize them for development.

Prioritization is a discussion. People forget that.

No framework or algorithm will produce an answer for you. You have to talk in detail about the things on the table and decide with each other what to build and when, and if at all.

Here are some questions to ask when deciding which Shaped work to build next:

• Does this problem/opportunity still matter?

• Does the time budget feel right?

• Is the solution attractive/does it satisfy the key criteria laid out when shaping (does it address its fitness function well, i.e., when the current outcome improves, then the solution works.)?

• Are the right people available?

• Can we deliberately allocate talent to this project for the time we want to spend on it without dragging them into unplanned/reactive work?

But when do we ask these questions? As close to the moment of execution as possible (during post-launch periods (Ramp-up)).

If we prioritize work well before we do the work, we'll run into slippage...or worse…conformity.

We want to be decisive and then execute, ideally at most one week after we decide, so we can ensure we are operating within the current context of the business.
Inaction is irreversible. Be decisive. That said, we do take the time to think, as now is not always the best time to decide. Incubate on it. We think, debate, persuade, listen, reconsider, and then someone decides/bets. If you disagree, that’s fine, but once the decision is made, it’s time to commit and support it completely.

---

Additional thoughts on prioritizing when shaping and building:

When prioritizing, start with things that contain more outgoing than incoming connections and those things that are the most unknown first. Always consider an impact-to-effort ratio but do your best to find the natural sequence of work above all else. We also want to ask ourselves: What can be solved together as one whole, and what can be solved separately? We want to know where we can work on one thing without getting into the details of another thing, i.e., to set boundaries where you can change one thing without affecting other things.
This is about identifying the epicenter or epicenters of an idea and developing the focus to work on the irreducibly independent parts, i.e., separate, but related, scoped-off parts, each solved as coherent chunks.

Always trade scope for quality, as cutting and shipping are often equally important (doing half a thing well versus doing a whole thing half-assed is a much better way to make software). This also ensures you stick to your time budget to preserve optionality by preventing never-ending projects (overruns) and reducing bloat.

Check out this article here for more on framing and shaping.

It also helps to visualize when to prioritize things (using a fixed-time variable-scope approach) model on a calendar. See that operating rhythm example below:

Innovation Portfolio Risk Management

When looking beyond six-week cycles (e.g., toward half-year and annual planning), thinking of allocation instead of fixed, long-range plans can be more effective. One way to do this is to assign percentages to different types of innovation—such as Efficiency, Sustaining, and Transformative Innovation—following a guideline like 70%, 20%, and 10%, respectively.

Next, overlay these allocations onto the Cycle Calendar. For instance, if you have seven cycles in 2025 for one Launch Team, you might commit four (or five) of those cycles to Efficiency Innovation, one (or two) to Sustaining Innovation, and one to Transformative Innovation (or one Launch Team 100% on Sustaining (with an H1 focus and stop-loss backstop) and another Launch Team 100% on Efficiency Innovation). By layering your product risk portfolio on top of a Cycle Calendar, you make strategic themes more concrete and actionable without having to plan out and commit to projects way ahead of time.

This approach helps focus your team on the kinds of ideas to put into and select from the Option Pool and clarifies how different types of ideas align with your business strategy’s overall risk appetite. This interplay ensures that allocation decisions are always tempered by the real, shaped ideas of potential bets in the Hopper, not just a theoretical, e.g., 70/20/10, plan.

By forcing a “Frame and Shape first” rule, you ensure that your entire portfolio is grounded in real, bottom-up customer strategy. This helps you avoid intangible or ill-defined plans or allocations that meander without a clear user outcome.

Ultimately, the biggest shift is mental: Planning and prioritizing aren’t separate from doing; they’re woven into each cycle. This ensures your resource allocation—no matter the specific percentages—remains grounded in real user needs, active collaboration, and the reality of ever-changing market dynamics.

There’s No One-Size-Fits-All: Allocation frameworks vary by a company’s mission, differentiation strategy, and culture.

Look at the core constraint for your company. Is it budget? Engineering hours? Availability of certain specialists? Identify that constraint (t, $, talent, or some combination) and express your percentages in a way that’s easy for everyone to understand and respect.

Putting It All Together

1. Maintain a Dynamic Idea Funnel

   • Raw/Unframed Ideas → Framed Opportunities → Shaped Solutions.

   • Only shaped solutions get pitched to fill the next cycle’s time budget.

2. Deliberately Allocate Types of Bets

   • Whether you call them Efficiency vs. Sustaining vs. Transformative or Core vs. Adjacent vs. Breakthrough, have intentional targets (e.g., 60/30/10).

   • Review these targets in each Ramp-up period to see if you’re on track or need to rebalance.

3. Incorporate Invalidation Prioritization

   • Framing + shaping + time-boxed “build or kill” help teams aggressively test assumptions and preserve optionality.

   • Kill questionable ideas early; funnel your best-shaped solutions into build cycles.

4. Use Fixed Time, Variable Scope

   • Bake in the mindset that every 2–6 week project can and should be reduced if it risks overruns. This prevents bloat and ensures frequent planning and delivery, as they both must go together.

5. Short Planning Horizons, Continuous Discovery

   • By never committing more than ~50 days out, you preserve agility. You still have a strategic direction (e.g., more emphasis on “Transformative” in later cycles), but the actual bets get decided near real-time.

6. Ramp-up = Reflection + Planning/Betting

   • Clean up previous cycle work and host betting sessions every ~7 weeks to ensure planning is incremental and dispatches close to execution.

7. Decide, Then Do

   • Once you bet on a shaped solution, start it quickly (within a week). No prolonged backlog queues that invite re-thinking or “feature creep.”

Related Notes: