Episode #9: Inclusive Product Collaboration with Jon Gordner
Jon Gordner explains how curiosity, inclusive collaboration, rapid learning, and comfort with ambiguity help product teams discover better answers.
Good product decisions rarely arrive fully formed from one person. Jon Gordner explains how teams can invite broader input, turn conversation into something testable, and keep learning after a product ships.
What you'll learn
Why product management combines making, storytelling, and shared creation
How curiosity can replace reflexive disagreement in cross-functional work
When to move from discussion to an experiment or a small feature
Why ambiguity can create room for more inclusive and better-informed decisions
Product work as invention and storytelling
Jon traces his interest in product management to two childhood ambitions: becoming an inventor or a clown. He later majored in computer science and minored in drama, a combination that made product feel like a natural fit. The work lets him make things while also communicating a vision and shaping the story a product tells through use.
That blend became important during his years at Microsoft, where he worked on user experience teams and often needed support from people outside his immediate group. When an idea looked very different from the current experience, simply presenting the output was not enough. He had to explain why the change mattered and help others see the intended future.
For Jon, this was not one-way persuasion. Effective storytelling also meant listening to what collaborators knew and using their input to improve the product. Product creation became a communal process: share a direction, invite people into it, and let their knowledge change the result.
A cycle for inclusive collaboration
Jon describes five principles used at Textio: lead with curiosity, leave no one behind, learn by making, lean into the details, and listen to the loop. Together they form a practical cycle rather than a collection of slogans.
Leading with curiosity means asking questions when a colleague says something we do not yet understand. The goal is to learn what sits behind the comment instead of immediately arguing against it. Leaving no one behind extends that approach beyond the two or three people a product manager already knows well. Colleagues in other functions, including people outside our usual social circle, may hold information the team needs.
The next step is learning by making. Conversation has limits, so the team looks for a concrete way to advance it. That might be an experiment, a quickly built feature, or something shown to a few customers for initial feedback. Making something gives everyone a shared object to evaluate and creates new evidence.
If the idea is going to become a product people use and buy, speed alone is not the standard. Jon says the team then leans into the details and spends the time needed to make the experience strong. After release, listening to the loop brings usage metrics and customer feedback back into the next round of curiosity.
Find and combine the useful signals
Jon's favorite part of product management comes after conversations with customers, prospects, designers, and other partners. Different people may describe pain points and possible solutions from distinct angles. His task is to identify the valuable signal in each contribution and combine those signals into an idea that holds together.
A passing customer comment can contain an important insight even when the customer does not present it as a polished product proposal. Product managers help the team notice that signal, give it language, and use it to move the discussion forward. The answer still belongs to the group. Synthesis is valuable because it connects contributions rather than erasing where they came from.
This is also why Jon advises new product managers to stay curious. Existing product choices often came from a real constraint or tradeoff, even when the result now looks strange. Asking why a decision was made helps a new PM understand the system before changing it. If a question feels obvious or uncomfortable, asking it may still uncover something others also need to know.
Use ambiguity as productive space
Jon considers his high comfort with ambiguity both a strength and a weakness. Earlier in his career, it could slow his move from a broad problem to a concrete specification. He wanted to keep working with people and exploring the idea when the job sometimes required a faster turn toward execution.
With experience, that same characteristic became an advantage. He could leave the problem open long enough to hear from a broader group, then draw out the insights that shaped his view of what should happen. The lesson is not to avoid commitment. It is to manage the tension between an inclusive process and the need to make something concrete.
Jon's approach gives us a repeatable rhythm for collaborative product work: ask, include, make, refine, and listen. Listen to Episode 9 for the full conversation about curiosity, synthesis, and leading through ambiguity.
Continue with the workflow pages
Use the ideas from this episode inside the selector, Playwright, and bug-reproduction pages that connect content to product intent.

