Business Operating System

When I took on the business unit, the problem was not a lack of metrics or schedules. They were disconnected. We could see status, but not always who needed to decide and deliver what, or by when.

I did not want this to end with one more project-management document. We looked at how customers behaved and how the business numbers changed, then turned the evidence into concrete choices: what to prioritize, who would own it, and when it needed to be done.

2025 average monthly logged-in users

402K

2025 annual payments

1.038M

Customers who paid at least once in the month

32.7K

Average purchases per payer per month

2.65

Average monthly logged-in users in 2025 fell 1.2% year over year, while FORCE revenue fell 25.7%. Traffic alone could not explain the size of the decline, so I split revenue into the number of customers who paid in a month and the average amount each payer spent, or ARPPU.

A payer-month is the sum of unique payers counted separately in each month. If the same person paid in January and February, they count twice.

Payer-months were 18.4% lower year over year and ARPPU was 8.9% lower. Existing-user months grew by 1.9%, but the existing-customer payment rate fell by 1.89 percentage points. Recovering conversion, purchase frequency, and purchase value among existing customers therefore became a core priority alongside acquisition.

Existing-customer share of Force revenue

91.1%

Monthly revisit rate among existing customers

68.6%

Next-month revisit rate among new customers

24.8%

The team and I reviewed business metrics, active projects, sprints, milestones, app-review dates, and cross-functional dependencies in one view.

The CEO set the direction for the annual priorities. Within that direction, I concentrated resources on the highest-priority work and adjusted the sequence of the rest. I only use project counts or allocation ratios when the scope is supported by evidence.

I set approval and escalation levels according to business impact, then used DACI to clarify roles within a project. The Driver did not make the final call; they planned the work, led kickoffs and meetings, gathered input, assigned work, and tracked progress. The Approver made the final decision, Contributors added specialist knowledge, and Informed teams received progress and change updates.

The source material establishes that DACI and Driver operating principles were shared in a 2023 Design Guild meeting. I do not extend that evidence into a company-wide standard or the outcome of a specific project. The brief below reconstructs those principles without real names, project names, metrics, or dates.

Each week, the team and I reviewed business metrics and project status together. We ended the review with agreement on that week’s decision, owner, deadline, and conditions for execution—not with a finished document.

The team used a weekly board to review business development, service operations, and iteration work together. The original view below shows the actual items used to align on progress.

Action Push is a CRM feature that sends a discount coupon as a gift through a push notification after a user performs a specific action. We changed the targeting condition to learn which behaviors were more likely to lead to actual coupon use.

Keeping the same 20% coupon, we narrowed the target from a search interaction to users who had opened premium details three times. Issuance fell 48.5%, from 14,196 to 7,305, while redemptions rose 129.9%, from 308 to 708. Redemption per coupon issued increased from 2.17% to 9.69%.

The free-item condition showed the opposite trade-off. Narrowing from one use to three uses raised the redemption rate from 0.34% to 0.70%, but issuance fell 66.8% and total redemptions fell 31.2%. I therefore set the next target by looking at both reach and total redemptions, not the rate alone.

Coupons issued

14,196 → 7,305

Coupons redeemed

308 → 708

Redemptions per coupon issued

2.17% → 9.69%

Redemption rate for free-item targeting

0.34% → 0.70%

The team shipped on a two-week cadence. At Weeks 2 and 4 after launch, we separated what happened from what we had assumed, then decided whether to continue, revise, or stop the work.

The purpose of this routine was to make better decisions repeatable, not simply produce better reports.

The business scale and customer mix shown here are baselines for a service operated by the team, not my individual outcomes. I also do not claim a formal Enterprise PMO title or company-wide responsibility for P&L, RAID, or capacity planning.

The CRM figures come from sequential observations without a randomized control group. The redemption-rate denominator is coupon issuances, not unique users. FORCE attributed after coupon use is also not interpreted as revenue newly created by Action Push.

I do not yet have before-and-after measures for decision time or throughput. This case is therefore about how I turned a data diagnosis into a working team routine within a Product Business role.