Listening to Customers

What’s important in interactions with customers is how we interpret what we hear. As Product Managers//Owners (PO/PM) our challenge is to listen actively and always seek for the underlying pain points.

Customers may be telling us how they want to change our product, but we always need to dig deeper to understand why. Never be afraid to follow one “Why?” with another, with another, and yet with another. Sometimes it takes several attempts to get to the bottom of why the customer really wants us to change the product. If we understand the real need, the real pain point, then we can present the challenge to our engineers and architects in a way that leaves room for them to address the root of the issue in a most creative and effective manner, potentially much better than what the customer had in mind.

Other times, the customer may not even mention the pain point, not realizing they have it. Here again a PO/PM using effective interviewing skills can pick up on potential opportunity to create value for the customer, to alleviate a pain point, to offer them something they would be willing to pay for.

Last, but not least, PO/PMs are managing products, not tailored solutions. We therefore need to look for common needs, ways to improve our products for all (or many) customers not just one. This requires ability co connect the dots, draw parallels, and recognize patterns when interviewing customers. Often times customers describe their needs, issues, challenges using different words and propose different solutions. No one is in a better position than a PO/PM to help translate this stream of data into actionable product roadmap and backlog.

Stretch Objectives

What do I think about them?

ox·y·mo·ron

Dictionary result for oxymoron

/ˌäksəˈmôrˌän/

noun

a figure of speech in which apparently contradictory terms appear in conjunction (e.g. faith unfaithful kept him falsely true ).

Way too often Stretch Objectives are understood and used by teams in a way that make them a classic case of oxymoron. And no wonder. After all “Stretch” implies uncertainty and hope. “Objectives” on the other hand imply exactly the opposite - certainty and commitment.

Teams may find it more self-fulfilling to present longer lists of objectives at the end of Program Increment (PI) planning by including along with PI Objectives also Stretch Objectives.

The reality however is that the product organization can only count on committed PI Objectives, not on hopeful Stretch Objectives. Stretch Objectives are merely work items that the organization wanted teams to take on but in the end admitted/realized they cannot be committed to in a given timeframe, due to some constraints.

Furthermore, the understanding of relative importance (priority/ranking) to deliver on Stretch Objectives is a snapshot in time, valid only at the time of PI Planning. As teams move through the Program Increment and receive new inputs, the product needs and priorities may change, potentially invalidating or changing priority of the original Stretch Objectives. For this very reason as a good practice teams should re-confirm with Product Management later during PI before work on any Stretch Objective starts.

Here is how SAFE defines Stretch Objectives:

Stretch objectives help improve the predictability of delivering business value since they are not included in the team’s commitment or counted against teams in the program predictable measure.

Unfortunately, way to often teams forget the difference and keep Stretch Objectives on the list just like PI Objectives. Over time I found it best to simply move out all PI Planning candidates back to the parking lot for consideration in future Program Increments.

What's your experience with Stretch Objectives?

Agile Transformation (Part 1) - Understanding Your Investors

In this miniseries I want to share my observations about the organizational challenges with Agile Transformation. The information I use originates from my personal experience as well as from anecdotes and stories I collect from my friends and colleagues working in the software industry.

Any Agile Transformation is soner or later bound by the organizational capacity to accept change, and this includes executive leadership. At the end of the day, no matter how far the product development team is capable of going in becoming lean and Agile, they need full support and understanding of their investors, including customers and executives.

To illustrate, I want to use the unrelated at first glance story about the Japanese/American cultural differences. I drafted and never published this post more than a year ago, finding it interesting from the cultural perspective point of view. As I re-read it now I was somewhat surprised at how natural the story read if I were to replace the "American Vendor" below with a software development organisation striving to adopt Agile and similarly the "Japanese Customer" with their corresponding corporate level executives.

Situation: An American Vendor working on addressing a Japanese Customer’s request. Part of the disconnect is due to some cultural peculiarities that need to be understood by the Vendor.

