Solutions vs. Capability
Solutions vs. Capability
"Everything Starts Out Looking Like a Toy" #84
Join smart, curious folks to get the Data Ops 📊 newsletter each week (it’s free!)
Hi, I’m Greg 👋! I publish this newsletter on finding data products and interesting data observations with the goal of finding patterns and future product insights. (Also, it’s fun.) If you need a background on how we got here, check out What is Data Operations?
This week’s toy: “fast flood”, a web game where you try to match colors to get the entire screen to one color within the fewest number of moves. Edition 84 of this newsletter is here - it’s March 14, 2022.
The Big Idea
A short long-form essay about data things
⚙️ Solutions vs. Capability
Wouldn’t it be easier if software knew what you wanted to do and was able to configure itself for that use? Hah! As we know, well-designed software manages to constrain what’s available or shape the experience of using it so that you end up selecting the “job to be done” that matches the sweet spot of that software. Because you’re already in a funnel that ends with you picking something that the software “knows how to do”, when you do that thing you think “of course it was designed to do that. This is an example of solution meeting capability.
But what happens when you start using a product (or considering the use of that product) and find that to reach this “solution/capability fit” situation it needs to be customized? Behind any great solution lies great capability, or at least well-attuned capability to the problem at hand. With great capability, a product can meet any outcome, create any solution, and solve any problem. But the level of effort or skill needed to achieve that outcome might be high.
Great capability means the ability to make Lego-brick like sets to build a series of primitive actions that can be combined into more complicated steps. Think of this as steps of a procedure, but there’s a paradox here. When you’re looking at platform capabilities, it’s often hard to determine how they can be combined into easy to use solutions.
Bridging the gap between solution and capability
How do we help people squint and see the possibilities implied by a solution? And how do we let them understand that just because one solution expertly solves their problem, that it’s not the only thing possible with this capability?
One way to solve this problem is to use capabilities and build solutions that match the market. In this way we keep our promises because we’re building something the capability can deliver. We are making it easier for people to see the capability by delivering the solution they needed to solve their use case.
Let’s take Lead Routing as an example. This is a common process in most organizations, and the outcome you want is to deliver the right lead at the right time to the right person according to rules you set up in your organization. The rules may be related to the size of the company, how much money they’ve spent in the past, or which seller owns the account.
It’s very difficult for a generic system to automatically read those rules from the way they were just described. There needs to be an underlying capability of routing that – combined with some standard structure – executes the actions that when configured conform to your routing design.
This is great when the things you are routing in your initial design match the capability of your system. But what happens when the behavior of the people in the system or the data in the leads changes in such a way that the underlying capability doesn’t work well with the rules you set? Now you’ve got a solution that doesn’t deliver and a capability that appears not to work.
Towards better product: adaptive capability
One way to handle this problem is to build capabilities that effectively build capabilities. This might sound like a puzzle but the core idea is that the composability of software and the ability to adapt to changes in that system is valuable. Using composable blocks of actions or reading metadata that changes how your system works means you’re able to react to what happens without stopping (most of the time).
A solution that solves this knows how to deal with likely anomalies. For example, you might depend upon a picklist to deal with possible values for lead sources and one of your systems might need that picklist to always be a set of discrete values rather than a random, ever expanding pile of terms that happen when you receive information.
One day, if you get a new lead provider, the typical solution that just “buckets items you get from a system” might fail. If you are relying on a static list in your application, seeing a new item appear could look like a bug. An adaptive application might know enough to not only notice a new value, but also to call a source of truth and validate that the new value that appeared is a valid and correct item for the picklist. Having validated the new information, you continue along the garden path of routing leads.
Solutions sound simple (because marketing!) but they are not always as simple as they seem. Checking when you receive new values to confirm you’ve got a good one is an example of an adaptable system with strong underlying capabilities.
What’s the takeaway? Neither solutions nor capability alone are sufficient to build a great product. You need both. But the root of amazing solutions is almost always a robust capability to adapt to new information and changes, expertly portrayed to solve the problem the customer thinks they have, right now.
Links for Reading and Sharing
These are links that caught my 👀
1/ it’s pronounced with a hard G - If you thought you knew everything to know about gifs, this story might uncover some new things. This essay will improve your gif game.
2/ Not eggzactly the story you expecting - Eggs are a good way to explain how inflation is affecting the larger economy, both because there are a lot of input costs but also because there is no “Big Egg” that monopolizes the market. This Vox explainer shares the details.
3/ Imagine before you build - One way to simulate the existence of a feature is to use a “Painted Door Test” - that is, to create a high fidelity version of something that doesn’t exist yet - to elicit a response and let you know whether to build.
What to do next
Hit reply if you’ve got links to share, data stories, or want to say hello.
I’m grateful you read this far. Thank you. If you found this useful, consider sharing with a friend.
Want more essays? Read on Data Operations or other writings at gregmeyer.com.
The next big thing always starts out being dismissed as a “toy.” - Chris Dixon