Difficult customers?

Not letting occasional unconstructive snaps from our customers rattle us and keeping communication channel open (friendly, forgiving, etc.) in the grand scheme of things will serve us best.

For starters what we hear will broaden our horizon and may teach us new things or let us connect the dots in our head in a new way.

Not everything customers ask us to do is best for our product. Listening to customers doesn’t have to automatically translate to action. It's all about acquiring as many data points as we can, even if these are low quality data points. ...just keep fishing.

Finally, it's not uncommon to see highly critical, skeptical customers eventually turn into most vocal and passionate advocates of our products, thanks to not giving up on them at some point.

Realize how others perceive you

Considering we don’t really change personality-wise over the years, it comes as no surprise that our communication style often remains essentially the same as we grow in our careers. I recently realized however that the role we play in the organization has a great impact on how people interpret our messaging. Consider how the same brisk but honest statement from junior engineer “we have to do better, our UI is too clumsy” would come across very differently from a senior manager...

Have you noticed how as people move up the organizational ladder their written communications become sparser, particularly when addressed to multiple recipients, ultimately disappearing completely or becoming outsourced to professional aids? Could this be driven by the fear of being misinterpreted?

Are we there yet !?!

With almost any sufficiently important project executives (or investors) want to keep a close eye on the progress made. As the project nears completion and the product launch looms ahead tensions may raise as uncertainty of successful outcome builds. See if you recognize this inquiry Product Managers may be responding to near the project end:

"As the owner of the backlog, how do you evaluate the priority? Do you have things such as must have vs wish for? Each time I have released a new product to market, there are always more things to do...it's a universal constant.

What I am looking for is a report that tells me how much of the backlog is customer driven/validated (required to be competitive in the market) vs. what folks desire. If we had a report that could provide insight into the health of the offering....not sure what metrics I would want to see, but I am sure I would like to know if the epics we started out to build, are creating the value we envisioned (i.e are market ready)."

 
In traditional requirements management, requirements are often categorized at 2-3 levels (e.g. Must/Important/Wish or High/Medium/Low). In Agile we are taught to rank them (user stories) from 1 to N, so if you have say 100 requirements ranked from 1 to 100, you may have only 10 show-stoppers - requirements that you believe absolutely prevent you from launching your product, or you may have 80 show-stoppers. In one case you are very close to be able to confidently launch your product, in another case you are probably quite stressed out.

So how do you know when you are truly ready to launch? Are you getting closer to that point, seem to be standing still or are actually drifting away?

Agile forces us to worry less about "launch readiness" in favor of most efficient utilization of available resources. In other words, as long as our teams (fixed resources) always focus on top priority (as defined and adjusted by Product Owners in timely fashion) issues there is nothing we can do... other than recognizing when we are not ready to launch.

There lies one challenge many Agile projects have to deal with: when the launch date is "artificially" fixed in advance the product team is like an airplane crew forced to land irrespectively whether the landing gear is down or not, without regard to weather and airstrip conditions. Should the crew be able to decide when is the right moment to touchdown, or in response to 1st class passengers "Are we there?" just strap on the seat belts and hold tight?

So in recognition of the need for transparency, how can we indeed bring more clarity to our progress on the final approach, without causing unfounded panic in the main cabin? :-)

The big question for your end game

As a Product Manager sooner or later you find yourself dealing with one of those precarious situations where there seems to be no sane resolution to the challenge in front of you. The release date cannot be moved, you have no additional resources to work with, and there seems to be endless number of release blockers - features or defects that absolutely must be addressed prior to release.

To help successfully navigate through this last mile of your release journey, ask yourself and your team the following question:

At this stage of the project, can we afford to expend any effort on anything other than feature or capability that if missing will prevent 100% of our target customer base from adopting our product?

• Any effort includes testing and documentation of workarounds;

• Anything other includes useful capabilities requested by loyal, real customers - people with families and kids who we absolutely want to delight;

• Target customer base does not necessarily include each and every one of our existing customers, and does not have to be centered on Big Bank ABC in particular (or Super Big Telecom, or Government Contractor XYZ, nor many other prominent check writers).

One way to upset your developers

While there is no shortage of different ways to upset someone working hard and under stress, I'd like to share a real life story to illustrate how even seemingly innocent discussion can have unintended effect.

