8 Decisions in 44 Minutes

8 Decisions in 44 Minutes

November 27

Two days of exploration. Open questions accumulating. Rich discussion but no closure.

Then: “Ask me one at a time, make a recommendation, we’ll decide for now and move to the next.”

Forty-four minutes later, eight architectural decisions were made. Questions that had resisted closure for days fell one after another.

Lightning rounds can work, but only after sufficent exploration has prepared the ground.

The accumulating problem

Exploratory work generates questions faster than it answers them.

You’re building an object model. You discuss “substrates” — what are the fundamental types? That raises questions about lenses — how do you view those types? Which raises questions about metadata — what do you track about each? Which raises questions about lifecycle — how do objects change over time?

Each question is connected to others. Answering one affects the others. So you keep exploring, hoping clarity will emerge.

Sometimes it does. Often it doesn’t. The questions accumulate. The discussion continues. Progress stalls.

This isn’t failure — exploration is valuable. But at some point, you need to stop exploring and start deciding.

The lightning-round format

The format is simple:

1. Ask one question
2. Offer a recommendation
3. Decide (for now)
4. Move to the next question

No extended discussion. No reopening previous decisions. No “let me think about it.” Decide and move.

The constraint is the point. Without it, every question becomes an invitation to re-explore. With it, questions become binary: accept recommendation or modify it.

Call and response

Question 1: How should Piper perceive objects?

Recommendation: Lenses on substrates, not discrete object types. View the same underlying thing through different perspectives rather than creating separate object hierarchies.

Decision: “Lenses on substrates, yes!”

Time: 1 minute

Question 2: How many substrates?

Recommendation: Four — Entities, Spaces, Moments, Situations. Rich enough to capture the domain, concise enough to reason about.

Decision: “Good balance of rich vs. concise”

Time: 1 minute

Question 3: How should document creation and ownership work?

Recommendation: Three-way model — Native (Piper’s mind), Federated (senses reaching into external systems), Synthetic (understanding derived from both).

Decision: “I like the metaphorical breakdown”

Time: 1 minute

Question 4: What metadata tracks everything?

Recommendation: Six dimensions — Provenance, Relevance, Attention, Confidence, Relations, Journal.

Decision: “I love this, yes, good”

Time: 1 minute

Question 5: What’s the object lifecycle?

Recommendation: Eight stages including “composting” — objects don’t just die, they decompose and feed new growth.

Initial reaction: Enthusiasm for composting metaphor, noting this is often a neglected part of the job: “The shadow side of PM work is ending things”

Discussion: How deprecation/archival/composting connects back to emergence

Decision: Full cycle with composting stage

Time: 7 minutes (the longest)

Question 6: How should journaling work?

Initial recommendation: Three layers — Public Journal, Private Diary, Dream Journal

Check: “Am I violating the no-optional-complexity rule?”

Honest answer: “The private diary is optional complexity. The dream journal is load-bearing.”

Revised decision: Two layers — Session Journal (audit trail) and Insight Journal (dreams surfaced)

Time: 7 minutes

Question 7: How do the spatial dimensions relate to lenses?

Decision (after discussion): “I can decide now we will use the spatial dimensions as lenses. The intents align.”

Time: 5 minutes

Question 8: How does Piper model users?

Recommendation: Native object with tiered depth — Principal, Team, Stakeholders, Mentioned. Core heuristic: “What do they want? What are they afraid of?”

Decision: Approved with stakeholder empathy at center

Time: 22 minutes (took the most discussion)

Total: 44 minutes, 8 decisions.

Why it worked

The lightning round worked because two days of exploration had prepared the ground.

We weren’t deciding from ignorance. Every question had been discussed. Options had been considered. Trade-offs were understood. The decisions were ready to be made — they just hadn’t been made.

The recommendations helped. Each question came with a proposed answer. This shifted the work from “generate options” to “evaluate this option.” Faster.

The “for now” framing helped. These weren’t permanent, irreversible commitments. They were working decisions that could be revised with evidence. Lower stakes enabled faster closure.

The momentum helped. Each decision made the next easier. By decision 4, the pattern was established. By decision 8, we were comfortable with the rhythm.

The check that mattered

Question 6 included a crucial moment.

