But the throwing-away of work is crucial to building something lasting, similar to editing the photos you show to the world. At the very minimum you gain a better understanding of the problem. The thing you keep probably wouldn't be as good without having done the throw-away work.
This also kinda reminds me of the Picasso Principle :
The famous Pablo Picasso was at a party. A woman
recognized him and approached the Master. She asked,
“Will you create a sketch for me?” Picasso agreed,
and, as he pulled out his sketchpad, asked her for a
subject. “A bird in a tree will do,” she responded.
So Picasso spent about a five minutes doing what
Picasso does on the sketchpad. Finished, he ripped the
sketch off the pad, handed it to the woman and said,
“That will be $10,000.” The woman was floored. “Ten
thousand dollars! Why, it only took you five minutes to
draw that sketch!” To which, Picasso replied, “No,
madam. That sketch took me a lifetime.”
You can imagine and tell any story (build any product) you want. The art is rather to build a great story and often leaving things out even if they sound like a good idea makes the story way better.
Here are great insights about how Pixar creates great stories:
Obviously not directly applicable to Product Management but I'm pretty certain that being a great story teller is one of the key skills for Product Management.
"When you're stuck, make a list of what wouldn't happen next. Lots of times the material to get you unstuck will show up."
"I use a trick with co-workers when we’re trying to decide where to eat for lunch and no one has any ideas. I recommend McDonald’s.
An interesting thing happens. Everyone unanimously agrees that we can’t possibly go to McDonald’s, and better lunch suggestions emerge. Magic!"
For our team, we say yes to whatever solves the biggest pain, for most of our users.
We discover this by reaching out to customers, and doing a lot of listening. We're trying to answer two questions:
1) What is your biggest pain in your daily work?
2) What is your biggest pain in our software?
#1 usually leads to new features.
#2 usually leads to revisions of what we have already.
At first, startup has 0 customers. Apple has a bit more. Both define customers differently.
(Yes, I know the landing page sucks and is buggy. Working on a new one.)
end of the world?
end of the customer?
same triage as in medicine. once customers get silent, it gets dangerous. as long as they are screaming, they are using your stuff and want more.
When it makes things easier for a sizeable percentage of your users.
When it can be done at a reasonable cost.
When someone with significant clout specifically hires you to. - In enterprise software it sometimes makes sense to build things to order for a specific client, even if just as one-off project.
When it saves you money behind the scenes.
And, to a certain extent, when you can rapidly prototype it and don't know what will happen - you can sometimes spin it off into a separate product if you're large enough.
Note that need and easier are not things that the users necessarily know themselves.
Only when these things intersect do you say yes.
So it's a good question, when is it time to say yes?
It definitely depends on the product's stage and having reached or not reached a good product/market fit. There's also the question, have you already discovered a local maxima or is it a global one? And there's a mix of product owner's gut feeling and long-term vision vs proved market feedback.
This post brought into my attention Intercom, which seems like a great product, which perhaps was and is still built with that "The Art of Saying No" philosophy, and which can help you communicate with your users and say yes or no to their requests.
"Yes" to anything not absolutely critical also carries a below-the-sea-part-of-the-glacier opportunity cost to focus on the most compelling part of your offer.
very insightful article.
If the product in question is an application or Web service with well defined purpose/workflow, then I agree.
If the product is something like an operating system then I disagree. Visualise different users needs as a series of overlapping circles in a Venn diagram. OPs approach would result in truncating the Venn diagram at the intersection, thus satisfying nobody.
Am I wrong? How?
If it's the latter, great! You're on track to a first-rate product.
But most designers make the mistake of going with the former. That's why most products are second-rate.