Why Stupid Product Ideas Matter
I was copied on an email chain today in which one of our sales representatives and our product’s service manager were discussing a feature request. The sales rep was asking for us to provide data in our UI that would identify who the recipient was from an email submission. A fairly simple, straight-forward request.
When the service manager and I talked about the request later that day, I scoffed at the idea.
“Why would we do that?” I said with hubris, “The client gets the emails directly to their inbox — our platform isn’t the place for that information.”
After our conversation, I continued about my day, but the request followed me around like a hungry dog. Was it really that bad of an idea to include that information? I thought to myself. The more I pondered the need for that data point, the more I realized it was not as stupid of a request as I had initially thought. I started to conclude that as the product scales, and our user base grows, this would be [potentially] a valuable inclusion in our data set — and I realized in that moment that I had made a huge mistake. I had put my pride and my concept of what was “right” ahead of both the user and the stakeholder.
That seemingly stupid request is going to eventually be an included data point in our application, and that’s why it’s important to appreciate the feedback we get from our users and stakeholders.
While not all requests make sense from a product perspective, all requests do make sense — in some way — from a user perspective. Our customers subscribe to our SaaS product because of the borderline excessive detail we provide them regarding their marketing campaigns, as well as the leads generated from those campaigns. Why wouldn’t it also make sense to include in those lead details who the recipient was? Especially since that’s such a low effort item to include. As of right now, a story has been written for that data point to be include in the UI, and it’s currently scheduled for our next sprint iteration. That seemingly stupid request is going to eventually be an included data point in our application, and that’s why it’s important to appreciate the feedback we get from our users and stakeholders.
Afterwards, I had to conduct a personal retrospective to better understand why I was so hesitant at first. Outside of my ego getting in the way, a conclusion I came to — and something I determined was extremely important for our organization to address — was that another product was responsible for collecting that data point. Not only would our SaaS team have to make changes to the UI, but I was also going to have to coordinate with that other team on determining how we could expose that data in the UI. Not a huge ask or blocker by any means, but it lead to an important question:
How successful can a product be if it is defined or limited by another product?
A question I tend to revisit on a weekly basis…
If you enjoyed the article, please give it a clap so others will see it here on Medium — I won’t discourage a share on your social media either! As always, please feel free to comment and share your thoughts. I’m always interested in hearing others’ opinions.
