...your bookmarks. Del.icio.us is offline and my whole morning routine is off. Okay, so instead of tagging these two links I’ll post them to my blog instead.

First, for those new product managers out there, as well as those that have been the copy machine once too often, check out the free ebook from Pragmatic Marketing, The Strategic Role of Product Management. There’s nothing new here; in fact, it’s all stuff you’ve seen before, on Steve’s blog or in other Pragmatic publications. But it distills a bunch of lessons on why product management matters to a single document that makes a compelling story.

Okay, but once you get management buyin of the strategic importance of product management, how do you avoid getting bogged down in minutiae? How can you stay strategic? One answer comes courtesy of the Good Product Manager: Delegate tactical responsibilities. The methods to do so are simple even if you don’t have direct reports: transfer knowledge, teach to fish, and examine priorities constantly to ensure that the “urgent task” really needs doing.

I ran across an interesting concept in my reading today: technical debt, and its cousin design debt. The concept is basically the application of the Second Law of Thermodynamics to software development. As you develop software, you affect the entropy of the code. Feature development typically increases entropy, while refactoring and explicit design activities decrease entropy.

Why do we care about entropy in software code? Code with high entropy is harder to maintain, harder to fix bugs in, and harder to add features to. It basically increases the cost and time to get new releases of the software out.

The concept of design debt argues that this kind of entropy is additive across releases, and that each time you perform entropy positive actions you increase the amount of work needed to dig out and make the code maintainable again.

I’ve lived this, for sure, and I suspect most others have too. But what makes it really interesting is thinking about it dynamically, where it is made clear that design debt decreases the profitability of a project. I think it’s even worse than it appears in the diagram, because the diagram neglects the time dimension. As the cost of development increases, more than likely the time to develop also increases—which means that Domain Evolution proceeds even farther while you are trying to catch up. This means that you have to increase the number of features even more, but that incurs a higher design debt still. It’s an unpleasant positive feedback loop.

I’ve stopped reading Jakob Nielsen on a regular basis, so I missed this: Top-10 Application-Design Mistakes. As it turns out, this is one of the few of Jakob’s Alertboxes that I agree with more than disagree with. Iterative design, paper prototypes, decide what your app should do, beware nonstandard GUI controls, design for the user rather than the back-end system, etc.

Number two particularly amuses me. I was on a business trip with someone who was bitten, hard, by this bug (on a different travel site). His boss booked his travel, and didn’t pay attention to the fact that the position of the months on the calendar changed between the Start and End date fields. Worse, the travel was in February in a non-leap year, so there wasn’t even a difference in date numbers to clue him in (since the Wednesday in March was exactly 28 days after the Wednesday in April). Result? A very long delay for our friend at McCarran Airport in Las Vegas trying to straighten the problem out, so that my friend could get back 30 days earlier than his ticket specified.

Usability mistakes cost.

When I came to my new company, I didn’t mind going from Vista back to Windows XP. There were a few tools and features that I missed, but ultimately one version of Windows isn’t too much different than another.

But I would have caused a serious uproar if I had to use something other than Office 2007.

It’s pretty rare for me to feel passionate about Office software. The last version of Word that I really, really liked was probably Word 5.1a for the Mac, back in 1992. After that I got proficient with some newer features, most notably working with references and TOC formatting for an 800 page software design book that I put together from individual documents in a ridiculous amount of time back in the late 90s. But it got harder and harder to like Word, and I found the time I spent typing in plain old text boxes on the Web to be a refreshing change. I even adopted Notepad and other text editors as my quick writing tool of choice, and still find I prefer working in plain text to having to think about formatting as I write.

So what changed my perception of Office? Why am I no longer afraid to set foot in Word? Why do I actually evangelize PowerPoint 2007? I think the answer is that the Office team, Jensen Harris among them, sat down and looked seriously at how people used, or didn’t use, Office, and made some hard choices about how to change the software to fix what they found.

Jensen had a great presentation at Mix that explains the process that the Office team used to come up with the new Ribbon-centered design for Office 2007. I’ve only looked at the slides so far, not the actual video, but by themselves they’re pretty inspiring.

What are the takeaway principles? I think the outline of the presentation spells it out:

1. Define the problem by talking to actual users. Don’t rely on the conventional wisdom to tell you whether there is a problem with your software. Conventional wisdom would have told Microsoft that Office was a cash cow with no issues and no room to improve the brand, that they should just keep marketing the product the same way and keep stacking on task panes.
2. Get data about the problem. Start with internal observations (menu and command count), then go to external observations to define a hypothesis and an approach based on user interaction data and the emotional tone of how your users approach and think about your product.
3. Define the design goals, and draft a list of principles that guide the solution. If the solution is too complex to define up front, you’ll need guiding principles to help you make decisions along the way as you iterate.
4. Prototype. A prototype can be created a number of ways, from plain old paper to Photoshop to RAD tools. Use what’s appropriate and don’t discount the low tech solutions. At my current gig, most of our prototypes are created in Visio.
5. Evaluate the prototypes. I love Jensen’s list for this process because it sums up about two semesters’ worth of marketing education from my MBA program:
   • Beta users
   • Anecdotal feedback (blogs, forums)
   • Benchmarks and Metrics
   • Observations and Interviews
   • Usability studies (around the world and remote)
   • Card Sorts and Paper Prototypes
   • Surveys
   • Longitudinal Usability Studies
   • Long-Term Deployments (5 months+)
   • Truman Show
   • SQM (Customer Improvement Program) [automated data collection from volunteers]
6. Finally, build in room for iteration. You probably won’t get it right the first time, but you’ll learn from every trial.

I’m excited about Jensen’s summation of the experience because it is high-visibility verification that structured software design matters. It’s a great story to tell your management team, your development team, or that guy in QA who complains about changes to the screens.

I already know this approach works because I’ve used it, or at least a subset of it. At my last gig, this is what our design process looked like for our last release:

• Problem: Users couldn’t find functionality in our software that was already there. Some of the functionality confused users. Prospects didn’t enjoy working with our product as much as with competitive products.
• Design goals: Improve discoverability and make the product more enjoyable to use. Design tenets: reduce the number of toolbars; have consistent places and ways to expose functionality; borrow UI conventions from products that the user is familiar with; use a familiar overall convention to frame what the user is doing and make them at ease; eliminate features that weren’t adding value.
• Prototyping: Paper, Photoshop, and quick XAML apps. In some cases, I mocked up parts of the UI using sticky notes to move around different modules or parts of the screen design, so we could figure out how to get the features in the most convenient places.
• Evaluate prototypes: Here customer presentations and beta users made the biggest difference. I would have loved to have the budget for more formal usability testing.
• Iterate: We rebuilt our development process to allow for course corrections along the way.

The process isn’t rocket science, but it works, and so will your product if you think honestly about every step along the way.

Apple has posted its application form for the new iPhone enterprise tools, whatever they are (Apple has been awfully nonspecific on that point). This is cool for a bunch of reasons:

1. It’s an open, transparent beta process for a piece of enterprise technology.
2. From Apple. When was the last time you heard any of the words in the first point from Apple?
3. And there is a fairly detailed feature list too!

Well, prospective feature list. And of course I should note that there’s a chance this comes from a marketing manager who’s looking to write case studies. But still: cool.