Five Design Principles for Modern Infrastructure Products
Having worked on Platform as a Service product for the last few years I have come to realize that Product Management and design for cloud products have a few unique aspects to them that make them different than other products. My experience has lead me to document several design principals for making great infrastructure products. These are intended to replace other first principals, but are intended to be domain specific enhancements.
Design for Teams
User centered design has almost become common place, but it falls short in the Cloud. Why? Because the expectation is collaborative. What was the main difference between Google Docs and Microsoft Word? Collaboration. It’s also the case that collaboration is messy, and hard to design for so this is my first principle. Think about teams, observe teams, and build for teams. They will be the users of your feature and how a feature works for the whole team is better than reaching an individual user every time.
In much the same way that going mobile first forced apps to be reductive, and only deliver the information and features that matter most to the user a Command Line Interface(CLI) does this ten fold. The feedback loops for CLI’s are extremely tight, and the design experience is so enjoyable that once you go CLI it’s hard to appreciate good UI design — and I still believe UI has a place. In the same way mobile first doesn’t mean no web UI the same is true for CLI. It’s also true that if you can avoid supporting multiple interfaces you should so it’s possible CLI could be your only UI. (It’s also the reason I have grown to love Golang).
I like to joke that we have two types of projects at Pivotal — Databases and Queues. Occasionally a project will use them both! It’s intentionally reductive and over simplifies all the nuances of our many great products but it also illuminates an important point. Most (if not all) the theory for Cloud Computing was worked out almost 40 years ago. Kubernetes, gRPC, and Prometheus are all just continuations of those foundations; heck, even block chain is aging at this point (and just a continuation of Cryptography). So unless you are truly pushing the envelope on things if you are inventing something you are probably over engineering it. Focus on packaging and learning from others.
Make Security Simple
One of my favorite products is 1Password. It’s an amazing product because it accomplishes two goals thought to be orthogonal. It makes your life more secure and it makes your life more convenient. Biometrics are another good example of this (despite their flaws). For years I have heard security experts wax on about how with security you trade off convenience. But it’s not true — in fact convenience can lead to better adoption which leads to better security. I want to use 1Password because I know it makes my life easier; to me it’s just a bonus that it is more secure. Strive to be like 1Password.
Make Change Easy
While market forces may encourage vendor lock in, your job as a Product Manager is to fight it, and survive. This is risky as it may be self destructive to your company as making it easy to choose another product to do the job potentially means making it easy to drop your product. But remember, you are a champion for your users and you should advocate what is best for them, and that means freedom of choice and a toil free ops world. Of course your company needs to stay in business and setting a strategy around this is hard — ideally making it easy to change puts you fist in line for user feedback. This should be all the competitive advantage you need.
It’s been a while since I have posted. Let me know what you think about these principles.