I had a funny discussion about roadmaps recently.

Me: If you can't hit your dates, then you shouldn't distribute roadmaps.
Client: But we must distribute a roadmap to sales people.
M: And what happens when you do?
C: They give it to clients.
M: And what happens?
C: They attach the roadmap to a contract.
M: How's that working for you?
C: Well, we usually miss our dates.
M: If you can't hit your dates, then you shouldn't distribute roadmaps.
C: But we must distribute a roadmap to sales people.
M: And what happens when you do?...

In Don’t Build a Stupid Product Roadmap!, Scott Sehlhorst at Tyner Blain writes,

A product roadmap is the product manager’s equivalent of a project manager’s rolling wave planning. In a sound-bite, you provide short-term details (for the next release), and long term “broad brush” discussions. If you don’t plan your product to address the needs of a particular market, and then execute against that plan, the only way you will succeed is by luck.

That's it. A roadmap is a plan, not a commitment. It says, "here are our current plans. Our objectives may change and we'll change our roadmap accordingly."

As they say, If you don't know where you're going, how will you get there?

In our Roadmapping seminar, we provide five different tools for articulating product strategy. The roadmap is evidence that you actually do have a strategy. The roadmap is the tool of choice for communicating with executives, sales people, and clients. And in fact, seeing your product roadmap is often a legitimate request from your clients and your sales people.

However, and I've ranted about this before, things don't change nearly as quickly as everyone thinks. That is, market problems exist for years and years. It's your awareness of those problems that changes day-to-day. I'd prefer that your long-term roadmap focus on industry problems and persona goals. In talking with a client about product capabilities, this client's feature request becomes critical. Talking to another client results in another critical feature request. As you talk about features, you discover the delta between the problem and your current solution. But if product managers actually interviewed the clients instead of just reacting to sales demands, we would see these problems years in the future.

You don't hear problems with your mouth. You need to create an environment where you can hear problems... with your ears open and your mouth closed. Better yet, see the problems by observing your ideal persona in a working experience.

You can observe a lot by watching.--Yogi Berra

We have a new puppy in the house. Her name is Bailey. I’ve gotten a few books on dog training and they all talk about thinking of things in the context of how the dog sees it. We must think and act the way the dog would in nature. Sounds a lot like personas, doesn’t it? Our marketing and development and sales should be about communicating clearly with the personas. Problem is, I don’t know very much about dogs in nature. I’ve never actually seen a mom with her litter of pups—or a wolf with pups for that matter. I guess I’ll have to start watching the shows on The Discovery Channel.

So if you’re a product manager, you need to understand your audience and the domain. How are you doing this? You should be visiting clients frequently to update your domain knowledge.

The training books also make the point that dogs have clear roles. In this case dogs are pack animals who follow an alpha dog. Uh-oh, I don’t know much but I’m pretty sure that I need to establish myself as the alpha dog. And I don’t really know how to do that either so I’m just being harsh. Is that the same?

Raising a puppy has me thinking about roles in development, particularly agile. In my experience, developers want clarity in roles and clear processes. Developers definitely want to hear the voice of the customer before they start building things. Unfortunately the product manager, who hasn’t established credibility yet, is trying to become the alpha dog by being harsh: trying to control the schedule and the specs and the prototypes. Regardless of your development method, the product manager should be the person who illuminates the market to the development team. In Scrum, your role is referred to as the Product Owner, not the Scrum Lord.

I'll be talking about product management's role in an agile environment in August; click here to sign up for the free webinar.

I believe that the Agile Manifesto is a response to bad management, particularly bad product management. Any of the agile approaches to development are focused on delivering products that work. And the key to delivering products that customers want to buy is for product management to understand the market better than anyone else.

The problem with “quick and dirty” is that dirty remains long after quick has been forgotten.--Steve McConnell

Reginald Braithwaite posted this to the Toronto PMA:

Try this experiment: go to an engineer, and say "I don't care, your
career is not on the line, it is more important that we have a
quality product and happy customers. Now: are we ready to ship? If
not, when do you think we will actually be ready?"

Now go to another engineer. Tell her that vacations and weekends are
cancelled until we ship. Tell her that hitting our ship date is the
only thing that matters, slipping dates is for losers. Explain that
we have made commitments in the press and that the President will be
embarrassed and angry is we miss our date. Now, ask her if we are
ready to ship.

Is quality a variable? As Reginald points out, quality is the variable when dates and features are fixed... and careers in jeopardy. Timeboxing is the only solution that I know of that consistently gets good results.

Time is so much less important than we generally believe; urgency is typically in the minds of the vendor rather than the market. So remember, you never get a second chance to make a first impression. Ship less or ship late but don't ship poor.

My mind seems to work in a funny way. A program’s quirk got me thinking about precision.

