Building Product For Negative Use Cases?

I earlier wrote about how Negative Questions Kills good products/ideas, and why one should not deploy traffic police while you are building a road. I am revisiting the article (and adding more) as I see a lot of startups planning more for negative use cases than positive ones.

For example, a typical negative use case is when you design a product to be “spammer unfriendly”, but not ‘user friendly’. Think of those cryptic captchas, the unfriendly registration processes that deter users to enter the system.

In the earlier article, I asked the following

If you were YouTube founder, how would you trustfully say that users will not upload porn or copyrighted material? How can Flickr founders confidently say that they will not allow site to be a porn sharing portal?

A better question is if you were the founder of Youtube/Flickr, would you really care about the porn traffic from the day one or focus on getting people to upload their videos?

Negative Use Cases

Chances are that when you share your idea with others, you will first encounter negative use cases, i.e. the ones starting with ‘What If’. People will first ask you about the ‘misuse’ of your product/service. And a side effect of that is you might start building for these use cases as well.

  • What if people start uploading porn to this newly launched video site called Youtube?
  • What if people write junk reviews in your newly launched review site called Yelp (or Burrp)?
  • I will hold on to the product launch, till the team builds a scalable solution.

Negative use cases are good as deploying traffic police when the road is not yet constructed.

A simple and short definition of negative use case is the misuse of a use case.

But…

Well, there is a difference between negative use cases and deviation from positive use cases. For instance, an airplane is designed to carry passengers from source to destination, but diverting the plan owing to some technical fault isn’t a negative use case – it is a deviation from the use case. It’s alright for passengers to miss the schedule/connecting flight, but it’s important for the product to carry on with the designed use case.

So what’s the ideal route for an early stage startup?

Early stage startups have resource constraints – hence the need to optimize on the product use cases.

Architect/Design keeping negative use cases in mind, but Code only for Positive Use Cases.

Until your product has achieved critical mass (to be specific Product/Market fit), focus on bringing more users/customers to your product, instead of planning features that are anti-user in nature. To start off, even a manual process will take care of some of the negative use cases, but spending time/effort on productizing them isn’t worth the prize.

What’s your opinion?

PS: Negative use cases have nothing to do with negative test cases.

» More on Product Management.

Total
0
Shares
Leave a Reply

Sign Up to Newsletter

Daily.