The tragedy of email commons (3 of 3)

For the past couple of months I've configured my Outlook client to automatically insert [Save our in-boxes! http://emailcharter.org] as my email signature. I found this helps me work on my own bad habits. I noticed on multiple occasions, just prior to hitting the Send button, this signature reminded me to shorten the text of my email, avoid open ended questions, remove unnecessary attachments, strip irrelevant prior email thread text, take out unnecessary recipients from cc: line and change the subject line to reflect the content.

There is still plenty of room for improvement in my approach to email, and somehow I am beginning to feel more in control. It feels better. Now if only more of us made an effort.

On the other hand, looking at generation Y, perhaps this will not be an issue in future... Email for them is like fax for many of us.

The tragedy of email commons (2 of 3)

These days I find myself again helplessly staring at hundreds of unopened envelopes deposited in my mailbox daily. There is no magic about receiving these letters. Gone is the anticipation, along with the paper smell, personal handwriting and stamps from far away. About the only thing that still remains is the stress from my inability to promptly respond to all these people writing to me.

The sad part of our modern electronic world is that we all contribute to this tragedy of commons, where commons is the time and attention of the people receiving mail. We find it easy to send an electronic letter, we don't even need to buy a stamp any more. We shamelessly deposit our unorganized thoughts, verbose sentences, unfiltered emotions - often poorly packaged, behind obscure subject lines - in front of others.

For the most part, we don't consider the price our recipients are paying to process our communication. Consider, when you and I receive an email. Even when we don't respond, we spend precious time as we have to notice new email, switch over from whatever we were doing, scan the subject line, often open and scan the content, close or delete it, before switching back to our original task.

If you are interested in more thoughts on this subject consider "How to get better at email: What science tells us" - a recent write up on Quartz.

The tragedy of email commons (1 of 3)

Growing up in 70s/80s I vividly remember the special experience of receiving a letter. The envelope, the stamp, the handwritten address with my name, even the smell of the paper - all emanated magic. Every arriving letter was either a surprise or on a contrary a long awaited communication, preceded with many empty-handed returns from the mailbox and keen awareness of local mail delivery schedule.

I learned early enough to appreciate reciprocity nature of communications. If I wanted to receive a letter from my grandma or from my Australian cousin Paul I had to find the will to write them a letter.

Writing a letter was of course a different experience, not quite like receiving one. It called for the discipline of setting aside time, thinking of the other person, paying attention to the grammar and appropriate style. It could take an hour or more to compose and scribe a letter. I would only do this for a person I cared about, and in most cases I was driven by the hope of getting a letter in response.

One day this simple and beautiful letter exchange experience has changed forever for me.

When I was 17 I founded a Youth Photo Club in my city. As I was looking to connect with other similar clubs across the country, I naively wrote a letter to the largest national youth newspaper at the time, seeking their advice. The editors simply reprinted my letter, complete with my home address.

Over the next several months the avalanche of letters, postcards, telegrams and even phone calls overwhelmed our household. People were reaching out from all corners of our vast country (we are talking Soviet Union in mid 80s) and even from abroad! Some went to length describing their unique life stories, some offered friendship and more, some asked for help.

On the first day, I wrote responses to all 5 letters. On the second day, I wrote responses to 9 letters. On the third day I mailed 18 stamped envelopes. I was beginning to run out of money for stamps, and by the time mailman begun dropping the letters in large bags I was struggling to just read all the letters. I could no longer write back.

This was the first time in my life I felt bad about not being able to respond to each and every letter I received. After all someone took time to be kind enough to write me a letter and affix a post stamp...

(to be continued)

Harnessing the power of word of mouth

Have you ever wondered if there was a way to control the power of Word of Mouth marketing for your product or service?

Jonah Berger in his recent "The Secret Science Behind Big Data And Word Of Mouth" write-up offers a nice structured approach to harnessing this elusive but highly desired marketing mechanism.

In the recent years I've worked extensively with online user communities, including building the new user community for one of my products from zero to over 800 participating members. I can attest first hand the power of genuine engagement from customers and the associated growing stream of word of mouth, amplified by natural transparency of social media.

