The best requirements prioritization scheme EVAR.

I thought I had seen every possible permutation on the problem of how to prioritize requirements. Then the engineers at my company came up with a new one: the pony priority.

Is “pony” an acronym? Nope.

It’s the lowest priority there is. It’s the “I want a pony! No, you can’t have a pony” priority. Or as the classic image has it:

pony

This priority is properly reserved for requirements that would be, like, REALLY KEWL but that won’t ever be implemented. Because they’re unsolved research problems, or because they would cost more than the whole company is worth.

This is a seriously useful concept. It provides a way to say, “I recognize the value of the idea, but we can’t do it no matter how much you try.”

Do use it in your own company and let us know it works out.

Roadmaps in Agile, part 1

As a product manager in an agile development model, one of the most difficult things to do is building a roadmap. This is because making feature commitments for six to nine months out feels contrary to the spirit of being “agile” and maintaining flexibility to change course to support the needs of the business.

Why is having a roadmap when you’re agile so hard? One word: sales. It’s relatively easy (provided you know how to do it) to move requirements around when the only people you’re communicating with are internal stakeholders. It’s much harder when a sales guy has already told the Big Prospect that the frimfram feature is going to be added in third quarter, based on a roadmap that he saw six months ago. Sales cycles have their own momentum, they have their own set of unforeseen requirements that weren’t planned for, and they’re very hard to sync up with a roadmap that’s moving to respond to current and future needs of the company and customers.

So how do you do it? There are three important dimensions to any roadmap, and those are priorities, cost/benefit, and time. Getting the first two properly defined is critically important; once you have that, distributing the roadmap across time is more of a mechanical exercise (but not without its hazards). First, though you have to know:

What do we need to do? If you’re a product manager who documents every requirement you ever unearth from a customer, prospect, sales guy, internal operations perspective, or executive, stores it in a backlog, and periodically revisits the backlog to organize and categorize it, this step might actually be relatively easy. If not, it will require some legwork–talk with each stakeholder, make sure customer voices are represented through input from the sales force (and/or SalesForce), write everything down, send the list around and make sure that nothing got missed.

What do we do first? Prioritization has to be done as a conversation; there’s no way around it. You can do prioritization in a vacuum if you’re using a static set of priorities (high, medium, low, for example), but if you’re stack ranking your requirements (which I firmly believe is the best way to go) you need the appropriate stakeholders to get together and make the tradeoffs. To do a good job in stack ranking, it helps to set some ground rules (e.g. the requirement contributes to current revenue, builds groundwork for future revenue, or reduces operational costs) and set some rules about how those translate into ranks (e.g. current revenue more important than future revenue). There are some finer dimensions to the problem; generally there are different types of requirements and different types of people who will work on them, so if you slice the prioritized list by those dimensions do the priorities still make sense? (They should.)

What’s the cost and benefit? Ideally this should be done before prioritization, since it informs it, particularly the benefit part. If you have a major initiative that’s supposed to drive new business, someone should be able to estimate how much new  business it will drive. Engineering requirements can be estimated by cost. Combining the two can help to drive prioritization. It’s important to know the details of the business model behind the requirement, too. If the revenue plan for the requirement assumes that it will help to drive revenue for two quarters, it had better be released by the middle of the year.

When do we do what? Here’s where the rubber hits the road. Up until this point, it’s better to deal with requirements as high level objects–epics of work that can span multiple teams and releases. But to actually assign features to releases, you need to be able to at least guess at a high level division of work (we’ll work on this for three release cycles before it becomes available to the public) and of responsibility (both teams A and C contribute, so we need to put something in both team’s work plans).

The reason that time based planning is trickier, too, is that it needs to make explicit assumptions about certainty. You can do a pretty concrete plan for releases early in the calendar year, because you know that the business requirements won’t change too much between planning time and the release date. But the back half of the year is far trickier. So each release during the year needs an increasing “change reserve,” unallocated capacity that can take on new requirements. Alternatively, management has to be comfortable with the proposition that the out quarters will be highly subject to change.

