For the first several years Twitter existed, I was a skeptic because I mostly saw friends commenting about what they had for breakfast or where they were. Who has time for reading that? It seemed like a huge waste of time.

But once I began writing this blog, Twitter turned out to be a great way to raise awareness of the blog. Then I discovered that Twitter was a great way to engage with the product and project management community as a whole, to identify authorities in the space, to make new professional connections, and to learn from others. Twitter’s power for listening and learning, not just speaking, is greatly underestimated.

In my copious spare time, I’d already been using video for HIV/AIDS prevention education for the last five years through my not-for-profit AIDSvideos.org and its YouTube channel AIDSvideos. Through that process, I learned how simple but educational videos could gain hundreds of thousands of views over time. Beyond that, I discovered that the questions people asked in response to the videos became our guide on what new videos we should create going forward. Listening to and engaging with the community of people watching the videos, answering their questions, and moderating their comments enabled an Agile approach to content creation. We did not plan the current list of 110 videos up-front. We created a few videos, watched the view counts, the questions, and the comments, created more videos in response, and iterated. Watching the number of views for each video became a heuristic to guide new content creation going forward. Using social media in an Agile and iterative fashion lets you engage with your customers, whoever they may be, learn more about their needs and interests, and serve them better. Agile project management isn’t just for software development by any means!

Also in my copious spare time, I learned that two people had been imprisoned in Afghanistan for their choice of faith, so I experimented with using Twitter and Facebook pages together to generate awareness of the problem and create pressure through multiple channels (tweets, emails, phone calls, and letters) for their release. Did my modest tweets cause their ultimate release? Hardly; I would argue that sustained behind-the-scenes diplomatic efforts for the preceding year by five nations that are supporting Afghanistan had a lot more to do with it. But I realized that social media marketing provides a low-cost way to raise awareness about an issue and make it clear to a government that the attention and concern won’t go away until the issue is resolved. Someday, I’d like to create a step-by-step “prisoner of conscience campaign in a box” so that anyone can do the same for a prisoner of conscience of their choice somewhere in the world.

Based on what I learned, I created the “Social Media Marketing for the Lean Startup” presentation at Silicon Valley Product Camp in the spring of this year, and now I’m happy to offer this four-hour hands-on course for those who are interested in learning quickly the fundamental skills that I learned over years of time. This course has a $95 introductory rate and limited attendance, so sign up now if you’re interested! Thanks to everyone in the social media community for everything you’ve taught me over the years!

This week I (and seemingly everyone else on the Internet) wrote about the self-inflicted wound that is Apple’s Final Cut Pro X product launch and the lessons to be learned about product transition management. I expect that Apple will ultimately regroup and come up with a plan that is somewhat less of a finger in the eye to professional video editing firms that have staked their businesses on Final Cut Studio and have invested years of time creating content with it. Why? Simple: the cost of continuing to sell and support Final Cut Studio 7 during a transition period is certainly lower than the cost of the PR hammering Apple is currently enduring, and before much more time has passed, some executive at Apple will realize that and cause the company to change course.

The core reason that the negative reaction to the launch of Final Cut Pro X has been so intense is that Final Cut Pro X doesn’t provide backward compatibility with project files created with previous versions, and Apple simultaneously pulled Final Cut Studio 7 from the market without any advance warning to customers. If you’re a professional video editing firm that is growing and just hired a new employee and needs them to edit some of your customers’ older files, Apple just yanked the rug out from underneath you. You can’t use Final Cut Pro X to edit that file, and you can’t buy an extra license for Final Cut Studio 7 so the new employee can edit on their new machine. Understandably, professional video editing firms are incensed.

These firms are doubly incensed because by doing this, Apple has violated the trust the firms placed in Apple when they decided to commit to using Final Cut Studio. Final Cut Studio creates video projects in Apple’s proprietary file format. As far as I know, Final Cut Studio is the only tool in the world at its price point that supports editing of files in that format with full compatibility. So when firms decided to make Final Cut Studio their standard tool for editing customer video content, they were placing a big bet that:

• Apple would remain in business.
• Apple would choose to continue supporting and improving Final Cut Studio over the long term.
• Apple would preserve backward compatibility with existing content as it upgraded the product over time.

If I’m a document editor who uses a tool to edit HTML files and the tool vendor creates a product upgrade that no longer meets my needs, I can easily switch to using another tool. HTML is an industry-standard file format so there are many tools I can choose from. But if I’m a professional video editor who chooses to create videos using Final Cut Studio, Final Cut Studio is the only tool that will let me open that video project file and make further changes to the project. (Yes, you can export the finished video to AVI and edit the finished video with another tool, but that loses all of the metadata and structure that are critical for productive individual or shared group editing of a video project and maintenance, enhancement, and editing of content over time. It’s like the difference between an Adobe Photoshop file and an exported JPEG.)

For both rational and emotional reasons, people respond far more intensely when they feel their trust has been violated than when they feel that someone made an innocent mistake. This explains the ferocity of the backlash that Apple is currently enduring.

Apple has apparently committed that a future release of Final Cut Pro X will provide full backward compatibility with existing Final Cut Studio project files. That’s a step in the right direction. But since the current release of Final Cut Pro X doesn’t provide that compatibility, Apple needs to continue selling Final Cut Studio 7 in the meantime so that its customers can continue to operate and grow their businesses during the transition period.

The main takeaway: if you are asking customers to pay money for your product and your product requires customers to create and maintain data in a proprietary file format, your business depends on customer trust. That trust is easily lost and hard to regain. Learn from Apple’s mistakes on the Final Cut Pro X launch. Earn and keep your customers’ trust!

I write this as a confirmed Apple fanboy. I learned to program on an Apple II+, got an SE/30 as my high school graduation present, got MacBook 140 as my college graduation present, and now have a G5, a MacBook Pro 15″ laptop, an iPhone, an iPad, an Airport, an Airport Express, and … uh oh … Final Cut Studio 6.

Final Cut Studio Rocks!

I love Final Cut Studio. I’ve used it since December 2005 to edit videos for my spare-time not-for-profit AIDSvideos.org. I’ve created over a hundred educational videos using it. It has more power than I will ever need, but it’s good to know that every feature I could ever want is in there if I need it, and the application makes this power accessible to non-professional video editors as well. You can use it for everything from family videos to professional movies.

Apple Mistakes in the Transition to Final Cut Pro X

This week, Apple released Final Cut Pro X, and it made several basic mistakes:

1. Final Cut Pro X does not have all the features of Final Cut Studio 7.
2. Final Cut Pro X cannot import project files created with Final Cut Studio 7.
3. Either Apple didn’t commit at the time of launch to ultimately provide full content backward compatibility and import capability in a future release, or if it did, it sure didn’t communicate that adequately to its existing customers!
4. Without any advance warning to customers, Apple ceased selling Final Cut Studio 7 as soon as it released Final Cut Pro X.

Error #1 and error #2 could have been managed and tolerated if Apple hadn’t made error #3 and error #4 as well.

A company has a right to re-envision a major product, as Apple has done with Final Cut Pro X. It has the right to create a new release that targets a larger, lower end of the market, as Apple seems to be doing with Final Cut Pro X. It even has the right to release a new version that doesn’t have all the features of previous versions, and that at least initially can’t import the previous version’s legacy files. But when a company does this, it has to manage the transition period carefully to protect the interests of its longtime customers. It’s here that Apple made terrible and uncharacteristic mistakes.

By taking Final Cut Studio 7 off the market without advance warning, Apple left in the lurch customers who had intended to upgrade to a newer version but need backward compatibility with our existing project files (me), and more importantly, people who have large companies and teams with many users of Final Cut Studio 7 and who need to buy more copies as they grow their companies (professional video editing firms).

Ironically, I was in the Apple Store last week and picked a Final Cut Studio 7 upgrade pack off the shelf, but I didn’t buy it because I knew that the new release was coming out this week, so I figured I’d upgrade directly and save some money and time. It didn’t even occur to me that Apple might release a new version of Final Cut without providing full backward compatibility with prior versions, or that Apple would do that and pull Final Cut Studio 7 upgrades off the market at the same time without warning. Had I known these two facts, I would have bought that Final Cut Studio 7 upgrade last week. I tried to today, and the Apple Store confirmed that the product has been discontinued and is no longer available in the store or online. So for the moment, I have no way to upgrade from Final Cut Studio 6 to a newer version, even though I want to do so and am happy to pay.

Consequences of Bad Product Transition Management for Apple

Because of these four basic errors in product transition management (especially the fourth), the release of Final Cut Pro X, instead of being an exciting release of a fresh, new product, has turned into a public relations disaster for Apple. Many online reviews of both the product and how Apple is managing the transition have ranged from highly critical to scathing. As DVCreators.net notes:

Articles like “Did Apple screw up with Final Cut Pro X?” and “The Final Cut Pro Backlash” are appearing by the hour. Even Fortune magazine has joined the fray, with “The Final Cut Pro X debacle“. Refunds are being processed as you read this sentence. At this writing, FCPX has a 2.5 star rating on the App Store …

An online petition demanding that Apple put Final Cut Studio 7 back on sale or sell the product to someone who went from 600 signatures at 2:35 p.m. EDT Monday to 4132 signatures at 4:20 p.m. EDT today. Apple has already announced that it will refund the purchase price of Final Cut Pro X for anyone who asks–a highly unusual step in a world of shrink-wrapped software installers, and to top it off, Final Cut Pro X has now been hilariously lampooned on the Conan O’Brien show. When even late-night comedians are making fun of your product, you know you’ve screwed up!

What Apple Needs to Do to End the Firestorm and Support Its Customers

Apple has already done the first thing it has to do. According to the person I talked to at the Apple Store, Apple has announced that a future version of Final Cut Pro X will support the ability to import projects created with Final Cut Studio 7. That’s a step in the right direction since it gives those of us with years of legacy content a forward migration path.

