Improving PM, part 2 – When not to listen to customers

This is part of a short series about the talk I gave at Product Camp Boston, entitled “Getting Better at Getting Better: A PM Kaizen.” A general introduction to the talk is here and you can view the slides.

The hardest thing for me as a PM has been to learn how to listen to customers, and when not to.

I know, I know. Customer centricity is a key tenet for growth, if you don’t listen to customers you die. But I’d argue that you can get yourself in real trouble if you listen to customers too much, or listen the wrong way.

Here’s the thing. Customers will tell you really important things about how your software works, or doesn’t work, for them. But sometimes you have to really dig for the key information. I can’t count the number of times that a customer request came into my email, passed along by a well-meaning co-worker, that when I dug in turned out to be a completely different issue.

The reason is that we all try to solve our own problems. Customers know their workflow better than anyone else, and so as they think about something that irks them about your software, they’ll consider lots of possible ways to solve the problem within what they understand to be the constraints, and discard the ones that won’t work for them. Then they’ll think of other problems and revise their solution, and ultimately pass along a solution that is so specific to their use case that it may actually not solve the problem for other customers, and may even create new problems.

So I tend to follow the rule of Five Whys. Because what is tremendously valuable is understanding the root cause, the underlying customer problem, that sparked the communication in the first place. Sometimes customers are inspired to identify good solutions, but often their understanding of the constraints, lack of knowledge of other features you have in your roadmap (or under development), or thought process constrained by their local environment results in partial workarounds that don’t solve the root issue.

So much for the microcosm of customer feature requests. What about your roadmap? Surely that should be customer centric?

Well, to a point. But you have to be keenly aware of who the customers are who are influencing your roadmap and who they represent—and what stage your product and your market are in. I find the Crossing the Chasm model helpful for understanding this part. A lead customer for a pre-chasm offering, or a mainstream customer for a post-chasm offering, can provide helpful feedback. But if you’re in the middle of a market disruption, listening only to your existing customers can be a recipe for disaster.

That goes double for when you get successful. Large software product teams get very good at listening to their existing customers, and miss out on the customer pain points that lead some prospects to choose other solutions. If you couple the crowded PM calendar with lots of feedback from existing customers, you can get into a trap of the Urgent Now and miss the signals that your market is shifting.

So how do you stay focused on longer term, bigger picture problems? How do you avoid being dragged into that tire fire in your inbox? It turns out that the tools you need to stay focused on the right things may be closer to hand than you think.

Improving PM, part 1: the calendar

This is part of a short series about the talk I gave at Product Camp Boston, entitled “Getting Better at Getting Better: A PM Kaizen.” A general introduction to the talk is here and you can view the slides.

The number one complaint I hear from PMs is the tyranny of the calendar. “There’s no time.” “I’m in meetings all day, all week.” “I’m staying until 8 to get work done.” “I’m logging in after the kids are in bed and staying up until 2.” “Let’s meet, two weeks from now when I have free time.”

The net result is a calendar like the above, with about three or four free hours scattered throughout a work week. There are all kinds of problems with this way of working. One of the worst problems is something I recognized first in working with building software for developers, and that I recognize in my own calendar: the time to build context.

Knowledge workers, like software developers and product managers (and marketers and others), rely on an understanding of the context in which they’re doing their work to be effective. As a software developer, you can’t effectively debug a problem unless you first build a mental model of how that part of the software works. That’s time-consuming, and if you’re interrupted you have to start all over again. (There’s a great illustration of this challenge for programmers by Jason Heeris.) And for some PM work—strategy, building roadmap, understanding user problems—you need that mental model time too. A half hour or hour here or there doesn’t really cut it.

But many PMs that I know are achievement oriented. We like to make lists and check off items. So what do we do? We spend all our downtime getting stuff done. It isn’t the strategic important stuff that needs a half hour of context building, because we don’t have time for that. It’s responding to email, putting out fires in inboxes, answering customer feedback.

The strategic, in other words, gets crowded out by the tactical.

