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!

Agile style customer collaboration

Don't we all aspire to build a product that will be a smash hit success? If you are interested in how the product team can engage customers to make this a reality read on.

One of the founding principles of Agile Software Development manifesto teaches us to value customer collaboration over contract negotiation. In this modern world we often hear calls to "fail fast and often" and for "end of sprint customer demos". As the product managers of hi tech products we ought to accept the uncertain nature of innovation. At the same time, while we are innovating, we should strive to keep up with the ever transforming reality of our customers world, avoiding the trap of the ivory tower. The ultimate success in our job comes with the product that every customer wants to have, not necessarily a research paper published in the scientific journal.

So, let’s engage our customers early and often. Let’s validate our vision, feature list, deployment diagram, UI wireframe, first build, second build and so on. Let’s not wait for feature completeness, code freeze or QA approval. Don’t be afraid, customers will understand the early nature of what they are looking at. They will appreciate the opportunity to have a say in what’s being built for them. Come back next sprint or iteration and show them your progress. If you are truly on track to develop something that will solve their real problems, customers will actively participate, test and feed ideas.

Don’t be afraid to engage too many customers. The more voices you hear the better you will be equipped to guide your team to deliver the product for your market rather than for a handful most vocal customers.

On a practical side, get ready to collaborate in three key areas:

• Questions: a message board of some sort might work well, make sure your responses are visible to others so you don’t have to repeat yourself;
• Ideas: if possible find a way to let your customers submit their ideas and vote up/down on ideas posted by others;
• Defects: look for a way to track them using a structured defect tracking tool.

As you move through the release cycle, you will notice the distribution between these three areas changes. Questions and ideas typically dominate the early part of the project. In the latter stages, as we often shift focus to stability and performance, majority of the feedback tends to be centered around defects. Anticipate this shift and be ready to deal with it.

Happy collaboration!

The dark side of Agile (Part 2 of 2)

6. Is the rest of your organization ready for Agile? Developing a great product is half the story. Depending on your organization setup and practices, you will need to go beyond your development team to conduct beta program, develop sales collateral, train account teams, solution architects and technical support to sell and service the new product, develop customer education content, set up back-office systems to accept and process purchase orders, etc. If your development team has only recently embarked on Agile path, chances are the rest of the organization will need some help to understand how they can best help successful product launch in this setting.

7. Arbitrary deadlines. I hear a lot about time, as opposed to feature, driven nature of Agile development. At the beginning of our project we had to put a stake in the ground, decide on the product launch date. We picked a date that happened to coincide with a major trade show so that we could announce a new release there. The thought was Agile forces us to work of the ranked backlog and produce a working product at the end of each sprint, so in theory any date is as good as any other. The problem I see with this arbitrary approach however, you are not necessarily giving your team adequate time to develop and introduce to the market a winning product.

8. Size is not everything, or is it? Not all aspects of new software product development can be broken down into chunks of work that fit in one sprint and still make sense. Consider a user interface design. What could fit in one sprint may resemble raw database tables exposed to the end user. On the other hand a wireframe that has gone through multiple revisions and validations by customers may seem to be too big to fit into one sprint.

9. The “wisdom” of not thinking too far ahead. I often hear: “it’s just software”, “let’s fail quickly and often”, “we always refactor later”. Not so fast. Later, we don’t have time because we are working on something else, so we end up with poorly designed product, missing on important objectives. Alternatively we create mountains of technical debt or technical stories. A good example, manually creating tens if not hundreds of similar views vs. investing some time upfront to have the same views automatically created by the product using data driven approach.

10. Multiple scrum teams. We have seven scrum teams and despite our efforts to follow best practices, we all the time deal with stories spanning multiple scrum teams. This leads to all kinds of drawbacks: developers from one team struggling to find time to help another team, Product Owners not always ranking/prioritizing their backlogs with respect to these dependencies, creating bottlenecks and delays for other teams. At the end of the day, the end to end stories and workflows are more likely to be left unattended without anyone fully taking care of them.

I am not trying to paint Agile in dark colors here. However, I have to admit adopting Agile approach like any other organizational transformation is a challenge in itself. In my future posts I'll look to share with you how I dealt with some of these issues and what happened.

In the meantime, if any of the points I described in this blog resonate with your own experience please share with me and other readers.

Thank you for reading, and may the force be with you!

The dark side of Agile (Part 1 of 2)

10 pitfalls likely to be encountered by the Product Owners