For project importing to work for all of its customers’ content, a future version of Final Cut Pro X will have to provide full backward content compatibility, which means supporting all of the content features that Final Cut Studio 7 did. I don’t know whether Apple is committing to full backward content compatibility, but it should. If not, it will be stranding those customers whose content depended on the features that are not carried forward. If it chooses to permanently drop some content features, it should continue selling and providing technical support for Final Cut Studio 7 for a much longer period of time than is customary since its customers will be forced to continue using it until and unless they can migrate their content to another supported tool that has the same features (a process that usually ranges somewhere from “painful, difficult, time-consuming, and expensive” to “cost-prohibitive” to “impossible.”)

Next, Apple should resume selling Final Cut Studio 7, in both “new” and “upgrade” packages, at least until a version of Final Cut Pro X is released with full backward content compatibility. That will enable individuals like me who need an upgrade path to have one and video editing firms that have standardized on Final Cut Studio and are adding staff to provide them the software they need during the transition period. (Because Final Cut Studio has network-wide license detection built in, installing extra unlicensed copies as a workaround for this bad set of decisions by Apple is not even technically possible, let alone legal!)

Rules for Product Transition Management

Learn from Apple’s mistakes on the launch of Final Cut Pro X.

• When you release a new version of a product, provide full backward compatibility with files and data created by previous versions of your product.
• If you release a new version without full backward compatibility, commit at the time of launch that you will provide full backward compatibility in a future release, and then do so promptly.
• If you permanently drop support for a product, feature, or especially for legacy customer-created files and data, provide plenty of advance notice, continue selling and supporting the product for a much longer period of time than is customary, and support affected customers in migrating to alternative, competing products if they choose to.

It’s not rocket science. It’s good product management. Apple, are you listening to your customers?

Or is it really that simple?

As a frequent flier myself, obviously I want my air traffic controllers to be well-rested, awake, and alert. But when they fall asleep on the job, are the individual air traffic controllers solely to blame? Of course not. It has now come to light that management has been scheduling the air traffic controllers in ways that are known to cause fatigue. So the story isn’t “Lazy, irresponsible air traffic controllers are falling asleep on the job.” It’s more like “Management is making humans work on schedules that scientific studies have shown cause fatigue. Humans are falling asleep as predicted by scientific studies.” Why are we even surprised? Air traffic controllers are human beings like the rest of us. Although they’re carefully selected and trained, they’re still subject to sleep-wake cycles, circadian rhythms, and fatigue like all other mortals.

In response to the public outcry, the Federal Aviation Administration is now taking steps to stop the use of work schedules that have been shown to cause fatigue. Why did they wait until highly-publicized incidents of controllers falling asleep to do this? Since they already had the studies in hand proving that certain work schedules cause fatigue, they could have proactively taken steps to eliminate those schedules instead of waiting and being reactive after a scandal.

There are two basic schools of management:

• dysfunctional school of management: Assume that humans can perform perfectly and consistently like machines. Design systems that require humans to perform perfectly and punish the humans when they fail.
• functional school of management: Learn what scientific studies have shown about human performance. Design systems that account and compensate for the known characteristics of human workers to the extent possible.

The dysfunctional school is guaranteed to fail. Worse, it creates incentives for the humans to hide their failings, preventing management from becoming aware of the problems in the first place and potentially leading to disastrous failures like plane crashes.

The fundamental problem was that management was requiring people to perform perfectly like machines (and expecting that they could and would) instead of accepting that humans are human and planning to account for human weakness and error. There are so many alternative approaches that could be used in this situation. For example:

• prevention: Avoid scheduling shifts in ways that increase fatigue and the risk of falling asleep.
• redundancy: Avoid scheduling controllers to work alone in the tower, so a second controller can notice and intervene or take over if the first falls asleep.
• monitoring and detection: Have the controllers wear devices that detect when they’re nodding off, or have their workstations detect that the human has fallen asleep. (Luxury cars now do this. Can’t we afford to do the same on air traffic control workstations?)
• intervention: Give pilots a way to use their existing equipment (such as setting their transponder to a particular frequency) to signal and cause a monitoring device in the air traffic control tower to sound an alarm that will wake up sleeping controllers.
• opt out: Permit controllers to “call in tired” a certain number of times per year without penalty. Staff with on-call backup coverage to make this possible.

Product managers can learn from this mistake. Don’t assume that your users will perform perfectly. Assume that they will get tired, busy, distracted, hurried, and interrupted. Assume that they will fail to read or understand messages, click the wrong button by mistake, and make every possible error under the sun. Then design your products accordingly. Give them a clearly-worded confirmation alert when they do a destructive data operation. Then, assume they will ignore or it click the wrong button and give your users ways to recover from mistakes. Save backup copies of their files so they can revert their changes. Move deleted files into a trash folder where they can recover them for a while if they delete something by mistake. And so on and so forth. Design for mortals and your users will love you. Design for gods and your users will hate you.

Product managers: your users are human beings, not machines. Design your products accordingly!

1. Does the company have revenue?
2. If not, does it have a credible plan for generating revenue?
3. Does the anticipated revenue support the current company valuation?
4. If not, does the company have value as an acquisition target to acquirers who can afford the company’s desired valuation? (For example, the product or technology may enable the acquirer to enter a new market quickly or increase the value and revenue of the acquirer’s other products. The acquirer may be able to increase revenue from the startup’s existing product via its greater size and sales and marketing power.)

If the answer to all four questions is “no,” then one of two things will happen: either the company will make changes to increase its anticipated revenue and/or value to an acquirer to match its valuation, or its valuation will decrease to match its anticipated revenue and/or value to an acquirer. The first scenario is more pleasant than the second!

Startups can save themselves a lot of time by asking themselves these four questions. These questions keep management and staff honest and avoid getting distracted by politics, personalities, power struggles, or boardroom and executive staff meeting drama. Note that “revenue” in this context is a broad goal that can be achieved by indirect means such as measures to increase reach and usage. LinkedIn grew into a very successful company by focusing in order on reach, usage, and revenue growth. Early focus on growth in reach and usage provided the foundation for later growth in revenue.

Product managers can save themselves time in product planning by focusing on these four questions. Everything you’re working on should in some way be contributing value to your product or the company as a whole. (Providing greater value to your customers is absolutely one way of doing that, of course!) If some of your activities seem to have no credible prospect of increasing revenue, cutting costs, or increasing the product’s or company’s value in other ways, ask yourself whether you should be doing those activities. Then ask whoever is making you do those activities!

Project managers can likewise save themselves time in project management by focusing on these questions. Projects are normally intended to increase revenue, cut costs, or do both. Project managers should continuously ask themselves whether the things they are doing (or are being asked to do) will likely increase revenues, cut costs, or achieve other specific targeted goals. If not, they should ask themselves whether they should be doing those activities!

Agile project management and Scrum make it easier to do this kind of ongoing evaluation of the usefulness of plans and activities and adjustment whenever needed because:

• Agile project management discourages companies from making monolithic long-pole commitments of resources that only provide value at the very end. When you’re working on individual user stories, each user story provides value, and each user story requires less than a sprint (or ideally a day) to implement, little or nothing will be lost if you change the next week’s or month’s planned activities at the next sprint planning meeting. User stories are independent, ideally, and the value of past user stories depends little or not at all on the implementation of user stories that may or may not come later.
• Scrum features regular sprint review meetings that provide a regular, scheduled opportunity to review the results and value of the most recent sprint’s activities. Therefore Scrum encourages self-awareness by the individual and the team and continuous evaluation of outcomes.
• Scrum also provides regular sprint commit meetings that provide a regular, scheduled opportunity to discuss what SHOULD be done next, regardless of what was done previously or what the team PREVIOUSLY thought should be done next.

Agile project management and Scrum therefore provide many more points during a project (the end and beginning of each sprint) at which it’s easy and natural to identify the need for changes and make those changes to future plans as needed. As intended, this encourages enterprises to be agile!

At a healthy, functional, well-managed company, people should be free to ask questions about the value and credibility of current plans and ongoing activities. If the plans and activities have value, people responsible for them should be able to easily and credibly demonstrate the actual or anticipated value with data or credible forecasts, and they should not feel threatened by being asked. They should welcome the interest and concern for the company’s future success and the opportunity to have their assumptions and progress reviewed and discussed.

Unfortunately, many companies are not healthy, functional, or well-managed, and many managers are insecure. Insecure managers discourage having their statements or assumptions questioned because they misinterpret questions as personal attacks on them instead of as healthy discussions about the company’s future. Insecure managers can create a toxic company culture that discourages open creative thinking and debate and is antithetical to the sprit and practice of Agile and Scrum. If you’re an insecure manager, get help so you can grow into a more secure, effective leader. If you have an insecure manager, unless you or others can persuade them of the need to change and they follow through on the work needed to change, either you’ll have to put up with irrational behavior driven by insecurity and the resulting inefficiencies, or you’ll have to find a new position working for a different manager!

As for twitter? They don’t currently seem to have a credible plan for generating enough revenue to support their current valuation. However, they have tens of millions of users and the opportunity to change that. Tweets provide a natural target for context-sensitive advertising. Google got rich through careful placement of context sensitive ads near content! twitter has been curiously slow to move forward on this opportunity. twitter needs to find a way to harvest that potential without alienating too much of their existing user base or creating a large enough incentive for users to jump to an alternative ad-free system after they make the changes. twitter also continues to be an attractive acquisition target to many companies with deep pockets. Therefore I’m not losing any sleep over the possibility that I’d wake up one day and no longer be able to tweet. The drama at twitter is really about how much money the founders, early investors, later investors, and common shareholders will get back, not whether the company will survive. I’m not losing any sleep over that!

• set up and configure a blog using WordPress
• search engine optimize (SEO) your web site and blog posts
• promote a blog or web site with twitter, RSS, and sharing icons
• make a video at low cost and publish it to YouTube and elsewhere
• video search engine optimization (VSEO)

