Original practice question. The scoring rubric is our teaching guide. How we research and score answers
TL;DR: Tenfold growth rarely comes from improving conversion for the current audience; it comes from reaching new segments. Size the segments (professional developers not yet using the tool, teams inside companies already using it, and non-developers who want software built), then fix the specific barrier for each: trust and setup for developers, procurement for teams, and an experience that does not assume coding knowledge for everyone else. Watch cost per active user and task success as you grow.
How to approach it
Clarify the starting point: who uses it now, how they found it, how many stay, and how it is priced. Then do quick arithmetic: if today's segment is close to saturated, tenfold growth cannot come from it. The answer should be a portfolio of two or three segment bets with the barrier each must remove, not a list of features.
A strong answer
Assume the tool is used today mostly by individual professional developers who adopted it themselves, with good retention once they get past the first week.
Where can ten times more weekly users come from? Three pools, roughly:
| Segment | What they want | Main barrier today |
|---|---|---|
| Professional developers not yet using it | Faster, less tedious coding in their existing setup | Trust (will it break my code?), setup friction, first-week value |
| Teams at companies where a few developers already use it | Standardised tool, security approval, shared context | Procurement, security review, admin controls |
| Non-developers: analysts, founders, designers, students | Working software without learning to code | The product assumes code knowledge |
The third pool is the largest and the hardest; the second is the fastest; the first is the most familiar.
The pools are large and still growing. GitHub's Octoverse 2026 (October 2026) counts 38.3 million developers in the United States and 32 million in India, each adding more than 10 million in the year, and reports that over 40% of pull requests started with an agent's first draft, up from 17% in March (company-reported). Growth here is a question of which of those people you can serve, not whether they exist.
Bet 1: land and expand inside companies. Individual developers are already the evidence. Give them a reason and a path to bring their team: shared project context, team billing, admin controls, and the security documentation that procurement asks for. Usage data showing several developers at one company is a sales lead. This multiplies users per account without new acquisition cost.
Bet 2: a first week that earns trust. For professional developers trying it, the first sessions decide retention. Trust is conditional: in Stack Overflow's 2026 survey, 48% said they trust AI "when they can easily validate the answers". And perceived speed is not measured speed: a randomised trial with experienced open-source developers found AI tools increased task completion time by 19%, while the developers themselves expected a 20% speed-up (METR, 2025). Design the first week around tasks whose results are easy to check, and measure accepted changes, not how fast people feel. Measure time to first accepted change and first-week retention by entry point. Improve the experience on the tasks people try first (writing tests, explaining unfamiliar code, small refactors), where success is easy to verify and builds trust before larger agent tasks.
Bet 3: a mode for people who do not code. Describe the app you want, see it running, change it by talking. This needs hosting, sensible defaults and guardrails (no deleting production data, no exposed secrets). It is a different product surface and probably a separate entry point, but it is where an order of magnitude more people are.
Constraints to manage while growing.
- Cost per active user. Agent features can make many model calls per task. Growth through free users at high cost per user can burn cash quickly. Free tiers need allowances, and routing must send simple completions to cheap models.
- Reliability at scale. New users try more varied tasks. Track task success by segment, especially for non-developers, whose failures they cannot debug themselves.
- Quality of the produced code. For non-developers, security mistakes in generated apps become our reputation. A 2025 vulnerability record against an app-building product described generated sites whose database access rules let unauthenticated users read or write tables (CVE-2025-48757, disputed by the vendor). Defaults like secret scanning, safe database rules and safe deployment templates matter more than any feature.
Metrics. Weekly active users by segment; first-week retention by entry point; users per company account; task success by segment; gross margin per active user.
What interviewers probe next
"Which bet first?" Teams inside existing accounts: fastest, cheapest, and it funds the rest. Start building the non-developer mode in parallel with a small team, since it takes longest.
"A competitor offers its tool free. Respond?" Compete on task success and team features rather than price; matching free usage on agent features can destroy margins.
How it's scored
| Signal | Weak | Hire | Strong Hire |
|---|---|---|---|
| Framing | Feature list | Funnel improvements | Shows tenfold needs new segments and sizes them |
| Strategy | One channel | Several growth levers | Two or three segment bets each tied to a specific barrier, sequenced |
| Constraints | Ignored | Mentions cost | Cost per active user, reliability by segment and generated-code safety as guardrails |
Common mistakes
Treating tenfold growth as conversion optimisation for the current audience.
Growing free usage of expensive agent features without allowances.
Launching to non-developers without safe defaults.