Darryl.net

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.

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!

Last week, we launched Yahoo! Photos v3 to the U.S. You can read the official press release, or check out the usual suspects. This is the culmination of over a year’s worth of effort - an entire re-write of the site from the ground up. Because we were able to start from scratch, you will notice many new features and “web 2.0″ concepts not found on other sites of this scale.

One of the most difficult questions that any product manager faces is ‘when do you launch the site?’ The old Photos site was launched in 2002 and was showing its age. While still the most visited photos site on the web*, it lacked some of the newer features of the competition. While we managed to add many new features, we could have added many more. Do you launch when all the feedback coming in from the beta is favorable? Or do you add the common enhancement reqeusts? Do you push to exterminate all the minor bugs, or do you live in eternal beta - always asking forgiveness from your customers for your experimentation?

Perhaps one of the tools that helped us most is user research - where we sit novice users in a lab and walk them through common tasks. Ealier versions of the site had some usability problems. For example, when users realized they could drag photos around, they started dragging them everywhere - even out of the browser. We started to notice common patterns, like dragging to an album on the left hand side navigation. Bit by bit, we fixed these common complaints until we no longer heard of them. Soon, the feedback changed to a more general ‘this is really cool.’ At that point, we made a branch, made it stable, and launched.

As a product manager, you are too close to the product to be able to make this call in a vacuum. Start walking your friends and relatives through the site. Do they get it? Do they like it? If not, keep going. If so, give it a bit more so the influencers digg it, then give it to the world.
* Many people point out that according to some sources, PhotoBucket receives more page views. However, you should understand how this site works: the user hosts their picture at PhotoBucket and posts it to MySpace. In the end, PhotoBucket receives credit for people viewing hosted pictures on MySpace, even if the visitor to MySpace never notices where that picture lives. These are ‘empty page views’ and distort the reach of the site as seen by the press. It works though - so if you’re a startup, do it.

You know what’s good for your business. But you don’t know what’s possible with your product. Sure, you have an engineering background, and you know generally how things work, but let’s be honest - you don’t know the half of what is the plumbing behind your product. This is why you have to tell the team how the business should work, not just what the product should be.

Many product managers usually concentrate on one or the other - the product, or the business. It depends on the PM’s background, their role within the organization, what they are comfortable with, etc. The product is more fun. The business is what feeds the family. One cannot survive without the other. Therefore, you must further both in tandem.

One easy way to do this (if you know the business behind your product) is to tell the team about the business. How do you make money? What are your costs? If people are logged in to your website, is your advertising more targeted? If you drive 30% more page views, will you see 30% more revenue? Or will you see 60% more revenue and 100% more in costs? If people open your application just 1 more day out of the month, do you gain any benefit? What are all the levers that are important to feeding the family?

Tell your team about these levers and dials and they will start to push and turn them in ways you never imagined. Even better - set up a program that rewards them in proportion to the amount of money they gain or save for you.

As a product manager, you are often the gateway between expectation and reality. The powers that be who circle above hear great things and expect the world. Your team knows what is and is not possible, and often, what is best for the user. But the two groups do not talk to each other - except through you.

Since you spend most of your time with the team making sure you ship, they might find it a bit strange if you start emailing them every day with the team’s latest status. So don’t. Now, the powers that be circling above might also find it a bit strange, but… once you realize that you are at the top of their mind and that they know exactly where the product is and what you need to be successful, you’ll be spamming them on a regular basis.

Ok, so maybe not every day, but at least once a week. Use some majordomo program or an Outlook group. Just get them the goods, be honest, SHOUT when good things happen… and savor the well-deserved attention.

It’s time to step up the editorial quality of the postings on my site. So far I’ve been posting about launches - and there have been many in the photospace as of late - but it’s time to dig a little more into the meaning of each launch.

A few days ago, Flock finally put up a public beta of the branch of the Firefox code they have been working on for some time now. I’ve heard some outcry that Flock is doing a bad thing by taking our beloved Firefox in a different direction and - God forbid - making a commercial venture out of it. Why not contribute back to the Firefox tree? Why ‘pirate’ the hard work of thousands of dedicated developers to line the pockets of a few?

This is capitalism at work. The market had a hole in it: people have been using the same ho-hum browsing experience for a decade now, and as websites and services have advanced, the browser has done nothing (besides add the Javascript, clean up the memory leaks, accept plug-ins, etc etc - which is a lot) to integrate the experience with the rich functionality of the desktop. In fact, the goal has been to isolate it from the desktop for security reasons.

In comes Flock and says “hey, we can make a better broswer that blurs the lines between desktop and web, and, by George, we’ll get paid by the search engines if people come our way.” So, the ever-present drive for innovation (and IPOs) has given us what is, in my opinion, a great new browser.

I met w/ Bart, one of the founders of Flock, last week and he took me through the experience of sharing Photos with my friends. The ease with which he could upload photos, blog photos, or view new photos from his friends was astonishing. A perfect blend of the desktop and web. I predict many downloads for Flock this summer. If this happens, the people will have voted.

The same debate ensued when Apple made OS X out of the Berkeley Systems port of UNIX. Most people on both sides of the debate probably own a Mac by now - OS X is, after all, the most widely-sold UNIX-based operating system.

With newer digital cameras shooting high-quality video, many users are looking for services and sites that solve the pain that is video manipulation.

A friend of mine who “transforms home video into memories” just launched her website, Time Capsule Films. She can make your graduation, baby, or wedding video into a valuable keepsake, rather than a long, boring video that gathers dust on your shelf.

Some photo sites, like One True Media and Snapfish, have taken on the problem, correctly assuming that consumers won’t venture too far away from what they are already used to when sharing pics from their digital camera. 

Expect online video sharing to become as commonplace as online photo sharing in the coming years.  If you’re not convinced, check out You Tube.