Stakeholder involvement in B2B settings
Dear scrum.org community,
I am a Product Owner in a software company building manufacturing IT components and systems. During product development we try to closely collaborate with our stakeholders and involve them frequently. We're marketing our systems via other B2B companies (let's call them customers; e.g. machine manufacturers integrating our products into their machines) to the actual users in the field. Our main source of feedback are the application experts of our customers. Because we're building systems critical for production stability, we rarely get early field-usage feedback and have to rely on the infor provided by the "user advocates" of our customers. But it's working well - these guys fit the user persona, are in regular exchange with the users in the field... We've made good experience with them as proxies. (It feels painful to sugarcoat this situation, lol)
We have developed a new product and our lead customers application experts participate in our sprint reviews. Now we are engaging new customers which are competitors of our first lead customer. Because it's still a young product and we're only just starting to get into the area of "excitement" features, I would like to include another customer as stakeholder into our development to broaden the feedback. But I fear that bringing in people from a direct competitor from my first customer will impact the willingness to contribute and share feedback in e.g. the sprint review.
Working directly with actual lead users instead of lead customers user advocates would prevent this situation. But due to the nature of the products we're building that's not really feasible. In my head I see these two options:
- Play it open, don't beat around the bush: "You guys are competitors, but you're also both important stakeholders to us. We would like to hear both your opinions - in the end you'll receive the same product anyways, let's make it fit your needs."
- Keep them seperated, e.g.: Only keep the first customer in the sprint reviews, try to get feedback via a different meeting from the new customer (I can already see how this idea doesn't scale well...)
How did you deal with such settings before? Any ideas?
Best Regards,
Jasper
You're right that bringing in stakeholders from competitors has a good chance of decreasing the willingness to share feedback at the Sprint Review. If representatives of two, and in the future, hopefully more, competitors are giving feedback about your product/services and how they use it, that could give their competitors insights into their business strategies that should be protected.
You may have to experiment with the right approach for you, but I can propose one that I've seen work.
During the Sprint Review, only involve internal stakeholders. Consider going to people who work in fields like sales, marketing, customer success, helpdesk or front-line support, and integrations - the people who work for your organization but work directly with current and prospective future customers for your product. You can use these people and the data that they have to serve as good proxies for the end users when you carry out the Sprint Review and do things like review the state of the Product Backlog, talk about progress and upcoming deliveries, review how customers and end-users are using or want to use the product or service, and review timelines and budgets.
However, don't cut out the customers and end users. The Product Owner should be talking directly with these stakeholders on a regular basis, but without inviting people from multiple customer organizations. As necessary, bring in other people from the Scrum Teams to be a part of those conversations so they can get first-hand information about the product and its use. You do need to be careful to make sure that the members of the Scrum Team recognize that when they hear from customers or end users in this setting, they are hearing one voice out of many and that the Product Owner will be the ultimate arbiter of which voices are acted upon, especially when there is conflict between them.
As you scale, you will have to prioritize where and how you hear from customers. Balancing two or three customers is different than twenty or two hundred. Having a team of people to support the Product Owner can be helpful in making sure that everyone is being heard, but having a single voice to resolve conflicts in the best interest of the long-term success of the product.