Healthy product discovery and delivery involve **moving fluidly** between high‐level goals and lower‐level concrete decisions. Below is a way to read the diagram attached here through the lens of *Abstraction Hierarchy*:
1. Wishing (High Abstraction)
- **Submit raw ideas**
- **Very high level**: The team is exploring the opportunity space and the seed of an idea without committing to specifics.
- Here, you are primarily in “blue sky” thinking—what could we solve or build in an ideal world?
- **Time to frame / Pursue**
- Still high‐level but a **slight move downward** to decide which ideas are worth exploring further.
- You’re establishing criteria for “why this idea might matter” but not yet deeply concerned with execution details.
2. Framing (Broad, but Narrowing the Opportunity)
- **Narrower opportunity & outcome**
- You step **down** one notch to clarify the real *push* behind your raw ideas.
- “Narrower outcome” signals that you’re still somewhat abstract but you’re starting to converge on a direction.
- **Time to shape (Bet value risk $)**
- A **pivot point**: you go back **up** briefly to weigh the bigger picture (risk, value, viability) before heading down into shaping solutions.
- This ensures what you shape is still aligned with a larger purpose.
3. Shaping (Mid‐Level Abstraction)
- **Shape / Viable technical paths**
- Moving **down** the hierarchy by turning the framed outcome into a plausible solution approach.
- You compare multiple technical or design paths, looking for feasibility and potential pitfalls.
- **Challenge / Spike / Unknowns / Knowledge of how things work**
- You dip even **further down** here when you tackle “unknowns.”
- **Spikes** and **proofs of concept** are very concrete experiments: you test an assumption at the technical level or do a design prototype to see if it stands up in reality.
- “Knowledge of how things work” is the result of going down to the details and then **coming back up** with insights for the bigger picture.
- **Package**
- Summarizes what’s been learned, bringing it **back up** one step: you create a coherent proposal or “package” to share with stakeholders that also functions as an input to the time-boxed build cycle.
4. Building (Concrete)
- **Alignment on commitment / Commit**
- A move **up** in abstraction again to align everyone on scope, budget, and schedule.
- But “commit” signals the threshold to the most **concrete** phase: execution.
- **Fixed time to build, e.g., six weeks (Bet value risk: $)**
- As soon as you set that time box, you’re heavily in the real constraints domain.
- **Break down, cluster, and sequence**
- Another move **down** into the *mechanics* of how you will organize tasks.
- Very execution‐focused: implementation tasks get populated.
- **Wire affordances to code**
- Among the most **concrete** steps: actual implementation details, and connecting interface elements to real functionality.
5. Finishing (Lowest Abstraction, Tangible Outcome)
- **Finish/Polish per vertical slice scope**
- You remain at the **bottom** of the hierarchy, refining the actual product.
- All the design polish and final touches happen here.
- **Finished experience**
- The result is now **fully concrete**—a tangible product or feature in users’ hands.
Moving “Up and Down” Continuously
Although the diagram might look like a left‐to‐right flow, in practice you constantly:
- Go **down** when you need more detail (technical or design specifics).
- Then go **up** if you need to revisit the broader picture or re‐align on outcomes.
That cyclical up/down motion is how you balance feasibility, usability, and viability. You never stay “purely abstract” or “purely concrete”—instead, you move up and down the abstraction levels to keep the right level of variation and focus at the right time within a range.