Once you’ve done the basic blocking and tackling, the real fun begins: how do you communicate this nuanced plan in a consumable format to management and sales? Well, that’s part 2.

Google Chrome 1.0 (.154.36)

Well, that was fast. Google Chrome went from new to 1.0 in about 100 days:

chrome1dot0

But is it ready? And why so soon?

chromepngbug

I expected Google to add more features over time, since the merely architectural improvements of the browser didn’t seem to meet the critical differentiator threshold to justify launching a new browser. But that didn’t really happen. And in fact, Google seems to be launching Chrome with some rough edges intact. Check out this snippet of the WordPress 2.7 login screen (right).See those black edges around the box? That’s a rendering bug in Chrome’s version of WebKit. (The black corners aren’t there in Safari.)

So: Google is rushing a new browser that they “accidentally” leaked just 100 days ago, a browser that has significant speed but demonstrable rendering flaws, into an already crowded market. Why? And why launch two days after previewing the Google Native Code plug-in, a web technology that seems a far more significant leap forward?

My guess: they’re scared of having their thunder stolen, maybe by Firefox. The new Mozilla JavaScript engine, TraceMonkey, appears to be running neck-and-neck with Google’s V8. And when the major feature in your browser is speed, you don’t want to risk being merely as good as your better established competitor. So maybe releasing Chrome ahead of Firefox 3.1 (which still has no release date, and at least one more beta to go) was simply a defensive move to make sure they aren’t competitively dead before they launch.

Release planning: How you prioritize matters

I hope I have the time to come back to this thought tomorrow (along with some overdue Thanksgiving blogging). But I had the opportunity to meet up with an old colleague for lunch today and to discuss, among other things, two different agile project cycles. One project cycle ships every four to five months, has seven or eight two-week iterations inside the release cycle, and uses MoSCoW-style prioritization (that is, Must, Should, Could, Won’t) for feature stories and for backlog. The other ships every six weeks, has one iteration inside the release cycle, and uses forced stack ranking for feature stories and backlog.

Which of the differences (iterations per release, release length, prioritization) is most important between the two projects? Which has the greatest impact on the release?

I’m going to give away the answer when I say I think there’s a stack rank of impact:

  1. Prioritization method
  2. Release length
  3. Iteration frequency

Why is prioritization so important? And which method is better, forced stack ranking or must, should, could, won’t?

The problem with any bounded priority system, whether it’s MoSCoW, Very High/High/Medium/Low, or simply 1, 2, 3, 4, is that it leads to “priority inflation.” When I was selling ITIL compatible software, we had a feature in our system that used a two factor method and customizable business logic to set priority for customer IT incidents. It was necessary to go to that length because, left to their own devices, customers push everything inexorably to the highest priority. Why? Because they learn, over time, that that’s all that ever gets fixed.

It’s true in software development too. I can’t count the number of features that were ranked as “must haves” on the project that used MoSCoW. It was very difficult to defend phasing the work, because everything was a must.

The project that uses forced stack ranking doesn’t have the problem of too many “must haves” because there can be only one #1 priority, and only one #2, and so on. Developers can work down the list of priorities through a release. If there’s been an error in estimation and the team has overcommitted for the release, it’s the lower priority items that slip.

The forced stack ranking works with stakeholders outside engineering too, because it forces them to evaluate requirements against each other in a systematic way. Rather than saying “everything is a must,” stakeholders can give answers about whether requirement A or B is more important within the scope of the release.

Release length and iteration frequency matter, too, because they provide mechanisms for market-driven and internal-driven course correction. But from my experience, as long as the release length and iteration frequency aren’t too far out of whack, the right prioritization method is a crucial ingredient for successful delivery of software that meets stakeholder expectations and for defining feature lists that have a reasonable shot of getting completed within a single release.

Taglocity 2 – Migration frustration

I installed version 2 of Taglocity on Friday. As I wrote a while ago, the older version of Taglocity has saved my bacon many times, and I was excited about the new features. I still am, but I’m a little more cautious about the new version today.

