Leaks in Your Product Game

Poker players...poker players aspiring to improve, anyway...are always analyzing “leaks” in their game.   Leaks are mistakes or tendencies that can dramatically impact one’s bankroll and success over time...not for the better.    Some leaks are particularly pernicious in that you are aware of them, you know you need to fix them, but they are so psychologically ingrained that you repeat them even when you know better.  I have those...but, no, I’m not “telling”.  My fellow poker players should appreciate the pun.

Over the last few months, I’ve found myself repeatedly answering the question “What are common reasons for product failures.    Great companies with very talented product professionals can have their fair share of “failures” and yet still recover.  I’ll use the term “leaks” to address some of the mistakes I see repeated over and over.  I have those, too.  But, again, I’m not telling.

1. Nobody Puts My Baby in a Corner  - I see this most often from founders and product-minded CEOs, but this can also afflict product managers, architects and just about anyone who develops product concepts.   This is the tendency to be so emotionally invested in your own product concept or product feature that you won’t/can’t listen to the market/customers/competitors/employees/spouses that are screaming at you to pivot or abandon the idea.  BTW, I put this first in the list for a reason.
2. Customers Just Don’t Understand - I fully appreciate the philosophy that you shouldn’t build a specific feature or create a specific product requested by your customers.  Instead, you want to understand pain points and business imperatives.  However, I am stunned at how I see customer feedback being treated as inconsequential.  Which brings us to...
3. Customer Said What? - You’d love to build value for your customers, but you don’t know what they want because you have no methodical and serious approach to any of the following: analytics, A/B testing, usability testing, customer feedback mechanisms, focus groups, regular site visits...and, whatever other mechanism will get you closer to your customer.  Whether that customer is a consumer using a mobile app or a knowledge worker in a Fortune 50 company using premise-based software, you really should understand them.
4. Customers? - OK, this is mostly for the very early stage companies with a brand new product.  But, even before the product is built...especially before the product is built...you should be vetting ideas with target users.  Wireframes, design comps and prototypes are all useful tools for garnering very early feedback.  
5. We’re Gonna Need a Bigger Boat - Or a bigger server.  Or more network bandwidth.  Or more I/O.  Or...whatever results in crushing scalability issues that bring the best products to their skinny little knees.    No, you don’t necessarily need to architect for ultimate scalability in your early stage product.  But, you better understand scalability issues and have a plan to get where you need to be well before you think you need to be there.
6. Just Say Yes...Then No - I have never worked in a software product company where the product backlog wasn’t much, much bigger than the development team’s bandwidth.    That is to be expected and you might as well get used to the tension that will arise from conflicting priorities.  Product people don’t like to say No.  Sales folks REALLY don’t like to say No.  You will say No...you’ll just be doing it implicitly or explicitly.  I prefer the latter.  For every release, I recommend being very explicit about what you aren’t doing and why.    Have that conversation early with key stakeholders.  Don’t wait until the release to hear “But, I thought....”.  Your “No” list should as carefully vetted and as well understood as your “Yes” list.