The Smallest Big Thing
"Everything starts out looking like a toy", #87
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: a receipt printed for every JIRA ticket. This is either a horrible idea or a brilliant way to break through the electronic noise when something is truly important. Edition #87 of this newsletter is here - it’s April 4, 2022.
The Big Idea
A short long-form essay about data things
⚙️ The Smallest Big Thing
Complex solutions are fun. When you think of a Rube Goldberg machine that can solve any problem, it’s easy to think but it’s the right way to go about the problem. Consider this awesome video from the band OK Go.
OK Go’s example shows you the benefit of delivering an elegant solution that checks all the visual boxes for a very particular solution. But spending all the time figuring out a wacky machine prevents you from finding the real reason that you designed a feature: to create a result. In this case, the design of this machine was to create a viral video. (Check.) At the end of the production, none of this machinery was useful.
The point of delivering a feature or capability is to answer a question that’s asked - either implicitly or explicitly by a customer – to get something done. Usually, the “something” they are asking for makes sense to you or to them. If it doesn’t, there might be another set of questions that need to be answered to move beyond a slick demo or a surface request.
You don’t see the work that went into it
The video above shows you a cool solution. As of April 2022, it had been viewed 70 million times. But you don’t know from looking at it how many takes were required, what budget went into the original plan, and how close the delivered video was to the vision expressed for the original project.
The message for the Product Manager? When designing features, be cautious. This often comes up when a colleague or prospect asks you if “something’s possible.” Given enough time and money, many things are possible. They are easy to visualize in an initial concept or the first draft of a Product Requirement document. Yet fancy solutions don’t always fit into the product you are building, meet the needs of the typical customer, or solve the problem.
You may think you are building a result that will be viral. Customers may think otherwise unless the result is also what they needed, easy to use, and the right thing for them at the moment.
Customers want to use your product because it delivers results or outcomes. They don’t care how complicated the solution is or how hard you worked to find it. That’s why it’s really important to think about the smallest big thing you can identify when you were trying to solve a problem.
What’s a Small Big Thing?
A “small big thing” sounds like a contradiction in terms. Small means: “small enough to describe" without reverting to using other related terms. Big means: “will provide a measurable impact”. Placing and delivering these concepts together delivers a smallish unit of work that will build in impact as time moves forward. That’s a lot easier to say than it is to do.
For example, a user-defined function sounds like a feature that could solve lots of ills. If the customer wants to, they can do anything (within a container.) But how many customers will use it? What’s the effort to create this? Will it introduce security concerns? Does it feel right for the product? These are some of the many things you might consider when thinking about building the feature.
And the core need might be much simpler. Perhaps the person wants to do a common thing like run a for … each loop on an array. A specific function (or a way to access elements in the array) might be much easier to build and solve *some* of the problems scoped by a complete custom function. If the underlying code is built in a way that could be eventually exposed as a custom function, that simpler prototype provides a way to test a complicated system with a lower risk in case the technique doesn’t work.
The smallest big thing does not mean the smallest thing. It means finding the smallest increment of something that creates a difference. If you are creating a way for developers to solve problems using an API doesn’t matter if they do it well. It matters if they can do it at all. Once you get a result, you can improve it.
When is it right to make a bet?
Knowing whether you have made a difference depends on knowing your customer. If you promise the ability to validate an email when you are looking at an email address if the customer expects you to do it every time for any email that might be an impossible task. But if you constrain the task to the most likely emails that need checking, you’ve made the problem smaller and more likely to be solved.
Bounding the input and the output is a key requirement to building a small big thing. And it also means that your solution needs to be small in nature. Each thing needs to build on another thing like nodes in a connected network. If you build unit tests into your problem solving then you will get more anti-fragile problem-solving.
A small big thing sounds like a paradox. How can a small insight be worth working on? You will know when you start getting results on the small insight. This also means you need to have criteria for starting a project with no progress is being made. One heuristic for thinking about this is the idea of how often you use the thing every day, how much time it might save you, and how much time you spent so far. If your proposed solution is taking weeks and you’re not sure of the benefit, even for something that people might use every day, it might be time to try something new.
What’s the takeaway? When considering customer feedback, reframe that feedback to them in terms of what they’re trying to do, what they expect to get out of that solution, and how they want to bound the data that enters the solution. Creating a small big thing requires you to make the solution as small as possible to get the result you need, and also to ask: is this necessary? There might be another way to do it.
Links for Reading and Sharing
These are links that caught my 👀
1/ Changing the perception of pricing - Food is more expensive at the supermarket these days. But what is the real, fully-loaded cost of bringing food to our markets? One startup in Amsterdam is building a metric to provide True Prices at the point of sale. The idea is to demonstrate the extra costs of transportation, production, and other costs to give consumers additional information for their purchase.
2/ Making art with AI - If you’ve thought about how to create generative art with AI, this is a good way to get started. This technique starts with a phrase or a descriptive idea and lets a neural network iterate through a series of repetitions on the same theme. You might create ideas like “classic 1980s cartoons rendered in the style of 1950s advertisements” or something simpler like “park landscapes that look like Van Gogh paintings.” Is it gallery ready? Nope, but it’s neat.
3/ How do you deliver e-commerce to remote places? - It’s easy to imagine a late-night delivery in Manhattan, Beijing, or London. It’s a lot harder to figure out how you get an e-commerce delivery in French Polynesia. Understanding the incremental steps to request, source, procure, receive, deliver, and accept payment is a recipe for any ops professional. The way to get started might not be the fancy, automated way.
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 it 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