Ilya Petrov

Growth You Get. Every Tuesday, 7am CET

Hey, AI, Make Me a Growth Plan (2/?): The Research

There's a number in every strategy deck. Everyone nods at it. Now AI found it too, cited the source, made a nice table. It's on the Internet! So it must be true.

Context, in one sentence

In Part 1, we tried one-prompt growth plans, found they compile but don't run, and chose a framework to solve for it. Now: research.

What research can AI actually do?

I'm exploring an AI-only workflow, so I'll skip the "AI as assistant" angle — using it to process your data, clean transcripts, summarize interviews. That works fine. The interesting question is whether AI can do the research itself.

Three modes of AI research are in play here.

  1. Gathering — AI reads the web, pulls reports, synthesizes openly available information. It's doing the legwork, not the thinking.
  2. Referencing — AI finds someone else's findings and presents them as building blocks. It's a librarian, not a researcher.
  3. Pattern-surfacing — and this one's easy to miss. AI itself is a form of research. It's a probability engine trained on the world's text, which means its outputs lean toward whatever conclusions were most common in the training data. This makes it surprisingly good for discovery — surfacing patterns, mapping landscapes, finding things you didn't know to look for. And genuinely dangerous for decisions — because popular conclusions and correct conclusions aren't the same thing.

The make-or-break question turns out to be simple: can AI access the data? Public information, published reports, open web — it handles well. Licensed databases, gated research — it can work with them if connected, but usually isn't. Your internal data — CRM, product analytics, sales pipeline — obviously not available unless you link it properly. And primary research — sitting across from a customer, hearing the hesitation in their voice — not even close (just yet).

For our experiment, this means AI can handle chapters 1 through 3 (market, audience, competitors) and honestly can't touch chapter 4 (internal data). Claude actually recommended skipping it. Nice! Knowing what you can't do is underrated, even for a probability engine.

Numbers are overrated

I've been looking at data for two decades, and here's what I believe: people use numbers as a habit. Not as a thought — instead of a thought.

Say we learn there are 43 million developers. Or 37 million. How does this change your plan? It doesn't. You nod, put the number in a slide, and move on. The number creates the feeling of rigor without producing any actual insight.

There are times you need numbers. Often not.

What I'm actually looking for are stories and repetitions. What's going on, not "how much exactly." When independent sources tell the same directional story, that's signal. When a number appears in every pitch deck but traces back to a single survey with a 260-person sample — that's decoration.

This matters more with AI, because AI is exceptionally good at producing decoration. It pulls numbers confidently, presents them cleanly, and never flags that maybe you should check the methodology. The most dangerous thing about AI research isn't hallucination — it's confirmation theater. You already had a hypothesis. AI made it look researched. The test is simple: did the research change any of your priors? If not, it wasn't research. It was a better-dressed version of what you already believed.

The research

Looking back at the growth plan frames from Part 1, only one was detailed enough to drive research: the first one, from the direct story-based prompt. The rest covered the same territory with less depth.

I did a meta-prompt exercise with Claude Opus — showed it our work so far, shared my requirements, and asked it to create a research prompt. It proposed a chapter-by-chapter approach. I fed the prompts into deep research with extended thinking.

Three things I was solving for in every prompt: structured output I can review without drowning, reasoning transparency so I can catch bad assumptions early, and validation hooks so I can check claims against reality. The tabs below have the very long prompts (which are mostly assembled from the structure documents in Part 1), outcomes, and my reactions.

Chapter 1. Market Landscape for CLion

