1. What makes a product plan?
1.1. Key Ingredients
A good product plan consists of 3 key ingredients:
- A clear problem statement
- Measurable outcomes with targets
- Identification of key risks with mitigation steps
1.2. Principles of a Good Plan
In general, a good plan follows 3 principles:
- Use Numbers Over Descriptions, because quantitative data aids objective decision-making.
- Make Reasonable Assumptions, provide estimates when reliable data is lacking to facilitate discussion.
- Apply the 'Goldilocks Rule'. But This is often easier said than done. Similar to civil service staff work, it takes good judgement to determine the right amount of details in your plan. Too little details gives people little confidence to decide, whereas too much distracts the decision-makers.
2. The Problem
You'll need to answer these questions:
- Who is the user?
- What are their pain points?
- Describe the problem as the user's needs that are not being addressed.
- How big or meaningful is the problem?
Example
- 80% of license applications on XXX’s system A take >6 mths to resolve, against target of 3 mths.
- This results in revenue loss of $X per year for these businesses.
- With N license approvals a year, the overall impact is significant.
Example
Does your thing solve a real problem in the world and are people clamoring, needing it badly?
... during those 20 minutes (of product downtime), our customers weren't furious. They weren't emailing us like crazy... I didn't realize at the time that was the signal that we did not have product market fit.
2.1. Writing Clear Problem Statements
- 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.
2.2. What is the pain point? (e.g. approvals taking 6 months instead of 3 months)
- What happens if we left this problem alone?
Example
Unclear and outdated documentation were flagged out as areas of risk during the audit reviews.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.
Example
Approvals continue to take 6 mths, or more with X new policySystem B takes 4 mths per approvalF&B licenses take 3 mths per approval
2.3. Clearly Describe Unmet User Needs
- Based on data collected from users and speaking to them, state the user's characteristics, needs, and why they have that need.
- Consider expressing it in the form of problem statement.
Example
[Name of user persona] is a [type of user] who needs [type of user experience] because [benefits of user experience].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.
2.4. What is the size of the problem?
- 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.
Example
Example
2.5. Finding it hard?
You might have too many problems in one problem statement.
- Break down large problem statements into its components.
Example
Users struggle to find the correct employee HR service they need in XXX employee portal, which also doubly frustrates them when it randomly crashes while they're filling in an application. Employee productivity drops and this also creates workload for manual application processing. - 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.
Example
XXX system will reach end of life in 2025, and we need $XXXM to do a tech refresh, as otherwise citizens would no longer be able to transact digitally for their XX applications.Example
Under the XXX system v2 milestone, we could not complete development to improve searchability and user centricity. Given the AI boom, it is timely to revisit development for those aspects, in the form of building an AI chatbot that can improve search and user experience.
2.6. Common Mistakes
Too Aspirational
- Being very aspirational when crafting a problem statement can prevent us from diagnosing the actual problem.
Example
Describing the solution
- Most problem statements have several potential solutions.
- Your goal is to find the best solution.
- Hardcoding a specific solution in the problem statement artificially narrows the range of solutions up for consideration, almost akin to premature optimization.
Example
Example
3. Measurable Outcomes & Targets
The right outcome metrics tell us if we are moving in the right direction, to solve the identified problem.
Metrics force trade-offs and decisions. They focus people on the direction where the collective can best feel like they can build a better product, satisfy more customers, bring in more sales.
Example
I had been working in our payments group at Stripe for a bit, and then I started working on some of our banking and incorporation services. In Atlas, when I started working on it, it had had some success. It had already existed for four or five years prior to me spending time on it. But when I started to look at the support tickets, people were pretty unhappy frequently. They had a DocuSign stuck in their email box. They needed a co-founder's address, but they didn't know their co-founder's address. They couldn't log into the dashboard to figure out their 83(b) manual filing instructions.
We saw this basically in the first week of spending time on Atlas. I was just like, "Just show me all the support tickets. Are they happy support tickets? People writing in being like, 'Oh, I love this service, it's absolutely fantastic. Can you just do A, B, C more for me?' Or are they sad support tickets?"
And they're like, "Oh my God, they're all sad support tickets." We're just asking ourselves, "Well, why would someone recommend Atlas to a friend?"
I was like, "Well, it would have to accomplish A, B, and C activities for them. It would have to get their company, it would have to handle getting their tax ID from the IRS. It'd have to handle all the downstream administrivia." But surely, if they had a bunch of support tickets at the end, they're not going to go tell their friends to use this thing. We could measure all of the intermediate parts, we could measure the success rate and the frequency of incorporation services and we do all those things, but if you looked at the support tickets, there's just no way if you had a support ticket, you would recommend it to a friend.
So we suggested this metric to ourselves, companies that have no support tickets through the incorporation service.
The whole process, from the moment you start the application open, actually the first page load at the very beginning, all the way through the process waiting for the government, waiting for the IRS, and we give you two more weeks to write into support. We give an extra buffer two weeks. And if you get through that whole thing with no support tickets, that's a yes. If you have any number of support tickets, that's a no. And we just looked at the percentage of founders that were going through the service with zero support tickets, which is very different than looking at an average, right? You could have the average as 0.3, but that doesn't necessarily mean that getting to 0.2 is going to cause them to tell their friends more. We looked and only 15% of founders were getting through Atlas with zero support tickets through that metric.
I just thought, "Okay, well let's just drive that number way up, and let's look at the support tickets aside what people are needing and we'll bake it into the product, and presumably it'll fix it. People will like that more and then tell their friends." And over about 18 months, we took that number from 15% to 85. We basically just flipped it. And you can look at the market share plotted on the same timeframe and it's the same shape.
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. If we were to showcase the internal Atlas metrics, which we often just screenshot and publish, I think they'd be pretty happy to hear that we were spending all of our time making sure that none of them had support tickets.
3.1. Attributes of the Right Outcome Metrics
Outcome metrics should be relevant, frequent, objective, and specific.
Example
Relevant
Improvement or worsening of problem should show in metrics.
Example
Frequent
Changes in solution should quickly show in metrics.
Example
Objective
Metrics should not be based on subjective impressions (e.g., better to use timestamps to measure time taken to perform X than to ask users to self-report time spent on X).
Example
Specific
Two persons reading the same metric must be able to calculate them independently without need for further clarifications. Aim for a scientific level of precision when describing the metric.
Example
Example
Example
Example
Instead of sitting around all day and saying, "Hey, I heard all these customer problems, we should build X, Y, and Z." And another person could absolutely reasonably say, "Well, I heard from these customers, we should build one, two and three." And they're all true. We could have a lot of success in both, but the majority case is that we don't build either and we sit around and argue and bicker and we go slowly. "What are we going to do to naturally, organically every day, orient a larger group of people in the right direction and see if our tactics are generating progress over time for a customer from their perspective?" And metrics on the left and a series of tweets on the right is a pretty great combo.
And in my opinion, if the problem being solved is incorrect, metrics that seem alright will be wrong as well.
Example
3.2. Set Targets based on Cost Per Impact
Generally, when setting targets, it is useful to consider what the cost per impact of the product will be.
Example
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.
Example
| Item | Current | New |
|---|---|---|
| Annual platform cost (Cost) | $100,000 | $200,000 |
| Annual applications | 100,000 | 100,000 |
| % Applications resolved within 3 months | 10% | 30% |
| # Applications resolved within 3 months (Impact) | 10,000 | 30,000 |
| Cost per impact | $10 | $6.67 |
4. Risks
4.1. Why mitigate risks?
Risk mitigation is important so we can be confident in delivering an effective product on time. At each point throughout the life of your product, it is useful to think about the risks that have been mitigated and those which remain to be mitigated through future action.
Broadly, there are three types of risk:
- Market risk - the product will not be used, or even if it is used, it will not solve the identified problem.
- Technical risk - the solution cannot be built within the time and resource constraints.
- Team risk - the individuals responsible lack the know-how or commitment to achieve the desired outcomes.
4.2. Market Risk - Will this work?
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
- Detailed form to collect more relevant information
- 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.
Example
| Step | Assumption | Change | Risk | Level |
|---|---|---|---|---|
| 1 | Users fill in application | Better quality | With more fields to complete, fatigued applicants might provide less accurate information | Medium – This could increase the need for clarifications downstream |
| 2 | Users submit applications | No change | With a more complex form, we receive fewer submissions | Low – businesses are strongly incentivised to apply for a license |
| 3 | Officers assess applications for completeness | No change | Officers might take more time to vet the detailed form for completeness | Low – This step is relatively short compared to the rest and so has minimal impact |
| 4 | Officers clarify additional details with applicants | Shorter duration | Officers might take as much time, if not more, to clarify additional details | High – this might fundamentally change our solution |
| 5 | Officers resolve applications | No change | Additional information will complicate decision-making | Low – decision-making process is based on a simple checklist |
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.
Example
And so compartmentalizing those (key features) because ultimately you'll have too much scope creep if you try to solve everything at once and validate. Also you're not going to get signal too, like you're trying to test one thing at a time.
The way that now I approach a lot of consumer product development is if this is true, then what next needs to be true for this thing to work out? And these layers of conditional statements. And the more layers you have, the higher risk your product is, so you should try to condense it to about like four things that must be true for the thing to work.
5. Product Plan Template
5.1. Variant 1 (Amazon)
- 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.
5.2. Variant 2
- Customer problem
- Observations
- Hypothesis
- Experiment
- Success Metrics
6. Credits
- Smart Nation Group's Product Plan Framework, Govind Ganesan
- BCG's RISE Programme materials