Darryl.net

Edge cases are typically deprioritized by product managers - there is usually little gain for the amount of work necessary to meticulously handle every case. After all, that’s what customer service is for: to hold the hand of the customer through those dark times when software is not responding. Right?

To add lemon juice to the cut, engineers typically thrive on thinking of and handling every edge case - that’s what makes good code. The opportunity cost is usually too high though, and writing a giant try { } catch statement usually allows you to move on to the next big thing that will acquire users / make more money / look flashy.

However, what if those edge cases cause make your customers want to leave?

Here’s two stories of where I was taken to wit’s end:

Citibank
Today, I wanted to open a savings account to be held under a trust (you should make one if you have kids!), so I walked into a branch since I figured it would be *somewhat* complicated. The agent said I would have to open a checking account first, then apply for the linked savings account online since the high interest savings accounts all required online registration. I asked “Are you sure I can open it online if the account is in a trust?” “You should be able to,” was the answer. Good enough - I opened the checking account at the branch.

I got home tonight, and tried to open the savings account online. No dice, I couldn’t seem to select the trust credentials as the primary account holder. I called customer service: “Sorry, you can’t open a trust account online, you’ll have to open it in the branch.” “But the branch ones have super-high minimums I can’t meet,” I said. “Sorry, nothing we can do from here.”

So, even though I’ve been a Citibank customer for 10 years, I started browsing Vanguard’s site.

Money Management
Not too long ago, I purchased Quicken for the Mac after ditching my PC. [Hmmm - another money example. Perhaps I feel the pain most when it involves money.] I then tried to download my transactions from Citibank only to find that they don’t support Mac. Turns out, Intuit charges banks more for the Mac connector - which most banks don’t buy. I don’t know who to mad at, Intuit or Citibank.

Well, off I went to Mint, an online money management site where I had been collecting transactions for a few months already. Perhaps now was the time to switch. Unfortunately, I found that I could not enter arbitrary categories. I also couldn’t exclude items from Mint. Both of these ‘exceptions’ ended up making the categorization and charts pretty useless. Frustrated, I switched back to Quicken after taking a whole month to sign up for Direct Connect with Citibank. [Kudos to Mint: turns out Mint added these two features later - perhaps after they received lots of feedback.]

What to do?
After you launch a product:

• Watch your customer feedback carefully to find any repeated edge cases
• Have customer care keep a pareto chart of issues
• Fix them quickly. Customers you lose b/c of them will likely never come back.

I was driving to work this morning and talking on the phone. A pretty regular occurrence. Another pretty regular occurrence for me: Cingular’s network dropping my call. In my opinion, Sprint dropped my call far less than Cingular. So how can Cingular’s tag line be “fewest dropped calls”?

As a product person, I’d be pretty upset with marketing for choosing this stance. How can I reasonably assure that we can have the fewest dropped calls? How can we measure it? The connection depends on the phone, the environment, the age of the equipment, the weather… The minute you can’t live up to it - is the minute that ad campaign starts to backfire (and people like me and this guy start posting on their blogs).

Following on the previous post, I just gave a guest lecture at Haas on requirements gathering. Here’s the presentation on product requirements gathering. It’s lacking some of the necessary verbal context - mainly that there are so many standard processes around requirements gathering that people miss the basic premise…

You have an idea, you gather as much information as possible from as many stakeholders as possible, then you convey the idea to others.

Often, during requirements gathering (building giant “product requirements documents” or “feature lists”), you forget what it is you set out to do. Because of this, you don’t know what you’re explaining to other people - so your team is not sure what to build. Then you launch something that doesn’t really meet any of your stakeholders objectives.

I’ve learned this both the hard way and the good way: set a vision, keep it simple, and be ruthless in cutting out everything that doesn’t meet that vision.

Requirements Gathering is one of the more important skills of a good product manager. The sooner you can lose your ego and ask as many dumb questions as needed from as many different stakeholders as possible, the sooner you will see the complete picture of what it is you need to build. Or, better yet, the sooner you will find the elephant to hunt that will feed your village for years to come. To help drill this into your brain, I’ve republished John Godfrey Saxe’s version of The Blind Men and the Elephant here, for your reading pleasure:

