Category: ProductManagement

The market failure of application security

Part 1 of an as yet indeterminate number of posts about why application security has historically been broken, and what to do about it.

Software runs everything that is valuable for companies or governments. Software is written by companies and purchased by companies to solve business problems. Companies depend on customer data and intellectual property that software manages, stores, and safeguards.

Companies and governments are under attack. Competitors and foreign powers seek access to sensitive data. Criminals seek to access customer records for phishing purposes or for simple theft. Online vigilante groups express displeasure with companies’ actions by seeking to expose or embarrass the company via weaknesses in public facing applications.

Software is vulnerable. All software has bugs, and some bugs introduce weaknesses in the software that an attacker can use to impact the confidentiality, integrity, or availability of software and the data it safeguards.

Market failure

The resources required to fix software vulnerabilities are in contention with other development priorities, including user features, functional bugs, and industry compliance requirements. Because software vulnerabilities are less directly visible to customers than the other items, fixing them gets a lower priority from the application’s business owner so fixing them comes last. As a result, most software suppliers produce insecure software.

Historically, software buyers have not considered security as a purchase criterion for software. Analyst firms including Gartner do not discuss application security when covering software firms and their products. Software vendors do not have a market incentive to create secure software or advertise the security quality of their applications. And software buyers have no leverage to get security fixes from a vendor once they have purchased the software. The marketplace is not currently acting to correct this information asymmetry; this is a classic market failure, specifically a moral hazard failure, in which the buyer does not have any information about the level of risk in the product they are purchasing.

So the challenge for those who would make software more secure is how to create a new dynamic, one in which software becomes more secure over time rather than less. We’ll talk about some ideas that have been tried, without much success, tomorrow.

Catching up

I’m starting to become that guy that I always laughed at at the office–staying up late working while the wife and family go to sleep around him. It isn’t that funny when it happens to you, though.

We’re in the final run to a big release, coming out in a week, and the days are packed between now and then–getting ready for my webinar tomorrow, two back to back big demos next week, lots of work coming on the horizon. I love this feeling when I’m on the cusp of a lot of big things happening, but already I’m looking forward more to beginning the next phase of work than I am to the release. There’s just so much waiting to be built. Maybe that’s why I never took to product marketing. I like building things more than talking about them.

Doing secure development in an Agile world

My software development lead and I are doing a webinar next week on how you do secure development within the Agile software development methodology (press release). To make the discussion more interesting, we aren’t talking in theoretical terms; we’ll be talking about what my company, Veracode, actually does during its secure development lifecycle.

No surprise: there’s a lot more to secure development in any methodology than simply “not writing bad code.” Some of the topics we’ll be including are:

  • Secure architecture — and how to secure your architecture if it isn’t already
  • Writing secure requirements, and security requirements, and how the two are different.
  • Threat modeling for fun and profit
  • Verification through QA automation
  • Static binary testing, or how, when, and why Veracode eats its own dogfood
  • Checking up–internal and independent pen testing
  • Education–the role of certification and verification
  • Oops–the threat landscape just changed. Now what?
  • The not-so-agile process of integrating third party code.

It’ll be a brisk but fun stroll through how the world’s first SaaS-based application security firm does business. If you’re a developer or just work with one, it’ll be worth a listen.

What’s the difference between iPhone and Android?

I work with iPhone users and Android users. I see no end of technology demos from both. It’s clear both phones are wonderful devices capable of doing amazing things.

So why do iPhone reviews make it sound like the device can walk on water, while a lot of Android reviews sound like this?

Unfortunately, these groundbreaking features come with enough fine print to give the White Pages an inferiority complex.

First, the screen… you can’t have a big screen on a small phone. The Evo is nice and thin, but it’s also tall and wide. It is not for the small of hand. People might mistake it for an iPad Nano.

The Wi-Fi hot spot business is slick…. this feature eats through a full battery charge in as little as one hour. (More on the Evo’s amazing disappearing battery in a moment.) And beware: the hot spot feature costs an extra $30 a month.

