Darryl.net

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!

Ok, so I haven’t posted here in some time. Here’s what we’ve been working on that’s kept me so busy these last few months: http://web.im/ – or, officially, http://webmessenger.yahoo.com/ (or, Yahoo! Messenger for the Web).

“It’s like travel size toiletries with everything that you love about the Yahoo messenger application in a lighter size.” Ok, so that’s a fun quote – but it is actually designed not to have everything – only what you need while you are away from your prized personal PC.

In fact, one interesting thing I [re]learned is that people only really need about 1/10th of what is normally shipped with any given product. The first thing we did when we started was to decide what it would not have. It would not allow you to set your image, change your stealth settings, pull up your web cam, share photos, transfer files, load plug-ins, change themes, etc. etc. You have an installable client that can do that. It would solve one user case: I cannot or do not want to install the client (perhaps I’m on the road, or at work, or in a cafe). By keeping scope limited, we were able to build it from the ground up in just a few months (thanks, in part, to our crack team – and, in the other part, to Adobe’s cool new tools).

Find out more about Yahoo! Messenger for the Web, and make sure to watch the embarassing video that I narrated. Here’s some of the early press: TechCrunch, Reuters, CNET, and this glowing blogger.

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.

After seeing all the trackbacks on the recent TechCrunch Apple iPhone post, I wondered if you could use the number of trackbacks as a measure of story importance. Are sophisticated blog readers essentially ‘voting’ for the events that will define the tech industry?

In The Wisdom of Crowds, James Surowiecki posits that ‘the crowd knows’ better than any individual expert. Especially if three conditions are met: Diversity, Independence, and Decentralization. On TechCrunch, readers work in different capacities for a diverse set of companies – but they’re probably all working in the tech industry. Most bloggers are making a relatively independent decision to write a post and link it to TechCrunch, and there’s no overarching authority over bloggers. Whether or not TechCrunch’s audience meets James’s requirements can be debated, but there’s some chance we can trust this data. Or is there? Let’s see the results:
I wrote a script to get the top 20 stories in terms of trackbacks since the dawn of TechCrunch time until around the Apple iPhone post:

1. Exclusive Screenshots: Google Calendar (365 trackbacks)
2. AOL Proudly Releases Massive Amounts of Private Data (246 trackbacks)
3. Google Has Acquired YouTube (202 trackbacks)
4. Completely Unsubstantiated Google/YouTube Rumor (186 trackbacks)
5. The State of Online Feed Readers (185 trackbacks)
6. The Online Storage Gang (143 trackbacks)
7. Web 2.0: The 24 Minute Documentary (135 trackbacks)
8. PayPerPost.com offers to sell your soul (128 trackbacks)
9. Comparing The Flickrs of Video (97 trackbacks)
10. Google Calendar is Live (95 trackbacks)
11. Digg Does The Acquisition Dance With News Corp. (93 trackbacks)
12. Digg 3.0 To Launch Monday: Exclusive Screenshots and Stats (91 trackbacks)
13. AOL-Netscape Launches Massive “Digg Killer” (90 trackbacks)
14. Yahoo.icio.us? – Yahoo Acquires Del.icio.us (84 trackbacks)
15. Companies I’d like to Profile (but don’t exist) (83 trackbacks)
16. Amazon: Grid Storage Web Service Launches (82 trackbacks)
17. Bill Gates On The Future Of DRM (80 trackbacks)
18. AllPeers Is The FireFox “Killer App” (79 trackbacks)
19. Comparing the Mapping Services (72 trackbacks)
20. Facebook Users Revolt, Facebook Replies (71 trackbacks)

I’ve bolded the ones that I think deserve attention, but I wouldn’t say this creates a perfect list. First of all, I can’t see how Google Calendar would beat out AOL opening its doors or Google buying YouTube – unless maybe, just maybe, people are desperate for a worldwide MS-Exchange-like system and we thought this would be the end-all be-all. More likely, there are many prolific bloggers working at Google who read TechCrunch. Second, the prominence of “The State of Online Feed Readers” and Digg articles leads me to believe that the people ‘voting’ with these trackbacks are not very diverse. Finally, AllPeers?

Nevertheless, we do see some of the bigger tech stories of 2006 represented here: the YouTube acquisition; Digg, Del.icio.us, and ‘web democracy;’ AOL opening its walled garden, and the immaturity of DRM. It would be interesting to run this script on some other blogs and see what happens… perhaps on another rainy day.

This is one of the strangest products I have seen in a long time:

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.

Even though I work for Yahoo!, I have to take a moment to applaud the Google Mobile Maps team. After reading ‘Freeing Google From the Desktop‘ in the WSJ the other day on the bus, I decided to check out the Google mobile site on my WAP phone, even after Walt warned me that it wasn’t the right URL for my phone.

Here’s a summary of the wins:

1. Went to the regular mobile site on my phone and there was a link that read ‘On a mobile device?’ Brilliant, because this link appears at the top of a page on a WAP browser, allowing me to click on it without waiting for the rest of the page.
2. Clicked on it, and Google recognized my Treo and suggested compatible apps.
3. Downloaded maps quickly and easily installed it on my Treo.
4. Opened maps, and saw San Francisco (now, does everyone see this, or do they know where I live?).
5. Easy scrolling with my stylus. Relatively fast download of the map data with feedback to let me know how long I might have to wait.
6. Instant feedback on the zoom (a box shows where you’ll be looking and gives you a chance to adjust further before downloading).
7. All the features I want without adding any additional fluff I don’t want: Find location, Find nearby businesses, Directions, Satellite View, and Traffic. (OK, I have one request: traffic incidents. The red lines are a good indicator, but 101N always has traffic. An incident is even a better indicator that 280N might be a better choice.)
8. The directions feature is beautiful: From, To, and then hit the spacebar for each successive instruction.

I’ve been told the Treo version is the nicest of the bunch, so maybe I’m a little spoiled. Kudos to Steve and the Google Mobile Maps team – an impressive product.

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.