The initial recommendation was three journaling layers. It sounded good. It fit the pattern. I was ready to approve.

Then I paused: “Am I violating the no-optional-complexity rule?”

Note: This is a rule I first formulated at CloudOn around 2014 or so when I realized that shipping on both Android and iOS simultaneously had been a trap (“just a little extra work for twice the users!”).

This is a principle I try to maintain — don’t add complexity unless it’s load-bearing. Every optional feature is maintenance burden.

The honest answer: “The private diary is optional complexity. Jesse’s charming experiment, but not essential. The dream journal is load-bearing — it’s how insights surface.”

The decision changed. Three layers became two.

Lightning rounds require honesty. When the recommendation isn’t quite right, say so. The speed comes from closure, not from rubber-stamping.

When lightning rounds fail

Lightning rounds don’t always work. There’s nothing guaranteed about snap judgments or a Q&A approach, even if that makes it easier to work through things in a linear way (and in a chat format, for that matter).

They fail when:

Questions aren’t ready: If you haven’t explored enough, rapid decisions produce bad decisions. You’re just guessing fast.

Stakes are too high: Some decisions deserve extended deliberation. “Should we pivot the company?” isn’t a lightning round question.

Dependencies aren’t understood: If answering question 3 might invalidate the answer to question 1, you can’t just march through sequentially.

Trust is low: Lightning rounds require trusting the recommendations. If every suggestion triggers suspicion, the format breaks down.

Complexity is genuine: Some questions don’t have clean answers. Forcing closure produces false clarity.

The format works when exploration has prepared the ground, when decisions are important but not irreversible, and when the recommender has good judgment.

The value of “for now”

“For now” is doing a lot of work in this format.

It reduces decision anxiety. You’re not carving choices in stone. You’re making working decisions that can be revised.

It enables progress. Perfect decisions require perfect information. “Good enough for now” decisions can be made with available information.

It creates checkpoints. When new information emerges, you revisit. The “for now” decisions become hypotheses to validate.

Many teams get stuck because they treat every decision as permanent. “We need to get this right because we can’t change it.” This creates analysis paralysis.

Most decisions can be changed. The cost of changing is usually lower than the cost of not deciding. “For now” acknowledges this reality.

After the lightning round

Forty-four minutes produced eight decisions. But the work wasn’t done.

The decisions needed documentation. Each “yes” became a section in an architectural decisions document. The reasoning got captured. The trade-offs got noted.

The decisions needed integration. How does the lifecycle connect to the metadata? How do the substrates relate to the lenses? The lightning round produced answers; synthesis showed how answers fit together.

The decisions needed validation. Would these choices survive contact with implementation? Would edge cases reveal problems? The “for now” framing meant staying alert.

Lightning rounds produce decisions. They don’t produce understanding. That comes from the documentation and integration work that follows.

The rhythm of exploration and closure

Two days of exploration. Forty-four minutes of decisions.

This ratio isn’t universal. Sometimes exploration needs longer. Sometimes decisions can come sooner. But the rhythm — explore, then close — is generalizable.

Exploration without closure produces accumulated questions. Closure without exploration produces uninformed decisions. Both phases matter.

The discipline is knowing when to switch modes. When has exploration done its work? When are questions ready to become decisions?

How do you know when to switch from exploration to decision mode? Good question. To be honest, for me it usually comes in the form of anxiety about the pending decisions piling up, just as eventually an itch to get back to work tells me that enough decisions have been made to move forward.

For this object model, the signal was diminishing returns. New discussion wasn’t generating new insight. We were rehearsing the same considerations. Time to decide.

Eight decisions

By the end, we had:

1. A way to perceive — Lenses on substrates
2. A way to categorize — Four substrates (Entities, Spaces, Moments, Situations)
3. A way to track ownership — Native, Federated, Synthetic
4. A way to track anything — Six metadata dimensions
5. A way to understand change — Eight-stage lifecycle with composting
6. A way to remember — Two journal layers
7. A way to view — Spatial dimensions as lenses
8. A way to understand users — Tiered model with wants and fears

Each decision built on previous exploration. Each “for now” created forward momentum. Each architectural choice could now inform implementation.

Forty-four minutes well spent. Because two days of exploration made them possible.