Product Methodology Systemization Playbook

What We Want

We want every failure to be recorded so that we don't repeat it.We want every success to be summarized so that we can reproduce or replicate it when needed.

Why?

We need evidence to support our product decisions, especially when working with teams that have drastically different goals.We want to build new successes based on our past experiences—both successes and failures.

What We Do Not Want

We do not want our experience to disappear into thin air.We do not want our decision-making process to exist only in words or memory.

Why?

Records and documentation help us remember.Recording and documenting force us to summarize, reflect, and think.

What Is the Principle of Systemization in Our Context?

Understand, remember, and practice the “Goal / Resource / Method” approach.

• Goal: The impact we aim to make on our users.

• Resource: The resources required to achieve that goal.

• Method: The way we utilize those resources.

So, What Should I Do?

This part is actually quite straightforward — the intention here is to create an actionable guidebook everyone can follow.

Pre-Product Design

This is the phase where product planning occurs.

Action Plan

• Identify a theme for product requirements and group them by a common goal.

• Define each theme based on user behaviors, rather than data-driven goals.

• Ensure each theme contributes to a specific, traceable goal.

• Determine priority based on potential impact on users.

• First, establish the priority of themes, then of specific requirements.

• Use frameworks like D.I.C.E to maintain consistent prioritization standards.

• Describe concrete action items — including design or logic changes for each requirement.

• Clearly explain the specific changes the product update will bring to users.

• Avoid vague or non-directional descriptions that fail to indicate what will actually change.

Post-Product Design

This phase might actually be the most crucial one.

We need substantial evidence to support our product decisions. The team is learning to use user input as guidance, but we often only hear from a handful of users — not enough to make accurate decisions every time. Meanwhile, user research is time-consuming.

Data is another way to identify existing user behaviors. However, our data isn’t always clean, and with only one data analyst in-house, we must prevent her from being overwhelmed.

That said, delivering new features is a continuous part of our work. This is why we need a playbook or experience log — to document what we’ve done. It’s also the most natural and time-efficient habit we can build.

Action Plan

• Ensure we understand how users are actually using what we deliver.

  • The goal is to draw insights such as: “Users tend to…” or “Users prefer…”

• For A/B tests, ensure test setups, design logic, and results are recorded and archived.

• For new designs, ensure that changes in user behavior are collected.

  • User behaviors refer to concrete actions such as button clicks and page views.

  • Behavior data should be granular and grouped by user segments.

• Avoid focusing solely on “big goals” (e.g., DUV → Order conversions).

  • These metrics are useful but don’t always reveal why users behave a certain way.

• Ensure all of these are properly documented.

What Is Proper Documentation?

Let’s Talk About Documentation Culture

Why Write and Read Documents?

• Writing documents is a process of structured thinking and conclusion-making.

• Good documentation clearly and reliably transfers and preserves information in a structured way.

• Reading documents is the best way to understand structured product reasoning and conclusions.

What Makes Good Documentation?

• Anyone with some project context (even if not present in every meeting) should be able to understand the document’s conclusions and the reasoning behind them without asking the author.

• It should not rely on unrelated documents or unrecorded verbal knowledge (e.g., “modified xxx/xxx based on online logic”).

• Use precise language to describe intentions and actions.

• Provide full names for abbreviations, and replace jargon or slang with clear, human language.

What Constitutes Good Reading?

• Understand the intent and conclusions of the author.

What If There’s No Time to Write Documents?

Check out the Working Backwards Document – How We Ship Features: The Framework.

Before Writing a Document...

• Understanding user behavior and journey is a prerequisite for discussing logic and writing a product document.

• Remember: documents are meant for readers other than the author — not just for the author themselves.