The Hard Thing About Building Platforms

Published: by

Most products and online services today revolve around four basic actions a user does with valuable data:

  • create
  • read
  • update
  • delete

For example, if you are managing a customer in Salesforce.com, you are likely to create a new customer record, read it before the next time you call, update it with details of the call, or delete it if it is no longer relevant.

In true techie fashion, these have become known by their acronym as CRUD activities. Not quite as appropriate as the acronym for Seasonal Affective Disorder, but still pretty funny.

Because of this structure, the overwhelming majority of product development (i.e. software engineering) and product management references use CRUD as their examples. Roy Fielding's REST proposal, which has become very widely adopted (with varying degrees of fidelity), is built around a similar CRUD model.

The problem is, CRUD is not the hard part. The hard part about any system or platform is policies.

Let's use an example. You are building a group management system, say like Google Groups. The activities seem pretty straightforward. Your basic business objects and their activities are:

  • Group: Create it, update its name, delete it, or read information about it
  • User: Create a user, update it, delete it, or read information about it
  • Membership: create it (a.k.a. join a group), update it (change membership level), delete it (leave the group), or read information about it

Seems pretty simple, right? Not so fast. The CRUD part is simple. The policy part is hard.

  • Who can update the group? Who can read it? Anyone at all? Maybe anyone logged in? Maybe anyone who is a member of the group, or is it just group admins?
  • User: Who can create a user? Do users self-create, or does some administrator create them? Who can read information about a user? What if it is different people? Can user X let one class of people see their name, a different one their email, and yet another their phone number? Who can delete a user? Is it the user him/herself or an admin?
  • Membership: can anyone join a group, or does "join" really mean "request join"? Who approves a join request? What if a group wants all requests to be approved automatically? Who can see group membership? Just the admins, or any member of the group, or perhaps anyone at all?

It gets even harder. What if group A wants everyone to freely join by automatically approving all join requests, while group B wants every request approved by an admin, but group C wants all requests that are not approved by an admin within 24 hours to be automatically rejected? What if user 1 is willing to share information publicly, while user 2 shares nothing except with those with whom she has explicitly approved, while user 3 is willing to share name and email with everyone logged into the system?

Perhaps the worst part of all is creating interfaces that enable people to manage these policies. I have no doubt a good engineer can write a policy line that looks like:

if profile.require_login && user.is_logged_in && profile.share_email && !profile.keep_secret && joint_membership(user,profile) > 0

But very few users can read that, let alone write it. It is incredibly hard to do the following simultaneously:

  • define sufficiently flexibly policies to meet most of your users' needs (80/20 rule)...
  • that are still simple enough for all of them to understand...
  • and visualizable enough that they can modify them to meet their needs without making mistakes.

The last requirement is the hardest of all. If you make them flexible enough and they understand it, but do not grasp the interface and its implications well enough - these are not logicians, mathematicians or engineers - they will set policies that expose their private in ways that upset them. If you think it doesn't matter, ask Facebook via Carnegie-Mellon, Consumer Reports (HuffPo link), the US Supreme Court, or even Facebook itself.

It turns out that the CRUD part of the system is  less than 10% of the work, both in product development and product management. Once you have defined your basic items and the create/read/update/delete actions around them, only then does the work really begin.