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.

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!

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.