Bob Sawyer kindly took notes which I have included below. Thanks to the sponsors and organizers of Silicon Valley Product Camp 2011 for putting together and managing a fantastic, educational, well-attended conference and to the attendees for great questions and feedback!

Product Camp 2011
April 2, 2011
eBay
Fireside AB
Session 4 – 2:30pm

Title: Social Media Marketing for the Lean Startup
Presenter Eric Krock, Co-Founder Voximate
Notes courtesy Bob Sawyer

Topics

Blogging
Why blogging: Raise awareness of your company, draw traffic, raise rank for organic search
Writing tips: (1) have someone proof read; (2) Read the post out loud
Wordpress
Customizing look of WordPress
URL best practices
Other WordPress configurations
Blog social media integration

Basics of SEO
Search engine optimization
Target keywords and key phrases
Where to use keywords. Are these in order of importance? Yes, more or less.
Avoid duplicate content
Put images in blog posts
Inbound link campaign
What about trackbacks? I don’t look at them much.

Twitter
Twitter tips
Twitter basics
Recommendation: Key is active, engaged followers, not just a large quantity of followers
Key twitter rules
Unofficial twitter good practices
How to find potential followers
Blog post and tweet sequence

Filming low-cost video
Filming low cost video: equipment
Teleprompter – free PC-based software is an option
Notes on filming video. Key: be agile about video

Youtube video search optimization
Video search engine optimization
More video tips

Facebook page
Facebook pages

Site and blog promotion tips

Questions:

Q1: How much time do you spend?
A: Too much. You have to decide how much time to spend.

Q2: WordPress spam. How are the spammers doing it?
A: I use akismet to prevent spam; it doesn’t have too many false positives.

• user stories, story points, and the the use of Fibonacci sequence values for story points
• release planning
• sprints, capacity, velocity, sprint commit meetings, sprint review meetings, and burndown charts
• the importance of returning the product to a potentially shippable state at the end of each sprint to reduce the accumulation of technical debt and keep the assessment of project progress realistic
• the roles in Scrum of the Product Owner (who writes or facilitates the writing by customers of user stories), the ScrumMaster (who manages the Scrum), and the Team (who do the work)
• daily standup meeting in which people share what they did yesterday, what they’re doing today, and any blocking issues they’re encountering
• a few key values in Agile
• common problems with waterfall project management including a serialized process, longer time to market, isolation of developers from customer needs, plans falling out of synch with reality, lack of visibility into rate of progress, features being slashed late in the development cycle to bring in release dates, long time to project completion, late feedback from customers, projects falling behind schedule, and projects missing their market window or being killed before launch
• problems with monolithic product requirements documents including length, lack of readability, disconnection from customer needs, and lack of clarity about which features are for which customers
• a list of books and web sites by Mike Cohn, Kent Beck, and others to learn more

David Barkovic kindly took notes which I have included below. Thanks to the sponsors and organizers for putting together and managing a fantastic, educational, well-attended conference and to the attendees for great, brief, on-topic comments and questions throughout!

Introduction to Agile Product Management

Presenter: Eric Krock, Voximate

Notes thanks to David Barkovic (with minor clarifications of intent by Eric)

Issues with waterfall include finding out too late that you’re too late.

PRDs get you sucked in your “self-assumed brilliance about what the market needs.”

Must understand the goal of the user as part of the user story.

As a (user), I must/want/wish to. This is equivalent to the ubiquitous P1, P2, P3 prioritization labels.

Story points are an abstract measure of *relative* effort. Story A is about 3x the effort than that of story B.

Fine grained prioritization mechanisms (ex. On a scale of 1-100…) can imply false precision. Many folks use the Fibonacci sequence to help avoid that.

You do actual time estimates when you create tasks.

No partial credit. You get the points only when the story is complete.

There’s a bit of a debate in the Agile community on whether defects should be tracked with points. There’s also the more general problem of non-story work.

Even if you don’t track issues using points, the velocity will eventually take into account the average number of distractions since they reduce the velocity. On the other hand, tracking issues via points will give you insight into the amount of resources required for the work on issues rather than new feature development.

Eric recommends Mike Cohn’s book – User Stories Applied. Same goes for Mike’s other books.

You’re always doing something for someone. The stories need to be clear on who that is. This includes both internal and external stakeholders. “As an engineer, need to refactor the codebase in order to…”

At the end of each sprint, you must return the product to a working state. That’s how you know you got the work done. Avoids the hidden step backwards when you’re trying to move forward.

Scrum managers are typically the engineering managers.

Difficulty with keeping the daily stand-up meeting to 15 minutes. Take problem discussions offline and keep the discussion to what each person is working on.

Product owner always participates in the daily scrum. This is much easier provided you can keep the meeting short.

Need test driven development – automated tests. If you’re doing manual testing, you wont be able to do get the product back to a reliable state after a one week or two week sprint.

Don’t really know the requirements of the foundational work until you develop the features. All the work should culminate in a feature of the product. This is depth first development, rather than breadth first development typically seen with waterfall projects.

The user story is the basis of a conversation on the actual development. It is not the spec. The goal of the user story is to get engineering to talk with product management.

Engineers update sprint burn-down charts every day.

Wireframes should be managed as a task derived from a user story. With that said, a wireframe could span multiple stories.

Two week sprints may be a good sweetspot for most organizations. One week sprints are typically better for small teams.

Do a three to five week moving average to get your velocity for the release.

Ideally, Product Owners should not be doing even tentative assignments of user stories to sprints more than three sprints out. Any more than that may lead to wasted effort as priorities change.

Eric recommends not having a single backlog. Should split the high-level stories or epics into multiple categories such as current release, next release, future. This avoids cluttering your collection of near-term stories with things you’re not going to touch for a really long time.

“Nothing is impossible. It’s just difficult and painful.”

Anticipate and Manage Product Problems Before They Happen

A recent New York Times article on the Fukushima disaster contains a remarkable statement that tragically illustrates the problem of doing product and project planning based only on events that have happened already:

“We can only work on precedent, and there was no precedent,” said Tsuneo Futami, a former Tokyo Electric nuclear engineer who was the director of Fukushima Daiichi in the late 1990s. “When I headed the plant, the thought of a tsunami never crossed my mind.”

“We can only work on precedent?” Nonsense! How about using your imagination to envision things that haven’t yet happened? That’s what imagination is for!

What kind of precedent were the executives at Tepco waiting for? And how could the possibility of a tsunami not cross their mind? As the article notes, in 1993, an earthquake generated a 30-foot tsunami that wiped out a coastal village completely. I was living in Japan at the time, and like everyone else, I watched the footage of the devastated town on TV. Wasn’t that precedent enough? Or were Fukushima executives and regulators incapable of imagining that the same thing, or something even worse, might happen in a different location such as Fukushima? After all, they were warned two years ago that a massive tsunami had hit the very location of the Fukushima reactor in 869 A.D. Or did they need the precedent of a tsunami hitting a nuclear reactor before they would think of evaluating the effect that such an event might have on the particular nuclear reactor they were responsible for? Apparently so. Now all of Japan is suffering the consequences for Tepco’s failure of imagination in threat analysis.

Don’t Just Study Past Product Problems. Imagine Possible New Product Problems!

Narrowness of thinking can endanger any product or project. You don’t have to wait for a problem to occur before you take steps to creatively envision possible problems and prevent them or mitigate the damage they might cause. But if you believe that “we can only work on precedent,” you will fail to imagine possible threats with an open mind and proactively work to address them. A person who believes that “we can only work on precedent” will fail to shut their barn door if they’ve never had a horse run away. They’ll fail to secure their servers if they’ve never been hacked. They’ll fail to monitor a project’s progress if they’ve never fallen behind schedule. If you live life by looking only in the rear-view mirror and dealing with cars that have already passed you by, you’re guaranteed to have a painful and potentially fatal crash with a previously-unseen car that lies somewhere ahead of you.

Periodically Review and Question Your Assumptions

Psychological research has shown that once humans have reached an initial working hypothesis or conclusion, they tend to assign higher weight to evidence that supports their existing conclusion and lower weight to evidence that contradicts it. This well-documented behavior is both irrational and dangerous. Evidence should be weighted according to its objective credibility and relevance, not by how well it matches our current beliefs. Tepco displayed this behavior in abundance. As Greg S. Hardy, a structural engineer, notes in the article:

“Once they made the proclamation that this was the maximum earthquake, they had a hard time re-evaluating that as new data came in.”

When You Change Assumptions, Think Through All the Possible Effects

The same excellent article illustrates another failure by Tepco to be even minimally forward-thinking:

After an advisory group issued nonbinding recommendations in 2002, Tokyo Electric Power Company, the plant owner and Japan’s biggest utility, raised its maximum projected tsunami at Fukushima Daiichi to between 17.7 and 18.7 feet — considerably higher than the 13-foot-high bluff [that the reactor was built on]. Yet the company appeared to respond only by raising the level of an electric pump near the coast by 8 inches, presumably to protect it from high water, regulators said.

Great! They updated their assumptions to increase the height of the maximum projected tsunami. But did they use computer software to simulate the result that such a tsunami would have? Did they even draw a whiteboard diagram of the nuclear reactor with the sea level raised by 18.7 feet and discuss how the reactor would respond? Apparently not. Now Japan is desperately struggling to manage the consequences of Tepco’s poor product planning and risk management.

Do Probabilistic Risk Analysis, Not Deterministic Risk Analysis

How did Tepco decide that the “maximum projected tsunami” at Fukushima could have a height of no more than 18.7 feet? Is there some law of physics that says that at Fukushima, it is physically impossible for a tsunami higher than 18.7 feet to occur? Of course not. Tepco’s fundamental mistake was to project a “maximum projected tsunami,” evaluate only the effects of that tsunami and smaller ones, and stop thinking there. They apparently didn’t consider the possibility that there might be an 18.8-foot tsunami. Or an 18.9-foot tsunami. Or a 30-foot tsunami like the one that hit Japan in 1993. Or a 70-foot tsunami like the one that hit Indonesia in 2004. Or the 46-foot tsunami that ultimately struck Fukushima this year. When 30- and 70-foot tsunamis have hit other locations during the last 20 years, it doesn’t take brilliant insight to realize that a tsunami of that size might hit the coast-side nuclear reactor you’re responsible for managing.