# Chapter 1: Market Landscape — Deep Research Prompt for CLion ## Context I'm building a growth plan for **CLion**, JetBrains' cross-platform IDE for C and C++ development. This is Chapter 1 of a five-part growth planning framework focused on Discovery — building a factual foundation before any strategy or opinion. The output of this chapter directly feeds into subsequent chapters on Customer Understanding, Competitive Landscape, and Current State assessment. Accuracy and source quality matter more than comprehensiveness — I'd rather have fewer data points I can trust than a wall of unverifiable claims. ## What I Need Work through each of the three sections below **sequentially**. Each section has a defined output artifact — produce it before moving to the next section. --- ### Section 1.1: Market Definition Define the market CLion operates in. Answer: - **Problem category:** What job does CLion do? How would a C/C++ developer describe their need before knowing CLion exists? - **Boundaries:** - Geographic scope (where does JetBrains sell? any restrictions?) - Customer type scope (individual developers, teams, enterprises, students, embedded, game dev, systems programming — who's in, who's out?) - Use case scope (what's clearly in scope for CLion vs. adjacent JetBrains products like ReSharper C++ or Rider?) - **Adjacent markets** that blur the boundaries: VS Code with C++ extensions, general-purpose IDEs with C++ support, embedded/RTOS-specific toolchains **Output → Market Definition Statement:** One clear paragraph defining what market we're analyzing, readable by someone with no context. --- ### Section 1.2: Market Sizing Build TAM/SAM/SOM from the ground up with explicit assumptions. **TAM:** - How many C/C++ developers exist globally? (use Stack Overflow surveys, JetBrains Developer Ecosystem surveys, Evans Data, SlashData, GitHub Octoverse, etc.) - What percentage use or would use a dedicated IDE (vs. text editors, vi/emacs, or basic editors)? - What would they pay annually? (use JetBrains' own pricing as one benchmark, competitor pricing as others) **SAM:** - Which segments can CLion realistically serve given its current capabilities? (e.g., desktop app dev yes, deeply embedded bare-metal maybe less so) - Geographic or platform constraints? - What's the realistic subset of TAM? **SOM:** - What market share does CLion plausibly hold today? (use any available proxy data: JetBrains survey results, download estimates, community size) - What share is realistic in 1-3 years based on comparable product trajectories? **Present the output as a structured table** with columns: Data Point | Value | Source (with URL) | Confidence Level (High/Medium/Low) --- ### Section 1.3: Market Dynamics Analyze the forces shaping this market: - **Growth rate:** Is the C/C++ developer tools market expanding or contracting? What's driving this? (Rust adoption impact, embedded/IoT growth, AI/ML infrastructure in C++, gaming, automotive) - **Technology shifts:** How do AI coding assistants (Copilot, Cursor, etc.) affect the IDE market? What about cloud IDEs? Language server protocol standardization? - **Competitive dynamics:** Is the market consolidating (VS Code dominance) or fragmenting (specialized tools)? - **Economic sensitivity:** How does developer tooling spending respond to tech industry cycles? - **Regulatory/industry factors:** Any relevant trends (automotive safety standards requiring C++, government/defense C++ usage, export controls)? **Output → Market Dynamics Summary:** A structured brief on where this market is heading and why, with timeframes where possible. --- ## Source and Citation Requirements These are strict: 1. **Every quantitative claim** (market size, growth rate, user count, revenue figure, percentage) must include a direct clickable URL to the source. 2. **Preferred sources** (in priority order): - JetBrains Developer Ecosystem Survey (annual) - Stack Overflow Developer Survey (annual) - GitHub Octoverse - SlashData / Developer Nation surveys - Evans Data Corporation - TIOBE Index, RedMonk rankings, IEEE Spectrum - Company earnings reports, press releases, blog posts - Gartner, IDC, Forrester reports (link to summary if paywalled, note it's paywalled) 3. **When sources conflict**, present both values with their respective sources and note which you consider more reliable and why. 4. **When no direct source exists** and you're estimating, mark it clearly: `[ESTIMATE: derived from [Source A](URL) and [Source B](URL) — reasoning: ...]` 5. **When making an assumption**, flag it: `[ASSUMPTION: ... — basis: ...]` 6. **Do not fabricate or approximate URLs.** If you cannot find a direct source for a claim, say so explicitly rather than guessing a URL. --- ## Formatting - Use clear headers matching the section numbers (1.1, 1.2, 1.3) - Produce each output artifact as a distinct, labeled block - Write in direct prose — no filler, no "it's worth noting that," no hedging preamble - After all three sections, add a final section: **Confidence Gaps** — list the 3-5 data points you're least confident about or couldn't find reliable sources for, so I know where to validate or supplement with internal data