O.K., so what about Flash? … The Evo runs something called Flash Lite, which is marketing-ese for, “Sometimes works and sometimes doesn’t.” It plays videos on some sites that the iPhone can’t — on Engadget, for example, plus all the blinking ads (a mixed blessing). But it still can’t play the Flash videos on CNN.com or, sadly, TV shows on Hulu.com.

All right, what about video calling? Surely this is the killer app. Imagine: your friends and family can not just hear you, as with normal phones, but see you as well (assuming they also bought Sprint Evos, of course).

Well, let’s hope they’re NASA engineers, because this feature is head-bangingly unstable….

And this?

There’s a sense, not just from reviewers, but from fans of the device, that what Android really needs is just killer hardware.Which is just absolute horse shit.

Android is an asshole of an operating system.

… I discovered software I could find no way to uninstall; programs which hung around after I was done with them with no way to quit I could find; interfaces which featured tiny poorly placed buttons near impossible to click without concentration; inconsistent search functionality where the “it’s right there on the phone” search button worked or didn’t work or did work but not as you’d think it’d work. I nearly started a tumblr called “Jesus Christ I Hate This Fucking Phone” just to document all the utterly asinine behaviors my iPhone-killer-anyday-now exhibited.

There’s an argument to be made (so of course, I’ll make it) that the Android experience failures described above are not technology failures. Android’s technology and operating system are impressive. But the whole package doesn’t seem to add up very well. Compare to iPhone, where (App Store policies to the contrary, and it’s a big contrary) the whole experience is consistent and wonderful and hangs together.

The whole experience part, I think, is the key. One suspects that on most Android phones that there’s no one–not Google, not the handset maker, not the carrier–who is taking responsibility for the whole end user experience. And it shows. David Pogue’s review describes a phone whose makers, if they made tradeoffs between features and constraints at all, traded off things that most people consider essential (size, battery, stability and consistency of experience) in favor of flashy features. The result is a phone that demos well but handles poorly. And Jack Shedd’s experience with the phone describes something that’s inconsistent and hard to use when you consider it as a whole device.

Does any of this — feature prioritization, product packaging design, user experience — sound familiar?

What’s the difference between iPhone and Android? Product management is the difference.

I’m willing to bet that the product managers on the Android phones had organizational limitations on how much of the user experience that they controlled, or edicts about must-have features in which the end user experience carried little weight, and that they could do nothing about those limitations. But show me a product manager who allows organizational pressure to impair user experience, and I’ll show you a product manager who has prioritized organizational harmony against sales success.

Technical skill set for product managers

We’ve been working on hiring a product manager here at Veracode, and it’s gotten me thinking about technical literacy.

The one thing you don’t want in a product manager is someone who thinks he can write the code better than his/her developers. That sets up a major problem with boundaries–you want the product manager to worry about user experience and whether the customer’s business need is being fulfilled, not whether the developers are implementing the feature the way that he would.

But you also don’t want a product manager who’s technically illiterate. That way lies unrealistic feature requests and their cousin, unrealistic customer commitments; communication breakdowns; and overreliance on engineering for decision support.

I think there’s a middle ground: a set of technical skills that the product manager will use to do his own job, and that will help him communicate better with his engineers, without getting into their business.

In my client-server days, the skill set might have included (in addition to normal technical literacy, e.g. ability to run Office apps):

  1. SQL
  2. Excel pivot charts
  3. Windows batch scripting

These days in the SaaS world, it seems like the skill set might be:

  1. Basic statistics
  2. XSLT
  3. Excel pivot charts
  4. CSS
  5. SQL (it never goes away!)

What’s your favorite technical skill that you use all the time as a product manager?

Apple iPad: first reactions

