Making lassi in a washing machine requires the right model
Lassi is a yogurt drink popular in India, but you wouldn't usually employ a washing machine to make it. Unless, of course your requirements are similar to those in this HSBC Ad. We call such differentiating requirements "scenarios." Think of scenarios as business use cases, or high-level business objectives.
As an example, here are the scenarios for evaluating Ecommerce platforms based on RSG's latest research we released this week.
Figure: Ecommerce Scenarios. Source: RSG vendor evaluations
Scenarios are an important way to differentiate one product from another. Most products excel at a few scenarios, but may not fare equally well -- or actually suck -- at the remaining scenarios. In RSG's vendor evaluation research, we rate platforms against these scenarios to show how much of a "fit" or "match" exists between the product and your requirements.
So does that mean if a MarTech or Ecommerce solution is not a good fit for a particular scenario, that you should avoid it for that specific requirement? The answer depends on many factors.
Having worked at various systems integration firms, I've known many people who believe that given sufficient resources and time, they can implement pretty much anything. If they work really hard, and invest huge amounts of resources, they can get a platform to work for a scenario it normally wouldn't fit.
But that's not how it works in real life, where you the customer always faces constraints, trade-offs, and bottlenecks.
When researching these products, you will often hear (mostly from vendors) many examples of diverse implementations. These examples will include implementations for scenarios that typically don't make sense for that tool. Just remember that examples of implementations may not necessarily give you a true picture of why that product was chosen. There could be many reasons why a particular customer chose to try to adapt a platform, from deep discounts, to organizational policies, to personal relationships, and sometimes geographic proximity.
In such cases, remember to dig a little deeper during your evaluation. You can:
- Create detailed scenarios describing your usage of those systems
- Ask the vendor to demo a subset of those scenarios. Don’t let them do a canned demo
- Make features as part of your use stories for these scenarios. Most vendors will always get tick marks on raw feature lists. The difference is in implementation, based on your specific needs
- Once your basic scenarios are supported, take time to understand support for customization and integration to support additional scenarios
- What does it take to integrate these with your remaining stack?
Remember: previous implementations cannot be equated with good "fit." So if you elect to buy a washing machine to make Lassi, make sure it's a top loading and doesn't come with an automatic dryer...