There’s an interesting issue we’ve noticed several times in recent months. It arises for publishers when departments want to access a broader set of customer data. That’s a great aim, but the way it’s raised can sometimes lead to problems:
Let’s call this the “perspective problem” – because it’s a perfectly sensible thing to propose, if you’re looking at just one single system most of the time. From that viewpoint, it’s not just one system among many – it starts to feel a lot like the system… and then it seems reasonable to suggest that everything should go in there. (It’s important to stress that sales aren’t doing anything wrong here: they’re looking to make practical suggestions to help them do a better job.)
However, this becomes problematic when you step back and look at the bigger picture, ie. all those other systems which are also in play. What’s the best place for each type of customer data to “live”? How should information flow between those different systems? And how to keep everything in sync? Those are all tricky questions for a systems architect to consider, and not ones a user can answer from their own ‘one system’ perspective.
What’s more, your sales lead tracking system (or marketing campaign system, or author submissions system…) has been built to do that particular job very well, and so it just isn’t designed to handle the separate challenges of large-scale de-duplication and integration.
This is what’s called an ‘XY problem‘ (you want X, you think Y is the best way of doing it, so instead of asking for X, you ask for Y):
In this case, users want to be able to see and use a wider set of customer data (X), they think the best way to do that is to load it all into the system they use every day (Y), and so they ask for Y rather than X.
It’s a subtle difference, but it can be very damaging if the XY problem isn’t spotted – your sales team will have a lot of expertise in knowing what they need to do a great job (X), but aren’t usually the best people to be making decisions about systems and data architecture (Y).
And that’s exactly what the perspective problem boils down to: staff making helpful suggestions about systems architecture, but from a perspective which doesn’t always include the ‘bigger picture’.
So far we’ve used the sales team as an example, but the same issue arises for other teams too:
Once you look at those different sales and marketing views together, it becomes much clearer why perspective is such a big risk: each team quite naturally wants to see the full picture within “their” system, but that will lead to a messy world with multiple copies of everything in lots of different places.
There is, of course, a better way… The sales, marketing and other teams can get what they need, without requiring all that copying between systems. A central ‘hub’ designed for the purpose can do the specialist job of cleaning and merging large volumes of customer data from many sources, and providing all departments with a complete customer view when they need it (a hub like MasterVision, for example).
Of course, that’s not the only way to do it, but the most important thing is to watch out for the “perspective problem”, and ensure that there’s a clear distinction made between user requirements, vs their own ideas about how to implement them.