Four reactions that I agree with (parts of) in response to Apple’s iPad announcement yesterday:

  • Doc Searls places the iPad in the context of vertical integration (apps all the way down to CPUs) and horizontal playing fields and says, “What you have to appreciate, even admire, is how well Apple plays the vertical game. It’s really amazing. What you also have to appreciate is how much we also need the horizontal one. The iPad needs an open alternative, soon.”
  • Dave Weinberger says that the iPad is the “future of the past of books” and says it’s missing interactivity and collaboration as key features.
  • John Gruber says that the iPad user experience feels like it’s all about speed, and says that Apple’s vertical integration play (the aforementioned Apple A4 chip) is responsible, and that “this is Apple’s way of asserting that they’re taking over the penthouse suite as the strongest and best company in the whole ones-and-zeroes racket” ahead of Sony, Nokia, and Samsung.
  • Michael at Cruftbox sums up the reactions of the rest of the world and says, “You’ll bang on about features, data plans, DRM, open source, and a multitude of issues. You’ll storm the message boards, wring your hands, and promise you won’t buy one till ‘Gen 2.’ The din will grow and grow as time passes. And then one day, in a few months, you will actually hold one and use it. And you will say, ‘I want one. Iwant one right now.'”

I think what disappointed me about the launch was not the device but the position it occupies. Jobs sees the iPad as occupying empty space in the consumer world between a PC (laptop) and phone. And there is probably room in that position. But the iPad seems also to be firmly positioned, at least for now, as a companion device. You sync it to another computer over iTunes. There’s no USB port or optical drive. It’s not going to be replacing anyone’s laptop any time soon.

And, frankly, that’s what I was hoping it would do. Because while it looks like it blows away its target use cases (web browsing, mail, calendar, gaming, music, book reading, even office apps), there are some very real use cases it doesn’t handle. And not just being a development platform. Like:

  • Preparing taxes (though Intuit could probably do a tax application for it)
  • Scanning documents (no USB port…)
  • Printing (ditto–though I wonder if it supports network based printing?)
  • Videoconferencing (no camera and no ports)
  • Organizing photos
  • Making a calendar or Christmas card

Additionally, I have question marks about some of the use cases that it seems to handle well otherwise. Like: can I point its version of iTunes at my 500 GB network drive and play music from there? How do the new iWork apps manage their files? (Remember, there is no user visible file system on the iPhone OS, on which the iPad is based.)

But, my quibbles aside, I have to confess that I’ve already talked with my wife about getting one. We’re pretty excited for the brave new iPad future. Because for most of what it does, it does beautifully.

The food court model of capacity planning

hmart

I just got back from the craziness that is the opening week of the new H Mart in Burlington, MA. It was instructive on several levels, not least of which was the personal (note to self: wait three weeks after the opening of a new highly hyped destination before attempting to visit). But there were also some business lessons in capacity planning to learn.

I was curious about the supermarket’s general offerings — always happy to find a new place to get specialty vegetables like galangal and lime leaves, and the prospect of picking up a carryout pint of kimchee fills me with something like culinary concupiscence (Korean takeout being thin on the ground in the northwest Boston burbs). But this visit, at noon on Monday, was about the other big letters on the sign out front: Food Court.

Takeout options are thin on the ground in this part of Burlington, with only a handful of places (Ginger Pad, Fresh City) within walking distance of my office, and only one or two more (Panera) within a reasonable drive. So I was excited that a new prospect was available. And I wasn’t the only one. When I parked (and the amount of time it took to do that should have been a warning flag) and got inside, I saw the big food court, about six counters in all covering various Asian cuisines, packed full of people. I parked myself in the line at the end for Korean food and waited.

And waited.

And waited.

There were some real operations problems happening behind the counter. The wait time to place the order was about twenty minutes, and when I got to the counter I found that about half the selections were marked as unavailable (“No pork,” the harried cashier explained). Average order fulfillment start to finish was on the order of thirty minutes or more, with about ten of that cooking time. The rest was consumed with waiting for someone to pack the order and get it out, a problem exacerbated by un-bussed trays and dishes, only two visible line cooks, and short supplies.

