Design Tradeoffs

At work, there are several instances where I've had to make decisions on what features are in and what are out for a product. There is always an (un) healthy tension between the forces of mass customization vs. the forces of one-size-fits-all or the forces of blue sky 50K foot view vs. what can be done in the next couple months. The answer(s) are invariably somewhere in between, but attempts at simplicity usually give way to eventual bloat and/or products are delivered later than desired.

The road to simplicity and good intentions is paved with trouble. Why? Because, people fundamentally have good intentions. They want to do a good job, be it engineers, product managers, designers or end-users. Asking people to work harder, or do better, or simplify processes is like asking them to have better intentions. It just doesn't work. What's important is to have a mechanism in place that will make this endeavor more predictable. There are three things that one needs to keep in mind for a complete process:
a) Automate actions, with minimal or intuitive user-inputs (poka-yoked to prevent confusion and mistakes)
b) Adoption: Make sure that what you build gets used (after all, why bother building something that is not used?). Set up appropriate monitoring and measurement metrics (key success criteria) and expose them. This, in addition to features, helps with adoption as it raises the overall level of awareness for your product.
c) Don't forget to audit or inspect the results - too many processes suffer from assumptions that change and an audit usually keeps people honest.

I've started to apply this technique when designing something new and have found this to be a good way to ensure better results. This idea isn't novel but it's seldom put in practice, so it's worth enumerating. In my past life as a consultant, there was a variant of this that I followed, which was very useful. It was called MECE or "Mutually Exclusive, Comprehensively Exhaustible" principles. However, the mechanism and complete processes is easier understood and applied.

In the same vein, I happened upon this article that also talks about simplicity in design and how one owes it to oneself to prevent bloat. That is necessary but not sufficient for success. What's needed is a complete process and a mechanism to make it work. So, go forth and simplify and make sure you're not solely relying on good intentions.

The best advice I ever got..

I read an interesting article in the March edition of Harvard Business Review. The article was titled, " The best advice I ever got". There were two things that stood out:
a) Smart people fail and are plagued with considerable self-doubt when that happens
b) The job of a smart (or responsible leader) is to recognize the above and re-ignite their confidence.

Seems pretty simple and obvious, but I've seen so many instances where (b) never gets done after observing (a). At work, I interact and lead very smart people and the work environment lends itself to situations where smart people don't always succeed at first. More often than not, depending on my own personal frame of mind, I've dealt with this in a brusque manner. I tend to lean towards efficiency and the efficient response would be to figure out how to course correct and move on. However, for the person who just failed, things aren't always clear as to how to get back on the wagon.

Over the past couple years, this is one area where I feel that I have grown the most - dealing with failures, recognizing the root cause behind it and building a support structure for people to not lose confidence in their abilities. But, when it comes to myself - Quis custodiet ipsos custodes?