As the New York Times article notes, Tepco should have done probabilistic risk analysis. They should have looked at a curve of possibilities with a high-probability 1-foot tsunami at the left end of the axis and a low-probability 70- or 100-foot tsunami at the other end of the axis. Then, they should have modeled the behavior of the reactor at multiple points along that axis, looked at where unacceptable outcomes (like the current situation) began to occur, calculated the total probability that an unacceptable outcome might occur by adding the probabilities there and at each point beyond on the axis, and then looked at what steps they could take to reduce the probability of an unacceptable outcome. (Like having at least one backup generator located somewhere up a hill, for example!)

Recognize That Your Ability to Predict the Future Is Imperfect!

Even if Tepco executives had never thought of the possibility that their projections of the future might be wrong, Mother Nature helpfully proved that fact to them four years ago. The same article notes that in 2007, an earthquake hit their Kashiwazaki nuclear reactor that was 2.5 times larger than the largest earthquake the reactor’s design guidelines had envisioned. When that happened, someone at Tepco should have said “Hey, if we were wrong about the maximum possible earthquake size at Kashiwazaki, could we be wrong about the maximum possible tsunami size at Fukushima?” Humility, an awareness and acknowledgement of one’s own past errors, and an attempt to learn from them and improve are critical for long-term, repeatable success in product and project management.

Account for the Unknown

In yet another disastrous oversight, Tepco modeled the largest earthquake that known faults in the area could produce, yet they apparently didn’t consider the possibility that a currently-unknown fault could produce a larger earthquake, and therefore a larger tsunami! It’s a well-known fact, even among laypeople who have simply read a newspaper in the last 20 years, that we don’t have a complete list of every fault on the planet. Human knowledge in nearly all domains is known to be incomplete and imperfect. In particular, previously-unknown faults are discovered all the time when they first generate an earthquake! Therefore, anyone doing seismic planning has to consider the possibility that their installation may be affected by an earthquake on a fault whose existence is yet unknown.

For example, Tepco executives have almost certainly heard of the magnitude 6.9 Loma Prieta earthquake that struck Northern California in 1989 and got worldwide publicity. The Loma Prieta earthquake was caused by a previously-unknown fault in one of the most intensively seismically-studied regions in the world. Since a previously-unknown fault generated a large earthquake in the United States, someone at Tepco should have realized that “Hey, if there are faults we don’t know about in North America, maybe there are faults we don’t know about in Japan too! It’s on the very same tectonic plate after all! If faults we don’t know about can generate significant quakes in North America, maybe they can do that in Japan too! And if an unknown fault can generate a significant quake, maybe it can generate a significant tsunami too!”

Cultivate Cassandras

Another striking thing about this sequence of events is that so far, there’s no evidence that someone anywhere inside Tepco was sounding the alarm about all these risks that required no specialized knowledge to recognize. Maybe there were such people and we haven’t heard about them yet. In his book Only the Paranoid Survive, Andy Grove notes that every organization has “Cassandras” who sound the alarm about risks that others are ignoring. To reduce the risk of a disaster, reward and cultivate the Cassandras in your own organization. You don’t even have to reward them financially. Reward them by listening to them and taking them seriously!

Product and Project Managers Must Manage Risk Proactively

Don’t be the next Tepco. Use your imagination. Think creatively with an open mind. Fertilize your thinking with diverse sources of information. Envision problems that could happen with your product or project before they happen. Develop a list of all the bad things that could happen and estimate the probability of each one. Review your assumptions and projections periodically and whenever you learn new information. Then ask yourself what you can do to reduce the possibility of bad events or to reduce the severity of the effects they will have.

AirportParkingReservations.com, this means you! The last time this site made me pick a password, it required me to use uppercase letters, lowercase letters, and numbers. So far, so good. But it wouldn’t let me use punctuation characters. That’s bad! Including punctuation characters in your passwords makes them much harder to guess. Blocking the use of punctuation characters in your own site’s passwords has two bad effects: (1) users of your site will be forced to choose passwords that lack punctuation characters and may therefore be easier to guess, and (2) users will be discouraged from using punctuation characters in their passwords in general when they discover that some poorly-designed sites block their use, which may reduce password quality at other sites too.

One reason that AirportParkingReservations.com gets away with this poor policy is that they’re not a very interesting target for hackers to attack. If a hacker does manage to break into someone’s account, the worst they can do is make a bunch of bogus parking reservations in a person’s name and pay with their stored credit card information–bogus charges that will likely be refunded upon request if the user notices them. Only a truly bored hacker would try to be the first to do this. But if your web site holds personal, financial, or other highly confidential information, you should permit stronger passwords.

Remember these basic rules:

• If your web site does any quality checking on passwords at all, it should allow the use of lowercase characters, uppercase characters, numbers, and punctuation characters so users are able to create maximally complex passwords.
• Your site should require some reasonable minimum password length.
• You may mandate the use of various combinations of characters (e.g. at least one lowercase and uppercase alphabetic character and one number). Personally, I’m reluctant to micromanage password complexity rules too much because you may interfere with a perfectly valid user password creation scheme that uses some kinds of characters but not others. Requiring characters from at least three of the four categories of uppercase letters, lowercase letters, numbers, and punctuation characters would be a good approach that would enforce significant password complexity without forcing users to use all four categories.
• If you can afford to, it’s even better to run automatic password-cracking software that will try to detect poor quality passwords so you can warn or force users to change truly stupid passwords such as “password,” their user name, their first or last name, and so on.

For an end user faced with the need to generate and remember hard passwords for every site on the planet, LastPass is a good solution. Increased adoption of OpenID by web sites over time will be even more helpful by enabling users to use a single credential to log in more places.

Incidentally, I tried to verify tonight that AirportParkingReservations.com still doesn’t allow the use of punctuation characters in passwords, but after logging in, I couldn’t even find a way to change my password. Clicking “My Account” didn’t do it. Additional points off for poor usability! Ironically, the necessary link to change the password appears to be hidden by a “McAfee SECURE” image that’s accidentally been positioned on top of it. This is true on the Mac in Safari, Chrome, and Firefox, so it’s not an isolated browser-specific glitch. Additional marks off for bad user interface design and poor quality assurance. No matter what McAfee says, your site isn’t very secure if you obstruct your users from picking strong passwords and block users from updating their passwords at will!

Critical Assets Need Consistent Protection, Not Inconsistent Protection

As the world has just been reminded, during a reactor meltdown event, the nuclear reactor’s containment vessel is supposed to keep the highly radioactive fuel safely separated from the outside world. The containment vessels are some of the toughest objects ever constructed by mankind. They’re designed to withstand earthquakes, the impact of a jet airplane, and the heat and pressure created inside them by a nuclear reactor experiencing an uncontrolled meltdown event. But the containment vessel won’t protect you from the radioactive fuel rods if you take the fuel rods out of the containment vessel, and that’s exactly what Japanese reactor operators have been doing during maintenance as a standard practice! The Wall Street Journal reports:

At the time of the quake, Reactor 4 was offline and not generating power amid annual maintenance. As part of that, five months ago Tepco relocated all the fuel rods—the heavy tubes that contain radioactive fuel pellets—from inside the reactor to what’s called a spent-fuel pool, a concrete holding tank that is less robustly protected than the reactor itself …. The events at Reactor 4 expose the risk of a commonplace practice in Japan, “full core discharge,” in which all the fuel in a reactor is moved during maintenance shutdowns …. In the U.S., reactors shut down for refueling typically retain most of their fuel in the thick steel reactor pressure vessel that provides much more protection against a radioactive release.

Saying that the spent-fuel pool is “less robustly protected than the reactor itself” is a considerable understatement. The containment vessel around the reactor is a steel and concrete structure designed to withstand some of the most intense stresses known to man. The spent-fuel pool at Fukushima is outside that containment vessel, separated from the outside world only by a thin outer wall of the building that is intended to keep the weather out and to burst outward to relieve pressure on the containment vessel if an explosion happens in the building. Essentially, it’s a concrete swimming pool in a drywall building kept cool by water being pumped in, and Japanese reactor operators have been storing the “live” nuclear fuel rods (not just the less-radioactive “spent” fuel rods) in that pool for extended periods during regular maintenance.

During the design of a nuclear reactor, enormous attention is paid to the design of the containment vessel and its ability to withstand every possible adverse event and extreme circumstance. The reactor’s designers, the utility, and government regulators will all minutely scrutinize the design and evaluate its expected performance under all kinds of dire situations. Why? Because they’re relying on the containment vessel to protect us from the highly radioactive “live” fuel rods.

There’s a basic contradiction here. If the “live” fuel rods are so dangerous that a containment vessel is necessary, why is it OK to take the “live” fuel rods out and store them what amounts to a swimming pool in a shed? Conversely, if it’s safe to store “live” fuel rods in a swimming pool in a shed, why is the containment vessel necessary in the first place?

Flawed Assumptions Create Disastrous Results

Essentially, the Japanese reactor operators and regulators assumed that a problem was most likely to occur within the reactor core, so robust protection was necessary there but not elsewhere. They assumed that problems wouldn’t occur with the “live” fuel rods stored in the so-called “spent-fuel pool.” (The name itself is misleading and highlights the contraction. It’s not a “spent-fuel pool” if you’re storing live fuel in it! Misleading names can contribute to poor thinking about product risks by masking contradictions.) They assumed that the pool would always be full of water and that therefore the “live” fuel rods stored within it wouldn’t overheat. Recent events have shown how wrong all those assumptions were, and Tepco was forced to admit that it was possible that the “live” fuel in the pool might go critical (restart the fission chain reaction that’s only supposed to occur inside the nuclear reactor) if the water boiled away and the fuel rods melted and congealed at the bottom of the pool. Put simply, thanks to the practice of removing “live” fuel rods from the reactor during maintenance, it became possible that a crude nuclear reactor might spontaneously form and start itself up at the bottom of what amounts to an unshielded outdoor swimming pool–a possibility that only heroic acts by Japanese nuclear workers risking their lives may yet narrowly avert.

