Open Space Technology: What Sales, Support, and Product Actually Wanted to Talk About

The first time I ran Open Space Technology, for a course app’s “what should the LMS become” day, the value was in letting the room’s actual priorities surface without a pre-built agenda distorting them. Running it a second time, for a CRM product bringing sales, support, and product together for a day with no fixed topic beyond “how do we make this product genuinely better for the people who use it daily,” taught me something more specific: OST is unusually good at revealing which cross-functional conversations the organization actually needs to have, because the sessions that drew people from all three functions — rather than clustering by department — were, without exception, the most valuable ones of the day.

The structure, briefly

OST replaces a planned agenda with a live marketplace: participants propose whatever topic they personally care enough about to convene a discussion on, post it to a shared board with a time and place, and the day runs as parallel self-organizing sessions. The one governing rule is the Law of Two Feet — anyone not getting value from a session is expected to leave and find one that serves them better, no questions asked. The earlier post has the full step-by-step; here I want to focus on what happens specifically when the room spans functions with genuinely different day-to-day realities rather than one cohesive team.

Why cross-functional OST is a different animal

A single-team OST day, like the LMS one, still has everyone sharing a fairly similar vocabulary and a fairly similar view of the product. A room with sales, support, and product together doesn’t share that — a sales rep’s frustration with the CRM is about deal velocity and quota; a support rep’s frustration is about ticket volume and repeat questions; a product person’s frustration is about technical debt and roadmap tradeoffs. Left to propose topics purely from their own function’s frame, you’d expect three parallel tracks that never intersect — sales topics, support topics, product topics, each function attending mostly its own. That’s roughly what happened in the marketplace phase. What was genuinely interesting was which sessions broke that pattern.

The marketplace

Twenty-six proposed topics went up on the board across sales, support, and product — a large number for a group of about thirty, which is itself a sign OST was doing its job: giving people a low-friction way to raise something they’d been sitting on. Most sessions did cluster by function, exactly as expected: a sales-heavy session on quota visibility inside the deal pipeline, a support-heavy session on macro and canned-response tooling, a product-heavy session on technical debt in the activity-logging system. Useful, but predictable, and mostly attended by the function that proposed them.

Three sessions broke that pattern and drew genuinely mixed attendance, and those three turned out to be the ones that mattered most by the end of the day.

The first was a session proposed by a support rep titled simply “why do customers keep asking us questions the product should have answered itself” — a support-framed complaint that turned out to pull in four sales reps and two product people, because it was really a session about self-service and in-product guidance, and both sales (who wanted fewer post-sale friction points slowing account growth) and product (who owned whatever in-app help existed) had a direct stake in the answer once the framing became visible.

The second was proposed by a sales rep, on the specific gap discussed in an earlier Drawing Together exercise on the deal-handoff process — sales’s picture of handoff as automatic-and-complete versus support’s picture of it as manual-and-reconstructive. That gap had been surfaced in the drawing exercise but the fix hadn’t yet been scoped in detail, and the OST session was where three support people and two sales reps actually worked through what a structured handoff-context capture step should ask for, in more specificity than the earlier exercise had time for.

The third, proposed by a product person, was on whether the CRM’s activity-logging system could be simplified enough that support could self-serve answers to “why did this deal’s stage change” without escalating to engineering — a technical-debt topic from product’s frame that turned out to be exactly the tool support had been wanting for the ticket-volume problem raised in the very first mixed session of the day.

Why the mixed sessions were the valuable ones

The single-function sessions were productive in a narrow, expected way — each function got to air grievances and generate ideas among people who already agreed on the frame, which has value but mostly reinforces existing thinking rather than producing anything the organization didn’t already half-know. The mixed sessions were valuable specifically because they forced translation across functional vocabulary in real time, the same way pairing an employee with a manager forced translation in the leave-balance kickoff — a sales rep hearing “customers keep asking us things the product should answer” had to translate that into their own frame (fewer support escalations means faster account growth) before they could see why they cared, and that act of translation is where genuinely new, shared understanding gets built, rather than three functions independently confirming what they already believed.

None of the three cross-functional topics were on any pre-existing roadmap document going into the day. All three came out of the day with rough scopes that made sense to people across all three functions, because the people who’d actually need to execute and live with each fix had been in the room for its definition, not just its handoff afterward.

The Law of Two Feet as a cross-functional signal

Watching which sessions people left, and which function’s people left them, was its own useful data. The technical-debt-in-activity-logging session, proposed by a product person, started as product-only and stayed that way — nobody from sales or support ever joined, which on its own told the product team something worth knowing: this technical debt, real as it was, wasn’t something the rest of the business currently felt the pain of directly, and prioritizing it purely on engineering merit without that cross-functional pull was a choice to make consciously, not a natural consequence of urgency. That’s a different, more honest signal than the same topic would have produced in a product-only architecture review, where the absence of sales and support interest simply wouldn’t have been visible at all.

Failure modes and when to skip it

Cross-functional OST is more vulnerable than single-team OST to a specific failure: functions retreating into their own comfortable sessions and never mixing, especially if there’s any existing tension between the groups. If sales and support have an adversarial history — blame over missed handoffs, competing priorities for the same engineering time — people may use the freedom of Two Feet specifically to avoid the other function’s sessions rather than to seek value, and the mixing that made this day valuable simply won’t happen on its own. A facilitator who notices this early can seed it by quietly encouraging a well-respected person from one function to attend a session proposed by another in the first round, which tends to give others visible permission to do the same.

It’s also worth skipping cross-functional OST — in favor of the more targeted structures like Drawing Together or 1-2-4-All covered elsewhere in this series — when you already know the specific cross-functional gap you need to close and don’t need to spend a full day discovering which gaps matter most. OST is the right tool for finding out what to talk about; once you already know, a narrower structure gets you to a concrete outcome faster.