I tend to be overly organized. I use lots of folders to categorize: office, photos, movies, product management, presentations, humor, and so on. For a while I tried cross posting if you will, putting aliases or shortcuts in one folder pointing to the actual document in another. I think it is rather natural to try to categorize items. I know I should just throw everything in My Documents without any organization and let Google find them for me but I don’t. And invariably I end up with the same document stored in multiple places. I found a great tool for searching for duplicate files: zsDuplicateHunter, available for Macintosh, Windows, and Linux. I’m sure there are others but this is the one that I use. It’s amazing to me how often it finds duplicate files even when I think my computer is clean.

But here’s my point (finally). The program uses unnecessary precision. It tells me that the search has 47.6 seconds remaining. Why is the .6 relevant? For that matter, is 47 seconds relevant or even true? Isn’t “less than a minute” more accurate?

I learned about precision back in public school. 1 divided by 2 is 0.5. Period. In this instance, more decimals are not more accurate. Telling me 0.5000000000000 is both irrelevant and harmful, as it implies a level of precision that is not supported by the data.

I see this error of precision in estimating dates for roadmaps and requirements. A developer guesses a man-week of work, which someone translates to five days, and someone else translates to 40 hours. It shows up on a Gantt chart as 40.0 hours. But a week could be two days if the developer gets in the zone and doesn’t encounter any surprises, or it could be a month if the developer gets pulled into a dozen other problems.

I fear that we have an unrealistic expectation of precision from our project schedules. Compare the precision of development estimates to sales estimates. How precise are the numbers in your sales forecasts? What accounts will you close on what date for what revenue amount? No sales person could provide that information. Yet we somehow expect exactly that from the development schedule.

An old estimating joke is this: take the estimate, add one, and change the unit of measure. One week becomes two months; one month becomes two quarters.

A guess is a guess. Let's not attribute precision where none exists. If we track our history of guesses, we can assign a factor of accuracy. Take a look at estimates of the past to see how accurate they were and use this against your future planning. Don’t infer precision without the data to support it.

My car turns on the lights when I start the engine and turns them off when I turn the engine off. Shouldn't all cars do that? I'm shocked when I rent a car and learn they still make cars that leave the lights on when the key isn't in the ignition. Sure, it's not hard to turn off the lights. If you remember. If you don't, you'll come back to a dead battery. And somewhere in Detroit an engineer is saying "but what if someone wants to leave their lights on all the time?" How often, really, does that happen? Who is this 'someone' that you're referring to?

Computing is rather the same. Windows is great because you can configure it exactly the way you want. You can change every setting. And that's also its weakness. Maintaining a desktop computer isn't really that hard. But somehow my dad manages to move his toolbars from the top to the bottom of the screen. My brother gets a new computer and has no idea what his email settings are. And it's not really the desktop software and OS as much as the settings and the data. Happily, Joel Spolsky has simplified my tech support life with CoPilot. It allows me to connect to my family's computers and fix almost anything without going over there.

I find that I'm now recommending gmail as everyone's primary email client; for me, it's better than Outlook, it can find messages faster, and it creates contacts automatically. And my family members need only to remember their logon info. Everything else is on the server.

Perhaps this is why ARNnet reports that the Software as a Service model is becoming the dominant revenue model for software companies. In some ways, we're returning to the bad ole days of the mainframe; SaaS turns our PCs into clients and puts all the important stuff on the server. The vendor can focus on managing the tools so its customers can focus on using the tools. Sounds like a win-win.

In a time when people are advocating simplicity, mobile phones are becoming pocket computers. A year ago, Seth Godin wrote, “I think we're going to discover a whole new universe of cell phone services that people want to pay for, things that we won't be able to live without. Like ringtones....”

And I’m fairly sure that I want to buy the new Apple phone as soon as it becomes available. I don’t care about ringtones but I very much care about elegant design and ease-of-use. But that’s me. There are a great many people who want a mobile phone to just be a phone. You know... a good phone.

This week I stumbled across the Jitterbug phone. They offer two phones: one with 10 numbers and Yes and No buttons and the other with only three buttons: Emergency, a number that you choose, and Operator for everything else. Have a question? Just call the operator.

As vendors, we always have a customer who wants one more feature or a developer with a great idea or a sales person who can close a custom deal. And so, our products get more features, and more, and MORE! But the more we add, the more our customers complain that the product is hard to use.

Which of the following phone features do you frequently use?

• ring tones
  
• syncing contact with your computer
  
• calendar
  
• camera
  
• screen saver
  
• any of the side buttons
  
• Google mail
  
• shopping
  
• web surfing
  
• messaging via SMS or IM
  
• games
  
• conference calling
  
• wireless headset (ie Bluetooth)
  
• calculator
  
• alarm clock
  
• voice recording
  
• voice dialing
  

Or put differently, which of these would you actually miss if they were removed? By the same token, how many features in your product are used by fewer than 20% of your clients? Would those 20% really miss the features if they were gone? And would the 80% benefit from their absence?

It seems no amount of process can overcome dysfunction. Perhaps the biggest challenge of developing tech products is respect among the team members. Or as we say in Requirements That Work, "friends build products."

