A prototype for story pointing uncovered a larger participation problem
StoryJam began as a lightweight create-a-thon prototype for Agile story pointing. The interaction worked, but it was unclear whether the problem it solved was important enough to justify building a product.
Meeting utility
↓Participation infrastructure
The strongest signal was not story pointing. It was the way simultaneous reveal protected independent contribution before group influence entered discussion.
I led research and product framing to determine whether the opportunity extended beyond a single ceremony. The project shifted from a meeting utility to a system for preserving independent contribution before discussion.
The challenge was not improving the prototype. It was determining whether the problem was real.
A working prototype raised a bigger product question
StoryJam started as a create-a-thon prototype for remote story pointing, where it won Best All-Around and People’s Choice. The original prototype demonstrated a simple interaction: participants submitted responses independently, then revealed them simultaneously before discussion.
Initially, we treated this as a lightweight improvement to story pointing. But before scaling the product, we needed to understand whether the interaction solved a meaningful problem beyond a single Agile ceremony.
At the same time, teams across Ford were rapidly shifting into fully remote collaboration during COVID. Meetings that once relied on in-person facilitation cues now depended entirely on digital participation patterns.
My role was to shape product strategy, participate in research and synthesis, and help the team translate behavioral patterns into a product direction.
The question was no longer, “Does the interaction work?” It became, “What problem does this interaction actually solve?”
The project began as a validation effort, not a product roadmap. Before investing further, we needed to understand whether the participation breakdown we observed was isolated to estimation sessions or reflected a broader collaboration problem across remote teams.
Participation appeared open until the first responses became visible
Across interviews and observed sessions, teams appeared to have open participation structures. Everyone technically had the opportunity to contribute.
But contribution patterns changed once the first responses became visible. Early input consistently shaped the direction of the conversation, and independent thinking narrowed before most participants had contributed.
- Early responses shaped direction before others committed
- Later responses clustered around visible input
- Senior voices unintentionally anchored discussion
- Quieter participants delayed contribution or contributed less often
The issue was not simply that some people talked less. The meeting structure itself was influencing participation behavior. To see where influence entered the meeting, I mapped the sequence of participant and facilitator behaviors across the full session.
The pattern was bigger than story pointing
The map showed that participation breakdowns were not tied to a single ceremony. Similar patterns appeared across planning, retrospectives, prioritization, estimation, and cross-functional decisions.
What initially looked like a facilitation issue began to resemble a broader participation infrastructure problem. Remote meetings still allowed contribution, but the timing of visibility shaped whose input influenced the room.
The research no longer pointed toward a better estimation tool. It pointed toward a broader participation model for decisions where independent input needed to surface before the group narrowed.
The strongest signal was not tied to story pointing at all
The interaction appeared valuable. But the original use case might not be.
One finding kept repeating throughout the research: the simultaneous reveal interaction improved contribution quality, but the value was not specific to estimation.
Teams responded positively because the interaction changed when influence entered the discussion. Participants could contribute independently before seeing dominant opinions, senior perspectives, or emerging consensus.
At the same time, story pointing itself was becoming less central for some teams. If the participation pattern mattered more than the ceremony, the product could not remain narrowly focused on Agile estimation.
Strategic shift: The interaction was more valuable than the original product framing. That forced the work to move from validating a workflow to understanding the broader behavioral patterns underneath it.
This was not a story pointing problem. It was a participation timing problem.
Initially, we treated StoryJam as a lightweight collaboration tool for Agile estimation. The research revealed something different.
The core value did not come from estimation itself. It came from delaying social influence until after participants had contributed independently.
That changed what the product needed to optimize for: independent contribution, simultaneous participation, facilitation without dominance, and discussion after contribution rather than before it.
Not better story pointing.
Better conditions for group judgment.
The product category changed from meeting utility to participation infrastructure: a reusable model for changing when influence enters the room.
The key design move was sequencing: capture input first, reveal it together, then discuss.
Independent input was protected through simultaneous reveal
Influence timing
The interaction was intentionally designed to delay social influence until every participant had committed independently.
The goal was not faster consensus. It was preserving signal quality before group dynamics reshaped responses.
Anchoring bias operates on a simple mechanism: exposure before commitment. The system worked by inverting that sequence — commitment first, exposure after.
Open session begins
All responses are visible in real time.
Early responses appear
First input sets the reference point.
Anchoring takes hold
Subsequent responses cluster around the anchor.
Decisions narrow
The group converges before independent thinking surfaces.
Private input collected
Each participant responds independently.
Responses remain hidden
No visibility until everyone commits.
Simultaneous reveal
All perspectives surface at the same moment.
Independent perspectives surface
Teams converge with genuine diversity on the table.
The core mechanic: changing when visibility enters the system changes what teams have to work with.
The MVP needed to support real participation dynamics, not ideal workflows
Once the participation model became the focus, the product architecture had to change with it. The MVP could no longer assume perfect facilitation, fixed meeting structures, single-round participation, or predictable attendance.
That required designing for the messiness of real collaboration: late joins, repeated voting, shifting discussion, facilitator coordination, and multi-round consensus building. Each product decision reinforced the same behavioral goal: preserve independent contribution before influence enters the discussion.
Addressing four failure patterns
Six rules for protecting independent input
Once the system optimized for participation timing instead of estimation speed, several product decisions became necessary. Each introduced additional complexity, but protected the core behavioral pattern the product depended on.
Capture before visibility
Input stays private until everyone has had a chance to contribute.
Reveal simultaneously
The room sees the range of thinking at once instead of following early anchors.
Discuss after input
Discussion becomes a response to independent thinking, not a substitute for it.
Support multiple rounds
Teams can revise after seeing the range of input — convergence earns its place through iteration.
Separate facilitation
Facilitators guide the process without becoming another source of influence over content.
Fit real meetings
The system must support late joins, resets, and facilitator improvisation, or it won't survive contact with real teams.
Participation platform, not pointing tool
The convergence failure was not limited to estimation. The same pattern appeared across retrospectives, prioritization sessions, and decision reviews.
Advocate for a general-purpose participation platform instead of a tool optimized for one Agile ceremony, one that could be declining.
A general system risked becoming too abstract without ceremony-specific affordances. Scope discipline had to compensate for what specificity gave up.
Post-launch usage showed teams extending the product across contexts it wasn't designed for. The behavioral model generalized because the structural failure had.
A system for divergence before convergence
The system protects independent input before the group narrows
These decisions combined into a single participation model that protects independent thinking before the group begins to converge.
The model was designed around a repeated cycle: capture input independently, reveal simultaneously, discuss after visibility, iterate through rounds, and facilitate without adding influence.
Capture
Participants respond privately.
Reveal
Responses appear together.
Discuss
The group sees range before debate.
Iterate
Teams revise through rounds.
Facilitate
Guide process without adding bias.
Teams entered discussions with more perspectives already visible
The most important outcome was not faster meetings or smoother facilitation. It was a change in contribution behavior.
Participants contributed earlier and more independently because responses were captured before group influence could shape them. Senior voices no longer established the starting point automatically, and quieter participants entered discussion with their input already represented.
Post-launch data showed teams extending the same participation structure to retrospectives, prioritization sessions, and decision reviews. That generalization was the signal: the behavioral model held because the underlying failure was consistent.
Quieter voices contributed before the room narrowed
Input was captured from more participants before early voices set direction. Contribution became a structural property of the session, not a function of who spoke first.
Facilitation became a system property
Facilitators gained structural leverage without needing to moderate more actively. Equalizing contribution timing gave them space to guide without adding another layer of influence.
Retention was a product signal, not just a growth metric. Teams returned because the participation structure worked: input was captured before discussion, giving every participant a voice before the group began to converge. That behavior is harder to fake than a high satisfaction score.
Leading a 14-person team across the US and India — where most members never share the same office, and staying quiet is far easier than speaking up.
“A tool I am using to build psychological safety is StoryJam. It builds psychological safety because people get to state their opinion without being biased by other people’s answers first. Everyone on the team participates and hopefully feels valued. This greatly improves the quality of our discussions and encourages challengers to open up in a safe way.”
— ITT Global Services Transition Manager
Senior enough to know he should hold back, self-conscious enough to notice when he didn’t. He tried to leave space for others — but when the room went quiet, he’d fill it.
“It changed our story pointing sessions. I used to dominate discussion — now more people speak up.”
— Senior Software Engineer
Product direction was shaped through structured discovery and risk reduction
Once the team recognized that the problem extended beyond story pointing, the next challenge was deciding whether participation imbalance represented a meaningful systems problem or a narrow workflow issue.
To reduce uncertainty, I facilitated structured discovery around opportunities, assumptions, participation risks, and possible intervention strategies. The goal was not to generate a long list of features. It was to identify which collaboration failures were recurring enough to justify broader product investment.
The team used opportunity mapping and assumption prioritization to define multiple participation hypotheses, then identified lightweight experiments to test which interaction patterns most effectively preserved independent input before influence entered the room.
The project changed how I think about collaboration systems
Mechanics scale. Intent does not.
I initially approached StoryJam as a workflow optimization problem centered on Agile estimation. The research revealed that the more important variable was participation timing.
That shifted how I thought about collaboration tools more broadly. The most influential systems are often not the ones that control decisions directly. They are the systems that shape when people contribute, how influence spreads, whose perspectives appear first, and which voices become visible.
The project changed my understanding of facilitation from managing discussion to structuring the conditions under which contribution happens.
When the problem is structural, change the structure.
Decision-level lesson: Participation is not created by asking people to contribute more. It is created by designing conditions where contribution can happen before convergence begins. The timing of visibility is a product decision, and many collaboration systems get it wrong by default.
A story pointing prototype revealed a broader collaboration problem
StoryJam began as a create-a-thon prototype: a lightweight tool for story pointing built in 2.5 days. It worked for a single ceremony, but it was unclear whether the problem it solved was large enough to justify building a product.
FordLabs leadership asked us to evaluate whether this was worth scaling. That meant understanding not just whether the interaction worked, but whether the underlying problem existed beyond a single use case.
What started as a focused evaluation quickly expanded into a broader question about how participation actually works in remote team meetings.
The prototype worked, but the product opportunity was still unproven.
The create-a-thon prototype demonstrated that the interaction could work for story pointing. What it didn’t answer was whether the problem it addressed was widespread enough to justify building a product.
At the same time, teams across Ford were shifting to fully remote collaboration during COVID. Meetings that once relied on in-person cues were now happening entirely through tools like Webex and Slack.
In this environment, it became easier to withhold input and harder to gauge participation through nonverbal signals. But it was unclear whether this was a meaningful product opportunity or simply a temporary side effect of remote work.
The task was not to scale the prototype immediately, but to determine whether the problem was real, how broadly it applied, and whether it justified investment beyond a single use case.
Before investing further, we needed to understand whether the problem extended beyond story pointing and whether teams would adopt a tool like this.
Participation looked open until the first responses appeared
Across 9 interviews and 13 observed sessions spanning planning, retrospectives, and prioritization, teams appeared to have open participation. Everyone had the opportunity to contribute.
In practice, contribution was uneven. Patterns repeated across teams, meeting types, and levels of seniority.
- Early responses appeared first and set the tone for the discussion
- Subsequent responses clustered around what had already been shared
- Senior voices shaped direction, even when unintentionally
- Quieter participants contributed less, or waited until later in the discussion
These patterns appeared consistently, regardless of facilitation style or meeting format.
Teams had mechanisms to contribute, but those mechanisms did not result in balanced input.
The pattern extended beyond one ceremony
The research showed consistent patterns, but not yet a clear product direction. I used two synthesis artifacts to structure the problem and understand where value might exist.
Mapping where participation broke down
The story map revealed that these patterns were not tied to a single ceremony. Similar breakdowns appeared across planning, retrospectives, and other types of meetings.
If the problem was not specific to story pointing, then the opportunity space needed to be broader as well.
Mapping where the product could create value
This made it possible to compare different directions, rather than assuming the solution should stay centered on story pointing.
The product couldn’t be limited to story pointing
We initially approached StoryJam as a story pointing tool. But interviews showed that story pointing itself was declining across teams, which meant a ceremony-specific tool would have limited adoption.
At the same time, the participation gaps we observed, uneven contribution, delayed input, and missing perspectives, appeared across many types of meetings.
This shifted the direction. Instead of optimizing a single workflow, we designed for meetings where diverse input mattered and where every participant needed a chance to contribute, even if they didn’t speak.
The MVP had to support real meetings, not ideal ones
The reframe shifted the focus from building a story pointing tool to designing a system that could support participation across different types of meetings.
Instead of optimizing a specific workflow, we focused on the sequence of interaction itself: how input is captured, when it becomes visible, and how discussion unfolds.
Designed as a system that could support planning, retrospectives, and other collaborative sessions, not just story pointing.
Created a facilitator role that could manage sessions, advance rounds, and support the group without shaping outcomes.
Designed for repeated voting and discussion cycles rather than one-time input, reflecting how real teams actually work.
Supported late joins, early exits, and session resets so the system could function in real meeting environments.
Success meant preserving participation, not just driving usage
Because StoryJam was designed to improve participation, success could not be measured by adoption alone. We needed to understand whether the system was actually helping teams contribute more independently before discussion.
I defined the analytics instrumentation plan before launch to capture both usage and behavior within sessions.
| Signal type | What we tracked | Why it mattered |
|---|---|---|
| Leading indicators | Vote submissions, session duration, room size | Showed whether teams were using the core interaction |
| Behavioral signals | Participation rate, response timing, session completion | Indicated whether input was being captured before discussion |
| Lagging indicators | Monthly active users, repeat usage, satisfaction | Showed whether the product had sustained value |
| Launch learning | A/B test on launch CTA | “Try StoryJam” achieved 2.00% CTR vs. 1.36% for “Try it Now” |
Broader adoption required more system complexity
Designing for participation required tradeoffs. Many decisions increased complexity, but were necessary to preserve the core interaction pattern across real meeting conditions.
| Observation | Decision | Tradeoff |
|---|---|---|
| Story pointing was declining across teams | Expand from a story pointing tool to a general collaboration system | Lost ceremony-specific optimization in favor of broader adoption |
| Participation patterns appeared across many meeting types | Design for reusable meeting rooms rather than one-off sessions | Added complexity in state management and session reset |
| Facilitators needed control, but could bias outcomes | Create a facilitator role without voting influence | Required more complex role logic and permissions |
| Discussion was iterative, not one-time | Support multi-round input and re-voting | Increased interaction complexity and state transitions |
| Meetings are unpredictable | Allow late joins, early exits, and flexible reveal timing | Reduced control over “perfect” session flow |
Teams entered discussion with more voices already on the table
“The quality of conversation is improving as a result of getting everyone’s input out.”
Manager“I used to dominate discussions. Now more people speak up.”
Senior Software EngineerSenior voices no longer set the starting point. Quieter participants contributed earlier. Teams entered discussion with a broader range of perspectives already on the table.
The opportunity tree became a way to choose what came next
Once the MVP was in use and early signals began to emerge, I revisited the opportunity solution tree with the team. We updated it based on what we were learning and used it to focus where future investment might create the most value.
I facilitated a prioritization exercise to compare opportunities, align on direction, and distinguish near-term product learning from longer-term platform bets.
Participation problems are often system problems
This work reinforced that participation challenges are rarely about individual behavior alone. When the structure of interaction allows early input to shape the group, uneven participation becomes a predictable outcome.
The fix that holds is not asking people to behave differently. It is changing the conditions under which they contribute.
This principle extends beyond collaboration tools. It applies anywhere group input matters: hiring panels, prioritization reviews, design critiques, and increasingly, AI-assisted workflows.
When systems introduce information before users form their own judgment, they risk shaping outcomes instead of supporting them.