Don't plug leaks when you got no boat(humbledmba.com) |
Don't plug leaks when you got no boat(humbledmba.com) |
We were solving problems that hadn't occurred yet! And I see this all the time. You invest emotionally in a dream and begin to believe in it as if it's already happened. And if you let those big fictitious plans infect your product development process, you're in a lot of trouble. Product development is about figuring out the single most important problem that exists right now and doing that and only that.
For a startup, I maintain that your time is better spent developing like a crazy person and let the chips fall where they may. (There are extreme cases, of course, but I hope that any customer issues are driving development, since that's kind of the point of a startup in the first place.)
For an established business, a lot more time needs to be spent on the customer's experience and maintaining that relationship.
Many people do like summaries and I don't think anyone should be penalized for providing them... Assuming they aren't too off-base.
But there's a fine balance to strike here. There's a massive spectrum of solutions to the problem of "Prevent the site from being swamped with spam and other inappropriate comments". Just because it isn't a problem now, because you have no users, doesn't mean it isn't going to be an immediate problem as soon as you start acquiring them. And just because there's an arbitrary upper limit of the complexity of those solutions doesn't mean that there's no point in addressing the problem at all right now.
"Keep V1 as your minimum viable product" is the advice. And the V1 solution could be as simple as "have an emergency global off-switch for the commenting system".
I'm certainly not criticizing hammock's summary. As these things go, his is pretty accurate. But the best you can say about a summary is that it doesn't really add anything to a discussion -- that's what makes a good summary.
So in that respect summaries can indirectly add to the discussion.