Module 2, Lesson 5: Generating the Investor Summary

In the last lesson, we wrapped up the UX/UI document — the front-facing picture of how the product is going to look and feel. Now we're flipping perspective entirely. This lesson is about generating your stakeholder summary: a non-technical, high-level document that answers one question above everything else — will this make money?

Before We Start

Here's what I'd expect you to have in place before this lesson:

From previous lessons:

• Your market research document — saved in Obsidian (or your notes tool)
• Your technical document from Module 2, Lesson 3
• Your UX/UI document from Module 2, Lesson 4
• Claude Desktop open, with Cowork configured to point at your project folder — same setup as the previous lessons

Tools / setup you'll need:

• Claude Desktop (local desktop app — not the browser version)
• Obsidian (or whichever notes tool you're using) with your project folder accessible
• The stakeholder summary prompt from this lesson — available in the notes below. Customise it with your product's domain name before you run it.

By the end of this lesson, you'll:

• Have a complete investor/stakeholder summary saved to your project folder
• Understand what investors and partners actually want to read (hint: it's not a feature list)
• Know how to review and sanity-check the output Claude produces
• Have a document you could genuinely hand to a potential investor, advisor, or co-founder today

About This Lesson

Duration: ~7 minutes video + ~20 minutes to generate and review your own document
Skill Level: Intermediate
What You'll Build: An investor/stakeholder summary document — non-technical, business-forward, and grounded in your research

This is one of my favourite documents in the whole pipeline. Most people building products never produce something like this unless they're actively raising money. But I generate it regardless — because it forces clarity. If you can't explain why your product makes money in one document, you probably don't know yet. And it's a lot better to find that out now.

Watch the Lesson

What We're Covering

Here's what I'm walking you through in this lesson and why it matters if you're trying to ship real things:

• What a stakeholder/investor summary actually is — and why it's different from everything else we've generated so far
• The prompt structure — what role I assign Claude and why, and what inputs you need to provide
• Walking through the output — what sections you should expect to see and what each one is doing
• How to use this document — whether you're raising, partnering, or just pressure-testing your own thinking

1. Let's Set the Scene (~0:00)

We've just wrapped the UX/UI document. At this point, you have a solid technical picture and a solid front-facing picture of your product. What you don't have yet is the business picture.

That's what this lesson is about. The stakeholder summary — I sometimes call it the investor summary — is a document you'd hand to someone who doesn't know how to build software, and they'd walk away understanding exactly what you're building, who it's for, why it's different, and whether it can make money. That's it. It's not technical. It's not a spec. It's a business case, generated from all the research we've done.

And the great thing? Claude already has everything it needs to write this. It's sitting in your project folder. All we have to do is point it at the right role and ask the right question.

2. The Core Idea

2.1 What Makes This Document Different

Every other document we've generated up to this point has been aimed inward — at the people building the product. The technical doc is for developers. The UX/UI doc is for designers or an AI coding agent. Even the market research is a working document for your own decision-making.

This one is different. The stakeholder summary is aimed outward. It's for someone who doesn't know how to build software and, honestly, doesn't want to. What they want to know is: does this opportunity make sense? Is the market real? Does the product have a clear angle? Can it generate revenue?

Investors, advisors, potential partners, even a co-founder you're trying to bring on — this is the document you hand them. They'll form their first real opinion of your business from this.

2.2 Lead With Consequences, Not Description

One of the first things I noticed when Claude generated this for my app was that it led with consequences, not descriptions. Not "this app does X" but "this is the problem people are living with and here's what changes when they use your product."

That's the right framing. A description tells someone what your app does. A consequence tells them what their life looks like after they use it. The second one is what gets people interested.

2.3 How This Connects to Module 2, Lesson 4 — UX/UI Document

We've been building up a folder of documents since Module 2, Lesson 1. Each one feeds the next. The investor summary is the first document that synthesises all of them — it pulls from the market research, the technical approach, and the UX direction — and reframes it through a business lens.

This is also why the order matters. You couldn't have written a credible stakeholder summary on day one. You needed the research first. The research earns the narrative.

3. Let Me Show You How It Works (~0:30)

3.1 The Setup

I'm still in the same Cowork workspace I used to generate the UX/UI document in the last lesson. The workspace is already pointing at my project folder in Obsidian — same setup, no changes needed. All the previous documents are in scope.

3.2 The Prompt

The prompt I use for this assigns Claude the role of a product strategist — specifically, one working for a company that builds tools for solopreneurs and small teams.

The key inputs the prompt needs from you:

• Your domain name — this is how Claude knows what product it's working with
• Your project folder — already in scope if you're in the same Cowork workspace

Everything else — the market context, the revenue model, the competitive landscape — it pulls from the documents already in your folder.

Here's the prompt structure I use:

Take that, customise your domain name, and run it. That's all you need.

3.3 What Claude Produces

Once the prompt runs, you'll get a structured document back. Let me walk you through what to expect in each section and what you're looking for.

The problem section should lead with consequences — what happens to people who don't have your product today. Not "people struggle with X" but "here's what that actually costs them: time, money, stress, risk." If Claude writes a generic description here, push back on it and ask it to make it more specific.

The solution is a tight paragraph — what you built and the one thing that makes it different from everything else out there. Not a feature list. One clear angle.

Key features maps to your MVP. For my app, Claude pulled out the receipt scanning, AI tone detection, and court-ready export — not everything on the backlog, just the features that define the initial value.

Target customer should be specific. Not "parents" but something more like: a US-based co-parent, between 28 and 45, navigating joint custody, who's already been burned by informal communication going sideways. The more specific it is, the more useful it is.

Value proposition — I love how Claude handles this. It writes a short first-person customer story. Not "our product helps users X" — but a realistic scenario of someone using the product and what changed for them. That's how you communicate value to an investor. Show them what a customer's life looks like after.

Revenue model is the section investors care most about. Claude will generate a free and paid tier breakdown, with pricing and a projection — something like "$15,000 MRR at 900 paying customers." That's the kind of number an investor can engage with. Does it feel achievable? Does the math hold? You'll want to eyeball this and decide if it's realistic for your market.

Competitive landscape maps who else is in the space. And here's the thing — if there's no competition in your market, that's a red flag, not a green light. Competition means there's money being made. Your job is to find your angle, not to be the only one.

Risks should be honest. Don't let Claude sugarcoat this. Real risks — user acquisition costs, regulatory exposure, dependency on a platform — make the document credible. An investor who sees a risk section with no meaningful risks will trust the whole document less.

Success metrics and timeline gives you a 12-month picture. What does progress look like? What are the milestones? This grounds the document in reality rather than aspiration.

4. Reviewing the Output in Obsidian

Once Claude's done, the document saves directly to Obsidian through the MCP integration — same as the previous documents. Go in and read it in full.

Here's what I'm checking when I review it:

Does it lead with consequences? If the opening section sounds like a product description rather than a problem statement, go back and push Claude to reframe it.

Is the customer profile specific? If it says something like "target customers include busy professionals," that's too vague. Ask Claude to sharpen it based on the research.

Does the value proposition feel real? The customer story should feel like something a real person would actually say. If it reads like marketing copy, ask Claude to rewrite it as a genuine user scenario.

Is the revenue projection grounded? Check that the numbers are anchored in the research — not invented from thin air. If they feel arbitrary, ask Claude to walk through the assumptions.

Is the risk section honest? If it feels too positive, it probably is. Add risks you know about that Claude may not have surfaced.

5. Watch Out For These

6. Practice

Exercise 1: Generate Your Own Investor Summary

What to do: Take the prompt structure from Section 3.2, grab the full version from the prompt library, customise it with your domain name, and run it in the same Cowork workspace you've been using.

A nudge if you're stuck: If you're not sure what to put for the domain name, use the app name or URL you decided on in Module 2, Lesson 3 when you named your product.

How you'll know it's working: Claude produces a structured document with all nine sections. It saves to Obsidian. You can read it top to bottom and it tells a coherent business story — not a feature list.

Exercise 2: Review and Sharpen

What to do: Read the document Claude produced. Pick the two sections that feel weakest or most generic, and use follow-up prompts to tighten them. Then share it in the community.

What this is practising: Prompt iteration — the skill of reviewing AI output critically and knowing when and how to push back. This is one of the most important skills in this whole course.

7. You Should Be Able to Build This Now

Here's what you can put together with what we just covered:

• A complete investor/stakeholder summary for any product idea you're working on
• A document you can share with an advisor, potential co-founder, or investor — today

Check Yourself

• I've generated my investor summary using the Cowork workspace
• The document is saved to Obsidian (or my notes tool)
• I've reviewed it section by section and it tells a coherent business story
• The revenue model section has specific numbers and I understand where they came from
• I've shared it in the community (or at least read it with fresh eyes)

If Something's Not Working

The Short Version

Here's what I want you to walk away with:

• The investor summary is a business document, not a technical one: It's aimed at someone who can't build software and doesn't want to. Its job is to answer one question — will this make money?
• Lead with consequences: What do people lose or suffer from today? That's the opening, not a feature description.
• Claude does the heavy lifting — you do the review: The output will be solid because it's grounded in everything you've already produced. Your job is to read it critically and sharpen the weak sections.
• What you can do now: Hand this document to anyone — investor, advisor, co-founder — and have a real business conversation.

Quick Reference

Prompt Inputs

Your domain name    — e.g. notoro.app, myproduct.io
Your project folder — already in scope if using the same Cowork workspace

Nine Sections of the Investor Summary

1. Problem               — consequences of the status quo
2. Solution              — what the product does and the one thing that's different
3. Key features          — MVP scope only
4. Target customer       — specific profile, not a broad demographic
5. Value proposition     — a real customer scenario, not marketing copy
6. Revenue model         — tiers, pricing, projections
7. Competitive landscape — who's in the market and where your angle sits
8. Risks                 — honest; what could go wrong
9. Success metrics       — what progress looks like over 12 months

Review Checklist

□ Leads with consequences (not description)
□ Customer profile is specific
□ Value proposition reads like a real person, not copy
□ Revenue numbers are grounded in the research
□ Risk section is honest

Resources

Tools Used

• Claude Desktop — local desktop app, used with Cowork
• Obsidian — where generated documents are saved via MCP

Prompts

• Full stakeholder summary prompt — available in the Build What Ships prompt library

Questions I Get Asked

Q: Do I actually need this document if I'm not raising money?

Yes, and here's why: it forces you to answer the question you'd rather avoid — can this make money? You can build something beautiful that nobody pays for. The investor summary makes you confront the business model before you've written a line of code. That's valuable regardless of whether you ever talk to an investor.

Q: What if the revenue projections Claude generates feel way off?

I get this one a lot. The projections are only as good as the research feeding them. If your market research document has real competitive pricing data and market size estimates, the projections will be grounded. If the research is thin, the numbers will be thin too. Go back to your market research, check what data you have, and either enrich it or ask Claude to walk through its assumptions and adjust them manually.

Q: How do I know I'm ready for the next lesson?

If you've generated the document, reviewed it section by section, and can explain out loud what makes your product's revenue model credible — you're ready. The next lesson is the GTM document, which is the last one we generate before moving out of documentation and into user journey mapping.

💬 Stuck? Come Talk to Us

Glossary

Stakeholder Summary: A non-technical, business-forward document that describes what you're building, who it's for, and how it makes money. Written for investors, advisors, and partners — not developers. (introduced in Module 2, Lesson 5)

Investor Summary: Another name for the stakeholder summary — same document, different label depending on your audience. (introduced in Module 2, Lesson 5)

Value Proposition: What makes your product worth using over the alternatives — expressed as a real customer outcome or scenario, not a feature list. (first appeared in Module 2, Lesson 1; formalised here in Module 2, Lesson 5)

Revenue Projection: A forward-looking estimate of monthly recurring revenue at a specific user count, grounded in your market research and pricing model. (introduced in Module 2, Lesson 5)

Competitive Landscape: The map of who else is in your market — the established players, the niche players, and where your product's angle sits relative to them. (first covered in Module 2, Lesson 1; presented here from an investor perspective)

MRR (Monthly Recurring Revenue): The amount of predictable revenue your product generates each month from subscriptions. A common metric investors use to evaluate SaaS products. (introduced in Module 2, Lesson 5)

Cowork: Claude's task/workspace feature that gives Claude continuity across a session — it can see your files, read your documents, and write back to your notes tool through MCP integrations. (first introduced in Module 2, Lesson 3)