You probably won't kill anyone when you make a mistake as a product manager or a founder, right?
(Unless you work in certain industries or deal with life-critical systems.)
However, a mistake that's serious enough can in fact kill your product, or your whole business. Definitely will in the long run.
I've made my share of mistakes first as a founder, then as a PM, so that you don't have to.
Let's broadly categorize them in 3 different buckets:
- Neglecting the fundamentals.
- Focusing on the wrong things.
- Not focusing at all.
Let's start with the fundamentals:
Neglecting the fundamentals
Like it or not, you gotta start with the fundamentals when you're in charge of a product or a business.
- Get them wrong, and nothing else you do matters in the long run.
- Get them right, and you'll reduce the impact of the mistakes you'll inevitably make.
You can try and fake many things 'til you make it, but you can't fake the fundamentals. If you have no idea what you're doing, you won't make it.
When I think of product and business fundamentals, I think of three main areas:
- The market. Failing to understand it.
- The strategy. Poor, or non-existent.
- The finances. Being sloppy with them.
Seriously, early in my journey I had no idea how these things work. (Un)fortunately, I got lucky having built a product that people wanted almost out of the gate, so I assumed I knew it all and didn't bother figuring out the fundamentals for a long time. These mistakes not only made me waste time and effort moving slowly, moving in random directions, and doing the wrong things in general, but their compounding over time was the reason I eventually failed to become the next Jeff Bezos.
There's more than these three things to building a successful product, but that's what I struggled with the most as a software developer turned founder turned product manager.
Failing to understand the market
Studies consistently show that failing to understand the market is among the top reasons for startup failures. This includes the lack of product-market fit, no market need, and other market-related issues. In other words, this means creating something that doesn't solve a problem people have, or solves a problem that isn't urgent enough for people to pay for your solution.
Let me tell you a secret:
There's a right and a wrong way to build a new product (or start a business).
- One way is to discover an opportunity (a problem people face), validate your idea for solving it, then create a product that does it.
- Another way is to stumble upon an idea, get excited about it, and immediately start building hoping they will come once you've build it.
Which one's the right one?
You know the answer, and I know the answer, but it doesn't stop PMs and founders from building things people don't need. It certainly didn't stop me from doing this more than once.
I have a simple explanation for why creators choose the wrong way to build their thing.
As a creator, you enjoy the process of turning an idea into reality. It's fun and rewarding, especially in the early stages. It doesn't matter if you're an engineer, an artist, a writer, or a musician, as long as you enjoy the craft, you probably enjoy tinkering with your projects. But creating a product or starting a business isn't exactly the same as tinkering with your projects. Strategizing, researching the market, validating hypotheses aren't exactly considered fun activities.
When I was a basement-dwelling software developer, I hated talking to people. I also hated to think that an idea I just came up with might actually be worthless. That would mean I'm worthless! So instead of spending a little time (and comfort) validating my idea and (probably) getting disappointed, I preferred spending a lot of time building something and hoping I'm right. I assume I wasn't the only one feeling this way.
The reality is of course that not spending a little time to understand, validate, and get disappointed means wasting a lot of time building something no one wants to get disappointed on a much larger scale down the road.
Poor or non-existent strategy
Understanding the market and validating your idea is step one. But knowing what to build doesn't mean knowing how to build it and get it to the market. For that, you need a strategy.
If you're like me in my early days, you don't think much about strategy. That's what corporates do in their stuffy conference rooms. Why would I need a strategy when I have this amazing idea for a product that's better than the competition? I can probably put it together in a couple weeks or months, launch it, and boom, success. Sound good?
So for many creators, the strategy often boils down to:
- Come up with an idea.
- Create the product (doesn't matter if it's software, a book, or literally anything else).
- Launch it (whatever that means).
And let me say this: if you do actually understand the market and have validated your idea beforehand, it just might work out like that. But I'd bet you don't, and you haven't. If you had, you'd put together a strategy that's something more than "I'll build it and they will come".
And when that's your strategy, a more likely scenario is you build something and they don't come. If you're unlike me, at this point you'll quickly understand you've been wrong, and will get back to the fundamentals. I didn't do that. Instead, I spent an excruciating amount of time throwing different seemingly random ideas at the wall waiting for something to stick. It took me way too long to run out of ideas and the desire to keep going.
Why would you risk wasting precious time trying to make it without a strategy? In my case, it was because I knew how to build things, but I didn't know how to strategize. And I was too impatient to figure it out.
The solution is simple: realize that a proper strategy is a fundamental part of creating a successful product or a business. It's literally part of the creative process. Then, accept that you shouldn't be doing anything else until you figure this out, by yourself or with the help of others. Besides, you don't need to be a superhuman or a corporate to strategize. It's not hard, you just sit down and figure it out.
If you have time and skills to build your product, you definitely have time to put together a strategy first, and to acquire skills needed to do that if you don't have them yet.
Being sloppy with finances
Another top reason for startup failures? Running out of money.
Building a successful product isn't just about creating what people want. It's also about getting people to pay for it, and managing revenue wisely to keep going in the long run.
When it comes to startup and business finances, I think of three main challenges:
- Where to get the startup capital?
- How to get to revenue and profit?
- How to allocate your resources?
Product managers have it a little easier than entrepreneurs with two of these tree questions. If you're a PM, you'll likely have an allocated budget already, although you might need to request additional funding.
In any case, you need to understand how finances work if you want your product to succeed in the long run. And just like with the market and the strategy, it's easy to overlook the question of finances when you're just starting out. Make some early assumptions and think you'll figure it out later. Well, the road to failure is paved with flawed and unrealistic assumptions.
Getting the initial capital is easy today compared to what it was a decade ago. If you're a founder, you'll use your income and savings, get a loan, or raise a fund to build the MVP. No matter which way you choose, have a clear plan of how you'll spend that initial capital to get to revenue. A common mistake here is burning through cash without ever getting to self-sustainability.
Now getting to sustainable revenue is the hardest part. Depending on your product and industry you'll have a hundred possible ways to monetize your product. From one-time purchases and subscriptions to ads, transaction fees, services, and about 95 more revenue models. Possibly multiple at once. But each model comes with its own strings attached, and the mistakes here range from choosing the wrong monetization model to failing to implement it right or relying on flawed assumptions.
If you assume you'll grow your user base 35% MoM each of them paying $100/mo, and see 3.5% growth instead, that's a problem.
Finally, there's the question of allocating your resources. Whether you're still burning through your initial capital or reinvesting revenue, you can do it in different ways. As a solopreneur, I used to spend most of my revenue on fancy new tools or on my own paycheck. For founders and PMs, the typical expenses might be operating costs like salaries and marketing expenses.
No matter what stage of your product or your business you're at, you need to understand what you're doing and why. Remember the ROI. As an inexperienced startup founder, I used to burn through cash based on my gut feeling without thinking much about the ROI.
Well that's how you go bankrupt.
Focusing on the wrong things
As a PM or a founder, you'll have a million things going on around you. Focus on the wrong ones, and you'll lose track of the big picture, miss important signals, and make poor product decisions.
Your PM focus needs to be perfectly balanced, as all things should be. This is particularly important in smaller companies where you're often setting (or at least suggesting) direction not just for your product, but for the company as a whole.
Before I became a PM, I ran my own software business. But before I had a business, I was a simple developer trying to make it as a product entrepreneur. And since I had zero product management experience, I was too often focused on the wrong things while completely overlooking the right ones. And even though this experience made me into a PM, it didn't end well for my business.
When I think of misplaced focus, I think of a few things:
- Architecture and technology
- Design and UX
- User feedback
- Sales and marketing
Architecture and technology
Technology doesn't always matter, but it still kinda does.
Around the time I quit my software developer job and became a freelancer, I had a few business ideas. And since I was a developer, I spent at least a month comparing frameworks and deciding which one to use for my business. Then I spent another few months designing the ideal architecture for what would become the next Amazon.
Long story short? None of this mattered.
The business idea flopped right out of the gate. Technology wasn't the problem, the idea was. I could've picked literally any framework and the result would've been the same. Months of life wasted.
But not thinking about the technology at all can backfire too. Here's another example from my own life. My Amazon killer flopped, but the engine I've built was mildly popular among developers, just enough to sell it as its own product. So I took that and turned it into a business without evaluating its long-term feasibility.
A few years later we've found ourselves being dependent on an outdated technology, but by that time the product was too complex to easily switch to a different solution. We didn't switch , and that was one of the reasons it didn't end well.
Lesson learned: don't obsess over technology, but don't disregard it completely.
Design and UX
Steve Jobs might have been obsessed with design, but you're not Steve Jobs.
They say content is king, I say UX is king. I call myself a UX-focused PM for a reason. I love UX. If your product has terrible UX, your users will jump ship as soon as a more user-friendly competitor comes around. And it will come around.
I didn't think much about design in my early solopreneurship days. As a developer, I was focused purely on features. More features = better. The product was feature-rich, but ugly, and a pain in the ass to use.
Fortunately, it didn't take me long to get UX. And for the next few years, UX became one of our main advantages. Most of the competition was more feature-rich, but a pain to use. On the other hand, users loved our product.
Unfortunately, this early experience made me obsessed with UX. Including in places where it didn't matter much, or at all. I spent months of my and my designers' time trying to make our blog pixel-perfect. Our blog, Carl! How much does the design of your blog matter for the success of your product?
Yes, Steve Jobs was obsessed with design. Sure, UX was a component to Apple's success. But people don't buy iPhones because Apple's <h1>'s are exactly 56px tall and #1d1d1f.
This made me lose focus on what really mattered, such as our actual product, our marketing, and our competition. And - you've guessed - it didn't end well.
Lesson learned: UX is king, but it isn't all there is.
It's not about building more features, it's about solving the right problems.
Products aren't about features, products are about solving problems. Let's continue the story from my early solopreneurship times. I was focused on features, I've built and shipped dozens of them every release. The number of features shipped was a proxy for success, and I felt great about it.
The result? It didn't take long for the product to become bloated, bug-ridden, and absolutely unmanageable. I was spending more time on support than on anything else. Eventually, I've made a decision to nuke a good half of the features. I was worried users would hate this, but the reality was most of them didn't even notice.
However, there will be features that do solve the problems that are critical for your users. If you don't pay enough attention, you will either miss them completely or implement them poorly, and that will have negative consequences for your product.
Lesson learned: don't just build features, solve problems.
Listen to your users, but don't do what they tell you.
I'm still guilty of listening to users too much sometimes, although I've become better at it lately. One of the reasons I had ended up with a whole bunch of features I had to nuke was I've built anything any of my users asked.
Taking your users words at face value and building whatever they ask you to build is a great way to end up building exactly the wrong things. You're the PM, not your users. They might think they know what features they want, but that's not always true.
However, back then I got the wrong takeaway out of this experience. Instead of listening to everything my users say, I pretty much stopped taking their opinion into account completely. I imagined myself being Henry Ford saying "If I had asked people what they wanted, they would have said faster horses" or being Steve Jobs and shipping the first iPhone without a keyboard. I thought I knew better than everyone. I was wrong, and I failed.
Lesson learned: listen to your users, but remember it's just one piece of the puzzle.
You are not your competition, but they are part of the market.
You can't become obsessed over your competition because you risk losing the big picture. You aren't competing against your competitors, your goal is to build the best possible solution for your customers.
However, you can't disregard the competition altogether. Whether you like it or not, they're part of the market you operate in.
At different times of my entrepreneurial journey, I was either too focused on the competition, or not paying enough attention to it. Don't be me.
Lesson learned: know your competition, but don't obsess over it.
Not focusing at all
Finally, there's the problem of the lack of focus and direction in general.
No matter how good your strategy is, you'll still fail if you can't focus on getting the right things done swiftly. And if you're a PM or a founder, you'll have plenty of opportunities to lose your focus with all the things going on.
Two common mistakes are not being good enough at filtering incoming requests and chasing shiny objects.
Yes man, no man, I don't know man
They say one of the most important skills of a PM is to learn to say no.
As a person in charge of a product, you will get bombarded by hundreds of questions, requests, pleas, and directions on a daily basis. You will get them from your teammates, your users, other stakeholders, and literally anyone else you interact with. You'll also have to juggle hundreds of thoughts and doubts of your own.
Two problems with this:
First, it's easy to get overwhelmed and fail to do anything at all. Analysis paralysis is a real challenge for PMs.
Second, it's easy to resort to automatic behaviors as a shortcut, i.e. saying yes or no to requests without giving them enough thought.
As a PM, you can't be automatically agreeable or dismissive. Being too agreeable means wasting time doing things you shouldn't be doing, and being too dismissive means failing to see real opportunities.
The solution is to use a decision-making framework that lets you quickly evaluate requests without overanalyzing them, discard the irrelevant ones, and keep the promising ones for further review.
Chasing shiny objects
Just like analysis paralysis, the shiny object syndrome is real.
This is where you're guided not by your vision, mission, and strategy, but by what's currently new, trendy, and seemingly more promising. And this isn't just about the global tech trends either, the syndrome can be limited to just a certain part of your job. We've seen chatbots, DTC and crypto, we've also seen the trends in tools, technologies, and methodologies.
The solution is to stick to your fundamentals. If your company has nothing to do with crypto, you probably don't need to jump on the web3 train and start building a blockchain-powered version of your product because that's what everyone's doing.
Be aware of your surroundings, but don't get caught by irrelevant trends.