Comments on: Failure To Launch (Your Product)

By: Top 10 Product Management Posts Of 2009 | Product Management Meets Pop Culture

Mon, 28 Dec 2009 16:42:47 +0000

[...] Failure To Launch (Your Product) // February 19, 2009 You’ve just launched your next big product — and your application crashes due to “unexpected” demand. What could you have done to prevent this disaster? From backwards planning to problem triage to root cause analysis, Product Managers are uniquely suited to make things happen programmatically and organizationally. [...]

By: Scott Sehlhorst

Scott Sehlhorst — Thu, 26 Mar 2009 04:16:17 +0000

@David: Thanks for the comment! I have seen organizations with mature processes that have frameworks that catch all this stuff. I’ve also seen individuals raise these issues, as you suggest. I’ve also seen people raise these issues “too late” to really address them. Raising them early (gathering the inputs from the team, asking the probing questions) with 3 sprints worth of runway to address them made a huge difference for one of my clients. SXSW was a successful launch, with no signs of the “fail whale” and no need to say “we’ve been so popular that our site crashed.”

By: David

David — Mon, 23 Mar 2009 09:33:25 +0000

Many of the failure scenario types referenced would be common problems expereinced by various members of the team. You would hope that the people working on the project would have these types of issues in mind, and raise the risks during the business requirements gathering phase. If they are discussed with the product owner, many of these risks can be mitigated initially, or at least be known upfront to not be a shock during testing, with the view of having everything working correctly for the final product.

Regards,
David
jacksguides.com

By: Scott Sehlhorst

Scott Sehlhorst — Wed, 25 Feb 2009 17:48:47 +0000

@Pawel – thanks! In a start-up, it can be a lot easier to remember that the whole company is trying to achieve something. Larger companies often have too much overhead and reporting structures and middle-management stakeholders getting in the way of global optimization.

By: Scott Sehlhorst

Scott Sehlhorst — Wed, 25 Feb 2009 17:34:35 +0000

Hey Patrick – great question. It wasn’t really a miss, just a change in the market – in the most recent case I’m thinking about. There was already a product launch (and load to near expected levels). There was a decision to add a public launch of some potentially compelling capabilities with some fanfare, added recently. As part of adding the new event, this new analysis was done based on new expectations. Basically revisiting the “business proposal phase” for the near term.

These are definitely good candidates for non-functional requirements, and that’s how they have been handled.

By: Pawel Brodzinski

Pawel Brodzinski — Wed, 25 Feb 2009 11:01:17 +0000

That's exactly what risk management is. You project what may go wrong and look for ways to avoid the problem. I really like your approach to look for solutions not only in the code but also in the whole product management machine (including changing a launch date). It happens oh so often development is forced to launch the product which isn't ready. Then it takes a lot more of effort to straighten things up than it would if all was done properly.

By: Patrick Masi

Patrick Masi — Tue, 24 Feb 2009 14:54:21 +0000

Hey Scott,

“…assume it is 10,000 total users, with 100 concurrent users (normally) and 500 concurrent signups.”

I am a little confused on why the product manager in this example didn’t know this information during the business proposal phase of market readiness, and therefore would have included user loads as a non-functional requirement for the development team ahead of building the software.

Was it just a miss? If so, a launch risk mitigation strategy would certainly be appropriate to catch it. If those sorts of numbers were known ahead of time, though, I would believe that this is a good candidate for a non-functional requirement.

By: Scott Sehlhorst

Scott Sehlhorst — Tue, 24 Feb 2009 14:39:01 +0000

Thanks, Dr. Jim! Yeah, I saw similar approaches to defining disaster recovery requirements for enterprise clients. What I didn’t see in those situations was a “compelling event” like a product launch as a means of working backwards into specific deliverables per release. If those had been agile projects, then yes, I guess we would have used the same approach.

The other difference was that the disaster recovery priorities were focused on “be able to fail over” and not “predetermine our limitations / capabilities.” You’re right that it is a very similar thought process, though. Great observation. I wrote this article with one of my start-up clients in mind, where Maslov’s hierarchy of needs usually has the company focused on “get it built” and “find users.” Thanks for the insight.

By: Dr. Jim Anderson

Dr. Jim Anderson — Mon, 23 Feb 2009 20:39:51 +0000

What's interesting about your approach is that it's very similar to how business continuity planners go about preparing an entire business to deal with the unexpected. The one additional point that I'd add to your list is that as a PM you need to test, test, test your ability to deal with a disaster should it occur. - Dr. Jim Anderson The Accidental PM Blog "Home Of The Billion Dollar Product Manager"

By: Scott Sehlhorst

Scott Sehlhorst — Mon, 23 Feb 2009 14:44:04 +0000

