8 Mistakes I made as a Product Manager

+ the role Product Managers play in tackling technical debt

Image Credit: Dilbert Comics

In my 12+ years in product, I’ve made a lot of mistakes.

Here are 8 that I wish I could ask my younger self to avoid:

1. I made myself the customer.

I self-projected my mental model during solution design. I wasn't getting customer validation. Design decisions were inspired by personal preference.

👉 Lesson > Be the voice of the customer. Don't just talk to them. Engage, distill & extract their point of view.

2. I winged it instead of declaring ignorance.

I was afraid to admit that I didn't know something during standups & meetings. I'd try to ideate answers on the fly. I would interpret numbers ad-hoc & stitched "trends" the way I saw them.

👉 Lesson > It's OK to not know something as long as you commit to find an answer.

3. I thought copying features = easy wins.

Competition scared/inspired me. I thought referencing an existing feature served as a pretty good spec for an engineer. Turned out that reverse-engineering & rebuilding is harder than it seems.

👉Lesson > Every product is unique. Competitor features don't necessarily mean your customers want the same.

4. I pushed major features with no go-to-market plan.

I found myself in the build trap. As my feature factory cooked up a new enhancement or feature, I didn't think much about how users would discover, learn & adopt the feature.

Later on in my life, when I took on product marketing duties, I understood how crucial messaging, positioning and GTM plans are to the success of a product/feature launch.

👉Lesson > Helping users discover, educate & onboard themselves on a feature...is part of the feature.

5. I prioritized work based on the "loudest" voice.

Louder & pushy stakeholders would get me to act in favor of them. I felt intimidated. Ideas weren't judged on merit. I didn't raise concerns or ask revealing questions.

👉Lesson > Evaluate the idea, not the person saying it. And don't just form opinions (see pt 1). Collect evidence, feedback, insights etc. before politely sharing your point of view.

6. I over-engineered specs.

My specs would exceed 50 pages at times. I thought the more detail I'll pack in, the better the results. To kill ambiguity, I specified every single UI detail. Little did I know, I also killed design creativity.

👉Lesson > Spec length isn't important. What counts is achieving shared understanding with the team.

7. I thought everyone understood "product".

I tried using the team as a sounding board for advice on what to do next. But I found product management is a lonely field.

Engineering worried about tech debt & hailed that as the #1 problem.
Design complained about process & protested against lack of time.
Leadership wanted reports & numbers. They weren’t in tune with the details.

No one really understood my challenges which was to represent the customer’s/user’s interest but also drive the team to get to the next immediate stepping stone. My problems were rooted in finding a fine balance between tech, customer & business. Others wanted to pull me in one direction or the other.

👉Lesson > Educate the team about the customer. Weave personas into conversations. Let them listen to conversations of the people whose life their work is affecting. At the same time, be mentally ready to walk some paths alone.

8. Developed solutions in isolation.

I mistakenly thought that I had to everything before code was written. I never thought of leveraging my engineering & design team to ideate solutions to customer problems.

👉Lesson > Explain the "why" to your product team. Make them part of the problem & solution journey. You'll be surprised by the kind of creative solution you can uncover via collective intelligence.

---

The role PMs play in tackling technical debt

"Technical debt" isn't a problem solely for the tech team. Product Managers need to play their part too.

Unless Product Managers attempt to understand it, the debt will return - often, with a vengeance.

What's technical debt?

Imagine you receive an IKEA dinner table an hour before your guests show up.

Instead of screwing it up as per the manual, you choose to take a hasty shortcut and set the table up with a combination of tape, glue and hammered nails.

The table stands upright but it's rickety. It can't support the full advertised weight due to the sub-optimal assembly. You can't place add-on accessories either because the table has an unstable base & slants at an angle. It does the job but that's about it.

To fix this for future parties with larger turnouts, you'll have to rip out the adhesives, strip down a few parts and re-assemble a lot of the sub-components.

This pending rework = technical debt.

And that starts to bite when your friends start to wonder why you aren't inviting them for your famous dinner parties :)

So, how should Product Managers approach it?

👉 Unpack it.

The worst thing you can do is to turn away from it because you think you're unlikely to understand it. Some PMs think awarding the devs some sprint bandwidth will make the issue go away. That's a poor approach.

Get in there. Put a label on it.

Ex: Is it a database structure issue? Do we have an unwieldy search framework? Did we hardcode aspects that needed to be parameterized? Help in prioritization.

👉 Size the debt footprint.

How closely is the problem hooked to other modules? Are we even working on that module in the future weeks?

Ex: A poor implementation of global notifications might affect a lot of areas.

Ask why are we fixing it now? What happens if we don't fix it? What's the opportunity cost?

If "debt" resides in a feature that's lies cleanly outside your near-term strategic focus, you may not need to prioritize it.

👉 Identify the root cause

Based on historical evidence, what approach could you take to avoid debt in the first place? Sure, we're taking shortcuts, but how much incremental effort was the "right way"? Could we have just bought that extra time to get ahead?

Ex: If we had made a report's timeframe controls configurable (as opposed to hardcoded), how much additional effort was that really? 2 days? 1 more sprint?

👉 Was debt a conscious decision or accidental?

Was this issue created because engineering consciously chose the shortcut to save time OR the requirements weren't clear? Was it because you as a PM didn't clarify how a feature was going to evolve over time and the architecture was prematurely designed?

Ex: if you didn't mention that prices on your e-commerce marketplace will support currency conversion in the future, then architects might lean towards a short-sighted solution. In this case, the debt is attributable to you as a PM.

-

In conclusion, Product Managers need to consider technical debt as a team problem, rather than an engineering guffaw. While engineering can help with the technical specifics, everyone should collaborate on how best to burn debt in view of where the product is headed.