As a product owner I began noticing more and more technical stories added to my backlog by the scrum team members. These stories often focus on improvements that are not immediately clear to the end user of the product. In many cases with a little extra effort it is possible to rephrase the description to turn them into user stories. In other cases, these are indeed technical stories benefiting developers more than the end users.

Here is how I tried to explain to my scrum team why I am not the right person to rank these stories for them.

I told them as a representative of our customers, I want to understand the value of every story on the backlog in as far as it relates to a tangible product feature or a capability. If I see enough value to potentially pay at least $1 for the feature, this means a story is a valid user story and I should be able to rank it. For example, if I buy a car, I may care about maximum speed, rear view mirror and even the type of stitches used for my seat covers. As long as I care for these things, I could potentially arrange them in a ranked list. On the other hand, features that I don't understand... I simply don't care about. For example, I don't care if my car is powered by a V-type, in-line, horizontally-opposed or rotary style engine, what type of alloy is used in my brake pads, or that my SUV came from the same assembly line that also makes minivans.

I told my team they are welcome to use technical debt for these stories, which can take as much as half of our typical sprint velocity. The team knows better which of these stories are more important and should make prioritization decisions based on technical merits, not the product owner.

Can you see a problem with my reasoning? If so how would you go differently about it?

Re-engineering an established product (Part 2 of 2)

A large established software development organization that has for years perfected incremental, enhancement driven innovation is likely to face challenges trying to launch a brand new version 1.0 product.

Most of the processes and procedures designed to help the organization be better at improving mature product are detrimental for the success of a young baby product, which is like green grass struggling to grow through the layers of bureaucratic concrete laid on top of it. These processes and procedures are meant to drive the costs down and bring quality sustained at higher scale, across large customer base. These issues are in fact least of the problems for a version 1.0 product. As we recall, the main challenge for a brand new product is to secure incremental funding needed to build version 2.0, and there is no better way to achieve this than securing early adoption by a small number of prominent customers.

Just when the team needs sharp as a knife focus on one set of priorities, a large set of existing customers, a dream for many aspiring entrepreneurs, can pull the product team in a multitude of opposite ways. These customers and their sales account teams will do everything in their capacity to tilt the product team’s backlog prioritization in their favor.

On top of this all, the so-called "corporate tax" kicks in. On the one hand, large established organizations often come up with a list of well intended minimum compliance criteria for all the products they release (e.g. foreign language localizations, certain OS platforms, Section 508, FIPS-140, Common Criteria) and are not prepared to negotiate any exceptions for version 1.0. On the other hand, these organizations from time to time commit themselves to various initiatives and expect all product teams to comply (e.g. Agile software development, CMM framework, and certain development languages, protocols and tools).

These are just some examples, but collectively these and other types of unnecessary distractions add up to heavy burden that explains why so few new product innovations succeed at large corporations. As a product manager you have the opportunity to recognize these obstacles early and help guide your team around them.

Re-engineering an established product (Part 1 of 2)

Attempting to re-engineer an established product within the same organization is a huge challenge.

Developing and launching a version 1.0 of any product is fundamentally different from releasing its subsequent versions. It is in fact the most special, most fragile stage of life of any software product. Only some products survive past version 1.0. "Why?" - You may ask. The explanation is in that version 1.0 rarely has broad enough appeal and sufficient momentum to generate enough sales to become financially self-sufficient. Instead, these “babies” almost always need some “milk” to go on, i.e. additional funding. To secure that additional funding, product managers need to work hard to convince investors in the high potential of these products, otherwise they may lose patience or simply become interested in another investment opportunity.

Cheating, delaying the release deadline trying to fit in more features, does not always help and is actually dangerous. Just when you least expect it, investors may lose patience, cancel the project and the product will die even before version 1.0 sees the world.

So how can we secure version 1.0 investors' goodwill? It's actually simple. The best approach is to get a targeted, small set of customers to start using the product. These would be the "early adopter" type of customers, those who are willing to live with its initial shortcomings in return for the latest, groundbreaking solution to their real problems. These customers will be enthusiastic, optimistic and not too shy to speak up and share their views with the rest of the world.

So with a version 1.0 product our focus should be first and foremost on demonstrating to our investors the high potential of the new product.

As surprisingly as this might sound, compared to a privately funded startup without any customers, bringing version 1.0 to market is actually much harder to do when you are attempting to re-engineer an established product already used by many customers. Let me share some of the obstacles you may encounter in my next post, see if you recognize any of them.