H Mart had, famously, months to get ready for the launch. How’d they goof it up? Chalk part of it up to opening week snafus, perhaps. But easy things like staffing the counters should have been solved problems by four days into the process. I think the real operational lesson is that H Mart neglected to anticipate all the potential sources of demand for its offerings. They didn’t have visible staff problems or lines elsewhere in the supermarket, and even had fully staffed demonstration tables nearby. What they didn’t count on was a large number of office workers eager for a new lunch option. That left-field demand spike apparently swamped their available capacity of workers and their foodstocks.

The general lesson? When doing capacity planning, consider all the possible uses of your service and think day by day and hour by hour how they will be consumed. Then ask: am I ready?

The death of tr.im, or why you are your own product manager

The recent flap over the impending death of tr.im reminds me of a discussion I had at the Berkman Center when I crashed one of their meetings back in 2004. The question was, do you use external services with your blog? That is, do you host your images on Flickr or a related service? Do you outsource comment management? These days, the question is do you host your own videos or do you let YouTube do it; or do you use a URL shortener.

Fundamentally, these are strategic questions like the ones that product managers face every day. The question is “Build, Buy, or Partner?” and it’s a question about how you add functionality to your product offering. In this case, the “product offering” is your public presence on the Internet–which is to say, in public, on-the-record discourse. As the question is conventionally understood, “build” means build it yourself, “buy” means acquire the functionality via some sort of purchase of rights, and “partner” means make a business arrangement where the partner delivers the functionality directly. In web development terms:

  • Build: You can build most of the functionality that people use on the web, from photo galleries to URL shorteners, yourself if you are a reasonably competent programmer.
  • Buy: You are acquiring via a license (even a free one) functionality from a third party and providing that functionality to your users. Can include purchased software or free software, whole packages or plugins.
  • Partner: You are using third party services directly–embedding photos and video from someone else’s server, using a third party URL shortener, etc.

So how do you decide to build, buy or partner? You can ask yourself the same questions that product managers everywhere ask:

  1. Do I have the capability to create this functionality?
  2. Do I want the responsibility of maintaining this functionality and adding to it over the long run?
  3. Is this functionality a core part of what I do? Do I derive some sort of competitive advantage from it?
  4. How much control over the final product do I want?
  5. Can I afford to have the content go away?

If you can do #1 but not #2, buy might be a better option than build. If the answer to #4 is “a lot”, partnering is not an appropriate option.

Let’s look at some people’s reactions to the event in this light:

Dave Winer had chosen the “partnership” model with tr.im (in the sense described above, that he is using their services and building atop them), building a lot of functionality on top of their APIs. He sees tr.im’s collapse as an argument to eliminate URL shorteners altogether, or at least to require that they provide a portability option. Portability is a way that you can escape Question #5, a safety clause if the partner goes out of business or if you don’t like what they’re doing with your content. I think that shortened-URL portability is in this analogy the equivalent of source code escrow and other safety provisions in conventional software contracts–it’s your escape hatch to make sure your personal data isn’t threatened. This is a perfectly sane request if you’re entering a real partnership relationship, where you’re adding value to the other party’s offering.

By contrast, Jeffrey Zeldman went the “buy” path, installing a WordPress URL shortening plugin to share pointers to his own content. For him, having short links to his content that work indefinitely is too important to risk having “the third-party URL shortening site [go] down or [go] out of business.”

Looking at it through the build-buy-partner lens, it’s also easy to see why WordPress has become such a dominant platform. The ability to add third-party developed plugins to add functionality provides a wide variety of options to add new functionality and allows you more options than simply blindly partnering with another organization, without any assurance that they’ll continue to support you.

Why go down this path at all? Why worry about the longevity of what are almost certainly transient services? One way to look at it is this: at the end of the day, your web presence is your product, and you are its product manager. You are responsible for the strategy that determines how the world views you. And in that light, it makes sense to borrow some strategies from product management to plan that strategy. Others use the formulation “You are your own CEO”; as your own CEO, consider that what people interact with online is not you but a product.

Creating a drama-free zone in product management