Why? Migration.

I installed the new version in the morning and was astonished when I went to tag the first message: my tags were gone. More precisely, there were no auto-filling tags happening at all. I went back to the Taglocity welcome screen, and somehow found an option to import existing categories as tags. Which turned all my tags into [tags], because the old version of Taglocity entered the tag values into Outlook categories with brackets around them. Grr.

I checked the website and there was no online migration guidance for users of 1.1 Grr. So I fired off an email to Taglocity support to ask what I was missing. I waited an hour (while I was in a meeting) and didn’t get a response. Grrrrrr.

So I started manually fixing the old tags. What a pain. I got partway through and threw in the towel for the day. When I got in on Monday, there was an email from Taglocity support telling me that there was an option to convert the tags to version 2:

All you have to do is ‘Import V1 tags’ and then convert them into version 2.

You can access these tools by clicking on the ‘Taglocity’ main menu and then clicking on ‘Configuration’ -> ‘Tools& Support’.

Which I’m doing now.

So, Taglocity, here’s what you could have done differently:

  1. Put the migration option front and center in your welcome screen–or detect that I already had Taglocity installed, and offered to migrate everything for me.
  2. Failing that, put the migration how-to on your web site. A no-brainer, really.
  3. Put an auto-responder on your support email to let me know you got my message and set my expectations about wait times. I hate them too, but they’re better than waiting six hours to find out if my email went through.
  4. Pat Vanessa in support on the back, because her answer was spot on.

Ok. Other than the migration issues, I like a few things about the update. The UI is cleaner, I love that I don’t have to use a tag cloud to filter by tags. I’m not super thrilled about the additional sidebar, mostly because I had Xobni installed, and it doesn’t seem to give me anything Xobni doesn’t. On the other hand, the stuff that Xobni gives me that Taglocity doesn’t is stuff I don’t use very much anyway–except for the phone number. If Taglocity added options to get me to the tags I use most often in conversation with people, that would be great, and I might start hiding Xobni’s sidebar instead of the other way around.

Apple: MobileMe isn’t really using “push” with your PC

MobileMe (aka former .Mac) subscribers received an overdue email from the MobileMe team today, apologizing for the rocky roll-out of the new service and extending a free month of service to all subscribers.

The email contained the following interesting paragraph:

Another snag we have run into is our use of the word “push” in describing everything under the MobileMe umbrella. While all email, contact or calendar changes on the iPhone and the web apps are immediately synced to and from the MobileMe “cloud,” changes made on a PC or Mac take up to 15 minutes to sync with the cloud and your other devices. So even though things are indeed instantly pushed to and from your iPhone and the web apps today, we are going to stop using the word “push” until it is near-instant on PCs and Macs, too.

What a welcome breath of fresh air: unambiguous retraction of unjustified marketing hype!

As a product manager, it strikes me that the team managing the rollout did an excellent job of damage control: fix the operational problems, apologize to the customers, change the marketing message where it’s out of line with the new reality, extend credit and move on. And they’ve done a good job. I even have to retract my characterization of MobileMe as the Lindsey Lohan of webmail services (last paragraph).

What does “beta” mean for Software as a Service?

Steve Johnson at Pragmatic Marketing points to an interesting article on five different types of betas. One of Steve’s commenters suggests there is a sixth kind, the SaaS beta:

…ratchet up your release cycles to monthly, then you can call it a ‘release’ or a ‘beta.’ Either way customers get their hands on the new functionality. If they don’t like what they get you’ll hear about it.

The good news about SaaS is that, by eliminating concerns about customer migration and installation costs, you can truly embrace the frequent releases recommended by most agile methodologies. The bad news is that four to six week release cycles don’t leave much time for customer feedback, and so most of it comes after the update has been pushed, when sales and customers start pushing back on some of the changes (or asking for more).

