Product Plan 101

• Who's the user?
• Focus on a few specific segments (e.g., business seeking license approvals) rather than large segments (e.g., all businesses in Singapore).
• Don't confuse the customer and the user. The customer (MOX) pays for the product, the user (business owners) interacts with the product.

What happens if we left this problem alone?

• Unclear and outdated documentation were flagged out as areas of risk during the audit reviews.
• Better: XX cases of non-compliance to prevailing policies cost us $XM each year because these users relied on guidelines in outdated policy documents strewn across our employee portal.

If you need a benchmark, compare with alternate solutions or adjacent industries

• Approvals continue to take 6 mths, or more with X new policy
• System B takes 4 mths per approval
• F&B licenses take 3 mths per approval

• Consider expressing it in the form of a problem statement.
• Template: [Name of user persona] is a [type of user] who needs [type of user experience] because [benefits of user experience].
• Example: Anne is a staff officer who writes AORs for overseas trips. She needs an efficient way to double check her submission against all applicable finance guidelines. She presently searches, downloads, and toggles among more than 5 separate finance policy documents for each AOR.

• When calculating the total addressable market (maximum potential target audience), working up from a small unit (e.g., number of applications to assess) is often better than working down from a large unit (e.g., no. of ministries that need to assess applications).
• A logical, back-of-the-envelope estimate with reasonable assumptions is often sufficient.

Examples

• Revenue loss of $XXM per year for X no. of businesses
• ~3 man months are spent by 15 officers monthly collating, cleaning, emailing, and drafting MS Word reports on service transactions, which are done manually on Excel, Outlook, Word.
• Symptoms of poor service delivery is only identified and acted upon up 2 weeks later, because data and business insights are manually collated and generated.

• Break down large problem statements into its components.
• When first starting out, it is better to focus on a narrow problem statement, affecting a narrow set of users. Once you have solved that problem, you can expand out to other related problem statements and/or other similar users.
• For 'brownfield' projects (i.e., tech refresh), the problem statement is not that the system is approaching End-of-Life (EOL) or End-of-Service (EOS).
  • Rather, consider what problem the existing system was solving and think about how you can better solve that when rebuilding it.
  • Reaching EOL or EOS tells you the timeline, not the value.

Case Study: Stripe Atlas

• Problem: Only 15% of founders completed incorporation with zero support tickets.
• Solution: Focused on this single metric - companies with no support tickets through the entire process.
• Result: Over 18 months, took that number from 15% to 85%. Market share followed the same trajectory.
• "I think you have to find a measure by which it speaks directly to what the customer wanted, and that if you accidentally leaked your dashboard to them, your customer would be ecstatic to learn that that's what you were measuring the whole time." — Jeff Weinstein, Stripe

• Formula: Cost per impact = Annual Total Cost / Target units of impact
• If the cost per impact is unreasonably high, you should consider whether the targets can reasonably be raised.
• If not, you should reconsider whether it is financially worthwhile to continue the project.

Determine the Theory of Change

• How will your solution achieve the desired outcome?
• It's too simplistic to think "If we do A, B will happen".
• In the real world, there are typically several steps between A and B.
• Map out your user journey and interactions and determine what needs to change at each step to lead to the desired outcome.
• Example: Reduce time taken for 80% of applications from 6 months to 3 months by introducing: (1) Detailed form to collect more relevant information, (2) Better UI to present info and cut need for clarifications

Identify the Riskiest Assumptions

• There is usually some underlying assumption behind each step.
• Low-risk assumptions are ones over which we have a high degree of control or where past data has proven that we are unlikely to be wrong.
• High-risk assumptions are ones that we have minimal control or will fundamentally change our direction if proven wrong.

Validate the Assumptions with a Proof-of-Concept (POC)

• Focus on the higher risk assumptions and find ways to validate if they were true (i.e., proofs-of-concept).
• Doing this early helps us find workarounds or pivot our solution before committing additional resources.

• Introduction - States the challenge or opportunity, and why it matters.
• Goals - The vision, what hitting the mark looks like. Paint a picture of achievement both inspiring and realistic.
• Tenets - Core values guiding your strategy.
• State of the Business - Where things currently stand, e.g., hard numbers, market standing, or any other pertinent details.
• Lessons Learnt - Assess previous efforts, identify effective strategies, learn from mistakes, and understand their causes.
• Strategic Priorities - Write tactics to tackle identified challenges in pursuit of stated goals.
• Appendix (optional) - Extra info that avoids detracting main flow of proposal.

• Customer problem
• Observations
• Hypothesis
• Experiment
• Success Metrics