If Picasso Was a Product Manager

It remains a mystery whether he said it or not, but you have likely seen Picasso quoted for saying, “Good artist copy, great artist steal” and “art is theft”.

True or not, Picasso wasn’t the only inventor that remarked on ideas and their originality. 

Henry Ford said:

I invented nothing new. I simply assembled the discoveries of other men behind whom were centuries of work.

Steve Jobs said:

It comes down to trying to expose yourself to the best things that humans have done and then try to bring those things into what you’re doing.

And since then, we’ve seen many books written about the notion that most creative work builds on others’ work—that all ideas are a remix. 

But these men aren’t really talking about stealing ideas. They’re talking about sampling ideas. 

Sampling? 

Yes, as in music sampling, when a producer reuses either the rhythm, melody, speech, sound or bars from an existing song in a new recording—take Puff and Biggie’s Mo Money Mo Problems, for example. 

Remixing others’ work is fundamentally how you produce new art in music.

However, in product management, there’s an interesting taboo against using other people’s ideas and building on others’ solutions. Especially for us PMs. We like to think that we’re unique creative geniuses. We want to reimagine things and think differently.

But it’s completely naive and inefficient. 

Naive because all the inventions we’re fortunate to have around us today result from people building on each other’s ideas. Whether we’re talking about electricity, cars, or ride-hailing apps, much of our technological progress relies on people sampling ideas. 

Inefficient because it is simply a waste to solve a problem that someone has already solved when you could have freed up time to focus on problems that will truly differentiate your product.

After exploring the idea for a few months, I’m now convinced it’s a superpower to have good intuition about when to sample solutions and when to pioneer, where to find solutions, and how to remix them.

Probably, what Picasso would have been really damn good at if he had been a product manager.

Sample sense

At On Deck, I learned from Shreyas Doshi that Product Sense, or Product Judgement as Paul Adams calls it, is an important trait of a great Product Manager.

They describe it as having good intuition about what products or features to build—and not to build—to solve the right problems for customers.

Simple and magical, yet very abstract. 

However, this ability to know when to sample ideas and how to sample them—I guess we could call it Sample sense—now feels like a more tangible element of good product sense. 

So let’s try to break it down. 

Standards

When building software products, you often build infrastructure and features that help users get whatever value you’re trying to create for them. It could be user accounts and authentication, payment checkout flows, or workspace functionality.

These are obvious examples that you don’t want to reinvent.

Just like the wheel, other people have already invented, optimized, and standardized it, so any attempt to innovate here will be a waste of time and effort that you could spend on more important things. 

You might even cause more harm than good if you mess with standardized patterns, as Don Norman illustrates with this mind-bending example in his book The Design of Everyday Things: 

Just try telling the time on the clock below. 

Tough one, right? It’s 7:11. 

But why is it so hard to read the time here? 

As Norman points out, this clock is just as logical as the standard one. 

The logic behind the time display is identical to that of conventional clocks: there are only two differences: the hands rotate in the opposite direction (counterclockwise) and the location of ‘12,’ usually at the top, has been moved.

It bothers us because we have standardized on a different scheme, on the very definition of the term clockwise. Without such standardization, clock reading would be more difficult: you’d always have to figure out the mapping.

Now that’s the power of standards. Don’t be the PM or designer that goes against a standard like this. 

Instead, working with these established mental models will make everything easier for your users. When things just work as they expect, it requires less effort to use it, it just clicks.

In March 2006, Google showed us the power of precisely that when they pulled off a beautiful sample for their new web-based Docs product. 

A beautiful sample

Microsoft had already established a mental model for millions of people for using a word processor with the Office suite and their Word product. 

They built the bold, italic, and underline formatting buttons and the File, Edit, View, Insert, Format, and Tools menu.

Now, let’s say you’re a product team at Google. What do you do here? Do you build a similar interface as Word, or do you reimagine the interface for a word processor? 

Well, the product team at Google decided on the former and ripped off Word’s interface. 

So why is it a good sample? 

I think it’s a beautiful sample because Google’s fundamental innovation was taking the word processor online and not pioneering document formatting. By sampling Word’s user interface, they could focus on new inventions like real-time editing, sharing, and online storage instead of reinventing the menu and formatting tools.

It was also smart from a growth angle because they instantly made their Docs familiar to millions of people, making it much easier for them to switch to Docs. 

They did the same thing with the rest of their Gsuite product, like adding almost all the formulas available in Excel to Sheets, and today Gsuite is reported to have a 60% market share of the US office suites market. 

And Microsoft Office? 40%. 

It looks like it was a good choice for Google to sample here, but is there a science behind it? How do we know when to sample? And how do we know when to pioneer? 

