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?