It was six men of Indostan,
To learning much inclined,
Who went to see the Elephant
(Though all of them were blind),
That each by observation
Might satisfy his mind.

The First approach’d the Elephant,
And happening to fall
Against his broad and sturdy side,
At once began to bawl:
“God bless me! but the Elephant
Is very like a wall!”

The Second, feeling of the tusk,
Cried, -”Ho! what have we here
So very round and smooth and sharp?
To me ’tis mighty clear,
This wonder of an Elephant
Is very like a spear!”

The Third approach’d the animal,
And happening to take
The squirming trunk within his hands,
Thus boldly up and spake:
“I see,” -quoth he- “the Elephant
Is very like a snake!”

The Fourth reached out an eager hand,
And felt about the knee:
“What most this wondrous beast is like
Is mighty plain,” -quoth he,-
“‘Tis clear enough the Elephant
Is very like a tree!”

The Fifth, who chanced to touch the ear,
Said- “E’en the blindest man
Can tell what this resembles most;
Deny the fact who can,
This marvel of an Elephant
Is very like a fan!”

The Sixth no sooner had begun
About the beast to grope,
Then, seizing on the swinging tail
That fell within his scope,
“I see,” -quoth he,- “the Elephant
Is very like a rope!”

And so these men of Indostan
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were in the wrong!

MORAL,

So, oft in theologic wars
The disputants, I ween,
Rail on in utter ignorance
Of what each other mean;
And prate about an Elephant
Not one of them has seen!

Sometimes your customers don’t tell you exactly what they want, but if you read between the lines, they tell you what will make your product stand out. I always hear people say two things: 1) “Minivans are so uncool - I’m going to buy an SUV with a third row seat.” and 2) “Minivans are so convenient if you have a lot of kids and carseats - it’s just too hard to ignore - I have to buy a minivan.”

According to this WSJ Article, Toyota and other car manufacturers are successfully reading between the lines. Toyota’s 2008 Highlander has a middle seat that can be removed and stored under the center console (see picture). What do you get with this? Two kid carseats in the captain’s chairs and the ability for people to get in the back without having to do any fancy chair-lifting acrobatics.

Toyota’s press release says “On the outside, Highlander moves away from traditional SUV styling cues with a statement of strength instead of ruggedness; of intelligence over toughness. Calty Design Research in Newport Beach, Calif. sculpted clean, crisp lines, a wide, stable stance and muscular contours to give Highlander an advanced, contemporary, forceful and dynamic personality.” In other words, you get the minivan without the minivan image.

Brilliant. I predict a long waitlist for this car when it comes out later this year.

Bathroom

Originally uploaded by GotreK.

In the traditional waterfall approach of software development, people document unknowns. Specifications are written at the beginning of the process. The team attempts not only to lay out the features they want to build, but also to posit the most efficient manner of development. By doing so, the team draws on the past mistakes of its members. Next, the team guesses what mistakes they might encounter based on the features requested and attempts to prevent these mistakes. The PRD and TRD are complete.

Why not just rely on your team members to recognize these mistakes if they encounter them?

What do we gain if we skip the unwieldy specifications process and only document the mistakes we see along the way? First, if your team members do not recognize the mistake when they see it appearing, then they didn’t have enough experience to predict it in the first place. You save time by not thinking about what might never happen. Second, design errors are now clearly visible and can be discussed and addressed. Normally these mistakes go undocumented (except the bug report which is the symptom, not the cause). Finally, while your PRD may be useless to other teams in the company, a database of mistakes and solutions is pure gold.

Let’s consider one of the most basic ‘user needs’ as an example: “I need to go to the bathroom.”

When the first bathroom was designed, the Neanderthal architect did not say: “For version 3 of our bathroom, we will have large common rooms with privacy stalls. To prevent theft of the materials that compose these stalls, we should begin making screws now that cannot be unscrewed.”