As Product Managers attempting to engage our constituency lets keep in mind this powerful approach, and take the right first STEPPS - Social Currency, Triggers, Emotion, Public, Practical Value, and Stories - (refer to Jonah's article for details).

When will you implement my enhancement request?

Here is how I usually respond to this common question from my customers.

We cannot provide a definitive timeline for WHEN an enhancement request will enter development cycle, and here is why:

There is only one way for an enhancement to enter our development cycle. One of our Agile development scrum teams has to commit to deliver the requested change within a given X-sprint long release cycle. Before we even get to this point Product Management team considers overall release objectives and compiles a prioritized release backlog – a list of user stories ranked from 1 to N, where every work item is ranked relative to each other so that no two requirements have identical priority. Depending on the available development capacity (estimated ability of available resources to deal with uncertainty of research and development) the line is drawn somewhere in the backlog. The requirements below this line do not enter development cycle and are left for consideration in future releases.

Note how proposed enhancements may be evaluated multiple times, every time we start planning a new product release.

We utilize online Idea submission board. Having an enhancement captured as idea allows other customers add their votes over time. It could be that a new enhancement request upon initial evaluation is on par with hundreds of other similarly important and valuable improvement ideas. Over time with this approach we may find that when we plan our next release this idea is voted into top 10 most requested enhancements. That will have an impact on the odds of it entering the next development cycle.

How would you respond to such a question from your customer?

Agile roadmaps

I believe the roadmaps for products developed using Agile methodology need to be composed and communicated slightly differently compared to those for traditionally developed products. This difference, however subtle, will without doubt be appreciated upon a closer look by everyone involved. The roadmap discussion approach discussed below will help build more trusting, collaborative relationships with your customers (or vendors if you are a customer).

Traditionally customers are using product roadmaps as means to manage uncertainty of investing in complex solutions. As a customer, whether you are talking to a plumber or a supplier of data center infrastructure or backup software, you want to know your costs and benefits as much as possible in advance, to help you optimize your investment decision. If you are a vendor on the other hand, you would want to understand and minimize your own risks and manage your customers' expectations accordingly.

For example, a plumber quoting a bathroom remodeling project may give you a minimum base quote, including estimated project duration and cost. An experienced plumber will also inform you about additional costs and time that may be needed if after opening the wall he discovers a rusted pipeline that needs to be replaced. In this case, the quote acts as a simple roadmap driving your purchasing decision.

Enterprise software development is significantly more complex than plumbing. The more complex a product or a service, the more challenging it is to capture, interpret and communicate consistently forward looking information (uncertainty) for the purposes of risk and expectations management for all involved parties.

In the world of traditional waterfall software development product releases are planned well in advance, and product managers tend to produce elaborate roadmaps loaded with details about releases well into the future, 2-3 years time horizon is not uncommon. These roadmaps rarely highlight the distinction between the levels of commitment to deliver features in the near and long term. For years, everyone involved in putting these roadmaps together, delivering them and listening to the presentations learned to be skeptical about the content, and yet we all still crave for these roadmaps.

With the adoption of Agile software development we find ways to take advantage of shorter release cycles, to benefit from the validated knowledge such as evolving customers' priorities and needs. As we adjust how we plan new releases in this setting we have an opportunity to make our roadmaps more relevant and insightful. Here are three easy to remember steps:

1. The product vision needs to be kept up to date and shared with the customers. This will communicate your strategic intent and help customers understand and even predict future potential prioritization choices your product team will make during regular backlog grooming.
2. The roadmap needs to articulate clearly what is a part of the current in-flight release. This planned content constitutes higher level of commitment since one or more scrum teams have scoped and sized the work in front of them and signaled their intent to deliver this within available number of sprints.
3. Beyond the content of the release already in development, everything else shown on the roadmap is essentially a part of the product backlog prioritized in line with the product vision. You can refer to this as the content under consideration.

As a final thought, engaging your customers in close collaboration around ongoing product development will go a long way in establishing their confidence in your ability to execute on your roadmap plans.

The weak links of Agile value chain (part 2 of 2)

Rapid shrinking of the time window separating new product release launches imposes pressure on functions outside product development. Consider for example, if development learned how to roll out a new product release every 90 days, continuing to target education content refresh 60 days after product GA no longer makes sense. Sales, services and support teams - all have much less time to get up to speed with latest changes and advancements in the product to stay ahead and be ready to provide solid quality experience to the company's customers.

Similarly, other teams may be impacted on the front end of the shortened product release cycle. User interface designers for instance will no longer have ample time to iterate new wireframe designs ahead of the development phase. Some UI design teams in an effort to be relevant will attempt to integrate into the scrum teams, others will struggle to maintain functional independence at the expense of their ability to stay relevant.

Any company engaged in complex activities aiming at growing sustained and profitable business can be represented by a chain with each link representing a different function within the company. Each function plays a critical role in delivering the winning end-to-end customer experience. Software product development is just one of such links, hence the company-wide benefits of adopting Agile methodology by this team alone are constrained by the rest of the company remaining outside of this transformation.

It goes without saying, the chain is only as strong as it's weakest link.