5 Creative Ways For Product Teams To Collaborate With Stakeholders
Stakeholder satisfaction is an integral part of Columinity. But many teams also struggle with this. Who is the stakeholder? How should they be involved? How can they be involved? In this post, we offer 5 practical strategies to improve stakeholder collaboration and satisfaction.
Who is a "Stakeholder"?
Your stakeholders are the people who are best capable of telling you what the product needs to do and support. So if your team is building or creating something - which is usually the case - it is the group of people who depend on what your team is creating. If your team builds a product, these are typically your internal or external (end)users. But you also want to include the people who are paying for the development directly. Then there are other groups of stakeholders who have a great perspective on what the product should support, like a product manager who defines the product strategy or people from sales who are selling it.
While most teams understand the importance of stakeholders, many also struggle to find ways to collaborate with them. Sometimes, this isn't allowed; sometimes, the stakeholders are too busy, and sometimes, it isn't clear who the stakeholders actually are. So, let's explore some practical strategies.
1. Handle Support Emails From Users
One of our favorite ways to interact directly with users (stakeholders) is to personally handle support emails instead of letting a support team handle them. We also do this for Columinity.
Each support email allows you to interact directly with a user. The first priority should always be to resolve the issue quickly and follow up to build a personal connection. Then you can ask questions such as:
- “What could we improve in the to prevent this issue in the future?”
- “What is the most valuable part of our product for you? What would make that better?”
- “Instead of what happened in the product, what did you hope would happen instead?”
This creates an excellent opportunity to learn about your product in a low-key way. Not every user will respond, but in our experience, many will. It also builds goodwill with users. It's also an excellent opportunity to notice patterns in support emails and patch issues that cause those support issues in the product. Finally, you can share some recent updates you released for the product and invite them to try it.
Of course, handling all support emails isn’t always possible or practical. Here are some ways that we have done or experienced the past with teams:
- Create a shared mailbox for receiving support emails (e.g., support@product.com) and give all team members access to it.
- Rotate the responsibility of handling support emails in your team daily.
- If an external team handles support, ask them to either give you access to their support dashboard or relay questions to you. If your organization's policies prohibit you from doing any of this, ask your support team if team members can join them for a shift on a rotation basis.
2. Interview A Stakeholder
A straightforward practice is to periodically interview a user or a customer directly. This can be a stakeholder you recently interacted with as a team or someone else who you have contact details for. You can either do this collaborative with your entire team, for example in a call on Zoom or Teams, or you can make it a rotating responsibility. We highly recommend doing this periodically, at least once every iteration, Sprint, or month.
In our experience, the prospect of having to interview a stakeholder is scary for many teams. You can facilitate this by preparing a set of standard interview questions beforehand. For example:
- “In what areas is our product helping you the most? In which areas would you like to use our product more?”
- “What similar products have you tried? What do you think is missing in ours that we should add?”
- “What is one small tweak we could make to make your use of our product easier?”
Since stakeholders and team members are busy people, a 15—or 30-minute interview should be sufficient. You can always do more. After the interview, debrief the results together. If good ideas emerge for a Product or Team Backlog, add them to it.
If you’re not allowed to contact users and customers directly, ask your Product Owner or Product Manager to conduct the interviews with you. Or let them select several stakeholders that can be approached.
3. Personally Onboard New Users
One of the best ways to learn how well your product works is to personally onboard a new user. We’ve done this a lot for Columinity and it's been profoundly helpful. When you develop a product, you also create an intimate knowledge of how it works. This makes it hard to look at the user interface and how it works with fresh eyes. When you onboard a new user, it's like watching your favorite movie with a friend who hasn’t seen it before; you experience it again through their eyes. More than once, we ran into bugs we never discovered before. Or we found a mislabeled button that we could correct immediately after. We would’ve glossed over those issues before.
If your company allows it, you can simply schedule a 1-on-1 virtual call with a new user of your tool. Perhaps it's a customer who just signed up or a new employee who joined your firm and will use your tool. We always begin onboarding with an overall explanation of the flow of the tool, and then we dive into more practical “How Tos”. We also leave time for other questions. 30–45 minutes is usually enough, especially since the goal is to start a new user. If further questions come up, it's easy to reconnect.
If your company doesn’t allow you to onboard new users, you may be able to join such a call with those who normally do it. This may be a sales representative for a product with external customers, or an HR manager for a product with internal customers. Even the opportunity to just see what happens in such a call and what kind of questions come up is already super helpful.
4. Add Feature Polls To Your Product
Some organizations don’t allow teams to contact stakeholders directly. While this is probably a bad practice because it makes it harder for teams to understand the purpose of their work, it's sometimes unlikely to change in the short term. In those cases, we’ve had great experiences with adding “Feature Polls” to the product. This is essentially an inline poll shown somewhere in the product — such as the dashboard — and asks users to rate the value of potential new features. If adding the poll inline is technically challenging, a link to a Google Form also works. However, the poll should be super short and not require personal details.
A poll such as this allows you to collect data about what else is valuable for your users. It's helpful to make evidence-based decisions or test hypotheses. For example, you could populate the poll with potential features you’re considering on the Product Backlog. Examples are “A way to export team-level data to Excel”, “Possibility to log in with Multi-Factor Authentications” and “Add a column to the participation list with completion times in minutes”. You can also add an open text area to collect more ideas.
If it isn’t possible to add an inline box or a link to an external poll to the product itself, perhaps other ways exist to reach stakeholders. For example, you could include the poll in a newsletter or post it on your social media channels. We’ve even done physical polls in our company's lunchroom in the past.
5. Guerilla Testing
The last strategy we want to share in this post is “guerilla testing”. This requires finding a place where you have a good chance of running into stakeholders. If you are building a product for users internal to your organization, this can be the lunchroom of your office at lunchtime. If you are building a product for specific external user segments, you can find a place where they naturally meet.
Guerilla Testing can take many shapes. You can use it to test a specific new feature — or an idea for a new feature — with users. You can either show a working prototype or a set of wireframes and talk them through it. Or you can pass the keyboard and mouse and let them click through a working version or a mock prototype. You can also deploy a number of “demo stations” with printed instructions, and let users click around for themselves and leave feedback and tips on prepared forms. In one case, we put down a stack of empty postcards with a note reading “What small tweak would make this feature much better for you? Write us a postcard with the idea on it”.
Closing Words
In this post, we outlined 5 practical strategies to engage with stakeholders in ways that are outside of the beaten path. Whatever you do, don’t accept “you are not allowed to interact with stakeholders” as an outcome. Persist and find creative ways to bring your stakeholders close to your team to succeed!
You can measure how effectively your teams collaborate with stakeholders with Columinity. Go to teameffectiveness.columinity.com to try now. Our free plan is great for individual teams, but with a paid plan you can track this factor - and many others - across many teams in the same or different organizations.
