Stripe · Product sense · Mid · 45 to 60 minutes

How should Stripe help users with tax?

Stripe provides payments and financial infrastructure that businesses use to accept money online and run internet commerce. Answer this product management case and get it graded line by line against a weighted rubric.

Product strategy
Prioritization
User empathy
Metrics design
Structured communication

The situation

Stripe's payments leadership asks you to assess a growing customer problem. In Stripe's public call for improvements, the most common request was help managing taxes. Follow-up survey and interview work with more than 1,000 Stripe users shows real pain: about one in five are not charging tax at all, many who do collect it find the rules hard to understand, and many already pay third parties for help. The opportunity is attractive because Stripe already sits in the checkout flow and has customer, address, and payment data that could help automate parts of compliance. But this domain is messy. Businesses sell into thousands of tax jurisdictions, more than 11,000 in the US alone, rules change often, and asking buyers for more location details could lower conversion. Users say they want an end-to-end answer, yet some parts of compliance may require operations, legal interpretation, or partner integrations beyond Stripe's usual API strengths. Your job is to recommend whether Stripe should enter this space now, and if so what problem to solve first, for whom, and how Stripe should define quality in a way that protects both accuracy and checkout experience.

What to produce

A 1 to 2 page product strategy memo.

Your answer must

State whether Stripe should launch a tax product now, and identify the first target user segment and core job to be done.
Define the v1 scope with 2 to 3 core capabilities and at least 2 explicit non-goals.
Explain how the product would use data Stripe already has in the payment flow while minimizing extra buyer input and checkout friction.
Propose 1 primary quality metric and 2 to 4 supporting success metrics for the first year.
Identify the biggest product, legal, operational, and technical risks, and say what should be built, partnered, or deferred.

Constraints

You cannot assume buyers will tolerate a meaningfully longer or more complicated checkout just to improve tax accuracy.
The product must operate across many jurisdictions whose rules, rates, and boundaries change frequently.
Merchants need outputs they can explain and defend to tax professionals and authorities, not a black box result.
Initial direction should fit Stripe's strengths in APIs and existing payments data, without assuming a large new manual operations team at launch.

Format

Use five headings: recommendation, target users and pain, v1 scope, metrics, risks and next steps.

How Stripe actually played it

Stripe explains how it decided to build Stripe Tax after tax management was the top request in a public call for improvements and a survey of over 1,000 users. The post describes the complexity of tax rules and a jurisdiction improvement that raised ZIP code coverage from about 60 percent to over 99 percent. It shows discovery, scoping and a quality metric working together.

The most common user request can point to a product opportunity.
Survey and interview many users before committing to a hard domain.
Pick a coverage metric that reflects real quality.

Built from Building Stripe Tax by Stripe.