Beyond Engineering: Defining Process at Mercari
Hey y’all, I’m Jonathon. I recently transitioned from Lead QA Engineer at Mercari to fill the role of the company’s first Program Manager, after successfully implementing a number of changes to our processes — changes that we hope will better enable each of our team members who are involved in the product development lifecycle to deliver high-quality work, effectively and efficiently.
I’m here to talk about the day-to-day of how our Design, Product, Engineering, and QA teams work together, and share some of our learnings from formalizing some of our processes.
Process, in service of Product
I believe that process, when properly implemented, is the foundation on which great products are built.
Every company has different ideas of how process should work. Some organizations treat process like law, and others completely eschew it — often because they see it as stifling or bureaucratic. There can be valid reasons for both of those approaches, but Mercari is a growing, mid-sized company making a consumer app; we’re not a hospital, legal firm, or a scrappy, early-stage startup.
To ensure that we don’t buckle under the weight of our own growth or find our work grinding to a halt because of misunderstandings, I studied how our teams generally get work done and then codified what most people were already doing to make the process consistent across different individuals and interrelated teams.
For our purposes, it became clear that the process we implement should be straightforward, lightweight, and flexible.
Prioritizing work
One of the first things I noticed is that the priority scheme we were using wasn’t being put to good use. We were using Jira’s default — highest, high, medium, low, lowest. No one had ever defined what each of these priorities meant in practice, and thus the distribution of our tickets was top-heavy.
“If everything is a priority, nothing is a priority”
This led to confusion around which issues truly needed immediate attention, like differentiating between an important upcoming feature, ranked “highest,” while simultaneously facing an outage with our shipping provider, also ranked “highest.” To better reflect the priorities of our work, I consolidated our priority scheme to three statuses that align with the colors of a stoplight — critical (red), important (yellow), normal (green). Fewer choices ensure easier decisions.
After identifying these priorities, I defined them:
P2 • Normal (formerly Lowest, Low, and Medium)
This is the default priority for all bugs, features, and chores.P1 • Important (formerly High and Highest)
These bugs, features, and chores should be prioritized.P0 • Critical
All other work should pause until these bugs are resolved or features are completed — no chores will be considered critical.
Once I felt confident in our new priorities and got buy-in from our team, I turned my attention to our Jira workflow.
Jira, the frienemy
Like many product organizations, Mercari relies on Jira as our primary issue tracker. Jira derives both its power and weakness from its ability to be infinitely customized.
To manage the software development lifecycle (SDLC), Jira uses workflows. When I arrived at Mercari, our workflow was… complicated:
As often happens, Mercari started with the default workflow and started bolting on statuses and transitions over time, without any consideration of how it would impact the various teams using Jira. The workflow you see above was made to accommodate the Design, Product, API Engineering, Client Engineering, and QA teams.
Making a plan
After spending a few weeks observing how our teams work together, it became apparent that we could optimize our Jira workflow to make it reflect the real-world workflow that had organically developed over time between these teams.
First, I focused on the Engineering workflow. From there, I conferred with key members of the Product & QA teams and made the decision to include them in that same workflow. And finally, after some consideration and input from our VP of Product and our Creative Director, I emancipated the Design team by providing them with their own workflow.
I then created a lengthy presentation (42 slides! In my defense, there was a lot of information needing to be covered, and this document was intended to serve as documentation, at least temporarily) proposing the aforementioned changes to our priorities, workflows, and even issue types; we later scrapped the idea to change our issue types, since it can wreak systematic havoc on Jira.
Execution
After all the teams’ questions were answered and a few minor adjustments were made, we started making the changes in Jira. Sometimes, this is where things can get quite hairy — relationships, among them.
Fortunately, the transition to our new workflow was relatively painless — all while we merged our instance of Jira with Mercari Japan! Due to diligent preparation and communication, everyone knew what to expect and when to expect it. We largely avoided unpleasant surprises.
“No plan survives first contact with (implementation).”
That being said, there’s no such thing as perfect and there were a few opportunities for improvement. Our team identified pain points in the workflow and graciously provided feedback on how it could be improved. All said and done, the number of changes we had to make can be counted on one hand.
Drumroll, please…
It’s my pleasure to introduce to you what our Product Development workflow now looks like:
As you can see, this workflow is more straightforward — it’s literally much more linear. “In Backlog” and “Blocked” are side states so that they have a few more transitional options, and “Awaiting Approval” is a specialized side state for our API team; I’ll explain that in more detail further down.
One aspect of the previous workflow that led to confusion was that many statuses could be selected at any point in the workflow (represented by the black “All” box pointing to the left). By narrowing down which states should truly be independent of the workflow (in our case, “In Backlog”, “Blocked”, and “Closed”), we were able to clarify how a ticket should progress through its lifecycle.
To illustrate how our workflow functions, let’s use hypothetical “Feature X” as an example. First, Feature X is created as a story with the status “In Backlog.” From there, it proceeds to “Spec In Draft” and iteration occurs in that state before entering “Spec In Review.” If no issues are found, it then proceeds to “Awaiting Development,” where our Engineering Team picks it up and breaks it into finite development tasks. After being defined with clear specifications and acceptance criteria, those tasks transition from “In Backlog” to “Awaiting Development.” As the development tasks transition to “In Progress,” so too does the parent story, Feature X. Once the development tasks are complete, they transition to “In Code Review” alongside Feature X.
It’s at this point that there’s a branch in the transitions, depending on various factors — namely, if the issue hails from the API component and whether QA is required.
To QA, or not to QA?
If an issue requires QA, it will transition into “Awaiting Testing.” From there, our QA Engineers can pick up the tickets and transition them to “In Testing.” Once complete, they proceed to “Awaiting Approval” or “Awaiting Release” based on the component of the issue — more on that logic below.
If the engineering team has determined that QA is not required, the issue can transition directly to either “Awaiting Approval” or “Awaiting Release” — again, based on the component of the issue.
Component logic
Before my time, it was decided that any issues within the API component require Product Manager approval before being released to production (while this may be an interesting topic for some readers, it’s beyond the scope of this article). To allow for this, we have a special “Awaiting Approval” status. This status signifies that the work is complete but is not yet “Awaiting Release.”
Our client issues don’t require the same oversight that our API issues do. Therefore, they can transition to “Awaiting Release” either by going directly there or through the detour of our QA statuses (i.e. “Awaiting Testing” and “In Testing”).
In Jira, we manage this using the “Conditions” function for our transitions.
Component = API
To ensure that only API issues arrive in the “Awaiting Approval” status, we use the following condition:
The field Component/s will have to be equal to value ‘API’. Compared as String.
And to ensure that issues only progress to “Awaiting Release” after being approved by the appropriate individuals, we use the following conditions:
Only users in project role Managers can execute this transition.
Only users in project role Producers can execute this transition.
Component != API
To ensure that non-API issues do not accidentally arrive in the “Awaiting Approval” status, we use the following condition:
The field Component/s will have to be not equal to value ‘API’. Compared as String.
With this logic in place, it’s now much easier for each individual to properly transition tickets to the right status the first time, without any confusion or hesitation. Jira fades into the background (as it should) and engineers can focus on engineering, QA can focus on testing, and product managers can focus on… er, product managing.
So what?
You may be wondering, “what was entire point of this exercise?” While we’re hoping that we’ve laid the groundwork to build an awesome product with minimal churn, all of this will have been for naught without some form of metrics. It’s too early to report results, but if I’m allowed to commandeer our blog once again in the future, I’m hoping to report back on the following:
- Does our Engineering Team ship more bug fixes than before the change?
- Does our Product Team ship more features than before the change?
Obviously, there are more factors that can impact these metrics than what I’ve discussed today. Ultimately, the greatest measure of success will be subjective:
- Do individuals on the teams impacted by this change feel like our processes help them or hinder them?
I hope this gives you some insight into how we get work done at Mercari; let us know if you’d like to see more of this type of content from us. Also, if you like what you see and are looking for new opportunities, come join our team!
