Towards Plato's Real World

We as product managers (should) have a platonistic ideal of what our product should be in its perfect, final state. This ideal is what drives us to improve our product and guides us in choosing which improvements to make first. The problem is that our ideal actually exists in Plato's Material World; that is to say, what we consider to be the perfect conception of our product is actually a shadow of what our product should really be if we were able to glimpse it as it exists in Plato's Real World.

The question then becomes: how do we steal that glimpse? Obviously we need to know what our product should be in order to improve on what it currently is; but who or what will allow us to gain that knowledge?

Only our customers are able to glimpse our product as it exists in Plato's Real World.

As our customers use our product, they have these flashes; these glimpses of the good and the bad of our product. They know, instinctively, what they want from our product; and they know where our product is exceeding, meeting or failing to meet their expectations. There is a problem, though: out customers are not able to communicate to us what they saw in the Real World. What our customers tell us when we ask them the questions "What do you think of this feature?" or "How would you change this product to make it ideal for you?" still exists in the Material World.

We are a step closer to learning about te Real World -- we know "who" will help us learn about our ideal product; but how can we steal our glimpse if our customers are unable to describe what they saw in the Real World without their explanation being corrupted by the Material World?

The only way to truly see how our product exists in its ideal form in the Real World is by capturing customer data while they are interacting with our product; not before; not after.

It is only during this magical moment when our users use our product that they are able to bridge the gap and give us a glimpse into how our product exists in the Real World. It's like a dream where, upon waking, it is hard to distinguish between what happened in the dream and what is real. They may truly believe something about your product, but until you have hard data from usage, you cannot really know.

This intuitively makes sense, doesn't it?

• Don't ask users if they would use a feature: see if they use it!
• Don't ask them if the placement of a call to action is effective: see if users are converting.
• Do ask them what they think they think the product is missing, but don't take that to mean that they will actually value the feature once it is implemented.

So here is to us listening to our customers -- please, listen to your customers -- but keeping in mind that both we and our customers are stuck trying to perceive the ideal product from the Material World perspective. And here is to us observing our customers using our product in order to steal that elusive glimpse into the Real World which allows us to see how our product exists in its ideal state.

Needing to Scale is a Good Problem to Have

I just finished listening to Scale at Facebook from InfoQ QCon 2010 where Aditya Agarwal (Director of Engineering at Facebook) discusses the layers that make up Facebook and where/how their content is stored, retrieved, aggregated, and presented.

This was an excellent talk, not only because Aditya gave good explanations of both the problems and the solutions that Facebook has worked through, but because he repeatedly emphasized: needing to scale is a good problem to have.

One of my favourite examples of this concept from this talk was Facebook Photos. When they launched Photos in May 2006, they created a solution that was quick, lean, and allowed for iterative improvement in the future; they did not over-architecture the solution.

As a result, they were able to launch Photos in 2 months which they considered to be a great competitive advantage.

They could not have predicted, in advance, how well this feature would be adopted. I remember when Photos came out -- I found it a bit strange, because that was not how I was currently using Facebook at the time. In fact, my first Photo album, "important things to remember", contains this image of colours that allowed me to test the "in this photo" tagging (you over over the colours and you are given their names). That is how seriously I took the feature at the time.

However, within 3 months, the Photos feature was so widely-used that it was time for a rewrite. Spending 2 months on a solution that lasted 3 months may seem like "waste", but consider which is the larger waste: 2 months to test a product in the market, before your competitors, with the option to iterate and improve later; or more than 2 months to over-architect a solution for a product that you do not know -- for sure -- will be adopted.

Yes, there is the ideal middle-ground where in a perfect world you know exactly how many users will adopt your product and thus spend an appropriate amount of development time scaling the issue; however, from my experience, marketing tends to over-estimate product adoption rates as often as developers tend to over-architect solutions.

The question then becomes: which would you rather have? Over-architected? Or under-architected? To echo Aditya's sentiments: needing to scale is a good problem to have.

Leave No Trace Programming

I just finished listening to the recording of Robert C. Martin's talk at QCon 2010 London. Martin offers a fresh look at code maintenance as a parallel to the Boy Scout's "Leave things better than you found them" motto: every time you added functionality to your code-base, you also do a small bit of refactoring and leave it slightly better than it was before your change.

I looked up the Boy Scouts of America's Leave No Trace training module and found some other interesting parallels when I substituted "camping" and "the outdoors" with "coding" and "your code-base". For example, here is a paragraph I have modified from the original text:

Leave No Trace Programming principles are not about restrictions; they are about responsible enjoyment of our code-base. Leave No Trace is not a simple program for coding; it is a way of life —- and learning Leave No Trace concepts begins with our own subject matter areas. The principles apply in our own area of ownership and our team's area of ownership as much as in the entire code-base. We should all practice Leave No Trace in our design and implementation, whatever area of the code-base we touch.

What exactly the tenets of Leave No Trace Programming are, I have yet to decide and may leave for another post.

All the same, I would recommend you check out his talk. There are a few areas that I find unnecessary (he spends some time throwing out numbers for "good lengths" of functions and classes which I wish had been edited out), but overall I found it to be worth the hour of my time.