There are times in the life of a blogger where you want to run to your keyboard and vomit the events of life for all to read. When I was a columnist in college, it provided far too many opportunities to share too much too soon. Often, it was probably funny to read the ramblings of an irresponsible student when put into context.

As I have aged, however, I have come to realize that it’s best to let life breathe before gleaning the truths from it.

My team performed a demo of a new feature recently that did not go well. Not at all. You see, as a new product team member at my company I am not what I would consider a subject matter expert. I don’t have near enough time in the saddle to understand how apps integrate and work in concert. As a result, I spent a lot of time interviewing stakeholders, users, customers, developers, you name it. Usually, what results is fully fleshed out stories and requirements for the development team to work their magic.

Instead, I got my wires crossed on one very important detail that resulted in some unhappy people.

At this point I would like to point out that this was not the end of the world. Once the stakeholders got a hold of their breath, we sat and explored what the expectations actually were and got the data right. That did not stop me from having a near meltdown as soon as the meeting ended.

In the aftermath, the jokes came about Murman rocking in the fetal position in the corner. It wasn’t the truth, but emotionally I was just about there. Often, we put so much emotional capital in trying to meet a tight deadline, please an unhappy customer or make do with limited information. In this case I had all three. When that capital results in something that doesn’t pass muster, it can take a lot out of you.

It’s really hard to have an ego about yourself when things like this happen, but there is success to be found.

The aftermath and lessons that were learned could move mountains. My mistake highlighted a communication gap between stakeholders and requirement gathering that had been happening long before I got to my company. The meeting that followed was one of the most positive experiences for most of the involved parties.

Many things happened as a result. A monthly round table was proposed to look at the road map and incorporate better ideation. Stakeholders are now being involved sooner in the requirements process. Overall, the level of confidence is growing that what development is going to demo will be what they asked for.

As silly as it sounds, the real danger is to think that you can turn lemons into lemonade like this all the time. To avoid this, I wrote the results of that sprint retrospective down for all of the team to see on a daily basis (including me). My calender is now filled with more idea gathering sessions and a process for how to communicate them is being formed.

Most of you reading know what all of this feels like and have experienced the ups and downs of a failed sprint. Even if you go through it with a previous project, team or company, it will happen again. Learning to glean success from failures might be one of the most important skills a product manager to have. How else can we model the agile mentality for the rest of the team?

One last note: we did a demo less than four days from production on this feature. The dev team did an amazing job of diagnosing the problem, and we managed to get everything in at the buzzer. My boss called it a win, and I went home proud.