The Myth of Consensus in the Search for BI
Hunting for an embedded business intelligence solution boils down to protracted diagnosis: you outline your needs, determine what needs the proposed solution can meet, and repeat the process as many times as it takes to find a perfect match. Your SaaS application is the lock, and now all you and your product team have to do is find the key, right?
A recent post by The Clever PM would suggest that it’s rarely (if ever) that simple. This lock-and-key idea of the product-solution pairing relies heavily on what he calls the “myth of consensus.” According to the article, our understanding of consensus as universal agreement on a position maps poorly to reality: “consensus is, more often than not, a means by which the great is sacrificed at the altar of groupthink.” Since coming to a consensus on your core requirements is the first step in searching for a BI platform, we thought it might be worth taking a closer look at how to avoid groupthink pitfalls.
The Clever PM identifies three problems with consensus in product management contexts:
- It wears away at edgy, disruptive ideas until they’re humdrum and safe.
- It takes a long time to reach.
- Once it’s reached, it’s often not consensus at all but rather the loudest or highest-paid opinion superseding the others.
When you and your product team are shopping for a BI solution, problem #1 comes into the picture right away. In order to outline your product requirements, you need a clear sense of what your product should be once the BI software has been integrated; and everyone needs to agree that this vision is optimal, doable, and marketable. Problem #2 is a constant, especially for agile companies who can’t afford to spend too much time on any stage of their go-to-market roadmap. And Problem #3 is perhaps the most insidious: if a team member keeps quiet about an important concern, it might not be discovered until it’s too late.
The Clever PM offers six tips for troubleshooting consensus challenges in product management more broadly, but we’ve come up with some more specific to shopping for BI and other software:
Get a prioritized list of core requirements from each department.
Requirement lists are great, but requirements subdivided into “crucial,” “important,” and “nice-to-have” lists are even better. This way, you won’t pass on a solution because it failed to meet a minor need (like a built-in Japanese language file) mistaken for a major one (like the ability to build custom language files in the first place). Having the lists in writing will also help you consolidate them into a master list, a rubric by which to measure each BI candidate.
Give everyone a chance to be heard, but be efficient about it.
It’s better to give everyone a voice and sift through the commentary than to prioritize some voices over others and risk muting an important idea or piece of feedback. Come up with an efficient process for collecting and evaluating people’s opinions, like a survey or a google doc. That way you and your team will be able to spend more time with the product you’re evaluating and less time in peanut gallery meetings.
Don’t let the perfect be the enemy of the good.
The more requirements your team has, the harder it will be to find a BI tool that meets them all; and if you find yourself struggling to find the perfect fit, it’s time to set your sights on good enough. Refer back to your prioritized list, change your rubric, and then re-evaluate all candidates by the new measure. You may be surprised to find viability in a solution you’d previously dismissed!
Product managers know the danger of trying to please everyone in the market, but pursuing internal consensus can likewise lead to stagnation and a lack of differentiation. Following these guidelines will help immunize you and your team in your search for the right BI solution.