The outcome: Opus 4.5

Summary: CLion operates in a ~$1.8–2.7B global C/C++ IDE market serving 18–20 million developers, where it holds an estimated 15–33% share (roughly $40–80M in revenue) alongside Visual Studio and VS Code as the three dominant tools. The market is growing at 6–7% CAGR driven by embedded/automotive/AI infrastructure demand, but faces structural transformation from AI-native coding tools (Cursor, Copilot) and longer-term erosion from Rust adoption — with JetBrains' key strategic challenge being whether deep language intelligence can sustain premium pricing as AI assistants become table-stakes within 2 years.

My thoughts: I like the market definition and the market dynamics summary. Overall, too much numbers: trying to cook something when most ingredients smell and are past their expiration dates. Well, that's what I asked for.

People, not users

Two unexpected things came out of the research. The smaller one: the most fun part turned out to be the history of C and C++ — how the languages emerged, what trade-offs got baked in decades ago, and why the market still looks the way it does because of them. Worth reading separately if you like origin stories.

The bigger one was a gap. The audience research was thinking about people in the context of the product — what IDE they use, what languages they code in, what frustrates them at work. And that's a miss. A huge one.

So I ran an additional chapter that wasn't in the scope: audience in context. Not "C++ developers as CLion prospects," but what surrounds and defines these people as people. What their industries look like, what pressures they face, what their careers feel like — not when they're staring at another memory overflow error, but when they're thinking about whether to stay in embedded or move to something that pays more.

C and C++ developers hold titles that are far more specialized than the generic "Software Engineer" label common in web development. The vocabulary includes Embedded Software Engineer, Firmware Developer, Systems Programmer... rather than the management-track titles more common in other ecosystems. This reflects a culture that values deep individual technical contribution.

This is transferable to any product. Your audience research probably describes users. It probably doesn't describe humans. AI defaults to the same pattern — it thinks about people through your product's lens, because that's how most marketing content is written. You have to explicitly steer it somewhere wider.

The map and the territory

AI research gives you a map. A good-looking one — labels, borders, proportions. The problem is: some coastlines are real, and some interiors are imagined. Early cartographers drew accurate ports they'd visited, then filled the middle of continents with plausible guesses. AI does the same with data.

So I spent a separate session questioning the methodology behind the numbers AI gave me. Not the numbers — the methodology.

One example. Several sources suggested CLion holds roughly a third of the C++ IDE market — an "equal thirds" split with Visual Studio and VS Code. Sounds plausible. AI presented it cleanly. But the survey behind the claim uses a multi-select question. Someone who uses CLion daily but opens VS Code for quick edits counts toward both. "Equal thirds" doesn't mean equal primary usage — it means equal mention in a checkbox list. A different survey, with a single-select "primary tool" question, shows Visual Studio at 64%.

Then there's who's answering. The JetBrains survey skews toward JetBrains users (acknowledged by JetBrains itself). Stack Overflow's survey skews toward web developers — embedded engineers, one of C++'s biggest segments, are 3% of respondents versus 32% in C++-specific surveys.

After triangulating across sources, realistic CLion primary-tool market share is probably 15–25%. Not 33%. That's not a rounding error — that's a different strategic reality.

AI caught none of this. Every number compiled clean. Full analysis is in this document.

What's next?

Roger von Oech's creative process has four roles: Explorer, Artist, Judge, Warrior. The idea is to stay conscious of which role you're in and not mix them. I like this as a stopping rule for research: you keep exploring until you have so many thoughts and ideas that you can't help but jump into creation.

I'm there. The discovery stage is about capturing what exists — facts, no judgment. I have enough data to move forward, and enough hard-won understanding of where that data is reliable and where it's decoration.

Next time, we start making sense of it. Diagnosis: where could we go?

#strategy #ai #growth