One way around this is inherent in the agile model itself. By breaking down new functionality into small chunks for release, you can take customer feedback as each chunk is delivered. You may be wrong with every release, but you won’t be as dramatically wrong as if you waited six months before getting customer feedback, and you’ll be able to quickly find and correct the areas where you were wrong with each new functional push.

In the meantime, you can take your overall plan for the functionality that you hope to have completely delivered over three to four releases, whether in the form of a design prototype or even a set of slides, in front of your key customers and get their feedback, and prioritize any changes into upcoming releases.

Becoming a product manager when you aren’t one already

Being one of the top Google hits for “product manager resume” has its responsibilities as well as its perks. I occasionally, as I was today, get contacted by people trying to figure out things about the product management career path, and sometimes they ask really good questions. Today my correspondent asked, essentially, how to become a product manager. It’s trickier than it sounds, since you can’t really go to school to become one, and there’s not (yet) an independent certification that you can study for at night to build the skills, as there is for project management. So how do you build the credibility to become a product manager when it seems you have to be one to become one?

There are two ways that I’m aware of to become a product manager:

  1. Start as an entry level product manager at a firm, generally as an outside hire.
  2. Get promoted internally to the position.

Option #2 is hard, particularly if you’re coming from a technical discipline (I’ll explain why in a minute). Most firms that I’ve worked at have a hard time figuring out how to take someone out of what they have always done and put them into a role where they could contribute, but which would be a completely different classification.

#1 is also hard, because you have to convince the new company to hire you without the experience. This is where the MBA helps; it’s a signal to a prospective employer that, despite a lack of experience, you have the basics of what it takes. This is actually why I took the MBA–I knew I wanted to learn some business fundamentals about finance and marketing that I wasn’t getting as an engagement manager and architect in my job at a consulting firm.

Are there ways to do #1 without having an MBA or a product management job beforehand? This is probably harder than option #2. Basically, you have to come up with some other way to prove that you are product management material. The good news is that you can do this by looking at what a product manager does and figuring out how do to some of the things inside the scope of your current employment. Maybe you can get some opportunities to work directly with customers and taking their feedback. Maybe you can build a track record of being really, really good at documenting what customers want and building user requirements. Maybe you can take some opportunities to build internal business cases for taking on a new project.

So why is it so hard to become a product manager from a technical background? Why do some people find it easier to move from a marketing position than from a development position into product management? The reason is easy: the skill set required for marketing and product management overlap, to an extent. Marketing folks need to look at the market, figure out what companies’ problems are, and identify what it takes to get them to consider your product (oversimplifying grossly). Product managers look at the market, identify what business’s and users’ problems are, and identify how to build a product (or modify an existing product) to solve those problems and meet those needs. The first two skill sets are common; the last skill set is where there are specific disciplines that come into play.

I’m sure I’ve insulted just about every marketer or product manager out there with what I’ve just written. Anyone want to take a crack at removing the noxious generalizations?

Audiophile quality music download club

Peter Gabriel’s RealWorld Studios have teamed up with Bowers & Wilkins (B&W speakers) to bring an online music club targeted at audiophiles. It’s not really a store, because the service offers only subscription pricing and the content is exclusive–up and coming musicians recording at RealWorld. The B&W Music Club is part of a set of B&W content offerings, including a blog and an article series on the industry. The intention appears to be to start conversations about bringing high fidelity audio back into the picture, after “audiophile” concerns have been pushed to the side for a few years by the prominence of MP3. It’s a smart marketing strategy for B&W, of course, who have their fingers in both the traditional high-end speaker market and the iPod accessory field; they have a strong interest in making sure that music listeners find out that uncompressed audio through premium speakers sounds much, much better than MP3s through earbuds. This is a classic market education play, in other words, and one that (presumably) has the benefit of sounding really good.

I would appear to be in the target market for this announcement; my primary home listening speakers are B&W bookshelf units (Series DM602s), and when I rip audio rather than purchasing it online, I rip losslessly to Apple Lossless Audio, the same format as the new B&W service. I think I need to check out the free trial of the service to give a better opinion on what it can provide.