Category: ProductManagement

…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.

I am in awe of another product manager: the Cranky Product Manager. She posts infrequently but many of her posts are brilliant.

One from last year on “how to say no” to customer or sales feature requests caught my attention. Many of the comments on the post were insightful and mirrored my experience with dealing with feature requests. Generally if you can turn the conversation away from a specific feature and toward the business issue the customer is trying to solve, you can usually either (a) point out another way the software can already do what the customer wants, or (b) give a more informed answer about what it will take to make it happen. The trick is getting away from the specific feature, which the customer and the sales guy may have spent some time building up as The Solution to the problem. To do this, Joel Spolsky’s five Whys is helpful.

Being open with your roadmap is important when you can; it shows the customer that you are thoughtful about the features that do go into the product, gets them thinking about the relative importance of the feature, and makes them feel included in the future of the product.

While there are whole blogs devoted to the topic of good product management, I don’t think anyone has a good answer for how to interview for a good product manager that doesn’t boil down to “it depends.” There are sound reasons for that: There is a continuum of roles that a “product manager” can play, ranging from almost entirely strategic/market focused to almost entirely development/product focused to somewhere in the middle. The roles I have played have been at all ends of the spectrum, or all roles at once; at most companies the role falls somewhere along the continuum depending on company size and organization. The competencies that you look for during the interview depend strongly on how you expect the product manager to function in your organization.

That said, here are some things to look for in a product manager, divided into categories:

1. General
   • Communication skills – one of the major roles of a product manager is being able to speak Sales to Development and vice versa and be understood
   • Decisive – need to take input and synthesize a clear direction even if it’s unclear what the right way to go is.
   • Negotiation experience – important when brokering a deadlock between priorities, or between sales and development.
   • Business savvy – understand how the product can make money. Prioritize according to business needs, both long and short term
   • Market savvy – understand the competition, the strategic landscape, and how the product fits
   • Driven to learn – do they keep up with what’s going on in the industry? Ask them what are the challenges for product managers in an Agile environment and you’ll quickly get a sense for their depth and how much they think about their role.
2. Development-facing specific
   • Tech savvy – I would say that the ability to quickly pick up and understand the challenges of new technologies is more important than specific experience in the languages your development team is using. I was a PowerBuilder dev, but I was able to understand the peculiarities and challenges that my development team experienced in C++ vs. C# vs. XAML.
   • Project management – Tracking, detail orientation. This can make or break a product manager on a day in, day out basis.
   • Facilitation and meeting management – In a lot of teams the engineering lead drives this almost entirely. But it’s a critical skill to have in your pocket, from requirements gathering to release post-mortems to gathering agreement between different stakeholders on what is to be done on a particular problem.
3. Market-facing specific
   • Experience working with analysts – Some companies have separate AR roles; some don’t. It’s a pretty good bet your product manager will need to face a skeptical analyst to describe the product’s direction at some point, and it’s a good indicator if a candidate has had that experience under her belt already.
   • Strong demo skills — even if the PM doesn’t do sales directly, they might do conferences, and at a minimum they will need to champion the work that development is doing.

Finally, there’s a really good article on Pragmatic Marketing that sums up some value drivers for good product managers as: Attitude, Knowledge, Communication, Customers, Managing, Decision Making. It’s worth looking into.

Great product manager joke from Art Petty (via Steve Johnson at Pragmatic):

Q: Why is a Product Manager like the Office Photocopy Machine?

A: Because when it works no one notices and when something goes wrong, everyone wants to kick it.

Heh. Heh. TANJ, indeed.

Of course, many a product manager has done the “Danse Russe” (“I am lonely, lonely, I was born to be lonely, I am best so!”), but I’ve found an interesting dynamic working as the second product manager at my company. In addition to the extra pair of hands to manage the workload, there is some reinforcement and validation. Of course there’s always the danger that that turns into “us vs. them,” so that is something to watch. But it really does help having a sanity check on team interactions, process questions, requirement prioritization, and all the other caution areas that product managers face.