Why You’re Struggling as a Product Manager (and How to Fix It)

Aim for the crooked path, not the straight one.

Here’s a reality check to help you get on the right track.

Product management isn’t a straight path, predictable up front.

Is that news to you? If it is, it might be what’s preventing you from reaching the vast demands placed on you. For me, I struggled too long before it clicked. What clicked? Shifting my perspective to embrace the crooked path. It results in less work, fewer headaches, and sooner value achievement.

Let me explain.

If Only We Had a Crystal Ball.

As product managers, we have lofty expectations. We must delight users in a way that works for our business. Why is this lofty? Because we don’t have a map. There’s no clear path to achieve this. We don’t know more things than we do know, especially at the beginning.

• We don’t know a timeline to build it.
• We don’t know our users and their pain.
• We don’t know how much cost it will take to build.
• We don’t know what will solve our users’ problems.
• We don’t know the technology snags that will surface.
• We don’t know if solving our users’ pain will give us a business impact.

Yet, at the start, we have the most pressure to predict these things.

When asked to tell the future, the way we answer predicts our success. We can fall down the rabbit hole of acting like we know it all. Or we can admit we don’t.

I know I’ve fallen into that hole more times than I can count. But I’ve learned I was aiming at the wrong goal.

Aiming Right: Our Response to the Pressures to Predict the Unpredictable Is Crucial.

When I used to put on the mask of control, I aimed to paint a rosy picture. One that illustrated I knew what I needed to do to develop a winning product. Then, all I had to do was organize the work and the workers with precision and make it happen.

I aimed at and followed a straight path to hit an arbitrary target.

Here’s the problem. Even if I perfected my ability to aim straight and hit a bullseye, I ended up hitting the wrong target. It was wrong because I set the target at the beginning when my ignorance was highest.

I did not aim at learning.

Learning allows us to change our course and our target after each step based on prior step evidence.

Here’s what’s tricky. Without learning, we can still deliver. I’ve seen many product managers who always deliver what they promise. Heck, I was one of them. But 80% of what we deliver is often not what users actually need in the time it’s needed.¹ In the end, the odds aren’t in your favor. Delivering what you promise misses the mark.

Learning lights our path in the dark, making our next step clear.

4 Common Pressures to Predict the Future and How to Overcome Them By Aiming at Learning Instead

Most of my product management mistakes boil down to these 4 areas. It comes down to me trying to look like I was in control versus admitting I wasn’t and putting learning and users first.

Pressure 1: Pleasing Stakeholders Who Demand Timelines

“When will you be done?”

This is the dreaded question. Why? Because I know the least when I am asked it—at the beginning before I start.

And in the beginning, all the visions of grandeur are dancing in my stakeholder’s heads. I’ve envisioned a better future ahead with them and now the pressure is on. So, “When will you be done?”

The urge to throw out an answer is strong. I’m excited. They’re excited. And we all have a business to run. Real businesses have dates, deadlines, and milestones, right? They do, and they’re the wrong target.

In these moments, I must remember and repeat my favorite mantra.

No user remembers your product for you delivering it on time.

Instead, my users will remember how my product made them feel. How in an instant, it increased their productivity. How it made their lives easier.

I don’t know when I will achieve that. I only figure that out by doing. By learning as I do.

So, when we get asked this question, we should respond, “I don’t know. But let’s pick a near-term goal in the direction of our vision and start trying out our ideas. We have to see if those ideas even stick.”

It takes more courage to say that than to throw out a date. It’s no joke. So, stay strong. Giving a completion date makes you look in control at the time, but it makes you look foolish in the end. Odds are you will miss it or cut corners to make it.

Don’t give in. Hold on to action and learning, not dates.

Pressure 2: Betting on Hope When Evidence Says Otherwise

Hope is a poor bet.

Yet, we often turn to it when things aren’t going as planned.

• “We will pull it off, I know it. We always do somehow.”
• “Who accomplished anything great by giving up when times got tough?”
• “It didn’t test well with our cohort. That doesn’t mean others won’t like it.”

Wishful thinking is aiming wrong. You are ignoring the insights right in front of you and sticking to your flawed path. To what end? To be honorable? To look like you were right all along? To save your job?

Believe me, it’s a losing battle. You end up looking like a fool in the desert waiting on a rainstorm.

