Product Build - iterations and experiments on getting work done (Part 1)

“Take a risk and keep testing, because what works today won’t work tomorrow, but what worked yesterday may work again.” Amrita Sahasrabudhe

Every new position is a new journey for me. Without doubt the temptation to bring your old and successful practice into the new environment is difficult to ignore on two counts. One, it's easy and convenient and proven to work and. two, it can help you quickly establish your role in the new environment with fast delivery of your values.

I have been guilty of proposing something I think would work (with a genuine and good intention to bring values to the company instead of personal gains and egos), but on reflection the adaptive paths we've been on as a team, I wish I was more conscious of the bias I had at the very beginning and took a step back to understand my environment and context first. I hope that my journey from proposing something without enough understanding, to eventually making it work to fit the environment will make you think differently, regardless of whether you are taking on a new challenge, or trying to improve your current practice as a leader.

When I first joined Localz I already understand Localz has and had an enviable focus on customers; In order to share the products outside of existing markets, we needed to deliver a structured/robust framework. My failing was not appreciating the immense about of sweat and long hours had been poured into the product set. Looking back it's like expecting a seed grow into a tree in one day. This iterative journey has changed me and here are the six stages as I feel them:

Stage 1: Naive and Ambitious: I proposed a framework that is illustrated below to explain how I visualised the team operating to achieve our goals. It made sense to me and still does in theory (if we are starting from scratch), but I wish I had more empathy to understand what has been working and what hasn't before I drafted this framework. During this stage, I faced natural and expected doubt/fear of change. As the person who introduces or initiates change, you often brush over other people's concern or even wonder why others don't see your point (yet). But we often forget how we felt when we were on the other side. If you don't get what I mean, try this now: If you are a right hander, try draw a face use your left hand (and vice versa). Did you feel the difference? And how would you show/teach a person who has never drawn in left hand?

So what happened after that? Lucky I was quick to get the cue and sensed some emotional resistance towards dramatic change to how the teams were operating at the time. I focused on the purpose of my role instead of forcing the change, and analysed what I could do to help immediately ease the challenges we were facing at that moment. By focusing on small change initially it helped to pave the way for greater change.

Stage 2: Get hands dirty and put your theories to the test. So it was timely when I was asked to own a product line. The immediate need was to develop the next version of our mobile app and relevant features. There is a saying, to find out whether you are a rebel (break rules for greater good) or a troublemaker (break rules for the sake of it, or personal gains), it is measured by your deliverables. That was the key moment that I got a chance to test myself......even though I never thought I was a rebel.

So as logical as I could, I made some high level plans of when our clear vision of the app will be finalised; when those nitty gritty writings of user stories will be finished to make development easy as a breeze; when the development with clear scope will be completed; and when we should be able to finish end to end testing, ready for product launch and client's implementation.

So what did I find out? I actually adjusted the delivery timeline at least 3 times across multiple sprints; and what I learnt was a plan is just a plan. In reality things rarely happen as you planned perfectly (unless you are talking about a grand scheme level). I knew if the plans kept changing I would have to embarrassingly explain to clients multiple times the goal post had moved out and this was not going to solve the problem but rather, would be likely to result in finger pointing blames. So instead of dedicating all my energy on stakeholder management and how to deliver those difficult messages, I invested more time to look deeper into what caused the delay within the team.

Stage 3: Get on the same page, literally. There were a few issues across the board, but one thing I could help to make it better was to bring all the scattered information together, such as design pattern, screen flows, the user stories relating to each flows and technical components. It may sound ironic as a software company where everyone is digital savvy, but I decided to put up a wall to map out the scattered information.

So what I did I uncover ? As a team jumping directly into digital tools is like writing a lot of letters that never get sent out, or reach a loved one. So we literally need to be on the same page, and I personally haven't found a digital tool that facilitate my 2 needs: 1 visually map out information and get everyone on the same page so they can see how their work contribute to the big picture; 2 have a constant reminder and involve conversations/debate in person to change the big picture.

Once we get into the rhythm, this wall has became less important and it is more of a visual reminder of what we were working on instead of daily discussion of the tasks and progress tracker.

To find out my next 3 stages of iterations, follow my journey in Part 2