In the past few weeks, I’ve looked for ways to apply the techniques of pull conversations to getting specifications from our customers. Pull conversation techniques advise us to let go of our own assumptions and judgments and to try to put ourselves into our stakeholders’ world. When you talk with business experts, reflect what they say back to them so they know that you understand. Build a foundation for collaboration.
I’ve also been studying up on agile business analysis techniques, particularly the work of Ellen Gottesdiener and Mary Gorman. Based on all that, I put together some examples of the types of questions that will help my own team understand customer needs:
- What’s the purpose of this feature/story?
- Who needs to participate in making sure this feature is delivered successfully? Are there subject matter experts who should be involved? What user roles have goals related to this?
- How will you know the right feature was delivered? What outcomes do you expect?
- Who will be using this functionality? What actions are needed to meet the users’ goals? Can we involve any of the end users during development and testing?
- What will users do before and after they use this particular feature? Let’s draw some flow diagrams or mind maps on the whiteboard.
- Could we implement this feature and still not solve the business problem?
- What’s the worst thing that could happen for a user using this feature? What’s the best thing?
- Can we get examples of the data that will be involved? What data objects are acted upon? What will users be looking for in the form of reports?
- Does this feature need to communicate with any external interfaces?
- Does this functionality need to comply with any controls or compliance rules?
Once you’ve understood what the stakeholders desire, there might need to be some reality checks. Maybe our system already has something close to what they want, but not exactly. Maybe they’re asking for something that will be crazy expensive. We all need to find ways to simplify the feature while finding the common ground.
After some conversations with Declan Whelan, who introduced me to pull conversations, I understand the possible need to raise the level of abstraction of your conversation. Look for the bigger reality to emerge.
Let’s say our stakeholders are giving us an implementation, instead of the purpose of the desired feature. We could say something like, “When you give us specific things to do, we feel like we’re missing an opportunity to partner up and come up with really awesome solutions together.” Emphasize that this is your feeling, so that nobody is trying to judge what is right or wrong. Explain the impact of trying to create their exact implementation and ask, “How can we get something better out of this?” They might think they’re doing us a favor by being really specific.
People are naturally wired to reciprocate the feelings you create in them. So, if you genuinely work to understand their reality, they will return the favor by pulling out your reality. This also applies to respect and trust.
We need to really hear what the stakeholders want, pull in their reality, and then try to pull them into our own reality. What is it we both want here that would help us move forward? What is the bigger reality that will help us all move forward? We want to get this message across: “Maybe there’s a better way that we could coordinate what we do with you. We can come up with a totally amazing product if we change the way we interact with you. You would get more of what you wanted sooner, and we would have more opportunity to provide creative solutions to problems.”
I think our success lies in building trust and safety between our development team and our stakeholders, seeking to understand rather than to be understood. We want to communicate to our customers, “We’re trying to increase the success of what you’re doing.” If we can achieve a better understanding of the problem domain of stakeholders, we can discover more alternative solutions.