I chased a plan with my team once when we had no hope of succeeding.

We ended up delivering what we promised, but the results sucked. We were mentally spent, burned out. Our users didn’t end up using what we built. In no way would I call this a success. Yet, we hit the plan. The organization had confidence in our ability to do it again. And the cycle would have continued unless I stopped it for a better path.

The better path was, you guessed it, to embrace learning and act on it. We now do this in three ways.

• When we learn our plan is unachievable, we change it.
• When we learn our solution is too complex, we find a simpler solution.
• When we learn our users don’t like our solution, we try something else.

Don’t force your initial idea to work. Be nimble. Shift when you learn. This is what will keep you honorable, savvy, and employed.

Pressure 3: Avoiding Rework When Learning Demands It

“The one thing we must avoid is rework.”

I’ve heard this statement uttered many times over the years. It stems from a “measure twice, cut once” mentality. I know they use this saying in woodworking to avoid wasting wood by cutting the wrong length.

Somehow, this thinking made its way to the product world. We think we can get it right by thinking and analyzing better up front. So, we measure twice (sometimes five times) before we make a move. But software product development is far from woodworking.

We miss a key truth when we try to avoid rework.

In product work, we don’t know before we take a step if it’s the right one.

So, even if we measure five times and cut once, it won’t matter if we choose to cut the wrong thing. So, it is better to go ahead and try the cut and test it out than to waste time perfecting the cut.

I don’t spend months toiling to perfect my product before releasing it into the wild.

1. I start modest, with a simple, inexpensive version.
2. I put it out and get feedback. I tweak it, throw it out, or evolve it.
3. Then, I stop when my users love it and when it solves their needs.

One step forward, two back is the product dance we must all perform. Going back (rework) is not a setback; it’s a product dance move. And it requires us to be light on our feet, not heavy with too much forward momentum.

We must dance, not charge, to the product outcomes we desire. And this requires us to expect and embrace rework. We must aim at learning.

Pressure 4: More, More, and More Features When Less Will Do.

“Just this one more thing will make the product usable.”

Ever heard that? I have. In fact, I have heard it almost weekly for over twenty years. It’s but one variation of our obsession with feature bloat. You may have heard others.

• “If we build it, it will attract attention.”
• “Let’s build this just in case we need it.”
• “We need to build it because our stakeholder wants it.”
• “We will eventually need this in the future, so let’s do it now.”
• “I’ve seen this use case once before. We need to cover this situation.”
• “We have to knock our first release out of the park and wow our users.”

Building “just in case” and adding things before we need them makes your bet too large. Big bets are risky. Swinging for the fence like this results in a strikeout more than a home run.

We’re aiming at what we “think” we’ll need, not at what our users actually need in the time they need it.

Every feature we build in product work has the potential to solve a need. If we keep adding more features before we try them out, we aren’t learning and we aren’t solving any pain. We need to keep our solutions modest and release them fast. This puts our ideas out into the wild. Then, we can harvest learning if it doesn’t solve our users’ pain or harvest value if it does.

More features mean delayed learning and delayed earning. Instead, do less, learn more, and, perhaps, earn more.

---

That’s it.

Admitting we have an aiming problem is the first step to recalibrating our targeting system. Instead of predictive control, we must aim at learning.

Four common scenarios pressure us to aim at control, at predicting the unpredictable.

1. Answering the dreaded question, “When will you be done?”
2. Betting on hope when things don’t progress as planned.
3. Trying to get it right the first time when it never does.
4. Adding more features to cover every scenario.

But this is aiming wrong. It assumes we are in control. And it shuts out learning.

When we learn after each small step we take, we can use evidence to reorient after each step. This is why we must aim at learning, not control, predicting, and wishful thinking.

Learning leads us to earn value sooner. It’s a crooked path, sure. But a crooked path to success is shorter than a straight path to failure. So, I take the crooked path, the learning path. Will you? Have you? Let me know your experiences with this choice in the comments.

---

➡️ Sign up for weekly insights like this. Learn about returning to the fundamentals that make product teams unstoppable. Join a community of like-minded professionals committed to achieving outcomes sooner.

---

References

1. Thomas, S. (2019). 2019 Feature Adoption Report. Pendo.io. Retrieved from https://go.pendo.io/rs/185-LQW-370/images/2019%20Feature%20Adoption%20Report%20Digital.pdf