Conflicting Goals for Product Safety and Security

How could the very same regulators require so much protection around the “live” fuel rods when they were inside the nuclear reactor and so little when the nuclear reactor was being serviced? It appears that they were optimizing for different aspects of safety in the two situations. When analyzing the strength of the containment vessel, they were trying to protect the public from exposure to radiation during a nuclear reactor meltdown event. But when allowing the “live” fuel rods to be removed from the reactor and stored in an unshielded pool, the Journal notes that the utility, no doubt with regulator knowledge and approval, was attempting to limit the exposure of workers to radiation during reactor maintenance:

“The Japanese argue it’s safer to move all the fuel to the pool, but the practice of full-core discharge caused a problem, in this case,” said Andy Kadak, a former professor of nuclear engineering at Massachusetts Institute of Technology, who has studied fuel handling for Tepco. Mr. Kadak said the Japanese feel the pools are safer because all the fuel is kept in a neutralized space, removed from workers.

Of course, the fact that the reactor was being serviced didn’t reduce the danger posed to the public by the “live” fuel rods at all. “Live” fuel rods don’t care whether they’re inside a reactor core or sitting in a swimming pool. They’re equally radioactive and equally dangerous at all times, and as any of the workers currently risking their lives at Fukushima will attest, the practice of “full core discharge” that was intended to reduce their exposure to radiation has now backfired, increased their risk and lifetime radiation exposure exponentially, and forced the regulators to increase the amount of radiation workers are permitted to be exposed to by 150%.

High Technology Security in Theory and in Practice

This kind of problem occurs with the security and safety of high-technology products in less dramatic ways all the time. People assume that passwords will prevent hackers from accessing their systems, but then they use short, low-quality passwords that can easily be guessed. They hire a reputable professional archiving firm to securely transport their backup tapes to a secure storage facility, then they assume the truck driver won’t remove and misplace the backup tape during a stop along the way, so they don’t encrypt the data on the tape. (That was the first way I had an employer lose my identity.) They assume that key card access controls and secure networks will protect confidential information, but then a human resources employee takes plain text files with social security numbers out of the office on a laptop that is then stolen out of their car. (That was the second way I had an employer lose my identity. I’m lucky that way!) The same behavioral problem comes up in public health as well. HIV prevention educators note that “It’s usually the person that fails, not the condom that fails.”

Product managers, project managers, and IT managers can help prevent this kind of problem by fighting for consistent safety and security standards for assets at all times. Watch out for contradictions. Flag, escalate, and resolve them. Don’t make the mistake of applying different security or safety standards to the same critical asset at different times based on convenience. If an asset is critical, it needs to be consistently protected, not inconsistently protected. Just ask the workers at Fukushima!

A friend who has de facto product management responsibility for a physical product manufactured on an assembly line recently told me the following story that reminded me of this lesson:

We discovered that one unit wasn’t working correctly. The unit would have to be scrapped, which was an expensive proposition. An executive and I went down on to the shop floor to investigate. The executive expressed concern about the expense posed by this problem. I commented that we’d never seen this problem before and I’d get working on it immediately. At this point, the manufacturing technician spoke up. “Actually, we’ve seen this happen once or twice before.” (SOUND OF SILENCE)

Needless to say, this conversation led to conversations with team members later on about the importance of getting problems entered into the bug reporting system promptly. The product manager thought the company had never seen the problem before because there was no record of this problem in the bug reporting system. But the bug reporting system wasn’t accurately reflecting reality because no one had entered this particular problem into the system. As a result, the product manager was blindsided and found out about the problem for the first time in front of an executive.

Nobody likes unpleasant surprises. When you start working with a product team for the first time, emphasize to everyone the problem of promptly entering problems into the bug reporting system as soon as they are discovered. Reiterate this lesson from time to time, particularly if the team gets blindsided by a problem that was known but not reported. Situations like that are (tactfully) teachable moments.

People sometimes hesitate to enter a problem into the system because they don’t fully understand it. That’s a dangerous mistake. It’s much better to have an incomplete bug report in the system than to have a bug reporting system with an incomplete list of the known problems.

• A bug report with incomplete information is a call to action. People will read it, recognize that a problem exists but is not fully understood, and know that they need to assign someone to research the problem further until it’s fully understood and can be prioritized correctly.
• A problem that exists without any record in the bug reporting system is an invisible monster lurking under the bed. You can’t see it, and you don’t know it’s there, but it can jump out and surprise you at any time.

Make a pre-emptive strike against invisible monsters under the bed. Train your team to report bugs immediately!

For the next six years, workers showed up each day at the Fukushima nuclear reactor. Japan is famously prone to earthquakes and tsunamis. The reactor is by the coastline. It needs continuous electrically powered cooling to prevent a meltdown. All of its backup generators were below ground, and its protective sea walls were apparently far less than seventy feet high. (Plus, as FishOutOfWater notes, tsunamis of a given height can overcome sea walls of the same or greater height because the incoming water piles up behind the sea walls and then rushes over them.)

Yet apparently, no one asked the question “Hey, what happens if WE get hit with a seventy foot high tsunami?” Or if someone asked the question, it wasn’t acted on. Why? Easy. Everyone had an explicit or implicit economic incentive to keep their mouth shut. People are generally promoted and rewarded based on meeting or exceeding their current work targets, cutting costs, and increasing profits. All of this is based on short-term metrics, and hypothetical high-impact scenarios with a perceived low probability of occurring aren’t factored in at all.

People are rarely rewarded for asking difficult questions with expensive answers. Employees are rarely rewarded for asking or pursuing hypothetical questions about bad things that may or may not happen when it would cost tens or hundreds of millions of dollars to guard against those hypothetical scenarios. Workers would likely not be rewarded for asking their managers about tsunamis. Managers would not be rewarded for asking these questions or escalating them to executives. Executives would not be rewarded for asking these questions or proposing to spend hundreds of millions of dollars to address what would likely be dismissed as an unlikely, hypothetical, worst-case scenario. The regulatory authorities, seeing nuclear power as the only viable answer to Japan’s lack of natural resources, may have wished to avoid raising uncomfortable questions about the risks their current infrastructure might be posing.

So even though seventy foot high waves had dramatically killed 250,000 people just a few thousand miles to the south, apparently no one at Tokyo Electric Power Company or in the Japanese government regulatory agencies asked or pursued any of the following fairly obvious questions:

• “The Fukushima reactor facility was designed in the late sixties based on what was known at the time. Should we review any of our design assumptions based on new things that have been learned since the late sixties?”
• “We only designed the Fukushima reactor to survive a magnitude 8.2 earthquake. If a magnitude 9.1 earthquake happened in Indonesia, could it happen in Japan?”
• “The earthquake in Indonesia produced tsunami waves at least 70 feet high. Could we experience tsunami waves that high at Fukushima?”
• “What happens to the Fukushima nuclear reactor complex if it gets hit by tsunami waves that are 70 feet high?” (Or even just 20 feet high, as apparently happened in this incident.)
• “If the Fukushima nuclear reactor complex is hit by a tsunami with high waves, what will happen to the backup power generators that are located underground? Water flows downhill, right?”
• “If the nuclear reactors lose all of their backup power, what will happen to the reactor cores?”
• “Should we do something to ensure that our facility will still have backup power even if it’s hit by a large tsunami? For example, should we build an extra backup power generator or two up on a hill somewhere?”
• “The spent fuel rods need to be kept continuously submerged and cooled with fresh water to prevent them from melting or catching fire. Is it really a good idea to be storing our spent fuel rods within the reactor buildings in pools that are above the reactors themselves, since the pools’ integrity could be compromised if something goes seriously wrong with the reactor? If there’s a serious problem with one of the reactor cores, do we want to be raising the stakes by pre-positioning radioactive time bombs directly above them? What might happen to those pools if there’s a hydrogen explosion at our reactor as occurred in the Three Mile Island incident?”

Addressing the problems raised by the last two questions might have cost hundreds of millions of dollars or more, perhaps even a few billion dollars. Tokyo Electric Power might have had to build new backup diesel generator buildings on hills at some distance away and provide secure underground power connections between them and the main facility. It also might have had to construct a separate building to hold pools for cooling the spent nuclear fuel rods and arrange to carefully move spent fuel rods out of the reactor buildings and into that building. It would have greater operating costs due to the expense of moving spent fuel rods from building to building. None of that is cheap.

But all of those costs are infinitesimal compared to the massive costs that are going to be incurred by Tokyo Electric Power and the Japanese government based just on cleanups of the partial meltdowns that have occurred already, let alone the costs that may be incurred if all of the reactors and all of their spent fuel rods melt down and fuel rod fires outside the containment vessels spew long-lived Cesium 137 in all directions, as now appears distinctly possible. Cesium 137 has a half life of 30 years. How do you put a price tag on the cost of potentially turning hundreds of square miles of central Japan into radioactive wastelands that may have to be abandoned by humans for the next hundred years or more?

Asking difficult questions and pushing to get them answered requires that you combat institutional financial incentives against asking or pursuing these questions. Managers don’t want to be bothered with unpleasant hypothetical questions. Finance doesn’t want to allocate funds to investigate such questions or implement preventive measures. In a dysfunctional company, employees may be passed over for promotion, disciplined, laid off, or even fired if they do this. Asking and pursuing difficult questions requires either supportive, far-sighted management or a fatalistic attitude about your own career: “I’m going to get this fixed or get fired trying.” If you’re fatalistic enough, you win either way. Either you make the right thing happen, or you get fired from a dysfunctional company before something really bad happens and you move on to find a better-managed, more supportive environment.

