PM 102: Deep cut is better than long cut

It is quite common as a Product Manager to realise that there were cheese holes in your discovery work that cannot keep letting air in anymore. Your product might have scaled (with a lot of uneasiness) and you have managed to carry water for a while in the hope that you would be able to paper over some of the gaps but the load seems to be getting heavier and heavier.

When it becomes evident to you that the product lacks a proper Product Market Fit and that without going back to the drawing board, you cannot make any further progress, you should stop thinking.

Because it is only a one way road from there - the one that calls for having an open conversation with your teams around how you want to pivot (or in some cases, kill the product).

One of the hardest conversations in that respect is the one you have to take with your engineering colleagues. Why? Because they built it with their hands (fingers)!

A common and a rather myopic way of dealing with this is to either blame another team, the users, or the market (of course). A better way is to deal with this head-on, once and for all (even if it is excruciating for a few days) and explaining why metrics clearly point toward a very tough road ahead and why your users have stopped loving your product (better still if you have NPS or equivalent to share).

In the long run, the deep cut, though painful at first, leads to faster recovery and less drawn-out pain than a long, lingering cut. This usually helps in three ways:

1. Saves everyone time: When you communicate the new vision for your product, it saves everyone the time that might be spent in fixing major features over a protracted period. Instead of fixing onboarding first, then revealing two weeks later that the in-app flow needs to be revamped and then after four weeks finally revealing that the checkout needs an upgrade, it is better to take the hard conversation on where the product has gone wrong and what all needs to be fixed (or the trade-off between killing and fixing) so you can generate better ideas from team and synergies while delivering. In the long run, your time will become more productively spent.

2. Builds trust: Acknowledging mistakes builds more trust with your teams as long as you can explain why there were gaps in your discovery (or in general, why the product hasn’t taken off). While embarrassment might engulf you for the first couple of days, if you go prepared with a plan on moving things forward, your teams will appreciate you and will likely bring you all together for what’s next. That’s just how humans are.

3. Smarter in future than in past: Deep and honest conversations are the best product failure stories you can tell and still be proud of. It is always prudent to be smarter in future and not repeat the same mistakes instead of brushing your failures under the carpet and not learning anything from the whole experience. Remember the excruciating pain? That will stay with you and remind you of how strong you were and which fire hoops to avoid while talking to users or relevant teams or while reading the market.

Till next time, enjoy the sprint!