First, the Customer fully expects to be able to provide input into the Plan. Not only the bottom-line value to the Customer has to be clearly articulated, the Vendor needs to sell the Customer on each item in the Plan so they understand how it maps to their concerns.  

Second, from the Customer’s perspective, the target completion dates should be thoroughly vetted and accounted for all possible delays. While an American might think this is unrealistic or overly conservative, from a Japanese perspective this is normal. From that perspective, it can be seen why multiple revisions to the Plan dates become problematic – the Vendor loses credibility with regards to its forecasting ability. This also helps understand why the Japanese Customer sometimes finds it hard to believe Vendor's explanation of the reason for a delay. The Customer believes the Vendor should have predicted the outcome and mitigated the risk before the Plan was committed (unless the Vendor is hiding the real reason for the delay). Again, from an American perspective this is unfathomable, but it helps to see things from the Japanese Customer’s perspective. 

Third, Japanese companies need frequent updates and hand-holding. Even if no progress is made, they need to be updated by the Vendor, with explanations why what is being done matters to them. The level of updates that Japanese companies see as normal may be considered an overkill to an American. Depending on the situation it is advisable to provide a weekly or even daily status update that simply states what has been accomplished and what is planned for the coming period. This can go a long way towards maintaining good relations. 

Fourth, the phrase “TBD” is not acceptable to the Customer. Culturally, Japanese are not nearly as comfortable with uncertainty as Americans. We see TBD as a necessary component of planning, but the Customer sees it as a lack of focus, investigation, and drive. For this reason, it is best to use TBD sparingly, and only if accompanied with an explanation of why it is undetermined, and when/how it will be determined. 

Bottom line, when helping Japanese Customers we need to make sure it is crystal clear what problem we’re trying to solve and exactly why that particular action item has value to them. Also, if there is some uncertainty, or if something will take more than a week to complete, or if there were multiple revisions to the target date, we need to thoroughly explain why.

What's my point? To be successful every Agile Team needs to understand the psychology of their investors, or their executive management.

Do you respect the backlog?

We always strive to be more effective in how we build software for our customers, and today I was compelled to reach out with the following to my scrum teams:

The backlog ranking order is in place for a reason. Traditional waterfall software development projects have for years struggled to meet planned quality, schedule and content targets. The Agile software development recognizes the unique nature of uncertainty associated with software development, and gives us an approach to improve the governance and predictability for shipping quality software while building the content that target customers want. We do this by 

• QA: building quality targets into our definition of done criteria and acceptance criteria. This way any work that fails to meet DOD or acceptance criteria is not accepted and is not shipped. 

• Schedule: fixing the timeline. Sprint duration is fixed. Anything that is not accepted is not part of a sprint delivery and is not included in the shippable product (we can choose when we ship the release, but only after one of the sprints). 

• Content: we use backlog ranking to control what gets built as part of the release. When we run out of time, ranking ensures that we had enough time to build what we wanted to include in the shippable product and that we didn’t instead use that time to do something less desirable.

Generally speaking you should not begin work on any defect or a user story if you are also the owner of another open defect or an unfinished user story that is/are ranked higher. If you want to work on this because you disagree with the backlog ranking order, this is material and it is important that other people working on the release know; so just bring it up in our daily standup meeting, or reach out to me or your scrum master (in person, Flowdock, Skype, email, call, SMS). We can quickly discuss this and come to a shared agreement which can then be communicated and logged (e.g. in the Rally Discussion tab of the affected work item).

This also applies to any new work items popping up in our backlogs in the middle of sprints, i.e. items that we have not explicitly planned for during Sprint Planning sessions. If you open a new defect during the sprint or move a story or a defect from future sprints, please communicate/log this (e.g. by adding the explanation in the corresponding work item’s Discussion tab in Rally). Again, in general, the work on these work items should only begin when all the items planned for the current sprint are either completed or the work on them is blocked. If the unplanned item is critical for the sprint progress, we should discuss and if deemed necessary rank it higher on the backlog and (again) communicate/log our decision.

