2. Process is a means to an end.

I am quite a process driven person. I think that has to do with my regimented Singaporean education… or just my insane need for control. But that’s a story for another day! What I’ve learnt recently is that part of being a good PM is to not miss the product-forest whilst in the process-trees. (To get this analogy perfectly right I had to google a proper definition of the original.)

Let me clarify. Process is a means to an end to best understand problems. The most interesting problems tend to be the large, tangled up, feels-like-i-am-wandering-into-a-maze-with-my-eyes-half-closed kind of messy. This means that mapping it (as a Product-Person should) often requires quite a lot of “cleaning”. For example: scrolling through rows of data, recording interviews, listing out use cases, creating spreadsheets, and coding feedback. However, I feel like it’s quite easy to forget that these processes are really just there to help you to better understand problems.

The word “help” here is crucial, because it is easy to get bogged down in the all the process to the point where it no longer helps, but hinders. You start to feel that you have to do the same repetitive things just to be consistent, even though the product/ team outgrows the need for it. You have to furiously take loads of notes during feedback sessions, when actually it might just make sense to fully engage in the conversation and decide what new frustrations the user is facing and why. You start to consider every single “what if” in order to roll out the perfect feature — but forget that what’s important is that users start… using.

A fast growing team and company should expect that as the team, product, and strategy changes so should the processes that are meant to support them. If we want to be innovating, changing, and creating — the processes we use should be a means to an end but nothing more.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.