Product Building: Iterating and Experimenting on Getting Work Done
by Quinnie Chen, Product Manager at Localz
“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 understood that we have an enviable focus on customers. However, 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.
Stage 4: Team Goals; Individual Champions.
Once we were on the same page and cleared out confusion and road blocks; it’s about tight execution. Having a clear team goal, either sprint wise or bigger program wise is great (this particular program took months to finish). However, it comes down to the individuals in the team to make it work.
I observed “then” agile approach of pick up the new cards in the backlog when you finish, but I saw the special modifications needed for the time. That agile approach works great for a very mature team with everyone hands on hearts for a bigger mission; for a less mature team with fluctuated number of people in the team (some are part time, or during uni vacations) it wasn’t necessarily the best way to achieve our goals in time, with fair distribution of workload.
So what I did I find out? Agile practices and any other industry practices are guidelines, and not a Bible. We have seen some hard working people and senior developers in the team naturally took on more workload while others were slow in finishing their cards. Cross skilling is a long term process that will address some of the problems here and benefit us sustainably, but it doesn’t address the other performance issues we have seen. So I ran a skill matrix at one of our retros to identify team’s skill strength and where they want to get better at.
To achieve our immediate goals of finishing the program on time, I mapped out a matrix to match component leads across features. This individual level of accountability that mapped into existing skill sets really helped us to push through the work and resolved issues as we go. The downside is people may get bored of what they were doing, which is what the cross-skill can bring more engagement to the team.
Stage 5: Elevate individual accountabilities.
Once we finished the big program with a base app; we moved on to smaller additional features to build on top. This gave us a chance to execute in team cross-skill pairing and also I started to delegate more responsibilities to the team so they started to feel and act more like an owner of the goals. I started to rotate the host of our sprint planning and retro sessions, so each of us get a chance to practice and show very diverse ways of leading the team. Specifically during planning session; I focused more on illustrating what the feature is about; how the user experience would be; One experiment seems to work well was creating a channel wide placeholder template for the team to break down the tasks at the same time on post it notes; we then look at the notes together to see whether anything is missing.
So what I did I find out? We were at a more comfortable position that the experts in the team were able to share some of their thinking process publicly with the team in a conversation, instead of their knowledge only visible at solution design document that may or may not be read by the team. The breakdown template as partially shown here, was also a great way to reminder everyone we should be designing and building a holistic experience, and piecing each other’s solution and thinking together to achieve the goal.
Stage 6: Look beyond the current sprint.
This is the last iteration of my experiments (until the next generation of iterations). Once we nailed 1 sprint planning, I looked into team feedback especially around the uncomfortableness when urgent priorities came to change our existing priorities due to broader scheme of things beyond the sprint. I believe transparency is the best solution for this and I started with a big white board with 3 sprints runway to bring forward thinking, work continuity, and prepare team to be comfortable with being uncomfortable.
So what I did I find out? The sprint goals has a mix of product feature build, clients work and tech debts and it provided fluidity to reprioritise within the fixed capacity, while still get the must have stuff done. It also naturally build a buffer if there is any unplanned production issues we need to deal with, so the portion of 10% tech debt can be traded off for production issue and support when we need to. And on the good days, we will be able to pull more tech debts and other tasks from our stretch goals.
Interestingly, the leave calendar kept me in check (as I am a terrible scrum master) and visually it helped me to set the right goals for the immediate sprint and beyond as it acted as a neutral negotiator of what is realistic to be achieved vs my expectations as a product manager.
What the team really liked about are the weekly milestones of 2 week sprint; and the easy to access sprint goals visible in the room when we do standup. I also confess I love the feeling of crossing the goals off when we finished them at standup.
As I cannot always predict and fill out 3 sprints capacity, the coming up product features and clients pipeline are another great way to give the team a hint of what might come up to fill the space.
So this is the latest iteration of how I ran the product team in building features that helps us to achieve our product vision; meet clients demand; and continue to build stronger platform for scalability.
What I have learnt over this six month process?
It seems like I am circling back around the initial thinking of injecting product feature build and tech debt into sole client services focus in our roadmap and development pipeline. But I am grateful for this experience to learn and practice bringing people along the journey. #ActionsNotWords.
The biggest lesson for me is about working with people, and be humble regardless of your experience. I will keep holding myself true to our company value “Diverse Thinking”, “Actions Not Words” and “Transparency”. Hopefully by sharing my stories, anyone joining us will see a snippet of how we hold our culture, and understand the meaning and purpose behind our company’s true values.
Republished from Quinnie Chen’s blog — you can read Part 1 and Part 2 here.
Like what you have just read? Hit that 👏 button — it lets more people see it!