If there’s any doubt that management skills are portable across industries, consider this: one of the most valuable organizational traits that carried the Obama team to victory in 2008 is one of the most valuable factors for success in product management. I’m talking about the ability to create a “drama free zone,” and the ability to do it convincingly can make or break you as a product manager. Here’s two real scenarios I’ve seen this week that underscore the point.

Scenario #1: “Where’s Feature A? We’ve been asking for it for a year? Why the hell haven’t we built it yet?”

You know this one. Someone’s pain point, which is perfectly valid, simmers along until one day it explodes. Only problem is that this is the first time anyone has mentioned Feature A in a long time, and certainly it didn’t come up in the last roadmap planning discussion.

Solution: The response can be heated–“why the hell didn’t you mention this six months ago?”–or it can be drama free. “Hey, I understand there’s a customer pain point here. Let’s look at the priorities we’ve got and understand where this fits in. Is this more important than our planned work in the next release? If so, that’s where it belongs. If not, then we all agree it can wait.”

There are three steps here: acknowledge, align, act. The first step is to acknowledge that the other person has valid reasons to be upset while shifting the discussion to the common interest–the customer–and introducing an objective measure, the priority. The key is focusing on the external, objective issue — the priority of the request — rather than getting into heated discussions. (Obviously it is easier to do this if you are using stack-ranked user requirements.)

Scenario #2: Suddenly four email threads pop out of nowhere regarding a longstanding customer pain point that has apparently reached crisis proportions for no particular reason. “Feature X is broken! We need to fix it!” goes up the cry. You, as the product manager, know that the apparent failure of Feature X is really a mishmash of legal and contractual issues coupled with a lack of Feature Y and Z. But management insists that the answer is to fix Feature X, and now four separate groups of people are trying to find things to fix in it (and generating long email threads).

Solution: The response should be comprehensive, quick, and above all drama free. It’s natural, as a product manager, to want to fly off the handle when there are so many people digging into an issue. But a quick, dispassionate, thorough response (“Here’s what we know, here’s what we’re going to do about it, and here’s what’s still unknown and our next steps to find out”) has benefits in that it acknowledges the problem, communicates that there are multiple issues, and lets the assembled parties know, to return to our Obama metaphor, “Everybody chill out: I got this.”

What are your favorite drama-free problem solutions? Conversely, are there cases where engaging in drama makes a positive difference in your work as a product manager?

I’m alive

I apologize for the plethora of linkblog posts here over the past little bit, and for their relative paucity. It’s been a busy few months. I got a new boss and transitioned from a “second product manager” to more of a lead role, at about the same time that we launched a set of significant initiatives (c.f. press release if interested, if not, c.n.f.). We launched last night, a day after I got back from a holiday visit to my in-laws, and two days into the rehearsal cycle for the last Boston concert of the 2009-2009 Tanglewood Festival Chorus season, the Berlioz Te Deum.

Like I said: busy.

Not too terribly bad, though. I’m batching it for a few days and enjoying the ability to just sit and catch my breath. Did you know that there’s this thing called television? And that, mercifully, Google Reader maxes out at reporting “1000+” unread items?

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.

Macworld Keynote 2009

It’s not going to be a Stevenote (and on that note, best wishes to Steve as he gets his hormones back in balance and gets some protein in his system). But I’ll be watching all the more closely, to see how Phil Schiller takes on the challenge of igniting excitement in the Mac faithful. Like many product managers, I have picked up a few tips about presenting product over the years from Steve, and Phil will have his own style and his own techniques which I can hopefully also snarf.

Product predictions? I like John Gruber’s, and can lend credence to the iLife prediction because I finally got the most recent version as a Christmas present. Pretty sure there won’t be any new iPhone products announced today though (outside of the iPhone version of Delicious Library).

I’m pretty sure that Apple won’t be announcing the Mac Wheel today, though (hat tip to Chris Eng for the pointer):

Apple Introduces Revolutionary New Laptop With No Keyboard

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.