There are many ways you can solve for this problem. One of them, which I heartily recommend, is becoming more effective at saying “no.” That has its own challenges. You can just say “no” and leave the requester with no way to fill that request. Unless you’re uninterested in the welfare of your customers and the bottom line of your company, that’s often not behavior that maximizes long-term outcomes. So you may find yourself trying to understand the breakdown in the system that led that person to your desk and left you as the only person in the organization that can help them solve their problem, and suddenly you’re back to square one.

If you’re good at saying no when you can, and diagnosing organizational breakdowns when you can’t AND taking steps to shift the permanent solution elsewhere in the organization, then that’s an effective way to keep your calendar clean. That means, though, that “just saying no” isn’t really within reach for most PMs.

So what’s the alternative? I would argue that we have to find a way to systematically think about our work, in such a way that we don’t constantly have to reconstruct our context before we can move the work to the next step. I’ll discuss this more next time.

Follow up reading: The challenge of being “the only person in the organization that can help solve the problem” is covered extensively in the writings of W. Edwards Deming; he calls the process of finding these “only people” identifying the constraint in a process, and recommends that you find ways to elevate the constraint by redesigning the process so that it is subordinate to the constraint. There’s some practical discussion about elevating constraints in the context of software development and IT in the classic DevOps novel The Phoenix Project.

 

Getting better at getting better

On Saturday I attended my first ever Product Camp Boston. This event, an unconference devoted to product management and product marketing, was massive in terms of attendance (over 500) and content covered (some 58 sessions). I was fortunate enough to nab a speaking slot. I debated what to speak about, and ultimately ended up giving a talk on applying agile scrum to the work of product managers to help a team improve their PM craft.

About now my non-engineering friends and family are looking at me with a little white showing in their eyes, and my engineering savvy readers may be skeptical as well. But I’ve written about this idea before in the context of agile marketing, that by committing to work up front for a limited period of time, documenting what we work on, publishing what you achieved, and being purposefully retrospective (what went well, what didn’t, what will we change), we can improve our effectiveness as individuals and teams.

For PMs the big payoff is in slowly transitioning out of firefighting mode and into bigger-picture thinking. It’s too easy to succumb to the steady pull of today’s emergency and tomorrow’s engineering release and lose strategic focus. Our kaizen has given me the ability to think farther ahead and be more purposeful about the work I take in.

I’ve posted the slides for the talk, and will write a little more about this topic soon.

We are the champions

It continues to be challenging for me to write much right now, partly because there is so much going on. One thing that happened today: I gave a webinar on how to handle the shortage of information security people when you’re trying to build more secure software. (The answer: you grow your own.)

The recording isn’t live yet, but I posted the slides and opened a discussion thread on Peerlyst for those interested. 

Tricking yourself into doing work

I’m a big fan, historically, of productivity hacks, or whatever we called them before we called them hacks. I was a Franklin Planner guy, then a Seven Habits guy, then a Getting Things Done guy, then an Inbox Zero guy. Nothing has stuck better than agile scrum.

Wait, what? Isn’t that a project management methodology for software developers? Aren’t you in marketing?

Well, yes. But agile marketing is a real thing, and it’s proven remarkably helpful in dealing with both routine and unusual work. Here’s why:

  1. Visibility. You go from systems that encourage personal to-do lists to systems that encourage shared backlogs, and the consistent maintenance of the same.
  2. Prioritization. The backlog becomes a tool for discussing and communicating priorities.
  3. Discussion. The best practices around “story grooming” encourage you to discuss what has to be done for a piece of work with the team. I find that in talking out loud what has to be done, I often discover new tasks or dependencies, and new ways forward.
  4. Limited work in progress. Boy, this is important. We all have to spin plates sometimes, but the emphasis on finishing what you start, as much as possible, before starting something new really makes it possible to focus on a task and see it through to completion—and not to sit on something indefinitely because there are improvements you might want to make before you are “done.”
  5. Retrospective. This is the hardest thing, but building in time for review of the work already done means you force yourself to look back and figure out how you might do better the next time.

