To share or not?

Should the product teams submit their internal ideas for voting by their user communities or not?

This reminds me of the internal dilemma some A/A+ students face: to share or not, i.e. to always do their work in solitary mode or to join a study group. Personally, I've always believed I can only get better by sharing what I know. Sharing allows improving my knowledge and skills either through teaching what I know, responding to broader range of clarifying questions, or through a realization that my perceived understanding is not quite accurate.

Hence, I fully support the concept of posting internal ideas for voting and commenting by the user community.

If a potential product idea is misunderstood by the audience or not really seen as valuable it will receive few votes and will be buried by other more critical in the eyes of the user community enhancement requests. It's far better to find out early that what we think is valuable is actually not.

In addition to straight voting score, this approach also gives us the opportunity to hear back from the user community members in the form of comments, including clarifying questions, fine tuning points and additional use cases and scenarios.

As an added bonus, sharing internal ideas with our user community promotes a true two-way collaboration and trust between the product team and the customers and field.

Running our calls on time

In his article Class bells Lynn Grant reminds us of the old good times when our classes in school ended with a bell, making sure we stop and move on to our next class in a timely fashion. Would not the bells be nice in many cases in our modern life when we are scheduled to attend multiple back to back meetings and calls throughout the day? Thanks for the fond memories and releavant association Lynn!

In the absence of bells a few more tricks/ideas may help run your calls/meetings in a more efficient manner:

• We tend to always block off the entire hour, even if a 15 minutes discussion should be sufficient. Go ahead, pick a suitable next meeting and schedule a shorter time slot for it.

• Yes, we are often more accustomed to start our meetings/calls 5 minutes past the official start time, allowing participants to switch from their previous call or walk from another meeting room. If you are the organizer, try allowing your meetings to end 5 minutes before the scheduled time.

• Time boxing a particular agenda item often helps.

• When using a WebEx, a GoToMeeting or other similar online meeting technology, making sure the online roster is correctly used/initialized by everyone dialing in helps save time at the start of the call going over the participants on the call, keeps people more engaged in the conversation because at any given time everyone can see who is talking and who is listening, and reduces time waste due to inevitable noise on the line (barking dogs, crying babies, music on hold) from an anonymous caller line.

• The rule of SEVEN, i.e. if you want your meeting to be a productive one where a decision can be made quickly, don't exceed 7 participants. Recent research by Bain & Company, published in the book "Decide & Deliver: 5 Steps to Breakthrough Performance in Your Organization" indicates that once you’ve got 7 people in a decision-making group, adding an additional member reduces decision effectiveness by 10%.  As a result, large groups rarely make any important decisions, at least not in a time efficient manner.

• Don't join every meeting or call, understand why your presence is needed and decline the invitation if you don't anticipate contributing to discussion.

• Excuse yourself from the meeting if you find yourself immersed in something else, reading or answering emails for example. Your departure will reduce participants count and may help run the meeting on time, and it will certainly help you focus better on what seemed to be your primary task.

• If nothing seems to help run your meetings on time, 2-3 minutes before the end time, announce you are leaving and hang up when the meeting time is over. The more people will do this the more we will run our meetings on time.

Do you Ba?

Have you ever attended a backlog grooming session where participants appear detached, yawning around the table, the scrum master is sizing the stories and handing out the tasks, and hardly any questions are raised about the new user stories? How does this compare to the loud, agitated white board discussion, team members eagerly leaning in, volunteering their help, clarifying the objectives and acceptance criteria of the user stories presented? What's the word to describe the different feeling in these two rooms?

For a while now I've been looking for a way to describe this special spirit emanating from a high performing Agile scrum team and, thanks to Dean Leffingwell tip, I think I've finally found it.

Meet the "Ba"

In their research of organizational knowledge creation Ikujiro Nonaka and Ryoko Toyama define "Ba" as a shared context in motion, in which the context is constantly moving and the knowledge is shared, created and utilized. Through interactions with others and the environment, both the contexts of Ba and the participants grow. To participate in Ba means to get involved and transcend one’s own limited perspective.

In his blog (On “Ba” at a Scrum of Scrums) Dean Leffingwell builds on the original teachings and shows how Ba is essential to Agile software product development, as the energy that drives self-organizing teams. 

• Dynamic interaction of individuals and organization creates synthesis in the form of a self-organizing team.
• The fuel of Ba is its self-organizing nature - a shared context in which individuals can interact.
• Team members create new points of view and resolve contradictions through dialogue.
• New knowledge as a stream of meaning emerges.
• This emergent knowledge codifies into working software.
• Ba must be energized with its own intentions, vision, interest, or mission to be directed effectively.
• Leaders provide autonomy, creative chaos, redundancy, requisite variety, love, care, trust, and commitment.
• Creative chaos can be created by implementing demanding performance goals. The team is challenged to question every norm of development.
• Time pressures will drive extreme use of simultaneous engineering.
• Equal access to information at all levels is critical.

