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.

How a small renovation turns into a new house

In this post I will try to describe what happens when one day we once again try to extend or improve our large and established complex product.

...

Imagine you live in a 100+ year old house and one day decide to make a minor renovation, say replace the kitchen cabinets. Cheerful, you start on the project reaping the old cabinetry apart, only to find behind them the water damage on the wall. You need to repair that to prevent mold formation, so you take off the damaged part of the wall to reveal rusty plumbing just about ready to burst open. You try to turn off the main water supply and the valve handle stays in your hand. On top of that you notice the beams of the foundation are nearly rotten through...

Before long you realize most of the house is in dire need of serious restoration. You step back and decide you might as well just bulldoze the house and build the new one, and while at that take advantage of all the modern technological breakthroughs and such, like energy efficient insulation, roof and windows; home automation controlling your heating, cooling, lighting and window shutters; modern kitchen appliances, plus add some excitement like sauna and indoor swimming pool and fully equipped exercise room. Awesome! Your family loves the project idea, you are excited and can't wait to start, and finally move out to a summer cottage...

As the project commences everyone can't stop talking about new and exciting things this new house will have. How it will all be wired for Internet, the custom made front door, Italian chandeliers, the Jacuzzi, the new furniture and flat panel TV that will go in the new open plan Living area...

Time goes on, the checks get written to contractors and the work seems to steadily progress. After some time we are all excited about the big hole in the ground. A little more patience and we have a skeleton structure that we are told going to be our new house. No walls or staircase inside yet, but we manage to keep our spirits up by imagining things. All we talk about are the new and exciting features of our new house: the pool, the Jacuzzi and Italian chandeliers.

More time passes by. Our impatience starts to build up and anxiety creeps in as allocated pool of money quickly dwindles down and the winter season approaches. We now have a temporary front door, just a cheap one to provide basic security. There is also a designated area for kitchen with one electric outlet available. No appliances or sink hooked up yet, but hey, there are now temporary lights throughout the house so we can be there after sunset!

When the first snow arrives and the remaining work on the house has to be put on hold until spring time we move back in.

So what do we have? Everything is very basic or temporary while the right stuff is on back order. Linoleum floors in the kitchen, cheap carpet in bedrooms, plastic bathroom counter top. At least for the time being we have no more money left for exciting extensions and additions, but whatever we have is brand new! We also feel good about how easy it will be to extend or improve what we have.

...

If you've ever engaged in a product innovation (see Dealing with Darwin) on a large scale the story above might resonate well with your experience. No matter how much it makes sense looking at it from aside, we are never quite ready to deal with reality of deep re-engineering existing feature rich, mature product. The risk of failing in this endeavour is very high, but if we succeed the benefits are superior to most of the other alternatives.

Let us succeed!