We’re about five months into our agile marketing experiment and so far we’ve learned a lot. Can’t wait to see what happens next as we expand. Next week I take a discount business class ticket to meet a possible business investor. Stay tuned!

Temporary autonomous mercantile zones

IMG_6090

Conferences typically have two official parts, talks (including big keynotes, little presentations in small gatherings, and everything in between) and the trade show floor. The talks are what people come for and are what brings press attention to the conference. The trade show floor pays the bills.

Trade show floors are infinite grids of elaborate temporary architecture, with each plot of land covered in concrete and cheap carpet and leased to a vendor for the duration of the show. The plots are sized according to how much the vendor pays for their sponsorship. On the plots, vendors and their marketing event companies build simple or elaborate booths, like the sukkōt of the Feast of the Tabernacles, only with no roofs. Also unlike a sukkah, the walls of a booth may, in fact, sway in the wind, or if a vendor walks behind them and knocks them down.

Some vendors have small ground height booths, but most go up, so that they can be seen from afar. Unfortunately, with every vendor “going up,” the effect is often lost and you end up with an air space arms race. I’ve seen a marketing manager from one company snarling at another because the second company’s booth cast a shadow on the first.

The trade show floor is a gathering; it is constructed quickly knowing it is only temporary, and demolished just as quickly. But in between, it’s a linear descendent of the oldest traditions of human commerce: the agora. Because to this giant assemblage of bright booths come booth staff—people like me—and conference attendees. Some attendees come to talk to vendors because they have a need to fill; most come for freebies. At this conference, the freebies include brochures, keychains, cheap electronic gizmos, stuffed animals, alcohol, and—critically important—coffee. And so people meet and trade. Maybe not directly, but they may take the first steps to an agreement. It’s a ritual that hasn’t changed in thousands of years.

In which I look a gift horse in the mouth

Springer has published a bunch of its books online for free. (Hundreds more were free until this morning but the plug has been pulled.) I went looking to see what I could find. There are some interesting finds there, including a festschrift for Ted Nelson, the inventor of hypertext. And, relevant to my work interests, a text called The Infosec Handbook.

What’s that, you say? A free textbook on information security? Sign me up! Well, not so fast, pilgrim.

Admittedly, I come to the topic of information security with a very narrow perspective—a pretty tight focus on application security. But within that topic I think I’ve earned the right to cast a jaundiced eye on new offerings, as I’m going to celebrate my eighth year at Veracode next month. And I’m a little disappointed in this aspect of the book.

Why? Simple answer: it’s not practical. The authors (Umesh Hodeghatta Rao and Umesha Nayak) spend an entire chapter discussing various classes of threats, trying to provide a theoretical framework for application security considerations, and discussing in the most general terms the importance of a secure development lifecycle. But the SDLC discussion includes exactly one mention of testing, to wit, in the writeup of Figure 6-2: “Have strong testing.” And an accompanying note: “Similarly, testing should not only focus on what is expected to be done by the application but also what it should not do.”

Really?

It’s pretty widely understood in the industry that “focus(ing) on what is expected” and “[focusing] on what [the application] should not do” are two completely different skill sets and that even telling a functional tester what to look for does not ensure that they can find security vulnerabilities. The problem has been well known for so long that we’re nine years into the lifespan of the definitive work on the subject, Wysopal et al’s The Art of Application Security Testing. But there’s no acknowledgment of any of the challenges raised by that book, including most notably the need to deploy automated security testing to ensure that vulnerabilities aren’t lurking in the software.

As for the “eight characteristics” that supposedly ensure that an application is secure, take a look at the list for yourself:

  1. Completeness of the Inputs
  2. Correctness of the Inputs
  3. Completeness of Processing
  4. Correctness of Processing
  5. Completeness of the Updates
  6. Correctness of the Updates
  7. Maintenance of the Integrity of the Data in Storage
  8. Maintenance of the Integrity of the Data in Transmission

Really? Nothing about availability. Nothing about authorization (determining whether a user should be allowed to access information or execute functionality). Nothing about guarding against unintended leakage of application metadata, such as errors, identifying information, or implementation details that an attacker could use. And nothing about ensuring that a developer didn’t include malicious or unintended functionality.

