The nature of product
https://www.svpg.com/the-nature-of-product/
In this article, I’d like to share how Steve Jobs tried to explain this concept.
In 1995, after he had been fired from his own company, and had some time to contemplate what he’d learned, he was interviewed for a PBS Documentary called Triumph of the Nerds. They only used 10 minutes or so in the eventual documentary, but it turns out that the full 70-minute interview was lost in shipping.
You can – and you absolutely should – watch the full interview here. I consider the hour you’ll spend watching this very likely one of the most valuable hours of your professional development.
He covers a wide range of product topics, including the nature of technology-powered products, but also the dynamics of strong product teams, what he considers “the disease of process people,” the perils of product roadmaps, why so many companies lose their product mojo, and the consequences of a CEO that comes from sales or marketing, rather than from product.
In this discussion, he is trying to point out that the common problem of stakeholders or customers picking their favorite ideas, and putting them on roadmaps, and how just telling their feature-teams to “build it” is destined to result in bad products. He is trying to contrast that with how product works in strong product companies:
“There’s just a tremendous amount of craftsmanship between a great idea and a great product.
As you evolve that great idea, it changes and grows. It never comes out like it starts, because you learn a lot more as you get into the subtleties of it. And you also find there are tremendous trade-offs you have to make…
Designing a product is keeping 5000 things in your brain and fitting them all together in new and different ways to get what you want. And every day you discover something new that is a new problem or a new opportunity to fit these things together a little differently.”
This is as good of a definition of product discovery as I’ve seen.
And it’s worth pointing out that he’s emphasizing solution discovery. Too many product managers and product designers want to spend all their time in problem discovery, and not get their hands dirty in solution discovery – the whole nonsense of “product managers are responsible for the what and not the how.”