The report you actually need to read.

Process · 5 min read

Early in every project, I deliver a product report. It covers the competitive landscape, user research, feature analysis, and strategic recommendations. It's dense. It's detailed. And it's the homework that has to happen before the design begins.

Some clients read it cover to cover. One client read it on a flight to Perth and came back to the next meeting with specific questions about competitor pricing models, feature gaps in existing apps, and which user segment we should target first. That meeting was one of the most productive I've ever had. We made decisions in forty-five minutes that would normally take three sessions.

Other clients skim it. Some skip it entirely. And the difference shows up in every conversation that follows.

What the report actually contains

The product report isn't a proposal or a pitch. It's research. I look at what already exists in your space. Who your competitors are. What they do well. Where they fall short. What their users complain about in app store reviews. What features seem standard and which ones are differentiators. I also look at the users themselves. Who are they? What do they need? What frustrates them about the current options?

Then I pull it together into recommendations. Based on everything I've found, here's what I think your app should focus on. Here's what it should avoid. Here's where the opportunity is. It's not a list of features. It's a strategic argument for why your app should exist and what it needs to do differently.

This is the foundation. Every design decision that comes after this report is informed by it. If you skip the report, you're making those decisions without context. And context is the difference between guessing and knowing.

The gap between reading and skimming

I can tell within the first five minutes of a meeting whether the client read the report. The ones who did ask pointed questions. "You mentioned that competitor X doesn't support offline mode. Is that something we should prioritise?" That's a conversation I can work with. We're building on shared understanding.

The ones who didn't read it ask broader questions. "So what did you find?" And then I'm spending half the meeting summarising a document they could have read the night before. We're not making decisions. We're doing information transfer. That's expensive time, for both of us.

CB Insights found that 58% of founders wish they had done more research before building. This report IS that research. It's the upfront work that most people skip and then regret later. Reading it before the meeting isn't optional homework. It's the single most valuable thing you can do for your project at that stage.

How to get the most from it

Read it somewhere quiet. Not between meetings. Not while you're driving. Give it thirty minutes of proper attention. Highlight the parts that surprise you. Circle the competitor features you didn't know about. Write down questions. The report is designed to provoke thinking, not just deliver information.

If something doesn't make sense, flag it. If you disagree with a recommendation, that's even better. Disagreement means you've engaged with the material deeply enough to form your own view. Those are the best meetings. The ones where the client pushes back with a clear reason and we end up somewhere neither of us expected.

The report exists to make every meeting after it faster, sharper, and more productive. But only if you read it. So read it.

Sources
Top Reasons Startups Fail (CB Insights, 2021) - 58% of founders wish they had done more research before building.

Related blog posts:

Don't forget to do your homework →

How to prepare for your first app design project →

The content bottleneck nobody plans for →