Instead, it went something like this:
“I need to go to the bathroom, so I’ll dig a hole.”
Mistake: No privacy with hole outside. Build shack.
“Our workers should wash their hands, let’s attach a sink to the outhouse.”
Mistake: It’s freezing outside in the wintertime. Attach shack to shop.
“It smells in the shop now, let’s add a vent.”
Mistake: Flies come in vents. Use fan to make forced air vent.
“The fan sparked an unnoticed fire and burned the block down.”
Mistake: Bathrooms are seldom visited spaces. Install fire detectors and sprinklers.
“Bathrooms are boring. Let’s put up funny pictures.”
and so on…

These mistakes and solutions were recorded and now comprise a county’s “building standards.”

Now, imagine if you had this “database of mistakes” within your company:
Mistake: TCP does not work well for voice applications on our proprietary servers. Use UDP for voice applications.
Mistake: If you install company_widget_g and company_widget_f together, people can break in to the system. Have your application use one or the other, or make this modification to company_widget_f.

By doing a quick search for ‘company_widget_f’ when you are about to install it, you’ll avoid a few weekends at the office. By looking at another project’s PRD or TRD, you wouldn’t have discovered this bit of gold.

It is far more exciting to develop a new software product than to maintain an old one. A new product requires creative thinking, strong teamwork, and racing against a deadline. An old product requires bug fixing, late-night support calls, “scheduled downtime,” and saying goodbye to colleagues who are headed for the next cool thing. How should we accommodate the dull reality of maintenance mode? I discuss three options below.

1. Never enter a maintenance mode.
This is also affectionately known as “Always Be Shipping.” Essentially, your team ships early and maintains what is in production while simultaneously developing additional features. The team remains focused and motivated, fixes critical bugs when needed, and stays dedicated to the product. Unfortunately, this means no downtime for the developers or QA, little chance to step back and analyze performance and feedback, and a constant need to balance between product stability and feature development.

2. Hire a maintenance team.
Call a spade a spade. Maintenance is no fun, so hire someone else to do it. This gives a chance for lesser experience developers to come up to speed and potentially contribute to the product in the future (and keeps the “rock stars” focused on new bling). You could even go so far as to ship it half way around the world to Russia or India – though Bangalore (sorry, Bangaluru) doesn’t want your bugs anymore than you do. The main problem with this ‘outsource’ approach, however, is that the new engineers do not know the code and it is difficult to transition this knowledge. It will take much longer to stabilize the product and add management overhead.

3. Swap maintenance and development modes.
What if you could get around the problems of both #1 and #2 by taking a hybrid approach? If you are developing under “Agile” methodologies, why not split the team up into two groups – each with their own set of rock stars and newbies. Let’s call these two teams the “Red Team” and “Blue Team.”

In the lower row, the Blue Team has just finished a series of sprints developing new features. Now they move into maintenance mode on those new features for a few sprints. During that time, they also work with User Experience & Design (UED) to spec out new features that they will work on when they move back into development mode. In the upper row, the Blue Team moves back into development, and the Red Team moves into maintenance mode. UED now attaches to the Red Team.

There are many advantages to this approach:

• The team gets a breather during maintenance mode. Furthermore, they can concentrate on stabilizing what they just built, rather than writing new code.
• There is incentive to develop more robust code and to fix it quickly. The more solid the code, the more time the team can spend with UED during maintenance mode to think about the future.
• “Rock Stars” stick around because they are always either a) developing the new features, or b) thinking about new features.
• If there is a product manager for each team, this also gives time for the product manager to analyze performance of and feedback on the new features.
• The developers fixing the code know it intimately.
• You can bring new hires into the mix by having them join a maintenance team. Veterans can take time out to help the newbies fix and learn the codebase.
• You are still “always shipping.”

This might require a slightly larger team than initially planned. However, in the long run it could make up for the churn associated with major product launches.

Of course, this “Maintenance-Development Swapping” is just a theory of mine right now. I do intend to try it out in the future and will let you know how it goes. If you get a chance to try it out sooner, please comment on your experience.

