Skip to main content
March 9, 2016

That “Oh Crap” Moment of Product Management

How to avoid putting your customer’s data at risk...

Nothing stinks worse for a product manager than hearing there is a security issue in the amazing feature you just released. Yes, that one you created specifically for your very important client. Telling your previously elated buyer that the new do-dad you created specifically for them – based on their unsolicited, but completely accurate feedback – now needs to get pulled back because you may be putting their data at risk, is not a fun conversation. I refer to it as an “Oh Crap” moment. Communicating timelines and the “whys” behind the “Oh Crap” moments fall squarely on the shoulders of the product manager.

Product managers should have their ears tuned to the market; predicting and building in accordance with the market’s expected maneuvers and opportunities, making tradeoffs between one opportunity and the next while continuously addressing bugs and tech debt.

This necessitates a deep, empathic understanding of the unstated needs of the market: the customer, prospect, and suspect that are current or potential buyers. While sales may tell product management that the Decision Maker at the Named Account absolutely needs Shiny Thing in order to close the Big Deal, the truth is the sales rep and even the decision maker are frequently focusing on an outcome rather than of the job they are trying to perform. If the product manager executes his or her function correctly, they are focusing on the task the customer is looking to perform and building for that. Which may look different than Shiny Thing, but may produce Even Better Thing.

Having your ear tuned to the market means spotting market trends in their infancy. Including the trend toward secure software products.

Customers have a basic expectation of a secure product. But they may not think to ask for it, just like I don’t ask for plumbing when I shop for new house (this isn’t House Hunters, Alaska), but I expect the shower to work. Functioning plumbing and hot water are basic expectations that I have in my new house, but I don’t bother to list them on my “must haves” since I believe that all houses come with running water. The same can be said about secure software: if you aren’t paying attention, you may miss security as a customer requirement that they never bothered to articulate, but still expect to be included. Which means, if you aren’t building security into your development process, into your release process and ultimately into your product, there is a high degree of likelihood you will are not meeting their needs. And since they expect security in their products, they also expect it in new features and functions you are creating. Which leads to even greater disappointment if you face an “Oh Crap” moment and need to call up your previously happy customer(s) and tell them that their data is now vulnerable –because of that shiny new feature you built for them.

Fortunately for me, I work at Veracode where we practice “dog fooding” aka eating our own product in our development process. Pete Chestna, one of our directors of engineering, has spoken a lot about our efforts in DevOps and seamless security integration. Project Purina – as we fondly call our dog food program - means that I don’t have any post-production “Oh Crap” moments. And even better, very few “Oh Crap” moments in pre-production/QA – where my highly desired features may have been delayed due to something in the code that wasn’t up to our security standards.

Rather than slowing down development, our dev team have been able move faster: with security baked-in they are now confident in what does and does not require additional security testing. In fact, we have security champions embedded on each team to ensure that if something requires additional security testing, it is flagged in grooming, not in QA. It’s well known that the earlier in development that you address a bug, the quicker and cheaper it is to fix the problem. The same is true when it is a security bug.

Embedding security into the development process means going faster confidently - without worrying that an “Oh Crap” moment is waiting to strike. And building the features and functions demanded by the market - including the demand for secure products – means that you are ensuring your current and future market position and the happiness of your current and future customers.

Senior Product Manager for Veracode’s application security platform including reporting, analytics and API feature sets as well are Veracode’s technology evolution from a monolithic architecture into MicroServices. Anne partners with Veracode customer’s to manage application security risk through new product features and functionality while enabling Veracode’s best in class scanning technologies.

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.