When to sample

Will Larson briefly touched on this idea in his book An Elegant Puzzle on systems of engineering management. For product teams in the solution phase, his suggestion is to start by asking if someone else has already solved your problem and, if so, look at it, reverse engineer it, use what you like, and then build from there. 

Interestingly, he calls it “identifying prior art.” 

There are, however, also many scenarios where it’s less obvious whether you should pioneer a solution or find solutions to sample, and I like how Melissa Perri points it out in her book Escaping the Build Trap:

When considering whether to experiment around a particular solution, I think of what my friend Brian Kalma, former head of UX for Zappos, once told me. “Don’t spend your time overdesigning and creating unique, innovative solutions for things that are not core to your value proposition. If someone has already solved that problem with a best practice, learn from that, implement their solutions, gather data to determine if it’s successful in your situation, and then iterate.

Reserve your time and energy for the things that will make or break your value proposition.

Building on her idea, there’s no need to go through a research project to uncover the fundamental desire and business goal with a sign-up/sign-in flow. Just steal one and go.

On the contrary, Apple probably made a good decision to pioneer their face recognition tech. It was core to differentiating the iPhone, and it was core to their developer platform to allow developers to build better apps with the technology.

At Butter, we also recently redesigned how our facilitators prepare and run breakout room sessions. Since it’s so core to our value proposition, we interviewed over thirty facilitators and spent months reimagining what the world’s best breakout room experience would be.

We found inspiration from competitors and adjacent solutions for sure, but as we explored territory that few others had, we had to reinvent—we had to pioneer. 

But say we do realize that we are better off sampling a solution to solve our problem. How do we then sample effectively? 

How to sample

Google didn’t just steal the word processor that Microsoft had created. They added lots of functionality that fundamentally made document creation better and more accessible by leveraging the internet. They enabled people to collaborate in real-time, from any device, anywhere in the world. 

Similarly, when sampling music, it’s the new lyrics or the manipulation of the elements that make it special—it’s the contribution that turns it into art. 

With product sampling, I think it’s the same. If you’re not building something new or contributing with new ideas, you are simply stealing. 

Some say that Instagram stole the stories component from Snapchat, but I think it’s a great sample too. They stole the fundamental idea of time-limited content, but they quickly innovated with the tools for creators and won. 

Imagine if Instagram’s product team had been too proud to sample it?

The site you’re on right now is full of ideas that I’ve sampled too. 

At the top of this page, you’ll notice the like function. That’s something I sampled on Medium’s clap function.

Another example is the Subscribe flow that you see in the top-right navigation. 

When a16z launched their new media property, Future, I saw the “Join Newsletter” call to action. When you click it, an input field smoothly slides in to take your email address.

It was love at first sight for me—no pop-up modals or redirects, no unnecessary input field, and no distraction from the article I was reading.

So, I thought to myself:

Hmm, since no one is subscribing to my newsletter, maybe I should try this on my site.

So, I spent some time inspecting the code to see how they designed it, and then after about an hour, I started coding it. 

A few obvious improvements came to me. 

For example, I knew that most of my readers were on mobile, so I designed the input field to fit on all mobile devices.

I also thought it would be ideal if the site automatically focused on the email input when you click Subscribe, so I added that.

I then realized that there was no need to show the Subscribe button to people already subscribed, so I added some logic that saves your subscriber status in your browser and only shows if you’re not a subscriber. 

Here’s the result:

It’s a trivial example, but I think it’s a good one of building on each other’s ideas to make things a little bit better.  

And isn’t that the same pattern that we can also attribute much of our societal progress to? New generations that learn from the old and make things just a little better for the next? 

You might be annoyed if someone samples your idea, but it’s a great thing for the rest of us if they improve and build on it. 

We actually realized this long ago and created legislation to encourage inventors to share their ideas with the public. In exchange, they get exclusive rights to make and sell them for a period of time—yes, patents.

The requirement for a successful patent claim, literally, is that you describe the invention so explicitly that an industry peer can recreate it. Do that, and we’ll protect your idea in exchange. When you’ve had your chance to milk the profits, the rest of us can use and build on your idea.

How great is that? 

I remember learning this in a law class in business school—one of the few classes that turned out to be useful—and it was such a lightbulb moment for me that I still remember the red seat I was in on a sunny spring morning in Copenhagen.

Fortunately, not all inventions can, or should, be patented. 

And maybe, instead of getting annoyed when someone samples our ideas, we should embrace it and let Oscar Wilde remind us that “imitation is the sincerest form of flattery that mediocrity can pay to greatness.”