The chapter also includes no mention of technologies that can be deployed against application attacks, though this may be a blessing in disguise given the poor track record of web application firewalls and the nascent state of runtime application self-protection technology.

All in all, if this is what passes for “state of the art” in a security curriculum from the second biggest textbook publisher in the world, I’m sort of relieved that information security isn’t a required curriculum in a lot of CS programs. It might be better to learn about application security in particular from  a source like OWASP, SANS, or your favorite blog than to read a text as shallow as this.

Next week: Austin, TX

You’ll be able to catch me in my professional capability twice next week. I’ll be giving a talk on Tuesday in Austin, TX to the Austin chapter of ISACA (the Information Systems Audit and Control Association) on “Best Practices for Application Risk Management.” The argument: the current frontier in securing sensitive data and systems isn’t the network, it’s the applications securing the data. But just as it’s hard to write secure code, even with conventional testing tools, it’s even harder to get a handle on the risk in code you didn’t write. And, of course, it’s the rare application these days that is 100% code that you wrote. I’ll talk about ways that large and small enterprises can get their arms around the application security challenge.

I’ll also be joining one of our customers to talk in more depth about a key part of Veracode’s application risk management capability, our developer elearning program and platform, in a webinar. If you are interested in learning how to improve application security before the application even gets written, this is a good one to check out.

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.

Screenshots in software user documentation

I’ve been up to my eyeballs in user doc recently, our software-as-a-service product offering having matured to the point that novice users need some guidance to get started with the software. This being a startup, we don’t have a tech writer, and I’ve added the relevant hat to my normal product management job–and rediscovering my deep respect for the profession.

A tech writer has to know the software better than anyone else from the user’s perspective, and has to understand the compromises, incomplete implementations, and other hazards of software well enough to explain to the user how it’s supposed to work in a clear, intuitive way. Tech writing reminds me of Henry Miller’s description of proof-readers in Tropic of Capricorn, which I took many years ago as a motto while working on the production of the second or third issue of Rag & Bone:

The world can blow up — I’ll be here just the same to put in a comma or a semi-colon. I may even touch a little overtime, for with an event like that there’s bound to be a final extra. When the world blows up and the final edition has gone to press the proof-readers will quietly gather up all commas, semi-colons, hyphens, asterisks, brackets, parentheses, periods, exclamation marks, etc., and put them in a little box over the editorial chair. Comme ça tout est réglé…

…A good proof-reader has no ambitions, no pride, no spleen. A good proof-reader is a little like God Almighty, he’s in the world but not of it.

So tech writers are a little like proof-readers–the release may blow up, but the tech writer will still be there updating the user documentation and taking the latest screenshots.

Which brings me around to the question at hand: the tension between the need for screenshots in documentation and the definitive non-agileness of it all. A thread on the Joel on Software Discussion Group questions the need for screenshots entirely but comes around to the concept that, yes, you have to retake the screenshots every time you update the GUI, and yes, it’s a pain in the butt, but it’s part of the cost of doing business. I was hoping for some more practical guidance: is there a rule of thumb on what to illustrate with a screenshot and what to leave out?

Test driving Google Reader

One of the downsides of being an early adopter in some areas is that I’m a late adopter in many others. I was using a desktop RSS aggregator back in 2002 (Radio Userland, then NetNewsWire) and so came late to the web-based news aggregator market. When I did hop on board, I used Bloglines, one of the early web based aggregators, and so missed out on Google Reader. I’ve stuck with Bloglines because it works and because it works well on the iPhone.

Yesterday, Bloglines wasn’t working. I haven’t seen anything posted about this, but while the site’s UI was up I didn’t get any new results for any of my 175 feeds from about 11 AM on. So in the early afternoon I decided to give Google Reader a spin.

