Hard-Won Knowledge: Learning from Product Failures
Intro
It has been a hard few weeks. I recently lost a job that meant a lot to me and its made me question myself in ways that I don’t think I’ve had to before. I fought really, really hard to get myself into Product Management and like many people I know who work in Product, I care A LOT about my work. I care about making the biggest impact I possibly can and being as successful as possible. I care about the people I work with, and I want to see them be successful. I care about solving problems and being seen as someone who is capable of helping organizations solve problems. For better or worse, this is a huge part of my identity and how I think of myself as a person.
So when I was let go because the company I worked for wasn’t able to meet the revenue targets it had set for itself and was suffering from execution issues, it hurt. It really, really hurt. It is hard not to feel like this is a personal failure on my part and that I should have done more to right the ship.
Everybody has a plan until they get punched in the face, right? So what’s my plan now? I’ll move forward. I’ll find new opportunities to prove myself, make an impact, and solve important problems. First though, I am going to make sure that I’ve learned everything I can from this experience and carry it forward with me.
Lessons Learned
Lesson 1: Product-market fit requires go-to-market discipline
Its not always true that there is ready demand for the product you are trying to build. This was not the case for my last company. We never had a problem finding potential customers who would talk to us, and plenty of companies were willing or already paying for similar solutions. Instead, our biggest product/market fit challenge was our own message discipline.
During the periods where we were focused on one set of customers, example mid-market SaaS companies, prospective customers were predictably inconsistent in telling us what their biggest pain points were. Because we wanted to be a single, end-all-be-all platform solution, there was always a strong urge to put every single customer problem on our roadmap right away and sometimes we even tried to rapidly build an “MVP feature” so we could say that we’ve solved the problem as quickly as possible.
There is no problem with a company being sales-led. Most early stage SaaS startups are. But it is a shared responsibility of both Product and GTM to be disciplined and to maintain a clear contract with one another about what we are building and who we are selling it to. This means that we are not only focused on a specific set of customers, but that we’ve also ruthlessly prioritized a narrow set of problems and we resisted the urge to “peanut butter”. “Peanut Buttering” is the tendency to try to evenly distribute resources across a full range of product problems rather than focusing on a few core value propositions where you can meaningfully differentiate. I can tell you, because I’ve experienced it firsthand, if you allow yourself to “peanut butter” your roadmap, there is a good chance you will commit the most classic of startup blunders and align on a product and go-to-market strategy that is too broad. In all likelihood, you will then over-hire in an attempt to execute on this roadmap and inevitably reduce headcount when you encounter bad assumptions or execution issues.
Lesson 2: Ask “Why Now?”
One of the unspoken rules of having the title of Product Manager is that you must speak in frameworks (just kidding 😄). Previously, I have written about a framework that a prior mentor had shared with me about called the “What”, “Why”, and the “Why Now”.
Reflecting on these last few weeks, I now believe that answering the question “Why should the business solve this problem NOW as opposed to focusing on something else?” is the most important question in this framework. It is very easy to fall into the trap of wanting to solve all of our customers’ needs right away because it is very difficult to have the discipline to be honest and say now is not the right time to solve this problem.
At my last company, we spent a lot of time on the “What” and the “Why” and, to be fair, we were actually quite good at driving alignment between R&D and GTM teams around the “What” and the “Why”. We did not, however, spend enough time truthfully asking ourselves “Why Now?”. I emphasize truthfully because, yes, we did prioritize what projects we worked on but this prioritization was usually done purely based on resource constraints. Answering “Why Now?” honestly means thinking through the possibility of never solving the customer need at all and being OK with that decision. Even when your company does a good job of maintaining go-to-market discipline, you will still find yourself “peanut buttering” if you don’t honestly engage with “Why Now?”.
Lesson 3: Shipping features does not mean you’ve solved the user problem
This is going to sound obvious but you cannot assume that by shipping a feature to production you have actually done anything useful. You must build a solution to a real customer problem and that solution MUST be intuitive (i.e. usable), reliable, and scalable. A trap of very early stage startups is that because so much of the product build is zero to one and you can’t rely on quantitative metrics to measure impact, you forget the need to take iterative approach to building product. As a result, product discussions often only involve conversations about features and timelines. My last company definitely fell into this trap.
This way of thinking can be incredibly dangerous for a few reasons. First, it actually takes a lot of time to go from shipping a software feature to production and then further iterating on it to ensure that you’ve achieved usability, reliability, and scalability. Every startup wants to ship product as quickly as possible, but a hyper-focus on features actually decreases product velocity. This is because it disempowers development teams and discourages fast iteration. Finally, organizations that align themselves around features rather than user and business problems are at a higher risk of disfunction and system complexity due to Conway’s Law; i.e. if we organize and align around features rather than problems, we tend to create teams and systems that appear overly complex and disconnected relative to the problems that they are meant to solve.
Conclusion
I took my last job with the mindset that I wanted to dive into the deepest pool I could find and challenge myself to rapidly grow as a product manager. Although my time there did not end the way I would have wanted, I am grateful for the valuable lessons and the people whom I worked with and learned from. This was not an easy post to write because I still feel a lot of guilt that things did not turn out better for myself and for the company. I take solace in the fact that hard-won knowledge is never earned easily and as a PM the most important skill that I can practice professionally and personally is maintaining a growth mindset and always asking questions from a first principles approach.
If you’ve read this post, I hope that you find it useful as you navigate your own career in startups or product management.