Company-Wide Self-Service Data: Cost-Benefit Case and Go/No-Go Recommendation
Company: Google
Role: Product Manager
Category: Product / Decision Making
Difficulty: medium
Interview Round: Other
You are the product manager who owns a company goal: make self-service data available to "everyone" in the company. You have been asked to decide whether the company should pursue it. You have no access to the company's internal data or research, so make whatever assumptions you need and flag each one as an assumption. There is no single right answer: the interviewers want a recommendation grounded in market research and your assumptions, and they care most about how you think and how you present.
Address the four parts below in an informal slide deck of no more than 10 slides. You will present for up to 15 minutes, followed by 10 to 15 minutes of questions. Keep the preparation light rather than polished.
### Clarifying Questions
- Who is "everyone": every employee, including frontline staff and contractors, or every employee whose job involves decisions informed by data?
- Where does "self-service" stop: reading trusted dashboards, exploring prepared data without code, or writing queries against raw tables?
- Roughly how large is the company, and how mature is its data stack today (one warehouse or scattered sources, existing reporting tools, an analytics team that takes requests)?
- Who will act on the recommendation, and is the decision about budget, headcount or both?
### Part 1 — Costs, benefits and one-year feasibility
How would you evaluate the costs and benefits of making data self-service for everyone? Which factors would you weigh, and can it be done within a year?
```hint Split "everyone" first
Before putting numbers on anything, break "everyone" into groups that need different depths of access; costs and benefits scale differently for each group.
```
#### What This Part Should Cover
- Benefit and cost categories, each quantified with an explicitly labeled assumption
- How benefits ramp with adoption compared with when costs land, and which inputs swing the result
- Non-financial factors such as trust in the numbers, privacy and the effect on the analytics team
- A direct answer on the one-year question, with what is and is not in place by then
### Part 2 — Hypotheses and minimum viable tests
What hypotheses does your case depend on, and what is the minimum viable way to test each one?
```hint Rank by what would flip the decision
Start from the assumptions in your cost-benefit model and ask which ones, if wrong, would change your recommendation. Look for evidence you could gather in weeks, before building a platform.
```
#### What This Part Should Cover
- Falsifiable hypotheses tied back to the cost-benefit model
- A cheap test for each, with the signal and the bar that would count as passing
- The order in which to run the tests
### Part 3 — Technical considerations
Describe the high-level technical considerations.
```hint Follow one question end to end
Trace a single business question from the systems that record the raw data to the screen of the employee asking it, and note what must hold at each step for the answer to be correct, permitted, fast and affordable.
```
#### What This Part Should Cover
- The data foundation and how metric definitions stay consistent
- Access control, privacy and compliance under broad access
- Tooling for different skill levels, plus performance and cost control
- Build-versus-buy choices
### Part 4 — Recommendation and presentation
Should the company do this? Give your recommendation and the reasons for it, and show how your deck fits the whole case into 10 slides and 15 minutes.
```hint Write the one slide first
Decide what an executive should take away if they saw only one slide, then make every other slide support or qualify it.
```
#### What This Part Should Cover
- A clear recommendation and the conditions that would reverse it
- Support from market context and from your own assumptions, with the assumptions visible
- A slide plan that respects the slide and time limits and leaves room for questions
### What a Strong Answer Covers
- A working definition of "everyone" and "self-service" settled early and used consistently
- Assumptions flagged wherever a number appears
- A recommendation that follows from the cost-benefit analysis and the test plan
- The main risks of broad data access, each with a mitigation
- Success measures and decision points that govern whether to expand
### Follow-up Questions
- If the pilot showed strong usage but analysts found material errors in many self-served analyses, what would you change before expanding?
- How would natural-language querying built on large language models change your cost-benefit analysis and your risk list?
- If leadership insists on every employee within the year, what would you cut or sequence to make that promise honestly?
Overview: A product manager case on giving everyone in a company self-service access to data, presented in a deck of at most ten slides. It tests cost-benefit reasoning under flagged assumptions, one-year feasibility, testable hypotheses with minimum viable experiments, high-level technical considerations, and a clear go or no-go recommendation.