Secrecy vs. Openness

This subject continues to pursue me as I work closely with my customers and continue to rely on the use of social media. I raised this subject more than a year ago in one of my blog posts Product Launch (1 of 3): Secrecy vs. Openness. Back then this was more of an open question than conviction.

A few weeks ago I was sitting on the Social Media panel at my company's annual event when I faced the following question:

• "Would Steve Jobs be as open and transparent with his customers as we sometimes aspire to be?"

My response was:

• Steve was genius and a great visionary, but he operated in a different space compared to our company. He built products for consumer space and took huge risks in developing his solutions in secrecy. Our company is engaged in developing solutions for much more complex problems in B2B markets, and I would not follow Steve Jobs' approach. I believe in openness, both because multiple minds are just more capable than few, and because it helps establish and nurture much needed trust between the vendor and the customers. A trust that goes way beyond brand loyalty in enterprise software market where these relationships are more like partnerships that extend over many years.

Eating your own dog food or the Platform Culture

I recently came across this Platforms Rant blog by Steve Yegge - quite provocative write-up, and if you are just beginning to look into this perhaps eye-opening, I have to admit.

So how do you introduce a culture of platform development and consumption to established software development organization that has not in the past been able to accomplish this?

Here are some of the important in my mind questions that need to be answered in order to move ahead with this.

1. Customers don't buy the platform, they buy solutions to their problems. How long will corporate investors be willing to pay for this non-direct-revenue producing function in future? Will the platform funding evaporate once the grey clouds show up on the horizon? Will the next organizational leader be as enthusiastic about growing and leveraging the platform?

2. How well can the users of this platform expect to be supported within their stringent project constraints? In other words, as a Product Owner or Scrum Master, will I get better treatment by an outside vendor in terms of defect resolution and enhancement requests handling?

3. Will the platform ultimately stifle innovation benefiting our customers? How competitive can this shared platform end up in the long run? As a Product Manager planning my next release, will I be left with inferior options if confined to the use of my company's platform, particularly when more attractive options exist in the open market?

4. How will the potential future acquisition of new solutions and technologies by my company be handled with respect to platform conformance? Will the newly acquired products be exempted from platform conformance for example? Perhaps with adoption of platform my company can rely more on organic development, less on exciting, but disjoint with the rest of my product portfolio, technologies brought in from outside.

What kind of time do you need?

Have you ever ached for uninterrupted window of time to be able to complete an article or a business plan for example? How about asking your management for 10% free time to work on some innovative idea? Did you notice how it may be easier to get hold of some people at certain times of the day?

A few months ago I came across a neat way to describe the differences in how we spend our days at work.

Depending on situation we tend to allocate our available time in one of the following two modes. We either work in short bursts, frequently switching context, issuing orders or instructions, offering guidance or advice, taking in information flowing from multiple sources, and in general participating in multiple communication threads over short periods of times. Or, we take substantial periods of time to work on something without interruption.

Paul Graham in his 2009 blog refers to these two time allocation schemes as Managers' and Makers' Schedule.

For example, if you want to get some undivided attention from a scientist, try to schedule some time with him or her around lunch, just before or right after that. In their pursuit away from all the meetings, conference calls and other interruptions, they often like to get in early or stay late in the day. Around lunch time however, people working on tasks requiring undivided attention are more likely to be accessible without feeling interrupted.

Coming to terms with this concept is equally as important for harnessing our own single most precious resource - time, as it is for appreciating what this means for others around us and becoming more effective in engaging them.

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.

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

Achieving successful adoption of Agile software development is no easy fit. Numerous organizations embark on this journey, investing significant energy and resources attempting to transform. Proven rules and best practices are challenged, the foundation of established organizational knowledge is questioned. Teams are sent to training classes, Agile coaches are hired, t-shirts and mouse pads with morale boosting statements distributed, managers have their annual performance objectives adjusted...

Not every organization is successful in this endeavor though, particularly when it comes to large scale software development and impatient investors and executives. Only few are destined to experience the freedom of creating value, unencumbered by waste. Only some will embrace the uncertainty of software development innovation.

When all is set and done however, the big gotcha is waiting for those who cross the finish line and deserve our tip of the hat.

Successful adoption of Agile software development will inevitably shock your existing customers, your sales force and finally the rest of your company who will now have to deal with the consequences of

1.  accelerated rate of new release introductions
2.  the fit of every delivered feature with market demand

While watching your customers coming to grips with this windfall may be gratifying, and will surely be followed by recognition and appreciation, the real challenge lies in how the rest of the company adopts to this faster go to market pace, and ultimately how can this be translated into a profitable and sustainable growth for your company.

What can help you getting promoted

I attended this morning Boston Product Management Association's 2013 Mentorship program kick-off and one of the round table topics discussed was related to factors contributing to getting promoted in your job.

Here are some ideas floated, in no particular order:

• Be conscious of where you've come from into Product Management and grow to be a well rounded business person. If you are formerly an engineer, reach out and make some friends among sales, if you've come from support delivery learn how development and marketing operate and what matters to them. Try to avoid getting labelled as single-dimension expert.

• While we are at this, develop a reputation for being a Subject Matter Expert (SME) in several fields relevant to your company's business. Make sure people know and value your knowledge and come to you for advice. This can be a particular technology or field of research, industry, set of standards, social media, market research, methodology such as Agile, vendor management, pricing strategy, etc.

• In general market yourself within the company, particularly if you work for a large company. Reach out to other functions, teams, business units, projects. Show genuine interest in what they do, offer help, create synergies. Get engaged in initiatives outside your main day to day project(s). That's a good way to get to know more people outside your primary circle, and get them to know you. Finally, make sure your contributions are known to more than just your immediate manager, also to his manager and/or peers.

• Many people have ideas and can talk about possibilities. Differentiate by picking something meaningful and succeeding at delivering results that everyone can see.

• Learn to be comfortable and communicate effectively with both senior executives, all the way to CEO, as well as with rank and file employees.

• It's always easier to get promotion when you have already been doing everything the new position calls for. In other words, don't wait to be asked to perform new duties. Recognize the need and opportunity and start adding value to your organization. Help your boss and he will appreciate and find ways to recognize you.

• Promotions come in different flavors. If your company does not currently have an opening to manage (more) people, you can still be recognized and promoted as an individual contributor. More and more companies understand the need to attract and keep top talent and are becoming increasingly creative about ways to satisfy career aspirations of their high achievers.

• Even if you don't get promoted soon enough at your current organization, you will begin developing a reputation that will serve your long term goal and ultimately put your career on the right trajectory. Fast forward 5-10 years in the future, when you apply for that coveted VP job, your recruiter will be searching and talking to your current boss and colleagues about you.

• Finally, be ready to recognize when there is just no room to grow in your current organization. Let's say you are in a small start-up that is not growing particularly fast, and your boss is one of the founders. In situations like these quitting is not necessarily losing, it may just be the right step to take you closer to the promotion you are looking for.

What is your experience? Can you add to this list?