Although we are dealing with high uncertainty associated with complex software development, our business needs us to be more predictable in our ability to ship the working product. This is really important for our company's ability to operate as a well-run successful enterprise. Improving the following will help us get better 

• Transparency and communication

• The discipline and consistency in how we allocate our time during the sprints 

What makes top performing teams click

I came across this great New York Times article called "What Google Learned From Its Quest to Build the Perfect Team", and since the topic is near and dear to me I am taking time to share my short interpretation of this knowledge.

This research points out that best performing teams typically excel in what psychology researchers refer to "conversational turn-taking" and "average social sensitivity" behavioral norms - both relating to psychological safety defined by the Harvard Business School professor Amy Edmondson as 

"a sense of confidence that the team will not embarrass, reject or punish someone for speaking up,.. It describes a team climate characterized by interpersonal trust and mutual respect in which people are comfortable being themselves."

Reducing the number of supported platform variations

Does your product support multiple platform variations (operating systems, databases, etc.)? Have you noticed how it slows your development cycle and adds to the cost of maintenance and new development? If you've contemplated how to get out of this situation, you are not alone. This is a common challenge for many established software vendors.

Consider this hypothetical example:

Two companies compete, both have the same budget. Company A only ships on Linux and only on MySQL database. Company B ships on Linux, Solaris and Windows, and supports Oracle, MySQL and PostgreSQL databases. Question, which company can offer more features, better quality and/or more frequent releases?

Of course one can argue that for Company A part of the market is simply shut off because of the strong platform preferences many customers exhibit, but is it truly always so? What if Company A offers far superior overall solution, could it in some cases swing the balance of platform preferences in its favor? Surprisingly, in many cases, yes!

New products these days are almost always pick one of the following go to market strategies to make it easier to accomplish what Company A is trying to do:

1. Appliance, where the customer gets a box, and simply does not know what OS or DB are inside;
2. SaaS, where the customer uses browser and mobile apps, and again does not know what’s in the data center behind flickering server lights.

In both cases, this helps software vendor to focus on capabilities, quality and time to market (instead of retesting the same feature set on yet another platform variation), helping better optimize available funding.

Granted, it’s a lot harder to shrink to fewer platforms vs. not letting them expand in the first place, just like losing weight. Trying to do this for an existing mature product is guaranteed to upset some of your customers, yet it is still possible to make this decision and announce that going forward you are dropping one of the operating systems and one of the databases for argument sake. In the long run this will help you better serve your customers. If you calculate this well, on a balance you will actually gain more customers, even if you initially lose some.

It's okay to be introvert

I grew up in Eastern Europe, and after immigrating to Australia and living there for 10 years I relocated with my employer to the USA. Ever since that move I started noticing one particular set of cultural differences. I felt like to be successful at work I need to fit in better, to find a way to behave in a way that is unnatural for me - to be more of an extrovert than I really am.

I found it necessary to speak louder and more frequently than I would normally do.

I observed how uneasy people feel about a pause in a conversation. Someone would often start talking without any particular substance just to fill the "awkward silence".

Somehow in this culture high performers are expected to be assertive and outgoing. The enthusiasm is expected not just at work but also during informal social events. Class Participation and Team Projects are important part of the grading process at business schools, while networking skills and etiquette at business dinners and cocktail receptions are often deemed important enough to be explicitly taught.

Over the years I watched how more and more organizations opted for open space office configuration for their employees. As much as I am a big fan of Agile and Scrum Team collaboration dynamics, I just don't find that à la "Wall Street trading floor" workplace setup conducive to any type of work requiring concentration and attention to detail.

Earlier this week I read the Forbes article titled "Research Shows There May Be A Hidden Dark Side To Working With Introverts". It mentioned Susan Cain's book "Quiet" and so I looked her up online. Susan's spirited presentation on this topic is amazing in terms of addressing this very close topic to me.