I’ve made a practice through my career of asking and pursuing difficult questions. (Fortunately, none of them have involved questions of life, death, or radioactive contamination.) It hasn’t made me popular, but it’s led to useful outcomes. Here are a few examples:

• “We’re encouraging customers to build custom applications with our proprietary user interface, but our next generation product will have an incompatible standard user interface. Isn’t this a problem?” (In this case, I developed a framework for easing the migration path.)
• “Setting up new applications is a pain. Can’t we make it easier?” (I ultimately wrote a tool that automated the process that later became a part of the standard product.)
• “Building web sites that work on multiple browsers is a pain. Shouldn’t we make it easier?” (In this case, I developed training materials that explained how to write cross-browser applications and later focused company resources to improve standards compliance and arranged to implement an extra compatibility extension or two.)
• “We’re able to develop custom client user interfaces for different customers, but if a single end user installs clients from different customers, they conflict. Shouldn’t we fix this?” (I ultimately got approval for major investment to enable the separate custom clients to smoothly coexist.)
• “Will enterprise customers be willing to deploy our next-generation client if it includes that known but approved potential security exploit?” (I scrapped the product road map and delayed the client’s release date by six months to get the problem resolved.)
• “We always seem to be out of space and power in our data centers. What’s our current capacity utilization rate and what should it be ideally?” (This highlighted the fact that the company had fallen a bit behind on data center investment and needed to catch up.)

Learn the lesson of Fukushima. Ask the hard questions, and pursue them wherever they may lead!

Which is more likely to kill you: the skin cancer that causes a visible growing mole very early on, or the stomach cancer that grows silently in your belly with no symptoms until it’s too late? Stomach cancer of course. As of 2002, stomach cancer, which is often asymptomatic for a long time, had a five-year survival rate of 24%, whereas melanoma had a five-year survival rate of 89%. The same is true in product and project management. It’s the big risks with no symptoms today that are most likely to kill you.

We discussed risk management, disaster prevention, and the problem of high impact, low-probability events previously in reference to the BP oil spill and the PG&E San Bruno natural gas pipeline explosions. The Fukushima nuclear reactor crisis, which we discussed yesterday as an example of how failover systems need to be truly redundant, is providing a couple of dramatic examples of the problem for the entire world to see:

• For the entire forty-year period since it started operation in 1971, the Fukushima nuclear reactor has been vulnerable to the risk that a large earthquake causing a tsunami high enough to overtop its sea walls would shut down the reactor, cut off backup power from the grid, and shut down all the backup generators simultaneously, leaving the reactor with insufficient power to cool down the reactors and prevent a partial or complete meltdown. But any given day or year, this low-probability, high-impact potential risk was not causing immediate problems, so the risk was neither focused on nor resolved, even after the 2004 tsunami in Indonesia demonstrated the possibility of tsunami waves up to 80 feet high. Mother nature gave us an advance warning, and we ignored it!
• Similarly, for many years, that reactor has been storing spent nuclear fuel in a cooling pool within the reactor building itself. Storing spent fuel in the reactor bulding created a risk that if the reactor lost cooling, the water in the cooling pool could boil and evaporate, which in turn might cause the spent nuclear fuel to catch fire and burn at a high temperature, injecting dangerous, long-lasting radioactive isotopes into the atmosphere. As the New York Times article notes, a fire in spent nuclear fuel would disperse dangerous, high-level, long-lived radioisotopes like cesium 137 far more widely than a reactor core meltdown because the spent nuclear fuel is sitting unprotected and unisolated within an ordinary, weak building structure (two of which have already blown their tops off, as designed, when pressure built up), not inside the strong, pressurized containment vessel that is supposed to securely isolate the reactor core, even during a meltdown, from the outside environment. (Incidentally, the pressurized containment vessel in reactor two may have been breached by an internal explosion, so we may not be able to place confidence in that either. This situation just keeps getting worse.)

There are many tragic ironies in this story. I’m sure that the reactor buildings and office interior walls were kept well-painted for the last forty years, for example. Old or chipping paint is clearly visible to the naked eye. It causes an immediate cosmetic problem, so it gets addressed and resolved in a timely fashion. But the fact that the reactor might melt down after a tsunami, or that spent fuel stored in a cooling pond might catch fire and spread for many miles, received no attention. Trivial problems with low impact that are causing a symptom today get fixed promptly, while potential problems that may cause a catastrophe down the road but have no symptoms today get ignored, particularly if addressing those problems would have high costs. This illustrates a fundamental, recurring problem in human evaluation and management of risks. We tend to respond to what we can see or feel today, not to what is objectively speaking most important to our welfare in the long run. We react to what’s urgent, not to what’s important.

The ways that the United States and Japan are currently handling spent nuclear fuel also illustrates what a poor job individuals and nations as a whole do of rationally comparing and responding to relative risks. In the United States, environmentalists have been raising concerns and filing lawsuits about potential risks that might be caused by spent nuclear fuel that has been reprocessed into a comparably stable form and stored in underground caverns, requiring only passive cooling provided by thermal radiation and natural air circulation. The United States government recently cancelled plans to move forward on using the Yucca Mountain storage facility, leaving the United States with no plan in place whatsoever for long-term storage of spent nuclear fuel. Reprocessed spent nuclear fuel in that location may indeed pose some small risks in the long term. But whatever risks those are, they pale in comparison to the immediate risk posed by un-reprocessed spent nuclear fuel stored in reactor cooling ponds near major population centers. Partial reprocessing of the waste for temporary dry cask storage, as the United States is currently doing, is an intermediate option. It reduces risk by eliminating the need for continuous immersion in water and enables us to continue debating, procrastinating on, or researching a long-term solution for as long as we’re willing to keep constructing and storing dry casks and incurring the costs and risks this creates. Since dry casks are often stored in the open where they are exposed to the elements and potential terrorist attack, these annual costs and risks almost certainly exceed those that would be posed by remote underground storage. The only possible rational justification for choosing dry cask storage for decades to come is the possibility that new technology might create a better way to use or reprocess this fuel in the future. Although that might happen, it also might not happen. Even if it does happen, the United States incurs significant dry cask storage costs, legal costs, and annual penalty payments to nuclear power operators for the foreseeable future, and it means that the pursuit and insistence on a hypothetical and possibly unattainable perfect is becoming the enemy of an immediately-attainable better. The management of complex, uncertain long-term risks in a democracy can be messy, inefficient, and costly, and optimal outcomes are not assured.

This kind of problem occurs in less dramatic fashion every day in ordinary product management. Given average quality product management, the squeaky wheel will get the grease, not the wheel that is silently grinding and about to fail catastrophically.

• If your product’s user interface has a non-optimal color scheme, it’s not likely to kill you, but people will see the problem every day, some fraction of the people will complain about it, the product manager will get tired of hearing the complaints, and resources will be assigned to fix the problem in a timely fashion.
• If on the other hand your product architecture has a silent security flaw, such as transmitting and storing credit card numbers in unencrypted form making them easier for hackers to intercept and use, that security flaw probably won’t create any actual pain on a daily basis, so it’s easy for everyone to ignore and avoid investing resources in resolving the risk. But when hackers manage to access that data, as happened to Heartland Payment Systems, suddenly you have a massive security breach, massive negative press, massive costs associated with resolving the damage caused by the breach, and you wind up spending the money to prevent future breaches anyway. If you’d spent the money on good security up front, you would have spent no more on total security, but you would have saved all the costs associated with the breach ever occurring. It’s cheaper to prevent problems than to handle them when they occur.

When doing product or project management, pay special attention to big potential risks that are causing no symptoms today. It is these risks that you’re most likely to underinvest in addressing and therefore these risks that are most likely to cause big problems in the future.

For further reading:

• eHow article on Safety & Security of Commercial Spent Nuclear Fuel Storage
• Wikipedia articles on radioactive waste, spent fuel pool, and dry cask storage

According to CNN’s television coverage, the nuclear reactors at Fukushima shut down as designed when the earthquake hit. However, even after you shut down a nuclear reactor of that design, you have to keep actively cooling it for a long time to avoid a meltdown due to the residual heat in the core. These reactors had several available backup sources of power to run the active cooling systems: the national electrical grid, thirteen backup diesel generators; and backup batteries that last for eight hours.

Unfortunately, the combination of the earthquake and tsunami cut off power from the electrical grid and caused all thirteen backup generators to fail about an hour after the earthquake, apparently because they were hit at that time by the tsunami. This left the nuclear reactors with only eight hours of power available to them from the batteries, which isn’t enough time for the reactors to cool down to a safe temperature. Now there’s a “strong possibility” that reactors one and three have experienced partial meltdowns, and the utility has resorted to flooding some portion of those reactors with raw seawater and boron in a last-ditch effort to prevent the situation from getting worse. This morning, reactor number two temporarily had its cooling pump fail and had its fuel rods fully exposed for thirty minutes, meaning it may have suffered a partial meltdown as well.

We need to be fair to Japan and Tokyo Electric Power. Currently available information is fragmentary and preliminary. This earthquake was one of the largest in recorded history, was the largest in Japan’s recorded history, and was beyond the magnitude that designers were required at the time to plan for. Anytime a magnitude 8.9 earthquake occurs near major population centers, it will cause enormous damage. Japan tries harder than any other country to prepare well for earthquakes and tsunamis. If the same size of earthquake and tsunami occurred at the same distance from a United States nuclear reactor along the coastline, the results would probably be even worse. And there are always some high-impact, low-probability risks, such as an asteroid hitting the middle of the Pacific and generating a 1000 foot high tsunami, that it’s not cost-effective for a single installation’s architects to design against.

