How we plan on Mutual Fund?

Background

To meet our business strategy and annual targets, our CEO and stakeholders explored a new way to help users stay engaged and enjoy investment tools in LINE Bank—without a stock-trading license. After collaborating with a securities company on the Settlement Account, LINE Bank shifted focus to Mutual Funds: a mature investment product in Taiwan with a lower entry barrier for beginners.

Another part of the story: another teammate and I took over the project from two members in the preparation phase. They had completed most of the research and studies, plus part of the PRD, and then handed the project to us. That made the start challenging—we had to quickly sort out what was done, what was pending, and what problems still needed to be solved.

Works

Role : Planner (similar as Design PM)

  1. Took over the PRD from other members as quickly as possible, while preserving the original intentions
  2. Aligned with KR designers to ensure we were moving in the same direction, and collaborated with developers to ship the product successfully
    1. Like many product process, there were always many issues happened during design and development period. We need to balance the schedule time and product quality, try to find a way to let the members keep going. It’s not a easy job, but fortunately we made it with lots of supports.
    2. Managed the design and development schedule, tracked each member’s progress, and helped solve problems during the workflow.
  3. Join the QA at the final period of schedule
  4. Observe the data after published, also help on solving user and system problems.
    1. We made some decisions by MVP rules: publish first and fix dirty logics later during development. After one year of Mutual Find published officially, we spent some time to fix some codes and designs to make product better and better.

Issues we met while in progress

  1. We had two platforms—App and CWA (a web-based system inside LINE)—and this was the first time such a large product launched on both at the same time. We had to pay close attention to the differences and limitations between native and web, from small UX issues (e.g., “scroll to top”) to major API constraints. Many of these required cross-team discussion and decision-making.
  2. Related to the above, we created many new components and layouts for this product. That was difficult because the team didn’t have a stable component library at the time. We also didn’t want these components to be “one-time use” — we aimed to design them for long-term reuse.

What we did and I learned

From handover to launch took about a year. There were many “firsts” for the whole team—including our first time holding a retro meeting at the end of a project.

Here were the first time list:

  1. We broke the whole feature into smaller pieces (around 10 parts) at the beginning. This helped us focus on each part with full attention.
    1. Side effect: it could be frustrating when we couldn’t finish an earlier part successfully but still had to move on to the next one due to schedule pressure.
  2. We realized how critical a component library is, and started building library documentation from this project—covering both page-level layouts and smaller components (e.g., search bars, tags, and scroll interactions).
  3. We documented clearly how business strategy influenced design decisions—for example, adding UI instructions and explanatory text to help users understand “special operation days” in mutual fund transactions.
  4. We set up regular demo sessions during development. We learned we shouldn’t wait until the end to test and review implementation—otherwise everyone faces schedule stress all at once. So we asked developers to demo progress every two weeks, even when it was tough.
  5. We discussed problems closely and frequently, even when they were small or caused by human error. We trusted that fast communication could prevent bigger issues later.

After all of that (plus the usual day-to-day project work), we launched Mutual Funds on time and successfully. Of course, there were still questions we wished we could revisit, and areas we would improve if we could go back. But we could still tell ourselves: we made it—and we didn’t introduce major business or usability issues.

Unlike many other digital products, financial products require extra attention to detail, regulations, and user protection. This project became a valuable learning experience for all of us, and we’ve continued to bring those lessons into later projects.