30 Minutes of “Why?” > 1 Flawed Feature

Problem

My team was considering new payment features for our product. The vast majority of us were on-board and in agreement on what the replacement payment feature should be, so we integrated with this provider. It turned out to be just an okay decision - there were some definite drawbacks.

Actions taken

We reflected on why we made this choice: To save money? To improve customer experience? To make our lives easier? And if only one out of those three things are met, was it a success or a failure? It turns out we were all forming opinions based only on our own perspectives. We didn't have a coherent definition of success, which resulted in a decision that didn't bring us closer to our company's vision. A lot of companies have moved to an agile product development methodology and so people don't take the time to write PRDs anymore. I've never written one, nor do I want to. But now, for large features, I ask PMs to write Product Memos instead. Product Memos are about one-page each and describe:

• what the problem we're trying to solve is
• what the feature we are building
• what is the measure of success/how are we going to know if it is a win or not?
• what alternative options we had before coming to this decision?
• other than building this feature, what else did we consider and why were they not good? It takes 30 minutes to write and circulate, and it helps everybody get clarity on why we are building something. It saves us from making big mistakes. It verifies the thinking. The agile definition of "done" is helpful because it allows us to go back be honest about our AB testing and whether or not we're hitting or goals.

Lessons learned

I learned that a little bit of process can be extremely helpful. Agile is a reaction to requiring too much documentation and planning, but some of that can be really valuable. Communicating the WHY is just as important as the WHAT.