With that said, anyone who decides to build a nuclear reactor is responsible for ensuring that it will not have a significant chance of a meltdown due to reasonably foreseeable risks that have a significant possibility of occurring during its operational lifetime. It looks like there was a serious failure in the risk analysis, design, and approval process on this point. The designers and regulators knew that Japan is located on multiple fault lines and is subject to major earthquakes. They also knew that earthquakes can cause a tsunami. The designers nonetheless chose to build a nuclear reactor directly on the coastline and to site all of their backup generators in a location that could be swamped by a tsunami about 20 feet high, and regulators approved this plan. It appears that no meaningful changes were made after the 2004 Indonesian earthquake generated tsunami waves up to 80 feet high, which should have been a wake-up call to operators of coast-side nuclear reactors worldwide that earthquakes can generate giant waves. Now we’re seeing the results.

After the reactor crisis has played itself out to its ultimate resolution, there will doubtlessly be an investigation. I suspect that at some point, a risk analysis document will be found in which the designers estimate the probability of all thirteen backup generators failing simultaneously. This risk analysis will probably be written in one of two ways.

• The risk analysis may calculate the risk of each backup generator failing and then estimate the risk of all of them failing simultaneously by multiplying each generator’s risk of failure together, concluding that the risk of them all failing simultaneously is statistically very, very low. However, such an analysis assumes that the backup generators are all independent systems. As this crisis has demonstrated, the backup generators were NOT independent of each other. Because they were all in the same coast-side, sea level location, they all shared the common vulnerability of being shut down simultaneously by the same tsunami. Therefore, the actual risk of them all failing simultaneously due to a tsunami was equal to the risk of a single one of them failing due to a tsunami. Since all thirteen backup generators in actual fact failed when hit by this tsunami, the risk that each backup generator would fail when hit by a tsunami of this size appears to have been 100%. Effectively, the backup generators as a group were a single point of failure, and constructing the backup diesel generators in this way was implicitly a bet that a tsunami of this size would not occur during its operational lifetime, a bet that Tokyo Electric Power and Japan just lost.
• Alternatively, the risk analysis may include a caveat that an earthquake and tsunami of sufficient size could shut down the reactor, cut off the electrical grid, and swamp all the backup generators. If so, the risk analysis probably either states that such an event is statistically unlikely to occur during the reactor’s operational lifetime or that one or more backup generators could be brought back online within the eight-hour lifetime of the backup batteries. Both assumptions have been proven wrong by what actually occurred in this incident.

It is possible that if the designers had placed two or three of the backup diesel generators at a higher elevation with secure, flexible, earthquake-resistant underground power cable connections to the reactors, we wouldn’t be having any problems with these reactors right now. Instead, we have to hope that the last-ditch cooling techniques of flooding the reactors with seawater (to cool them) and boron (to absorb neutrons) and the strength of the containment vessels will together prevent uncontrolled meltdown events and the release of massive amounts of radiation. If all else fails, the containment systems should probably prevent a catastrophic release of radiation into the environment. Let’s pray that’s the case.

The lessons from Fukushima are not limited to the operators of coast-side nuclear reactors. As a product manager, project manager, or IT solution architect, learn from the crisis at Fukushima and ask yourselves these questions:

• Are my failover systems independent of each other, or do they share one or more single points of potential failure?
• What is the statistical probability that one of those single points of failure will in fact fail?
• What are the consequences in the worst-case scenario and in other, lesser scenarios if one of those failures occurs?
• Have I invested in failover and backup systems to the point that further investment is not cost-effective and that reasonably foreseeable risks will only cause acceptable damages and costs?

Don’t just point fingers at Tokyo Electric Power or the government of Japan. Look in the mirror and ask yourself if your own product or project is next in line for a catastrophe, and then ask yourself what you can do to reduce significant risks!

As we posted previously, if you’re in the San Francisco Bay Area and are a product manager or product marketing manager or want to learn about either role, register now for Silicon Valley Product Camp 2011 on April 2nd in San Jose. It’s FREE! Only 257 tickets are left as of today, so it may well fill up before the day of the event!

You can now vote online to choose which sessions will be offered at Product Camp in the morning. The afternoon sessions will be chosen on the morning of the event by a vote among those who show up.

Register today to save your space, and vote today to influence the choice of sessions!

As the indispensable Productologist notes:

We expect more than 500 participants at this year’s event, so you’ll have lots of opportunities to meet new people, as well as reconnect with friends of old …. If this is your first Product Camp, or you can’t remember last year’s event, check out the 2010 Product Camp website: http://pcamp10.weebly.com/

This will be my first product camp and I’m looking forward to it. You can propose a session topic online. I’ve proposed the following possible topics:

• twitter 101: Promote Yourself, Your Company, or Your Product with twitter!
• Blogging and WordPress 101: Start and Promote a Blog!
• Search Engine Optimization 101: SEO Your Site, Blog, Videos, and More!
• Social Media Marketing on a Shoestring: blog, site, twitter, video, YouTube, SEO …
• Agile 101: Getting Started with Agile Project Management
• Low Cost Video 101 and Video SEO 101: Film, Edit, and Publish Your Own Product Marketing Videos
• Head Game: Putting Social Psychology to Work at the Office

Attendees will vote online between March 7 – March 25 to choose the morning sessions. (Votes cast before that period will be discarded.) On the morning of the event itself, attendees will vote to choose the afternoon’s sessions. So it will be a dynamic, grass-roots event!

Thanks to Productologist for the heads-up, to eBay for providing facilities, and to the Silicon Valley Product Management Association for organizing this and so many other valuable educational opportunities for product managers!

CORRECTION: The headline of a previous version of this post incorrectly stated that Product Camp would be in Sunnyvale. The correct city is San Jose.

In product design, beware persistent object selection.

A friend of mine was working at a company with tens of thousands of customers. Data about the customers was held in a proprietary internal system based on a database. The customers were divided into many hundreds of categories. The category that a customer was in determined what products and services they were eligible to purchase in fine detail. So keeping track of which category each customer was in was extremely important.

Naturally, they limited which employees had the ability to change a customer’s category and trained those employees to be careful and follow proper procedure. However, due to the pressure to rapidly implement new features to grow the business, engineering had never been given the time necessary to implement a “rollback” feature to undo changes to the categorization.

One evening, one of the small number of authorized administrative employees selected a large number of the customers out of the database intending to do an innocuous operation like running a report. Suddenly, he was interrupted and pulled away for another matter. When he came back to his desk, he selected a few customers and changed their category.

Unfortunately, he didn’t realize that the large list of customers were still in the selected state from his previous operation. He changed the category not only of the small number of customers he intended to, but of thousands of others he didn’t.

The next morning, all hell broke loose. Customers went to the online portal and suddenly found themselves offered products and services they didn’t want or need and unable to purchase the products and services they did need. Customers immediately phoned the call centers to get help. Call centers phoned support, which contacted engineering. And my friend suddenly discovered that thousands of customers had had their category reset and there was no way to do an automatic “undo” operation. He had to have a team of many engineers spend half a day doing emergency database analysis and cleanup, and the company and its call centers were essentially tied up for half a day. Ouch!

Pain is an expensive but talented teacher. In this case, it teaches the following lessons:

• Beware product designs in which a user can select large numbers of objects and do destructive data operations. Any such design creates the possibility that the user may select a large number of objects, forget that they have done this, and then do a destructive data operation intended for other records.
• If you implement such a design, include steps to make sure that the user must confirm they know how many objects they’re about to alter and what the objects are.
• Log all user actions, including property values before and after data changes, so that it’s possible to quickly detect what records were changed and how they were changed if a mistake is made.
• Implement undo and rollback features wherever possible so that it’s easy to undo a bad mistake quickly.
• Beware the tendency of companies pursuing growth to postpone investment in areas like security, reliability, and uptime that don’t perceptibly increase revenue in the short term. Profit-driven companies always have a short-term incentive to skimp on investment in these areas so they can invest in demand creation, growth, product line expansion, and so on. Skimping on these investments is usually pleasant and profitable in the short-term until it suddenly and unexpectedly becomes painful and expensive. At that point, the same people who were demanding that the company invest in other areas usually are shocked and amazed and demand to know why the company has been skimping on these important areas of investment. Walking on a tightrope without a net gets lots of applause and praise until someone takes a fall, at which point people belatedly begin thinking about the usefulness of nets!

Beware persistent object selection and interruptions. They don’t mix well!!!

“I already know how to think like an idiot! Need someone to sort me out” – twitter follower shim_marom, who takes home this week’s awards for self-awareness, humility, and humor, thereby proving he’s got very little to worry about!

Shim, here are the people to sort you out. They sorted me out!

Product managers need to think rigorously about products to ensure the best possible decisions on product definition and delivery get made. Project managers need to think rigorously about projects to ensure that projects are clearly defined, appropriately scoped and resourced, and delivered on schedule. Both can benefit by investing in improving their ability to think. Here’s a list of books that will make a product or project manager a better, more rational, and more successful thinker.

Everyday Irrationality: How Psuedo-Scientists, Lunatics, and the Rest of Us Systematically Fail to Think Rationally by Robyn Dawes

Dawes demonstrates how people predictably makes the same kind of cognitive errors across many different domains. It’s much less painful and expensive to learn about these mistakes by reading about them than by committing them, so I recommend the book highly. Seeing the patterns in others’ mistakes helped me to detect the patterns in my own (and in some cases even to prevent mistakes!).

Rational Choice in an Uncertain World: The Psychology of Judgment and Decision Making by Reid Hastie and Robyn Dawes

You can’t read too much Robyn Dawes. We live in a world in which information is both incomplete and imperfect. How then can we make rational decisions? This book provides a rigorous framework for understanding the problem of rational decision making on the basis of incomplete and imperfect information. It also explains what psychological research has shown about the errors people tend to make, provides examples so you can avoid making the same errors, and even covers rigorous math on decision analysis.

The Demon-Haunted World: Science as a Candle in the Dark by Carl Sagan