One of the nice things about feed readers is that it’s pretty easy to take all your feeds to a new reader, thanks to OPML (one of Dave Winer’s many innovations in this area). Most feed readers support exporting your feed list to OPML, a structured XML format, and support importing feed lists from OPML. So you can pack up your feeds and easily bring them to a new place–minimizing vendor lock-in. I did that with my Bloglines feeds and was up and running quickly in Google Reader.

One thing that struck me almost immediately was the poorer UI in Google Reader. While it uses the same left pane navigation–right pane reading metaphor as Bloglines, the left pane is cluttered with a bunch of stuff on the top–starred items, trends, shared items and notes, a big help pane, and THEN your list of feeds. Bloglines’ feed list takes up the whole left pane and is just your content–much easier to manage–while other information like your personal blog and “clippings” are in separate tabs. If you’re just interested in reading feeds, Bloglines’ navigation is easier and less cluttered.

The right pane UI is a little better too, imho. I find the separate drop-shadowed feed boxes in the expanded view (what NetNewsWire used to call “smash view”) distracting; Bloglines’ zebrastriped list is visually flatter and doesn’t get in the way of the content. And I can’t imagine a use for the list view for most of my RSS feeds; though perhaps the notification-only ones are better suited for this kind of presentation, I can’t imagine trying to read BoingBoing or even Krugman this way.

Google Reader does feel a little snappier–feeds update more frequently and quicker. But the reading experience is actually slower, because items don’t get marked as read on display, but only if you scroll them off the screen. That might be beneficial for some people, but I’m a quick scanner and like to run through the feed list quickly. And because Google Reader doesn’t fetch all the items in a folder at once, dynamically fetching items as the user scrolls, there’s no way to quickly scroll to the bottom and read everything all at once. You have to wait for the fetch to catch up, then scroll to the bottom again.

So this morning I was pleased to see Bloglines is back online. I’ll still test out the Google Reader iPhone experience, because there are things that don’t quite work for me in Bloglines’s. But I’ll be continuing to use Bloglines in my browser.

Technical Debt part II: Security debt

I wrote previously about “technical debt,” the concept that the decision to defer necessary technical work (adopting an updated version of a new component, refactoring code to reduce cruft, etc.) accumulates across releases until it absorbs a project team’s entire capability to develop code. You “pay interest” on technical debt because it’s much harder and consumes many more resources to make a necessary technical change the further downstream you get from the point where the change becomes necessary.

It occured to me today that there’s a specific flavor of technical debt, security debt, that is both more insidious and much easier to see in operation, because we have so many prominent examples of it. It might not have cost the developers of Windows too much more to make the OS more secure at design time, but some of the decisions were deferred, until the point where you had whole features introduced to address security deficiencies in prior features, and the six month long security push that postponed Vista’s launch while the team took care of outstanding security issues in the already-shipped version of the OS.

What’s interesting about security debt to me is that it balloons over time. My once-favorite mix sharing site, Art of the Mix, is a good example. The guy who developed it didn’t really understand SQL injection or XSS, or at least didn’t code defensively against them, and it’s become a hive of malware as a result–and is now flagged as a “reported attack site” and blocked by Firefox 3. So, to carry the metaphor to its logical conclusion, the site’s security debt drove it into a kind of “bankruptcy” when it proved susceptible to drive-by SQL injection attacks.

So how do you avoid incurring security debt? Learning good development practices is a good start; keeping up on the prevalent attacks–the current risk space–is another. But there’s one key thing to remember about security debt: in many cases fixing the underlying flaw that permits exploitation is far far cheaper than getting hacked, or even putting bandaids like web application firewalls in place.

Keep your hands and feet inside the car at all times…

…because something tells me this race is going to be a rollercoaster for the next few weeks.

Screenshot below from the excellent Election ’08 iPhone App, from Pollster.com and Slate. For a more nuanced view, look to the fine folks at Electoral-Vote.com, which shows Obama’s lead 338 to 185 electoral votes, with 15 ties. This high margin is pretty new in the race–back in early September, the lead was only about 100 electoral votes.

For more context, check out the historical trends on Electoral-Vote.com, where you can see what happens if you don’t count the states with a less than 5% margin of victory (answer: we don’t have a clear winner yet).