Now that we are more aware of it, what are the different options available to employees at all levels in their organization to help build and nurture Ba?

Concealing your weaknesses alone will not make you a winner

My young daughter is quite competitive by nature and when we first started playing chess she immediately focused all her attention on not losing, whether that was about individual pieces or the whole game. She quickly improved at that aspect of the game, but she was still miles away from actually winning her first game...

I am a big believer in open Ideation with my current and prospective customers so that

1. I can build a vibrant Ideation community, with more eyes, views and opinions shared (in the end I will still translate what I see and prioritize my release backlogs, but the value of any Ideation system is only truly unlocked when it is open and embracing vs.when it is tightly controlled)
2. I incur zero admin overhead for membership management (I am busy, and I don't want to stand in the way of my end users who are willing to donate their time to help me build a better solution for them)

I support responsible Ideation - anyone making changes to Ideas (voting, commenting, submitting new ideas) should be authenticated. This allows moderation of online community behavior and generally understanding the participants better, e.g. if we want to interview someone to clarify or better understand where they are coming from.

We are often naïve worrying too much about our "evil" competitors. Truth is they are too busy fighting their own demons.. and if we lose to them it's not because we are open and transparent but because they move faster and develop better solutions for our customers.

We should be worrying more about our ability to execute better and about improving our company's brand appeal. This will make more for growing our business than trying to conceal our deficiencies. Open user communities, Ideation and even the user documentation shared publicly can help turn around sometimes dated and unfavorable perceptions about the vendor. Trust is a critical foundation for turning around stale brand perception (i.e. what our customers think of us), and being more transparent and embracing with our customers, partners and our own employees will go a long way in this endeavor.

The fallacy of "low hanging fruits"

Why does it take so much time to make small improvements in our software products?

I am noticing how the pace of product improvement slows down as the product becomes larger and more complex over time. What seem to anyone as a small change, perhaps a matter of modifying a few lines of codes, for some inexplicable reason drags on and on and often not gets done at all. I set out to understand why this is happening, particularly when Agile culture seems to be so firmly embraced by the product team.

I found several contributing factors, and perhaps there are more.

First, the complexity and sheer size of the software product plays a role. Put simply, making the same change in the product that is 10,000 lines of code is not the same as touching the product that is comprised of over 1 Million lines of code. While a lot depends on what exactly is touched, in general the number of dependencies is higher in larger products, and hence the likelihood of unforeseen impact is also higher.

Second, the number of people who may touch the same area of code plays a role. The more developers involved in the same or adjacent parts of the source code that need to be modified, the harder it is to avoid misunderstanding about the intentions of individual software developers. This in turn makes it harder to foresee the impact of even a seemingly straightforward change. Those of us who have ever coded can surely recall encountering some questionable coding styles, cryptic naming conventions, commented out blocks of code and lack of comments explaining the intent.

Third, and somewhat related to the previous factor, is the age of the code. Over time layers of code changes are made by different people. Each change is tackling a particular need, often a special case favoring unrelated requirements or a subset of customers. Again, a developer supposedly making a minor improvement may not necessarily know everything about the code he is touching.

Fourth factor is the number and variety of customers using the product. With just one customer, usage of the software product is specific and generally more predictable. On the other hand, with more customers the number of different scenarios, integrations and workflows raises, increasing in turn the cost of adequately designing and testing even the minor change and considering the full impact on all customers. After all what might improve the product for one set of customers may break something for other customers.

Perhaps after all not all of those "low hanging fruits" are hanging low enough or maybe they are not even fruits at all.

Cloud security - who is in control?

I was looking for some numbers in support of my belief that we should focus more on enabling organizations to benefit from cloud applications, rather than sticking with the “on premise security” mantra of control and prevention. Any applications or services consumed from the cloud just can't be as tightly controlled by the enterprise IT as anything operated within their own environment.

I found these articles:

IT's Losing Battle Against Cloud Adoption

I share the view expressed by the author in the conclusion of this article:

"If anything, it seems like IT needs to shift away from its role as gatekeeper to instead being an enabler, one that finds different ways to deliver security. For example, Apigee enables enterprises to secure sensitive data rather than the devices or apps running beyond IT's control. These and similar measures may be ways for IT to remain relevant in a cloud-dominated enterprise, one that doesn't need or seek IT's permission to spin up another EC2 instance or start a Dropbox shared storage space.

One thing is clear: IT has no control over the cloud, and likely never will be. Time to get over it and figure out ways to live by its rules."

Most CIOs grossly underestimate how many cloud apps their employees use

Measuring scrum teams' velocity acceleration

No matter how exactly the scrum teams decide to measure their velocity, how the people are incentivized or motivated to drive productivity improvements, at the end of the day what really matters is the elimination of waste due to unproductive activities and increased output of value for our customers.

I found this blog post by Jeff Sutherland (Six Signs your Team’s Acceleration is Too Good to to be True) offering a great insight into the challenges with measuring velocity improvements of Agile scrum teams.

Why should we aim for shorter sprint duration

I was asked the other day why do I prefer shorter sprint duration, say 2 weeks instead of one month. I’d like to have shorter sprints for a number of reasons:

• Assuming we are motivated to demonstrate something tangible at the end of every sprint, with shorter sprints we end up looking for ways to produce something tangible sooner. The resulting sense of urgency in itself is good, although this is not about making our engineers work harder, that’s not the point at all.


• Shorter sprints encourage teams to master ways to break down large chunks of work into smaller independent user stories and as a result to better manage technical risks, helping increasing the odds of delivering more value at the end of each iteration.


• Shorter sprints motivate us to scope and size just enough level of detail and just enough user stories ahead (Just in Time) to help us deliver value and move at brisk pace. We gradually find ways to reduce and eliminate waste from our processes. For example, we learn that a user story that is thoroughly researched too far in advance often ends up collecting dust on our backlog as we may switch our priorities before we ever start working on it.


• With shorter iterations there is less time to procrastinate. Every day the team goes through daily stand up and it does not take long before we all know who makes good progress and who needs help.


• Shorter sprints help better manage risk across multiple scrum teams within a release. The longest a product team will go without knowing something is wrong is two weeks instead of one month or longer.


• With shorter sprints we become more nimble, more Agile as a vendor and competitor. In only two weeks we can pivot, change our priorities based on newly acquired knowledge, instead of sticking to the plan for one month or more.

Self-promotion vs. Tall Poppy syndrome

Some years ago my first manager/mentor in Australia warned me during my exit interview, "to beware of tall poppy syndrome." At the time I took it to refer to the price of doing what's right. Later I learnt this was a more general reference to Australian culture of low tolerance toward people who stand out from the crowd.

Australian is not the only culture where keeping low profile is a common norm. Growing up in Russian-speaking Moldova, I remember how children were taught modesty. The teaching was supported by a popular illustrated fairy tale about nasty, selfish letter "I" who no one liked, and an old folk proverb roughly translated as "I is the last letter of the alphabet". Indeed, the Russian equivalent of "I" is the letter "Я" and it is the last letter of the Russian alphabet.

Not surprisingly, people brought up in cultures that place high value on humility and teamwork often find it difficult to adjust when moving to the USA, where every growing child is encouraged to seek stardom, and a strive for individual achievement is widely considered to be a key success factor.

This HBR article (by Dorie Clark and Andy Molinsky) takes a look at how people deal with these differences in the context of self-promotion in a business setting, and offers some good tips.

Personally, 14 years after moving to the USA I came to see the self-promotion as a way to simply inform others about me. When I frame it like this it does not feel like bragging at all, not in the culture where others are often genuinely interested in my personal accomplishments...

Why do Product Managers need to master Social Media?

Modern social media comes in many shapes in forms these days - online user communities, blogs, consumer reviews such as Trip Advisor and Amazon, YouTube, Twitter, Facebook, LinkedIn, Tumblr, Foursquare to name just some. Going forward we can expect to welcome more and more innovative concepts in this space, all fueled by ubiquitous access to connectivity, continuous proliferation of portable (or even wearable) computing and the eternal human nature of curiosity and desire to be heard.

Social Media helps people connect in a meaningful way. With the help of Internet connectivity emerging shared interest often leads to formation of online groups and audiences of all sizes, some only exist briefly and fall apart (think of a comments thread for a Facebook post), some turn into large active online communities. Product Managers who find a way to attract the right people to their audience and turn that audience into a stable self-sufficient online community gain access to a powerful strategic resource.

People who join online communities are typically at first driven by curiosity, but some of them end up expressing their opinions and often find themselves contributing in ways that help strengthen and grow these communities. It does not really matter if some voices in the room are negative, what matters is that people have opinions and care to express them.

Having access to this pool of people, weather they are colleagues, partners or customers is invaluable for Product Managers as this enables targeted communication with the audience you helped build and therefore know well. This can help with market research, Agile product development customer validation, product usability studies, new design wireframes reviews, identification of new differentiation opportunities and pain points and more.