Hello everyone, my name is Maylee, Product Management of Legal contract, a B2B SaaS software that supports business in Japan Market.
Back to the article topic, how many of you believe launching equal a close in your Epic?
To me it’s just a new opening
Money Forward is a product company, which means that we package our value in our solution. To know if our value has solved business painpoints, delivering only is not enough. Here’s why
Output is what we created in our work such as tickets, the code, or even the launch.
Outcome: this what we need to care after we produced: If our products bring decent value to users such as growing their business, reducing task time
In a product context, if your focus is strictly on output, where a launch equals job completion, you are operating more as an executioner. The success is measured by shipping Jira tickets on time.
However, if you shift your focus toward outcomes, viewing the launch as just the beginning and measuring success by how well you solve customer problems, you are truly operating as a Product Manager.
No one wants to deliver bad products or product that is below the line. Your metrics should be comparable to see the growth time by time.
So what are the metrics in cloud contracts?
Within 30 days after launching, my team will set 2 time frames for evaluation, day 14th and day 30th, 1 hour each day.
You should set them immediately after launch. What you will do in those 2 days:
Day 14: Check-in: Early quantitative look at Metabase logs to see basic trends.
Day 30: Evaluation: The deep dive: Quantitative (What) vs Qualitative (Why).
Post-Launch Evaluation Plan
Within 30 days of launching, the team will schedule two 1-hour evaluation sessions—on Day 14 and Day 30. These should be blocked on the calendar immediately after launch.
Day 14 Check-in: An early quantitative review of Metabase logs to spot initial usage trends.
Day 30 Evaluation: A comprehensive deep dive balancing quantitative data with qualitative insights.
The Day 30 Deep Dive: "What" vs. "Why"
Quantitative (The "What"): Hard data provided by logs and dashboards.
Example: "Overall adoption is currently at 2%."
Qualitative (The "Why"): The context behind the numbers that dashboards can’t capture. This phase requires collaborating with PMMs, Sales, and Customer Success to gather feedback and uncover root causes.
Example: "Our top three enterprise clients love the feature, but standard users find it distracting.
Once you have gathered the "What" and the "Why," evaluate how the feature is performing against your original definition of success. From there, a Product Manager will typically take one of three actions:
- Iterate: If the data shows user confusion (e.g., a UX bottleneck), create a Jira ticket to refine and improve the UI.
- Educate: If users are simply unaware the feature exists, collaborate with PMM to introduce in-app tooltips, guides, or product tours.
- Contain/Kill: If the feature is highly niche or creates unnecessary friction, move it to advanced settings or sunset it entirely.
None of this is possible without clean data. If you need to request that engineering implement event logging or tracking, always explain the why behind the request. Developers build better when they understand how the data will drive product decisions.
A launch is exciting, but it isn’t the finish line. It is simply the moment you begin validating whether your product truly delivers user value, and discovering how you can maximize that value moving forward.
