How deriving use cases from your data/analytics may be costing your company $?On a lot of analytics-driven projects, I am told by my clients that there are many possible use cases or user stories that the design needs to support.
Why so many? I think it stems from the fact that products and companies are collecting more and more data, and so the logical assumption is that there are more and more possible values we can deliver to our users with that data.
Have a healthy dose of skepticism when your team starts saying, "this data we have (x) might be useful if the users were trying to do (y)."
Sometimes, you will get lucky and one of your hypothetical use cases (y) that was reverse engineered from an (x) actually hits the nail on the head and satisfies a latent need well. But, you probably can't depend on these types of guesses to build a viable long-term business or product.
There are costs involved with trying to stuff every data point or analytic you're technically able to capture into your product:
- More product means more complexity, cognitive load and overall friction for users.
- Technical debt increases with each release, slowing you down, and potentially impacting sales.
- Teams are reluctant to eliminate existing features that aren't performing well (and if you don't have objective goals established, then the team cannot even agree on what "well" means, alloing a single anecdotal story of a customer loving a minority feature to heavily bias the team to retain the feature.)
- Your product marketing will likely be less effective (you have too many messages to convey).
Let's say a SAAS has 100 customers and two of them love feature (f). If everyone is paying the same subscription fees, then that feature (f) accounts for 2% of the revenue. However, your total revenue may be lower than it could be because there is a cost associated with keeping (f) in the product:
- (f) is not mature enough to satisfy new customers. As such, you're losing sales and have limited growth opportunity unless you improve (f).
- A competitor is solely focused on doing (f) well, but your product is trying to support (f) + 49 other things.
- New or existing customers in need of (f) cannot find the feature or have trouble using it (too much clutter from competing features, not enough design time invested to make it simple to use, etc.)
- You're not maximizing profit from the 20% of your product that likely would be generating 80% of the revenue because resources are spread to thin. You have 50 fishing lines in the water, all requiring attention, but only 10 of them are near fish, and the other 40 could get tangled up in the 10 valuable lines.