Often overlooked, a good vision is an octane boost for your project.

A good vision:

• is a short and concise statement or illustration
• has soul and is from the heart
• inspires; makes an impression
• starts with one person
• can be explained in less than a minute
• is a stretch, but feasible
• can help eliminate all the distractions that do not get you to your end goal quickly
• is embraced

A bad vision:

• is a meaningless sentence comprised of cliches and buzz words
• is forgotten two hours later
• leaves people more confused after hearing it
• is written in a 2 hour meeting with 10 colleagues
• doesn’t align people
• is a project plan used in lieu of a vision
• is used in water cooler jokes

The time to create a good vision (at LEAST a few days of individual thought, followed by some fine-tuning with stakeholders) is well worth the investment.

A few books to help: Leading Change by John P. Kotter and The Leadership Challenge by Kouzes and Posner.

Public Radio International (PRI) recently aired a repeat episode of This American Life called “Fiasco!” There are four ‘acts’ in the episode, each chronicling a horrible confluence of events that leads to utter chaos. For some reason, I found myself remembering equally poignant software development experiences when listening to three of the four ‘acts.’

Act One: a dramatic production pushed to its limits.
The actors are good, but are striving for something beyond their capabilities; the set is overdone, but beautiful; the technology is new, but promising… Peter Pan is flung into a giant mushroom because the high-tech flying machines are too hard to operate. Captain Hook flings his hook-hand into an old lady in the first row. The audience goes from forgiving to cackling and hungry-for-destruction.

Ever had a similar experience with a high-performing software team? Probably - these teams are usually pushed to their limits and on the verge of collapse. When managed well, amazing results can occur. However, when stretched too far in all directions, any setbacks can ricochet throughout the organization and tear a team apart. Sometimes, people outside the team (the ‘audience’) might help the fiasco along in order to poach prized engineers.

Act Two: castle defense gone wrong.
An army leader defending a medieval village makes many promises based on sound testing. When the time came to defend the village, the cauldron of oil didn’t get hot enough due to unforeseen heating fuel issues. The attackers, having giving into to their weariness from beating on the gate, a re-enraged when lukewarm oil is poured on them.

Testing and forecasting is a best-guess effort. Often, when put to the real world, previously elusive special cases seem to sprout like weeds from the beautifully designed garden that is your final product. Then, these issues cause other problems, like failing to meet a marketing deadline. Then the marketing team gets pissed and doesn’t want to support you in the future.

Act Three: attempting to oust Car Talk.
A local radio station doesn’t want to pay for the popular car show that has destroyed all others. The producers decide they can roll their own. Not only does it flop, but it gains a few ardent followers that won’t let it die, forcing the radio station to continue to produce the show while also airing the victor.

When a competitive software product has won, why do we continue to fight against it with the same formula? The me-too approach doesn’t win - further, it backs you into the corner of maintenence. The only way to get around this is to flank the competitor with something materially different. Open Office is a FREE me-too office suite that can’t gain traction. Firefox embraced the security angle to gain a foothold, but is still having a hard time because it is just another browser (maybe Flock has a chance).

Act Four: a fiasco as a force of good.
I couldn’t think of an example where a software development fiasco turned out to be something good.

To avoid these fiascos, check out the following document forwarded to me by Tim Anderson, a PM friend of mine: Is Your Project Out of Control? found on Team Central. I found many of the situations and tips to be valid.

Good luck controlling the chaos.

It’s that time of year again - when product managers look out into the future and try to predict what their products will look like 3 years down the road. Usually you can get to within 50% of next year’s reality, and perhaps less than 10% for years 2 and 3. It’s a tough and fuzzy exercise, but is inevitably demanded by any large public company.

I recently gave a lecture at Haas on what roadmap planning is like for a product manager at a large company, and presented my Top 10 Tips & Tricks for Roadmap Planning. Since it is that time of year, I figured I should distribute it more widely and try to help my brothers (and sisters) out.

Best of luck in the process this year - and remember to give us something different than what we have grown accustomed to!