Welcome to Part 2 in this series. When I started Part 1, I had no idea how quickly a whole lot of thoughts would flow regarding the cross-over utility of some ideas from sometimes time-pressured or higher-stakes fields into general product management.

Train How You Fight

Another great line from a fire instructor, “You can never train too hard for a job that can kill you.” This stresses the importance of realistic training that prepares firefighters for real-life scenarios. And train we do. Beyond initial training, we have weekly sessions, special classes, and more. In aviation there’s recurrent medical and flight checks, etc. Now, in corporate, there are hopefully less things that will kill you than in emergency response situations. But there are systems and equipment breakdowns. There are high-stakes situations. Are you prepared? Have you practiced scenarios? Or is the book up there on the shelf getting dusty? The problem with risk mitigation is you don’t make money from it. It’s value preserving, not value accretive. It’s a cost item, not a revenue item. Backup systems, security efforts are necessary, but they are on the cost side. Regardless, the only way to be really ready is training. Some say – with some validity – that’s what insurance is for; to buy away risk. And yet, is that responsible? Is it ethical? Maybe. It depends on your situation. You have to assess that. It’s not all gloom and doom though. There’s items on the plus side here. What about customer training / onboarding? Or sales? Whether it’s to mitigate bad outcomes or drive towards good ones, are you constantly learning? The better the training, the better the game is likely to go. Train how you fight.

[Read more…]

This article started from chats with a colleague about how I managed doing volunteer emergency work at night or weekend adventure sports and then went into the office the next day to deal with important, but less extreme matters. It turned into lessons I’ve learned, (or think I’ve learned anyway), from that part of my life and how they affect my perspective on working in more corporate environments. She thought I should share them. I quickly ended up with more than I’d thought so this will turn into a few posts perhaps. Here we go…

[Read more…]

Introduction

Artificial Intelligence is yet another tool that is an overnight success, decades in the making. The Fear Of Missing Out (FOMO) seems huge since ChatGPT brought AI from what Gartner’s Hype Cycle calls the Trough of Disillusionment to what might be the beginnings of the Slope of Enlightenment. But what do you really need to do with it, if anything? Do you need to build anything strategically core to your customer offerings? Use it as a tool to enhance existing offerings? Or use something more operational; from process management to marketing. One challenge right now is people seem to want to just sprinkle some AI on things to make sure the buzzword is in a product checklist or annual report.

According to Statista’s “AI Trends & Predictions Roadmap to 2025,” AI market value will increase from US$244 billion in 2025 to US$827 billion by 2030. You can find predications of various magnitudes from other sources. But what does it mean? Chances are it means your competitors are deploying AI. Whether it’s for something useful with solid ROI or not is the question. If your competition is deploying things, you’d better at least be doing research.

So where do you start? Too many posts I’m seeing talk about AI Strategy go right to implementation. That’s AI at tactical level. There’s value in that. And it’s possible to think of general capabilities as strategic. But being strategic means starting with your business drivers. Your AI strategy, (just like all the others), should be based on the value you’re trying to create. At the very highest level, as always… there’s basically two goals: Increase Revenue. Or Decrease Costs. Unless you’re actually building and selling the AI tools themselves, chances are the value you’re creating comes from elsewhere. In which case AI is “just” a tool; another means to an end. Being skilled at it may be a strategic capability, but it’s not a business strategy in and of itself.

[Read more…]

Introduction

The title isn’t a euphemism. This is about when product management decisions can do damage.

In Part 1 of this writeup, I’m going to define some of the challenges for Mission and Safety Critical applications as compared to typical development. If you want to skip right to more practical considerations for what to do about such things, go right to Part 2, with a checklist followed by explanations of the line items.

Over the years I’ve moved from consumer oriented products to B2B and B2B2C, most recently several years working on healthcare solutions. On this path, I’ve learned a lot about Safety Critical application issues. It’s stuck me that people who ‘grew up’ in such environments may have a lot of this knowledge through intrinsic experience. But for those transitioning to such areas or in startup mode who haven’t been there, (as was my path), it’s possible there’s knowledge gaps. What I often do when learning new things is take note in my own Wiki, and over time develop some degree of body of knowledge in a subject area. So my goal now is to share back what I’ve learned for those who may find it useful.

What’s the difference between “Mission Critical” or more extremely, “Safety Critical” vs. “typical” product management? Rather than try to formerly define it, let’s keep it simple. Safety Critical products are those that – for certain failure modes – can hurt or kill people. (Or cause significant property or environmental damage.) Often, they’re things that move in our environment; that is, actually do things. A basic compare and contrast might be an advertising delivery system for content vs. an insulin pump; failure of the first maybe means some lost money, whereas failure of the second… clear enough, right? Mission Critical – as distinct from Safety Critical – might mean less severe human consequences, but a ‘hard’ failure or challenge nonetheless. E.g., a failure in a basic regulatory compliance issue could result in anything from minor work stoppage or fines though potential criminal negligence. Or a failure of the software on a Mars Rover results in loss of the unit, associated waste and data loss. No one gets hurt or dies, but the mission is basically lost.

In short, these are not really applications where we want to “fail fast and learn.” These are apps that have somewhat more crisp “Minimum Viable Product“ standards when it comes to the “Viable” part.

The Short Version of Issues for Mission / Safety Critical Products

• Mission and Safety Critical systems demand something beyond basic Agile Product / Project management approaches. (And this may include products in highly regulated areas as well.)
• There is often a moral component that exists beyond other types of products / services.
• More planning is required than for non-critical systems.
• Agility may be more often impacted by external dependencies.
• So called “Non-functional” requirements may become critical.
• Risk assessments must be included as a core concern.
• There’s a suggested checklist for Mission / Safety Critical Products in Part 2 of this writeup that you may find useful if you work on these types of products.

That’s it. You can stop reading now. But for fuller discussion of these points, please continue. Or skip to Part 2 for the just mentioned checklist items.

[Read more…]