[ad_1]
My nine failures as a product manager and lessons learned
Recently three years have passed since I started working in the tech industry.
Over those years, I wore multiple hats, and each time I managed to mess up — a lot. And I am very happy about that. After all, the more we fail, the quicker we learn.
Let me share a few examples of my recent failures. Hopefully, you’ll be able to learn from them as well or use them as an inspiration for your own professional retrospective.
1. Fear of facing the facts
We had an important deadline to deliver.
The problem: we were closing our sprints with roughly 40% of the sprint backlog still in progress. Sprint by sprint, we told ourselves that this time we’d catch up with the roadmap.
Deep inside, I knew we were screwed, but it was easier to fool myself with false hopes.
When the shit hit the fan, we had to take a whole sprint out of the roadmap just to wrap up all our work in progress. It wouldn’t be such a big deal, haven’t I waited until the very last moment to do so.
Lesson learned: If things repeatedly don’t work, act immediately. Don’t just hope that, for some unexplainable reasons, it will work this time.
2. Not considering design for performance
We first designed and developed the site and then worried about the SEO.
Turned out that not only do you need specific page structures to be SEO-optimised but also site performance plays a critical role.
And apparently, you can’t have 4K images and expect Google’s PageSpeed Index (PSI) to be 100 out of 100.
We realised, after the fact, that our design decisions influenced our SEO more than we thought it could.
Lesson learned: To win SEO, you should also win performance. And if you want to win performance, you must consider it during the design phase.
3. Thinking that sending messages =/= communicating
I was managing a project with a very constrained budget. We already knew we would probably go above our initial cap.
I informed the client weekly via mail reports (he was the type that’s hard to catch on a call). Since we initially agreed on a specific cash reserve for cases like that, I didn’t overthink it.
Imagine my face when the client suddenly exploded over the budget situation a few weeks later — as if he had heard it for the first time. He even admitted that he read my warnings, but for some reason, he believed the prediction would become more optimistic over time.
That was a very tough conversation.
Lesson learned: Sending messages =/= communicating. Communication happens when we ensure both sides are on the same page, not when we press the send button. Always double-check if the other side understands the message the same way you do.
4. Not double-checking the riskiest assumption
I was a product owner for a brand new service within our main product.
Amongst our riskiest assumptions was a potential dependency on our point-of-sale software. We weren’t sure if the service would work with PoS as it is or if the team responsible for it would also have to implement changes on their side.
I gathered a team for a workshop, we discussed high-level implementation, agreed that we don’t see any PoS dependencies and called it a day.
Three months later, it turned out that we missed a critical piece of the puzzle, and we’ll need changes on the PoS end after all.
That late discovery delayed the launch by half a year.
Lesson learned: Double-check your riskiest assumptions. If the assumption is a game-changer, treat it with due respect.
5. Doing performance testing too late
We were building a platform for migrating newly acquired marketplaces. Due to the nature of the project, we had a somewhat waterfallish approach with one big bang release planned.
Once we had our E2E user flows done — roughly two months before the planned release — we ran performance and security tests.
That was bad.
Without going into unnecessary details, we needed months to fix all issues and bring the performance to an acceptable level.
Lesson learned: Finish E2E flows and start testing them ASAP. Then build on top of them and keep re-testing. Leaving performance tests to the very end is a big bet.
6. Surprising stakeholders with ideas
I was working as a corporate product manager and had some ideas on how to improve our product development process.
I proposed the changes during a meeting with key stakeholders and was almost crucified. People started arguing about it, threw various unrelated objections and killed the idea within minutes.
From a time perspective, for people who heard the idea for the first time, it might have sounded a little bit crazy.
I tried again, this time approaching people individually and refining the idea on the go. It also allowed me to get buy-in in a more manageable setting. It took more time but yielded a better result.
Lesson learned: For bigger initiatives and changes, get the buy-in of key stakeholders first, and THEN call a meeting.
7. Launching a product without a clear go-to-market plan
We spent a few months building a marketplace just to launch it without a clear strategy on how to solve the chicken and egg problem. Time passes, and the platform still has no traction at all.
Looking back, it’s understandable. The product wasn’t optimised for any growth channel. We fell into the trap of building a product first and believing that great products sell themselves.
Spoiler alert: they don’t.
Lesson learned: Distribution is everything. Think of it from day one.
8. Underestimating payments complexity
I was once scoping a subscription feature. We hadn’t yet decided on payment methods and providers, but since we were short on time, we had already started development.
What could go wrong? We just needed to integrate with a payment provider down the road, easy peasy.
It couldn’t be further from the truth.
Not only did we have integration issues, but we didn’t expect 3DS to break half of our user flow. Let alone these 20 payment-focused edge cases we realised we needed to tackle.
The overall effort estimate doubled.
Lesson learned: Don’t underestimate payments; the number of edge cases and threats they bring is enormous.
9. Forgetting the big picture
I was wearing a proxy-product owner hat, and we were building a chat-like extension to a CRM platform.
I immediately fell in love with the #messages sent metric; after all, engagement is great, isn’t it? So when it came to prioritisation, I always kept engagement in mind, and it steadily grew.
Once I was bragging about the engagement growth with the product sponsor. Then the reality hit. He didn’t care. Why would he?
Although we positioned the product as chat, in practice, it was more of a platform for various plugins and bots. Our objective was never for actual humans to chat with each other! It was a nice-to-have at best.
Although #messages sent might be a joyful metric, given our business context, it was nearly meaningless.
Lesson learned: Always remember the big picture. It’s ridiculously easy to fall in love with micro-optimisations that don’t move the needle where it’s truly needed.
[ad_2]
Source link