Joel St-Denis writes in the Agile vs Waterfall debate: It was interesting to see that 2 of the companies in question had success in moving from a Waterfall to Agile methodology and both Product Management and Development had made the transition with success. On the other hand, 2 of the other companies had found challenges, and continued to struggle with the shorter sprints, or scrum approach, to Agile. The consensus seemed to be that there was a lack of respect between the PM and Dev groups in the companies which had issues, and this led to both departments pointing the finger at one another for delivery failures.

We commented on the role of product management in agile environments in Extreme Product Management with more specifics in how to deliver products people want to buy in an agile development environment.

Regardless of the development methodology, product managers should serve as conduits of market information. Too often we're attempting to control product development through rigorous requirements and a comprehensive Gantt chart. Instead we should influence with market information in the form of stories and personas.

Bob looks at requirements: different types of goodness:"As I consider a raft of requirements from both inside and outside the organization, I'm struck by the motivations behind them. Some features are suggested because 'they'll make money'. Others because 'they complete the product'. Still others 'are really, really important to customer x'. Competitors dictate some, preferences of developers others, and executives still others. The list of sources is as long as my arm, which truth be told, is rather on the longish side."

An old Danish proverb states: He who builds to every man's advice will have a crooked house. As Bob points out, choice involves focus--focus on a segment, focus on a persona, focus on a set of problems for a persona in a segment.

The more we listen to everyone, the less we actually seem to accomplish for anyone. The question for your next MRD is what type of customer do we want to delight?--and who are we not going to focus on, at least not this time?

When everything is a priority, nothing has priority. But, according to Sage Software product manager Dave Jones, a modified version of a technique developed more than 20 years ago by Japanese engineer Noriaki Kano can quickly and easily help you sort through long lists of customer requirements and prospective enhancements to help you decide which features really need to be first in line. Read more in Setting priorities at the Product Strategy Network.

Return on investment calculation is critical to using ROI for prioritizing requirements. Tyner Blain offers five tips to help you when calculating return on investment. Also check out the links to how to forecast return on investment by estimating costs and predicting benefits.

The use scenario may be the most important artifact of the requirements document. They go by many names depending on your company's nomenclature: goals, tasks, usage cases, whatever. The use scenario provides the details of the question "what is the customer attempting to accomplish?" Or said another way "Explain the entire experience from beginning to end."

I have a personal blog--updated information about what's happening with me, my family, and especially my son's band The Alternate Routes. I use the blog to update my extended family and friends without having to send emails to all of them. I frequently want to post a picture in the blog, which shouldn't be hard but actually is. Here's what I used to do: resize and copy the desired picture to a shared folder on my Mac that was synchronized with my .Mac account on the web; then I would link to the picture in my public folder which actually involved using an undocumented URL. It was convoluted but easy enough once I figured out how to do it. I later found that I could accomplish the same thing a little more easily via Flickr but it was still rather convoluted. Nowadays I add the picture to my photo program, which can export to Google's PicasaWeb. Then I click on Embed and PicasaWeb generates the HTML necessary to incorporate the photo into a blog post. Photo resizing, transfer to web, and code-links are all easily done in three steps. If I managed the blog with iWeb (which I don't for other reasons), it's even simpler: drag and drop the picture onto a placeholder. That's it.

What I've been describing are all of the individual tasks necessary to achieve my goal: I want to include a photo in a blog post. Use scenarios explain "Steve wants to have a photo in his blog post." Or perhaps "Steve has taken a dozen pictures of the winter storm. He wants to put one of those pictures on his blog with a link to the collection of pictures."

Instead of saying "the user might want to do" this or that, a use scenario is a specific, illustrative situation. And thus, keeps us from the edge cases of the implausible and from the vagueness of non-specific.

The American Cancer Society defined their use scenarios extremely well; they followed the transaction from the beginning to the end. My office made a donation recently in memory of a family member. The American Cancer Society sent me a notification in the mail and included a ready-to-use Thank You card with a return envelope. Beautiful. Think this through. After a funeral, the bereaved family gets dozens, perhaps hundreds, of memorial gifts. As with a wedding, etiquette requires that you acknowledge the gift. But while a wedding is a period of great anticipated joy, a death usually is not anticipated and certainly not joyful. While the wedding bride may not be completely thrilled with writing hundreds of thank-you notes, a bereaved family after a funeral must dread it. The American Cancer Society has made it simpler to pen a short note and get it in the mail without all the drudgery of addressing the envelope. They looked at the gift from the standpoint of the 'customer' and the customer's usage. After the giver or 'buyer' transaction was complete, they also helped the receiver or 'user' with their part of the transaction.

We get so caught up with tasks that we miss the goal; we get some involved with buyers that we often forget the user. What is your customer trying to accomplish? Write some use scenarios from their point of view and from beginning to end, and you'll be delighted with the outcome.