My Biggest Product Management Mistake
How I painfully learned to appreciate the fourth dimension
TL;DR - When starting a new SaaS product, even if your V1 ships quickly it will probably take several years for your product and go-to-market efforts to reach full strength. Plain on this! Build a product strategy that anticipates likely market changes, and set your own (and your investors’) expectations for this likely future.
One of my favorite interview questions to ask PM candidates is “What’s the biggest mistake you’ve made at work?” In this post I’ll share my own biggest mistake: the time early in my career where I built and executed a product plan that assumed our market would stay the way it was. I failed to anticipate likely changes in the marketplace and likely reactions from our competitors. The only constant in life is constant change, and by forgetting that I doomed our product.
Here’s the story: in my first PM job (at a large tech company) I led PM for a team that designed and built a V1.0 software product that was designed to replace networking hardware that our competitors sold for $5,000 per connected server.
Our business plan was simple: offer comparable but easier-to-use functionality in software, simplify the IT environment (one less piece of hardware to manage!), and sell it for $500 per server. Easier, cheaper: what could go wrong?
It was a good business plan… if we’d launched in a week. But, like most hard things, the product took a while: about 2 years from elevator pitch to initial design to MVP to betas to production release.
In the meantime, the market had changed. Thanks to Moore’s Law and competition, what used to cost $5,000 per connected server now cost 10x less—exactly the price point we wanted to hit! And competitors’ products now had more features and were significantly easier to use.
Our price advantage had evaporated. Our ease-of-use advantage was reduced. And now we were battling entrenched competitors in a more mature space. Predictably, our product failed to gain much market share beyond our enthusiastic early adopters.
What I learned: When building a new business, don’t build the product that the market needs now. Instead, build the product that the market is likely to need several years in the future. Don’t assume that the market and your competitors will stand still waiting for you!
In a standalone, well-funded company we might have weathered this speed bump by improving usability and pricing, boosting marketing, and pivoting to success. But, as is often the case, our “investors” (senior management at the company) were impatient. In the end we eventually decided to cancel the product and redeploy resources to products with better market traction.
This was another important learning: always be aware of your investors’ expectations and their definition of success. For example, if additional investment is contingent on a fast market win, then you must take a more short-term approach compared to the case where you have patient capital that’s willing to back you even if you have to pivot a few times before product/market fit.
Of course, methodologies like Lean Startup will tell you that these problems can be avoided by not spending 2 years building something before you know there will be market traction. This is good advice, and we actually followed it! We built our product hand-in-hand with early adopters, released early code, iterated quickly, etc. But knowing you have a few eager early adopters is *very* different from crossing the chasm to mainstream customers where customer expectations are different.
This was the final important learning: the product required to succeed with early adopters is usually different from the product that mainstream customers want. If you get lucky, mainstream adoption only requires “more of the same”: incrementally adding more features, more reference customers, more documentation, more marketing, etc. But in my doomed product’s case, we weren’t lucky. By over-relying on early adopter feedback I missed a fundamental fact about our market: our early adopters were mainly DevOps people focused on software who wanted to scale their server apps without having to deal with network IT people. But the mass market for our product turned out to be network IT engineers who preferred hardware solutions to messy software. What was a feature (“no hardware!”) for our early adopters turned out to be a fatal bug for the mainstream.
The lesson here: do your homework early about what a “pivot to the mainstream” will require. Don’t just assume you can double-down on your initial customers and everything will work out fine. One way to do this is to interview very large customers, even if you know you won’t be able to sell to them for many years. The purpose of these interviews is to provide an early warning system to understand how mainstream customers differ from your early adopters, and to highlight fatal problems (like our software-vs-hardware issue noted above) that may trip you up when you later want to “cross the chasm”.
All three learnings above have one thing in common: the need to think several years in the future while not neglecting day-to-day execution. Especially when launching a new product or company, it’s important to take a hard-headed look at market trends and to predict what the market is likely to look like when your product and go-to-market efforts are at full strength and you’re winning mainstream customers. Be honest with yourself, your team, and your investors about what it will take to succeed in *that* market, not only the market that exists today.
Epilogue: you’re not doomed to repeat the same mistakes!
A good thing about making mistakes is you can use what you learned to change the future! When I started as Head of Product at Cantaloupe, I kept these lessons in mind:
Plan for a future market.
Align with investor expectations.
Know the needs of the mainstream.
The last lesson was immediately useful. When I joined, our product was popular with early adopters but struggling to win mainstream customers. Remembering my earlier mistake, I went on a long road trip with my new team to interview large customers who weren’t yet in our target market. We learned that software integration hassles were the main obstacle; mainstream customers wanted a seamless, single-vendor offering instead of the patched-together solution of best-of-breed components that our early adopters preferred. (The reason for this was that early adopters often had in-house IT talent, while mainstream customers relied on vendors.) My team absorbed this knowledge and we soon pivoted our product strategy from a “depth-first” model that required integrations to a “breadth” approach that filled in competitive feature gaps and gradually replaced 3rd-party integrations with our own software. This turned out to be the key to winning the mainstream.
A few years later, I used the other two learnings—planning for a long-term future and paying close attention to investor expectations—when our Board started squabbling about whether to do another funding round and “swing for the fences” or to buckle down and achieve profitability. Hiring was frozen while our investors tried (for years!) to work out their differences. Meanwhile, product velocity was slowing and we desperately needed more engineering headcount. Using the lessons from my earlier mistake, I didn’t simply walk into the next Board meeting and ask for more headcount. It would have been shot down. Instead, I carefully built an investor-friendly (quantitative, graphical, and simple), dollars-and-cents business case using analysis of 1500+ JIRA tickets to project our likely roadmap capacity in three different engineering headcount scenarios. By showing the Board the likely outcome of this quarter’s hiring decisions 18-24 months later, we got approval to hire despite the overall headcount freeze.
Obviously, it’s better to avoid making mistakes the first time. But if you do screw up, it’s helpful—at least it’s been helpful for me!—to take an honest look at what you did wrong, and to mine that experience for ways to make a better future.