In previous article I tried to share as much as details about importance and types of insights, and in this article I want to share how we collect insights from various teams and stakeholders within our organization, with the hope that you might find these methods applicable to your discovery process.
At the Atlassian Unleash event, JPD Product Team shared how JPD originally planned to use a feedback board for different departments to contribute ideas. However customer research and interviews made them to hold back from this idea because engaging multiple departments was a hard-to-pull task.
For us, the difficulty remains in bringing stakeholders together to share insights before our high-level roadmap is fleshed out and ready for alignment meeting with top management.
Ideally, I’d like stakeholders to share their insights earlier in the process, as this can dramatically influence our product roadmap storytelling and alignment during roadmap presentations. As unfortunately, not all top managers understand that we need to be customer-centric. Sometimes, you need to be flexible to maintain a customer-centric approach by framing it in a way that is friendly to stakeholders and their vision, and knowing beforehand how they perceive the problem, helps us to do that "framing" more efficiently.
Last but not least, while customers are at the heart of our decision-making, aligning their needs with broader business objectives is crucial, and collecting insights from other teams often spreads the light on how solving this customer problem influences the organization goals as a whole.
These are async sessions that help us prioritize and understand different perspectives about "boulders" or customer problems that our product team is willing to solve through conversations and feedback from different teams within our organization—from customer support to C-level executives.
We usually schedule Slash Poker sessions strategically between customer interviews and surveys. This timing ensures that we consider both internal feedback and business alignment before diving deeper into customer insights and prototyping.
Here’s how we do it: We use a Slack and AI chatbot, as JPD doesn’t support our setup. We post top-priority issues (up to 10) and challenge stakeholders with a question: “Why shouldn’t we focus on this customer problem?”
Participants use the /slashpoker command, and the chatbot collects their insights, asking them to defend or reject ideas using the "Slasher" or "Veto" options.
Participants can provide both slasher and veto insights (which they very often do). However, if you do provide both, the bot prompts you to explain your reasoning with "five whys" helping you to decide whether to keep or discard the Veto or Slasher rationale.
Ultimately, each idea receives a veto or slasher status at the end of the conversation.
These sessions and conversation threads provide us with a clear understanding of how stakeholders from different departments perceive the problem, and we appreciate detailed communication over merely assigning impact or value points at this stage.
This is also useful for writing effective storytelling for roadmap presentations and refreshes our perspective for the next prioritization session.
Lastly, we are a distributed team and we prefer to avoid lengthy meetings, and often have difficulty to align our time zones, therefore we find this async method of collecting insights highly effective.
Moreover, it fosters a sense of required participation, unlike merely sharing a roadmap link with a request for feedback, as this method has significantly boosted engagement compared to previous approaches where we simply asked for feedback on shared roadmaps.
As of now, I'm channeling my energy into developing an app aimed at identifying, merging and lining duplicate or similar ideas, but maybe in the future I will develop a dedicated app for Slash Poker to hold these sessions directly in JPD, as it will save our team a lot of time and would make these sessions more convenient to analyze and organize.
If you have your methods that you use to gather insights please feel free to share them in the comments.
Actually, we look at each boulder in isolation. The reason is that relative comparison usually does a good job at "just keeping the lights on," meaning even subpar ideas get prioritized or chosen through planning poker or value-effort matrix as the least bad option. With Slash Poker approach we do radical shift - a change of paradigm: instead of prioritizing/choosing ideas relative to one another, which often gives every idea a chance to be executed, even the worst ones. Instead, we ask which ideas we should definitely not pursue and why, or we must purse and why.
We do voting and use prioritization frameworks when we break down boulders to smaller, more low-level ideas (e.g. Rocks), where we can already calculate the effort. At Slash Poker phase we can only decide if it aligns with product vision or business goals - for example: "Goal: Admins must be able to place orders right from our solution (e.g. portfolio tracker app)"