Driving Product Organizational Process Change at Scale
Established in 2010, Bukalapak is an online marketplace based in Jakarta. Its number of employees has doubled each year for the past few years from 300, 600, 1200, to 2400. As the tech industry is a relatively new industry in South East Asia, the company has employed people from different industries outside of tech.
With almost half of the employees being members of a traditional tech company (Product, Technology, Design, and Data), our Product Discovery, Development, and Launch processes were very challenging because so many members of the team have had very little or no exposure to this way of working in their previous roles or companies.
I joined Bukalapak as VP of Product a little over a year ago. We have been developing, rolling out, testing, and tweaking a standardized product process for the company since then.
Back then, there was no clear expectation on responsibilities of each role which caused gaps. Product managers usually ended up filling those gaps. For example, I found out a few product managers were doing technical API documentation for their teams. It was neither productive time spent by them, nor was it effective because they might not have had proper training to fully understand what an API is to be able to create proper documentation. The engineers would be more appropriate to do that instead.
Moreover, each of the product teams had a different product process at that time. This caused expectation mismatch and communication problems across functions. For example, some of our new product releases caught our customer service agents by surprise because the product managers didn’t communicate with them. There was no clear expectation of how early a product release should be communicated to the other teams. Some product teams did that weeks in advance, some did that just a couple days before the release, some didn’t do that at all, unfortunately.
We made lots of mistakes trying to fix these problems, but we’ve come a long way. I’d like to share some of the learnings here. The main takeaway is not about what process we implemented, but rather how we got there.
Top-Down vs. Bottom-Up
What didn’t work for us: When we started developing the process v1 in Q2 2019, we followed the Top-Down approach. Myself and other cross-functional leaders in the company worked together and came up with a responsibility matrix that describes the responsibilities of each role in each product stage (Discovery, Development, and Launch). Eventually, the implementation of this process fell short because the employees didn’t feel ownership of this process handed down to them. “People don’t resist change. They resist being changed.” — Peter M. Senge
What worked for us: In Q4, we changed to the Bottom-Up approach (v2). We built a working committee consisting of members from Product, Technology, Design, and Data. The committee consists of twelve employees and we had four hours of weekly workshops for two months. From the product team, I selected some product managers who had good tenure in our company and those who had experience outside to share best practices. With this bottom-up approach, we observed much better ownership and commitment from the team to implement the process successfully end-to-end.
KISS (Keep It Simple, Stupid)
What didn’t work for us: In our process v1, we listed out fifty steps that ended up to be confusing and difficult to remember. We defined fifty steps across three different stages: discovery, development, and launch. And we documented those in an elaborate spreadsheet. That was far from KISS.
What worked for us: What we did right in process v1 is we introduced the DACI framework which I learned during my time at Intuit. DACI stands for Driver, Approver, Contributor, Informed. There are many articles about this framework online. We identified the DACI in each step of the process, especially the driver. This helped in reducing the number of responsibilities with unidentified drivers which oftentimes would go to the product managers’ plate. This protected the product managers’ time to do more important things such as meeting customers. We carried the DACI forward to process v2.
We also simplified our process v2; from fifty to ten steps by combining and removing some steps to be as concise as possible. We focused on what to accomplish instead of the how. We summarized those steps into one page and distributed it to all employees so that they can easily remember. The additional details of each step including the DACI are given as supporting documents for their reference.
Big Bang vs. Phased Roll
What didn’t work for us: We launched process v1 in Q3 2019 with a big bang approach. We organized a two-hours broadcast to all employees explaining each step. We were naive enough to think our job was done and the product teams would start implementing it and improve over time. A quarter later, we didn’t see much improvement. That failed BIG.
What worked for us: After we came up with process v2, we piloted it to only two product teams for four sprints. A couple of the committee members and agile coaches were embedded in the teams to give support. We monitored and gathered feedback, made adjustments, and relaunched to the next few teams. It took us more time to roll out to sixty product teams in the company, almost one quarter. However, we were able to identify what worked and what didn’t, what needed clarifications and improve the process early. We then shared the experience from the pilot teams to the rest of the teams to lower any change resistance.
“The process is clearer than ever before. The discovery makes the planning phase more seamless and it affects the whole process onwards.
“ Previously all steps seemed to be driven by PMs, now everyone knows what to do in each step, has some ownerships of the process and the product released, this empowers the team”
Communicate, Measure, Support
What didn’t work for us: For process v1, we communicated once and we thought it was done. We didn’t do any follow up to measure. It was a mistake.
What worked for us: We communicate the process v2 in every opportunity we get including 1–1s, team meetings, and town halls. I read an article and this sticks to my mind, something like, “when you start to get tired of communicating, that’s when people start to listen”.
We also measure the effectiveness of the new process regularly. One of the ways we find very effective is through “Pulse Check” live survey sessions. It’s an in-person team meeting with the full members of a product team. We set up a session with each team once every six months. A moderator, usually not a member of the team, goes through a set of twenty questions designed to measure how well the process has been implemented by the team. For example “How well are the metrics for your products defined?” or “How well are the user stories written?”. For each question, the team members anonymously answer (Strongly Disagree to Strongly Agree), and then the answers are revealed altogether. A successful session is one that brings out polarizing answers for some questions into a follow-up discussion where team members discuss the disagreements and identify action items to improve. We set the basic rules at the beginning to make it a safe environment: Full Participation, Honest, No Blaming. The feedback of these sessions have been great, team members enjoy the productive discussions, they feel safe, and they work together to define action items to improve their collaboration.
Finally, we give support to product teams that face challenges via coaching. We understand that change can be difficult, a good support can make a big difference and provide some safety instead of simply enforcement.
Be Involved and Be Patient
As leaders in an organization, we need to be heavily involved in driving the organization-wide changes from planning, aligning stakeholders, building change committees, measuring results, getting feedback, etc. Only through those involvements, we learn which changes work and which don’t. Blindly adopting any change from another organization to yours doesn’t work because every company has its own culture. For example, some cultures need more prescriptive change, some need more directional change, some need balance of both.
Driving towards a clear product process and role is more important than ever before. A Trends and Benchmark report published by Product Management Festival organization in 2019 by surveying 1011 respondents from 59 countries shows that what PMs desire the most in their role is product management maturity. It’s about how they can do product management roles and what environment they are in. Meanwhile, only 1 out of 5 organizations has the PM role clearly defined and understood by everyone in the organization. “Clarity and understanding of the role from others in the organization can have challenges that PMs face and hindrances to product impact”.
In summary, driving organizational change at scale is not easy. Moreover, things are most likely to get worse before they get better. Listen to your team for pain points, paint the better vision, work together to come up with the solution, improve, iterate, and empower them to persevere and go through these changes. In Bukalapak, it took us almost one year to build and deploy a standardized process v2 to all product teams of about 1000 employees in Product, Technology, Design, and Data. I want to thank all Bukalapak process committee members who made this happen. They are all very passionate individuals who worked tirelessly to make OUR process better. Hope this article could help anyone who is working on driving organizational process changes at scale and avoid the mistakes we made.