Thanks, Andrew!

By: Links for Feb 22 2009 | Eric D. Brown - Technology, Strategy, People & Projects

Mon, 23 Feb 2009 01:44:12 +0000

[...] Failure To Launch (Your Product) by Scott Selhorst on Tyner Blain Share and Enjoy: [...]

By: Andrew Meyer

Andrew Meyer — Sat, 21 Feb 2009 15:56:33 +0000

As always, I love your insights. Your post reminded me of a saying Charlie Munger (vice-chairman at Berkshire Hathaway) is famous for:

“Invert, always invert.”

By: Scott Sehlhorst

Scott Sehlhorst — Sat, 21 Feb 2009 14:38:07 +0000

Thanks, Allan and Eric. Allan – send me an email if you want, with more details – happy to offer an opinion.

By: allan

allan — Sat, 21 Feb 2009 03:23:13 +0000

How true Risk and mitigation are so vital before the launch. I have been reading your posts for some time now, appreciate every article you’ve posted. Co Incidentally I am stuck in a similar situation, the launch is somewhere near and we have uncovered major roadblocks, my doubt is whether the roadblocks need to be cleared wholly and fully and put off the launch to a later date, or keeping the launch date the same as thought off earlier, and handling the roadblock in a controlled manner. Your thoughts on this are appreciated

By: Eric Hannon

Eric Hannon — Sat, 21 Feb 2009 03:02:20 +0000

I like this approach. I am a pessimist by nature and I spend a lot more time thinking about the bad things that might happen than the good things. This should be pretty easy for me to follow. Thanks.

By: Scott Sehlhorst

Scott Sehlhorst — Thu, 19 Feb 2009 22:49:56 +0000

Thanks David! Yes, these are definitely things that I consider to be “on my plate” when playing a product owner / product manager role. There are so many long term, and strategic things we focus on as product managers, that I thought it was important to highlight that some things that appear to be tactical really are strategic. I remember the epiphany I had (or heard, can’t remember, so I’ll assume “had”) when I was a technical consultant for an enterprise software provider: People don’t get credit for preventing fires, only extinguishing them. I definitely saw that in compensation and accolades, and I never liked it. The problem is that putting out a fire is just mitigating damage. Preventing it can be huge.

Most of the start-ups I know of hire primarily talented but inexperienced people, who usually haven’t had the experiences to put this stuff on their radar. And the “gray hairs” they do have are usually too diluted by the other thousand things that have to happen for the company to succeed. If one company reads this, immediately thinks about their next big marketing event, and asks a couple questions to get the ball rolling, then this article is a “success.”

Thanks again for reading and commenting!

By: David Locke

David Locke — Thu, 19 Feb 2009 22:47:58 +0000

If you mitigate the problems you can think of, then you’ll have fewer to mitigate later. It’s the nature of proactivity that you mitigate things that might never happen. Reactive crisis management is no fun.

In operations, ITIL change management can reduce staff beeper moments. They make less mistakes when they sleep more.

Eventually, over a career, you’ll have built up a catelog of risks. You can put those in MS Project and just roll them in. With each new project, you explore risks yet mitigated or discovered. Have a risk day.

By: David Locke

David Locke — Thu, 19 Feb 2009 22:39:48 +0000

Each of those problems identified in your Ishikawa diagrams is part of either your offer or your marketing. Regardless, they are part of your user’s experience. The user’s experience drives your P&L regardless of your profit models and business model.

All of those problems are within the scope of the product manager’s responsibilities. They are well beyond the scope of development and marketing. They are why the product manager is the CEO of the (product or) offer. Some of the problem owners won’t feel like they are on your team, but in a price-based competition market, the offer broadens and reaches the desks of the non-customer contact people. You, as the PM, will need them, so start gaining influence with them now.

Reach out and grab your organization, then reach further.

By: Scott Sehlhorst

Scott Sehlhorst — Thu, 19 Feb 2009 22:38:15 +0000

Yup – back in my waterfall days, that was how we dealt with it too. The spin feels different when working with an agile team, but it is still the same stuff. Thanks, Val! The other difference is that now we explicitly fold stuff into the backlog and prioritize (helping the other parts of the company to course-correct if needed), instead of just tracking line items in a spreadsheet.

By: Val Workman

Val Workman — Thu, 19 Feb 2009 22:35:26 +0000

Sure sounds like a Risk Exercise.
1) Identify your potential risk events.
2) Determine the probability of each event happening
3) Establish the expected impact if the event occurs
4) Score all events
5) Develop mitigation events for the risks that keep you up

Only problem is, identifying potential events or problems that might happen.
“If only I’d seen it coming”