These days I rarely run into anyone who has not heard about Agile software development methodology. It has become almost universally accepted brave new way of taking on the world. Let’s admit it, it’s hard to stay unaffected, and most of us embark on this bandwagon. The benefits and advantages are all too convincing, sweeping the minds of young engineers and seasoned executives alike.

With so much said and written about what makes Agile good, I’d like to contribute to the knowledge pool about some challenges you might face in adopting Agile, so here come my 10 picks, in no particular order:

1.   The turnaround on customer feedback may be too slow. You read me right, taken too literally Agile can be used as an excuse for being slower than you need to be. Let me demonstrate this with an example. We work on large scale enterprise software destined for open market, so we don’t show end of sprint demo directly to 1,000s of potential customers. Instead Product Managers find a way to schedule customer demo to validate results of each sprint’s worth of work. In the ideal case, we can arrange such demo on Friday afternoon, at the end of the sprint. In reality the feedback does not rich the team till well into the next sprint. By the time this feedback is converted into a user story with clear acceptance criteria, the earliest the team can take this on is in the following sprint, i.e. nothing to show for 2 sprints. In our case this translates to 6 weeks for something that could have taken an engineer a couple of hours to correct. This inability to react fast is becoming more impeding as the project nears completion.

2.      You may end up developing the wrong product faster than you would otherwise. Okay, overall Agile can help speed things up, but here is another catch. If you don’t have enough seasoned Product Managers able and willing to take on the Product Owner role, be prepared for someone else to step into these shoes. Whoever turns up in the Product Owner’s role is responsible for day to day guidance for their scrum team, dictating essentially what gets done and what does not (the pitfalls of engineering driven organizational cultures has been a well-studied topic).

3.     Technical stories. I find developers like the idea of measuring team’s velocity by describing work that needs to be done in form of a user story added to the team’s backlog. From my point of view however, this is not a real user story, but a technical story. Why is this distinction important? Because in my experience, the Product Manager in the role of Product Owner, and by extension majority of real world customers, would not understand the essence, let alone the value of this type of story. This begs the question, how can a Product Owner rank such story on the backlog? If there are too many of these stories on the backlog, can the Product Owner still claim the ownership of the backlog, or is this now a development team who decides what to work on next?

4.     Underperforming super stars. Don’t be surprised to find your former top performers struggling in the new Agile culture. These seasoned developers have long basked in the glory of their superiority, and may find it less motivating to learn new roles, and to listen to the arguments of junior team members. In short, someone used to be star on the team will not fit in naturally in supporting role, or don’t expect Many Ramirez to thrive at pinch hitting.

5.      Generalists vs. Specialists. On a related note, Agile encourages erasing functional demarcation lines, asking everyone on the team to be able to work on any part of code, to be able to test, and contribute to the user documentation. The reality is, not all of us are equally good at everything. Taken to extreme this normalization of expected contribution leads to mediocre results. Just imagine the User Interface developed by color-blind database architect and IEEE network engineer who have neither talent nor desire to be good at GUI design (and let’s not go to Manny Ramirez pitching skills).

 

 

More to follow...

How to become a Product Manager?

I occasionally run into people who aspire to become a Product Manager and I try to help them with advice. Here is what I tell them.

A Product Manager is someone who owns the product from start to end, from cradle to grave, someone who ensures the product is a success in terms of market acceptance and profitability for the company. Essentially a Product Manager is a spirited leader and a CEO of the product.

This is a very diverse, multi-faceted role dealing with a broad range of aspects such as project management, design, market research, pricing, finance, operations, branding, public relations, communications and more. The good news is you don't have to be an expert in all of these functions, not as long as you can join or help build a team that is collectively strong in these areas. A good Product Manager knows how to succeed with rich but scattered resources that can be found at a large corporation as well as with scarce early stage start-up resources.

So, you might ask, where do I begin?

You do need to bring something to the table. And one thing that cannot be compromised is your expertise in one or more competence areas, be that the technology, the market place or the relevant industry. I really do think to make a switch into this career and succeed you have to be an established subject matter expert or on track to become one.

In addition to being an expert, rest assured your prior background will contribute as well. You may be an engineer or a scientist which will help you quickly establish good rapport with your product development team. You may be transitioning from sales and marketing, possessing knowledge and skills sure to come in handy when devising the best positioning and go to market strategy for your product. Dear I say, anything you were good at in the past will help you in your new Product Management career. Even if all it ensures is your attitude toward being good at whatever you do.

In any case, understand your strengths and strive to rely on them as much as you can. And where you know you have weaknesses seek to partner with other people who can complement you.

Good luck!