Sagan covers widely-held misconceptions, superstitions, and false belief systems and shows how diverse bogus beliefs result from shared errors of thought. His chapter “The Fine Art of Baloney Detection” alone is worth the price of the book. The specific beliefs he cover aren’t relevant to product and project management, but developing a mind that quickly detects and rejects nonsense absolutely is!

Emotional Intelligence by Daniel Goleman

Raw intelligence of the kind measured by IQ tests is not sufficient to achieve optimal performance in the workplace or in life. A product or project manager must be able to read their own emotions and those of others around them and use them as input in their decision making process. Goleman explains how emotions and reason interact in decision making. When people are unaware of their own emotions, they may miss valuable clues about what to focus on, their thinking may also become irrationally biased, and they may fall into excessive and needless conflict with others. When people are aware of their emotions and manage them, they can reduce the cognitive distortions that emotions can create and benefit from the insights they provide.

Blink by Malcolm Gladwell

People often assume that they think about a topic and only then have an emotional reaction to it. Evidence from brain scanning studies shows that in fact, when people are exposed to a stimulus they often have an instantaneous subconscious positive or negative reaction to it and then come up with a conscious, logical explanation to justify their “blink” reaction. If you are aware of this phenomenon, it can be a useful tool. It provides a possible explanation for the “gut reaction” that an experienced product or project manager (or an expert in another domain) may feel when they see a problem they’ve encountered before. It’s also important to be aware of this phenomenon so that you allow “blink” reactions to inform but not to dictate your final conclusion and give yourself time to think through an issue logically in case there are rational considerations that one’s instincts overlooked.

The Wisdom of Crowds by James Surowiecki

The average of the opinions of a group of experts is more likely to be correct than the opinion of any single expert. Product and project managers need to keep this in mind as they think about problems. By gathering and averaging the opinions of many people who have insight on a problem, they will be more likely to make optimal decisions and achieve optimal outcomes. This reminds product and project managers to have humility and not to become overly confident in their individual intelligence. Estimating when a project will be complete provides a classic opportunity to put this principle into practice. Instead of trying to estimate it alone, ask everyone on the project to make their own estimate and average the results.

Feeling Good by David Burns, M.D.

Subconscious “blink” reactions notwithstanding, events don’t cause long-lasting feelings. Events happen; we place an interpretation on the events; and we have an emotional reaction to our interpretation. By changing your interpretations, you can change your emotions for the better (emotional health and rationality) or the worse (depression). This is the basic insight of cognitive psychology and cognitive behavioral therapy, one of relatively few forms of therapy that has been clinically tested and found to be both safe and effective. Burns discusses the common distortions that emotional states introduce into the thinking process and explains proven techniques for controlling such distortions. It’s important for product and project managers to know these distortions and be able to recognize them because they will see them often in the workplace, and if they’re not careful, they will experience those distortions themselves!

How to Lie with Statistics by Darrell Huff

The text and examples are a bit dated, but this book is a classic and worth knowing for the title alone. Statistics are constantly manipulated and misused in marketing, product management, business, and all other domains of life and must be regarded with eternal suspicion as a result. A product or project manager must know the common ways that statistics can be misused so they recognize it when others are playing these games to buttress illogical claims. Biased survey questions, unrepresentative samples, and conveniently-chosen boundaries for a range are only three of the common tricks the book describes.

As we’ve said before in this series, an idiot is a person who reasons poorly and has low odds of reaching valid or optimal conclusions, yet has unjustifiably high confidence in their unreliable conclusions. By reading these books you’ll improve your ability to reason and develop a healthy skepticism about your conclusions. This will keep you humble and open-minded, reduce the risk you will wind up in the “idiot” column, and help you to deal with the arguments made by those who do!

Psychological research has shown that:

• Just saying something out loud, even if it’s incorrect, increases the speaker’s belief in the statement.
• Hearing another person say something out loud can increase a listener’s belief in the statement. This effect is even more powerful if the speaker is perceived as an authority figure or an expert (as product and project managers may be, rightly or wrongly).

To reduce the risk of biasing yourself (and others), avoid stating a position on an issue before you have to. Start by asking questions with an open mind, learning, and hearing what others have to say. Good product and project management conversations go through stages:

• data gathering: Everyone in the conversation is asking questions, gathering data, and learning about the problem.
• discussion: People have an open-minded discussion about the data they’ve gathered, ask further questions, and identify unknowns that need to be investigated.
• brainstorming: People begin throwing out possible solutions as open-mindedly as possible without attacking each others’ proposals. This maximizes idea creation and cross-fertilization.
• evaluation: The team begins discussing the pros and cons of each possible course of action.
• proposal: A particular course of action is proposed and reviewed very carefully.
• decision: One or more proposals are chosen and the team moves forward together on implementation.

In managing the flow of a conversation about a product or project management question, I generally start by trying to draw the other participants into the conversation and see what they know. This ensures that their ideas are included in the discussion and that they know and feel they were included. I also remind myself mentally at the start of the discussion to try to have an open mind on the topic and not jump to conclusions. Only later on in the conversation will I begin focusing the conversation around possible solutions and finally focusing the team on what appears to be the best possible solution.

Much time can be wasted in a conversation and much needless friction produced when a person begins strongly advocating for a particular solution too early without allowing time for open discussion and brainstorming first. A person who reasons poorly yet is overconfident in their conclusions is most prone to make this mistake. Since they reason poorly, they’re likely to reach a poor conclusion, and since they’re overconfident, they’re less likely to recognized that they made up their mind too quickly and reached a non-optimal conclusion.

The problem is made worse when a person starts advocating a particular position more strongly than the facts justify simply because they’ve publicly committed to that position and now their whole fragile sense of self worth hinges on whether the group accepts their hasty conclusion or not. Managing the flow of a meeting poorly, jumping to conclusions too quickly , and emotional insecurity among the participants can create a toxic brew from what could and should have been a simple, painless, open-minded discussion of possibilities. Above all, don’t get your own ego mixed up in the question of whether you’re right or wrong about a particular point. Be part of the solution, not part of the problem!

Dr. Edward de Bono provides a more structured framework for managing conversations and the roles people are playing with his Six Thinking Hats. I only learned about that recently and have never bothered to announce to people that I’m “wearing a blue hat,” but it’s worth reading. You don’t have to think in terms of colored hats, but make sure you’re aware of the roles people can play in a conversation, are playing, and need to play and that you manage the flow of the discussion accordingly.

Reach a conclusion as soon as you need to, but not sooner. Speak up at the right time, but not sooner. You’ll make better decisions with less friction!

• Find out how many people disagree with you and how many people agree with you. The higher the ratio of people who disagree with you to people who agree with you, the more careful you must be. When nearly everyone disagrees with you, ask yourself why. Do you know something they don’t? That’s a fixable problem if you can communicate what you know persuasively. (If you can’t, you shouldn’t be a product or project manager.) Do you think you’re doing better analysis than the others? That’s possible, but if so, you should be able to demonstrate to rational observers why and win their agreement. Do you think you’re smarter than all of the people who disagree with you combined? It’s possible, but the more informed, intelligent people who disagree with you, the lower the chance that you’re smarter than their collective intelligence. (Read The Wisdom of Crowds to learn why the averaged opinion of a group of experts is generally more reliable than the opinion of any single expert.) Do you think you’re just more rational than all the people who disagree with you? It’s possible, but if so, perhaps you’ve chosen the wrong workplace. If numerous informed, intelligent people disagree with you, be very open to the possibility that it is you who is wrong!
• Find out why those people disagree with you. Who knows … you might discover a fact, worthwhile assumption, or viewpoint that you don’t already know!
• Test your opinions against the facts. Facts are inconvenient. They get in the way of absolutely perfect opinions. See what conclusions you can draw from your opinions and see how well those conclusion stack up against reality. If your opinions conflict with the facts, it’s not the facts you should be changing!
• Test your opinions against each other. Look for internal contradictions between your opinions. Relentlessly resolve contradictions wherever you find them. It’s a lot faster and less embarrassing to do this for yourself than to rely on other people doing it for you.
• Test your predictions against the future. Make concrete, quantitative predictions about what you expect to happen within a specific timeframe. Examples include: a deal will or won’t close; the company will close a certain number of deals within a target market segment; customers will or won’t request a specific feature; certain customers can be satisfied if we give them features XYZ but not ABC; and so on. Make sure you remember your predictions (putting them in writing if necessary), and later review them to see how many of your predictions turn out correct. It won’t be 100%. This will remind you to always be open to the possibility that you may be wrong. We all need to be reminded of that, particularly if we’ve been right for a while!
• Still think you can predict the future? Check the performance of your investments over time. Anyone who could really predict the future would be the wealthiest person in the world. Unless you bought gold in 2002, sold your stocks at the top of the market, and bought them back at the bottom, your ability to predict the future is probably limited. (Or you’ve studied history and have chosen to be a buy-and-hold long-term investor, which historically has been a good strategy, the last decade notwithstanding.)
• Cultivate humility by comparing your success with that of the best. Those whom the gods would destroy, they first make proud. Keep that inflating ego under control by asking yourself if you’re as wealthy as Larry Page and Sergey Brin, if you’ve founded as many billion dollar companies as Marc Andreessen, if you’ve made as many successful investments as Peter Thiel, or if you’ve put rockets into orbit like Elon Musk. If the answer to these questions is no, you probably still have plenty to learn from others.

It is always possible that you are right and everyone around you is wrong. That does happen. Galileo and Copernicus were right about the sun being at the center of the solar system, and the Inquisition was wrong. Churchill was right that Hitler posed a grave threat to the world and had to be confronted sooner rather than later, and the appeasers were wrong. But for every Galileo and Churchill, there are a thousand people who think they are Galileo or Churchill and are not.

It’s OK to be wrong. Everyone is wrong from time to time. It’s not OK to be wrong and unable to detect your mistakes or stubborn when you do. Be alert to the possibility that you may be wrong and ready to change course when you are. It’s less painful for you, your product, your project, and your company than the alternative!