More on this book
Kindle Notes & Highlights
Many of them are incredibly smart, but meeting big problems head-on usually isn’t the winning approach.
Smart data scientists don’t just solve big, hard problems; they also have an instinct for making big problems small.
To start, for me, a good definition of a data product is a product that facilitates an end goal through the use of data.
After all, there’s nothing more fun than throwing a lot of technical expertise and fancy algorithmic work at a difficult problem. That’s what we’ve been trained to do; it’s why we got into this game in the first place.
Building a great data product is extremely challenging, and the problem will always become more complex, perhaps int...
This highlight has been truncated due to consecutive passage length restrictions.
Does anyone want or need your product?
doesn’t have to be a great solution; it just has to be good enough to let you know whether it’s worth going further (e.g., a minimum viable product).
The key is to start simple and stay simple for as long as possible. Ideas for data products tend to start simple and become complex; if they start complex, they become impossible.
The point is to have a conversation rather than just a form. Engage the user to help you, rather than relying on analysis. You’re not just getting the user more involved (which is good in itself), you’re getting clean data that will simplify the work for your back-end systems. As a matter of practice, I’ve found that trying to solve a problem on the back end is 100-1,000 times more expensive than on the front end.
As technologists, we are predisposed to look for scalable technical solutions. We often jump to technical solutions before we know what solutions will work.
The key thing is to watch for the signals the humans use to make their decisions. When we’ve identified those signals, we can start building more complex automated systems.
The point is that technical solutions will always win in the long run; they’ll always be more efficient, and even a poor technical solution is likely to scale better than using humans to answer questions. But when you’re getting started, you don’t care about the long run. You just want to survive long enough to have a long run, to prove that your product has value. And in the short term, human solutions require much less work. Worry about scaling when you need to.
By giving data back to the user, you can create both engagement and revenue.
How do you give data back to the user? LinkedIn has a product called “Who’s Viewed Your Profile
One of the biggest challenges of developing a data product is figuring out how to give data back to the user.
When we were building the prototype for “Who’s Viewed My Profile,” we created an early version that showed all sorts of amazing data, with a fantastic ability to drill down into the detail. How many clicks did we get when we tested it? Zero. Why? An “inverse interaction law” applies to most users: The more data you present, the less interaction.
The best way to avoid data vomit is to focus on actionability of data.
you want them to be impressed with the number of things that you can do with the data, then you’re likely producing data vomit. If you’re able to lead them to a clear set of actions, then you’ve built a product with a clear focus.
Precision — The ability to provide a result that exactly matches what’s desired.
Recall — The set of possible good recommendations.
The most common guideline is to strive for a distribution in which there are many good results, a few great ones, and no bad ones.
Thus, a little twist in the product can make a hard relevance problem disappear.
We often focus on getting a limited set of data from a user. But done correctly, you can engage the user to give you more useful, high-quality data.
Take heed not just to demand data. You need to explain to the user why you’re asking for data; you need to disarm the user’s resistance to providing more information by telling him that you’re going to provide value (in this case, more valuable recommendations), rather than abusing the data. It’s essential to remember that you’re having a conversation with the user, rather than giving him a long form to fill out.
By using Data Jujitsu and sending the results to the recipient’s network, rather than directly to him, we create a product that doesn’t act like an overly intelligent machine that the user is going to hate. By enlisting a human to do the filtering, we put a human face behind the recommendation.
This provides an opportunity to engage users as well as give them control.
Data Jujitsu embraces the notion of the minimum viable product and the simplest thing that could possibly work.
While these ideas make intuitive sense, as engineers, many of us have to struggle against the drive to produce a beautiful, fully-featured, massively complex solution.
The key aspect of making a data product is putting the “product” first and “data” second. Saying it another way, data is one mechanism by which you make the product user-focused. With all products, you should ask yourself the following three questions: What do you want the user to take away from this product? What action do you want the user to take because of the product? How should the user feel during and after using your product?
Data Jujitsu isn’t the end of the road; it’s really just the beginning. But it’s the beginning that allows you to get to the next step.
