Recommended resources
The freely available resources this lesson will direct you to.
Hello! This course begins with a product-management question: how do you decide which logistics problem is worth solving before choosing an integration—or, later in the course, an AI feature? In this first module, you will build that judgment from customer workflows, evidence, and business priorities.
Today’s focus is a product problem statement for a customs-filing integration. By the end of the lesson, you should be able to describe who encounters a specific filing difficulty, when it occurs, what it costs the user and the business, and which parts of the story are still assumptions. That gives a team a useful starting point without prematurely committing to a technical solution.
Start with the filing work, not the proposed connection
Imagine someone proposes, “We need to integrate our logistics platform with a customs-filing system.” That describes a possible output: a connection between systems. It does not yet explain the problem. Is the filing specialist re-entering information? Waiting for an overseas supplier? Correcting conflicting values? Unable to tell whether a draft is ready? Each answer points to a different opportunity, and an integration may address some but not others.
Consider Importer Security Filing (ISF), a specific U.S. ocean-import filing context. The diagram below shows the ten importer-side data elements and two carrier-side data elements commonly described as “10+2.” Treat it as a workflow orientation, not a substitute for current compliance guidance.
A value such as manufacturer may appear in supplier communications, shipment documents, and a filing record. The useful product question is not simply, “Can these systems exchange a field?” It is, “What happens to the person preparing the filing when the needed value is missing, arrives late, or differs between records?” The first question suggests a feature; the second identifies a situation you can investigate.
The following video introduces two habits that matter here: resisting solution-backward framing and defining the customer more precisely than “importers.”
Webinar: How to Nail the Customer Problem Statement by Amazon Sr PM, Rashi Gupta
Watch “Webinar: How to Nail the Customer Problem Statement” from Product School for its approach to identifying a customer problem before proposing a product.
Watch problem framing for the distinction between a customer problem and a technology-led idea. Then watch customer identification for the discussion of a more specific target group. As you watch, consider why “a filing specialist preparing an ISF draft” is more informative than “a logistics customer.”
A precise who also keeps different perspectives separate. A filing specialist may need an accurate, ready-to-submit draft; a manager may care about dependable operations; your product business may care about support effort or customer retention. These interests can reinforce one another, but they are not interchangeable. For this lesson, stay close to the person doing the work. The next lesson will map the wider set of stakeholders and their constraints.
Turn signals into customer and business evidence
Suppose a sales colleague reports, “Customers keep asking for an ISF integration.” That is worth investigating, but it does not establish which step fails or whether the proposed integration would help. Similarly, a high count of support tickets tells you something is happening, but ticket labels alone may not tell you what customers experienced.
Evidence becomes useful when you can say which claim it supports, where it came from, and what it cannot establish. Read the following sections with that distinction in mind.
How to make Evidence-informed Product Discovery Decisions
Read this article by Tim Herbig to distinguish a promising signal from evidence that reduces uncertainty about a particular product problem.
In “Differentiating Information from Evidence,” read information versus evidence. Then, in “Understanding Context: Proximity and Commitment,” read proximity and commitment. Focus on why a secondhand feature request and a record of what someone actually did support different levels of confidence.
For a customs-filing problem statement, look for two complementary kinds of evidence:
- Customer-workflow evidence: a specialist walks you through a recent draft, shows where a value had to be checked, and explains what work was interrupted. This helps establish the experience and its context.
- Business evidence: appropriately scoped operational records show how often drafts were paused, or support records show the effort spent handling related cases. This helps establish why the issue may matter to the organization.
Neither automatically proves the other. Support hours are a real business cost signal, but they do not prove that an integration would eliminate those hours. A customer’s recent workaround is compelling evidence of friction, but one case does not tell you how widespread it is. Note the time period, customer group, and definition behind every count; otherwise a number can lend false precision to a vague claim.
Write a statement that leaves room to investigate
A good problem statement is short enough to guide a discussion, yet specific enough to be challenged. ProdPad’s framework offers four ingredients: the user, the context, the pain, and the impact.
The Product Management Problem Statement: How to Get it Right
Read this ProdPad article for a compact structure you can apply to the filing workflow.
In “What Makes a Good Product Problem Statement?”, read quality criteria, including the warning signs near the end. Then, in “Key Components of a Product Management Problem Statement,” read four components and the example sentence format. Notice that the format describes a difficulty and its consequence, not the feature to build.
One useful drafting pattern is: A specific user encounters a specific difficulty in a defined situation, with an observable consequence. You can add a second sentence for the business impact when it is supported by separate evidence. The wording should make it possible to ask, “What observation would show that this description is wrong?”
The video returns to drafting and comparing statements. Use its examples to test whether your sentence describes the customer’s situation rather than the team’s preferred implementation.
Webinar: How to Nail the Customer Problem Statement by Amazon Sr PM, Rashi Gupta
Return to Product School’s “Webinar: How to Nail the Customer Problem Statement” for examples and statement-building frameworks.
Watch statement examples. Focus on how specifying who, when, what, and how improves a draft, and on what a weaker, solution-led statement leaves unexplained.
Compare these two formulations:
Solution-led: “Our platform needs an automated ISF integration so customers stop entering data manually.”
Problem-led starting point: “Filing specialists preparing ISF drafts sometimes need to reconcile manufacturer and country-of-origin information across supplier messages and filing records before a draft is ready.”
The second version names a user, a moment in the workflow, and the impediment. It still needs evidence of how often this happens and why it matters. Crucially, it does not assume that automation is the answer: an upstream party might not yet have supplied the information, in which case faster transfer between systems would not make it available.
A worked example: from observations to a defensible statement
The following figures are illustrative, invented evidence for learning purposes, not findings about any actual customer.
In a 30-day review across three importer teams, operational records show 120 ISF drafts, of which 31 were paused for clarification of manufacturer or country-of-origin information. Two filing specialists walk through recent cases and show how they checked supplier messages against filing records before marking a draft ready. In the same period, nine support cases tagged to that clarification issue consumed 24 logged staff-hours.
Those observations support a narrower claim than “customers need an integration.” They show a recurring pause in the sampled workflow, examples of reconciliation work, and a measurable service-cost concern. They do not show that every paused draft was late, that the sample represents all customers, or that connecting systems would remove the need for clarification.
An evidence-qualified problem statement could read:
For filing specialists preparing ISF drafts at three importer teams, manufacturer and country-of-origin information sometimes requires clarification across supplier messages and filing records before a draft is ready; in a 30-day sample, 31 of 120 drafts were paused for that reason. Nine related support cases consumed 24 logged staff-hours during the same period, making this a customer-workflow problem with a measurable service-cost impact.
It is longer than a slogan because its scope matters. “At three importer teams” and “in a 30-day sample” prevent the result from being presented as universal. The user consequence is a pause before readiness; the business consequence is logged support effort. The sentence does not convert those hours into a monetary saving or claim that a filing deadline was missed.
Keep an assumption alongside, rather than hidden inside, the statement: Would better exchange of available information prevent these pauses, or were the necessary values unavailable or unresolved upstream? That question preserves the possibility of an integration while giving discovery a clear purpose.
Takeaway
A product problem statement is not a feature request with more polished wording. For a customs-filing integration, it identifies a particular user and filing moment, describes the observed obstacle, and connects customer evidence to a credible business impact without claiming that the proposed connection will solve it.
The next lesson expands the view beyond the filing specialist: you will map the stakeholders, jobs, incentives, and constraints around the workflow. That wider map will help explain where information originates, who can correct it, and whose needs a proposed integration must satisfy.