All Blog Posts

What does a good brief look like in the age of AI?

AI can write you a shiny spankin’ new brief in seconds. Useful is another matter. Here’s what a good brief actually needs, what to leave out, and why AI slop wastes everyone’s time.

3 SIDED CUBE
9 Min Read
Two people smiling and working together on laptops, in a bright office setting with a whiteboard in the background.

TL;DR

What does a good brief look like in the age of AI? These are the ten things you need to do:

  1. Be clear about your role and involvement

  2. Start with the problem, not the solution

  3. Know your users, even if you do not know everything yet

  4. Be upfront about timeline and budget

  5. Define what success looks like

  6. Share the context you have, even the awkward bits

  7. Outline your technical landscape

  8. Be clear about the RFP response and deadline

  9. Say how you will benchmark agencies

  10. Include any useful documentation or tools you already have

What does a good brief look like in the age of AI?

Let’s keep it 💯

A lot of AI briefs out there right now look tidy, sound clever, and are about as useful as a chocolate teapot. (I said what I said!)

They have neat headings. Lovely grammar, and the odd phrase like “innovative digital solution” is peppered liberally throughout. Some even throw in a suggested tech stack, which is always ambitious.

But once you get past the shiny surface, a lot of them are missing the stuff that actually matters. Like… What is the problem? Who is this for? Why now? What does success look like? Is there a budget? Is there a deadline? Has anyone actually validated the idea, or did ChatGPT just hype girl it up and send it on its merry way?!

At 3 Sided Cube, around 70% of the briefs we have received over the past year showed clear signs of AI being heavy-handed with its involvement somewhere in the process. And look, we are not here to do the tired “AI bad” routine. We are an AI-first agency. We know the robot stuff can be brilliant.

But there is a difference between using AI to help shape your thinking and letting it write a brief that sounds polished while saying absolutely sod all.

That’s where things go sideways.

Because a good brief is not meant to win points for sounding fancy. It’s meant to help the agency understand what you are trying to do, what is getting in the way, and whether they are the right people to help you build it.

And when that bit is missing, the whole process gets a whole lot more… process-y.

You get vague proposals. Confused follow-up questions. Agencies making completely different assumptions. Timelines that do not match. Costs that are all over the shop. Everybody smiling politely while quietly realising the brief has told them almost nothing.

So we ask… beg… plead with you to read this handy-dandy guide to using our BFF AI before filling out your next brief.

(Spoiler: the collab needed is a human x AI one)

What is a good brief, really?!

At its core, a brief is just the thing that helps an agency understand what you are trying to do before anyone starts chucking timelines, budgets, and shiny new ideas around.

That’s it!

It is not a creative writing exercise. It is not a place to try to sound wildly impressive. And it is definitely not where you dump a huge list of features and hope the agency works out what the actual challenge is from context clues and vibes

A good brief gives shape to the opportunity. It explains the problem, who it affects, what you think needs to change, and what might get in the way. It gives an agency enough to respond properly, challenge you where needed, and tell you honestly whether they are the right fit.

It does not need to be fancy. It just needs to be useful.

Why does a good brief actually matter?

Because a vague brief creates a vague process (our absolute kryptonite)

If your brief is fluffy, generic, or mostly stitched together by a chatbot that knows nothing about your users, your organisation, or the internal politics quietly bubbling away in the background, you are making life harder for everyone involved.

You will get wildly different responses. One agency will assume you want a full build. Another will assume you need a discovery phase first. Another will send you a giant strategy deck full of buzzwords and stock imagery. Another will come back with twenty questions because they are trying to reverse-engineer what on earth you actually need.

Then suddenly you are comparing apples, oranges, and one mysterious fruit no one can identify.

A strong brief cuts right through that.

It helps agencies respond to the same challenge with the same context in mind. It gives you better proposals, better questions, and a much better shot at finding the right partner. It also helps the agency spot risks earlier, recommend smarter approaches, and save everyone from disappearing down the wrong rabbit hole at speed.

And no, it does not have to be perfect.

Some of the best briefs we see are the ones that are honest. They come from people who know the problem they are trying to solve, have thought about the humans involved, and are upfront about what they know, what they do not, and where they need support.

That is infinitely more useful than a glossy doc that sounds clever and says very little.

Woman smiling while working on a laptop at a colorful office desk, surrounded by plants and a vibrant wall design.

What should a good brief include?

You do not need to write War and Peace

You do need to include the things that will help an agency understand the shape of the project and respond in a grounded, useful way.

1. Be clear about your role and involvement

Before anything else, be clear about who you are in this process.

Are you the decision-maker? One voice in a bigger stakeholder group? Leading procurement? Bringing ideas together from different teams? Hoping for a very collaborative relationship, or looking for an agency to take more of the lead?

This matters more than people think. It shapes how the work is run, who needs to be involved, and how quickly decisions are likely to happen.

It is useful to include things like how involved you can be day to day, whether internal stakeholders will be joining calls, whether you have product or technical people in-house, and whether you expect to bring any of the work in-house later on.

You do not need to draw a little organisational family tree (although that sounds cute!). Just help the agency understand who is in the room and how this thing is likely to move.

2. Start with the problem, not the solution

This is the biggie!

A lot of briefs start with the thing someone thinks they need. We need an app. We want a platform. We are looking for an Artificial Intelligence tool. We need a dashboard. We want a chatbot.

Cool story, bro. But why?

What is actually going wrong right now? What is clunky, manual, slow, confusing, inconsistent, or driving everyone slightly up the wall? What is the real problem under the shiny proposed solution?

That is the useful bit.

If your field teams are collecting data on paper and manually re-entering it later, say that. If your customers are dropping off because the booking journey is a faff on mobile, say that. If your internal team is doing the same repetitive task a hundred times a week because your systems barely talk to each other, say that.

That gives an agency something real to work with.

The strongest briefs do not start with a laundry list of features. They start with a clear challenge. Because once the problem is understood, the right solution gets a whole lot easier to shape.

If you start with the solution too early, you run the risk of solving the wrong thing really, really well.

3. Know your users, even if you do not know everything yet

You do not need a giant research deck. You do not need fictional personas with names like Busy Brenda and Strategic Steve.

But you do need to show that you have thought about who this thing is actually for.

Who is going to use it? What are they trying to do? What is getting in their way today? What does their day look like when they come into contact with this product? Are they under pressure? On bad signal? Time-poor? Already juggling ten things at once?

That context matters. A lot.

And if you are not fully sure yet, that is completely fine! Just say so.

“We think our primary users are X, but we have not fully validated that yet” is a genuinely useful sentence in a brief. It tells an agency what you know, what is still a bit foggy, and where some early discovery work might be needed.

Honest uncertainty is far more helpful than fake confidence.

4. Be upfront about timeline and budget

This is the section where people suddenly get a bit coy.

Nobody loves putting a budget in writing in case they anchor too low. Nobody loves admitting the timeline in their head might be a tiny bit optimistic. But if you leave both of these things out, it becomes much harder for an agency to respond with anything grounded in reality.

Budget and timeline are not boring admin details. They shape everything.

You do not need to be exact. A range is helpful. A rough target for launch is helpful. A note on what is fixed and what is flexible is helpful.

“We are working with roughly £80k to £120k and would like to launch an MVP in six months” gives an agency something real to respond to.

“We want something brilliant and quick, but we are open-minded” does not. Ambition is lovely. It just still needs a postcode.

If you need some help estimating cost and a timeline, check out our handy dandy video guides below!

How much does an app cost?

How long does it take to build an app?

5. Define what success looks like

Please do not write “a working app”.

That is not success. That is the minimum requirement.

What does good actually look like six months after launch? What needs to be different? What are you trying to improve, reduce, increase, or unlock?

Maybe it is more active users. Maybe it is fewer support tickets. Maybe it is less manual admin, stronger retention, better data visibility, faster response times, more revenue, or greater engagement with a key feature.

Whatever it is, say it.

If success is clear, an agency can build towards it. If success is vague, you often end up with something that technically works but does not really move the needle on anything that matters.

Then six months later everyone is having a very expensive conversation about whether the thing “feels good”. Useful projects need useful measures. 

6. Share the context you have, even the awkward bits

Honestly, this bit is gold dust.

Had a previous build that did not work out? Say it.

Worked with another supplier and it went sideways? Say it.

Got internal stakeholders pulling in different directions? Say it.

Tried a similar idea before and watched it fall flat on its face? Defo say it.

The bits that feel messy or awks are often the most useful. They tell an agency where the risks are, what sensitivities exist, and what baggage the project is already carrying into the room.

No decent agency is going to be scandalised that something failed before. We would much rather know the truth than accidentally repeat the same mistakes in a shinier deck.

7. Outline your technical landscape

You do not need to be technical to write this section well.

No one is asking you to suddenly transform into an engineer and start throwing platform opinions around for sport. We just need to know what already exists and what this new thing needs to play nicely with.

That might include existing systems, internal tools, data sources, codebases, integrations, device limitations, compliance requirements, accessibility needs, or security constraints.

If there are technical preferences, explain why.

“We need this to work on Android because most of our field teams use Android devices” is useful. “We want Flutter” with no context is the kind of sentence that leaves agencies staring into the middle distance for a second.

The clearer you can be about the technical reality around the project, the easier it is to recommend the right approach!

8. Be clear about the RFP response and deadline

If you are sending the brief to more than one agency, make the ask clear.

When do you need a response? What format do you want it in? Are you after a detailed proposal, a rough ballpark, a presentation deck, a written response, a workshop, or a chemistry call? Will there be a second stage? Is there time set aside for questions?

These are not tiny details. They shape how agencies respond and how easy those responses will be to compare.

If you give no steer at all, you can end up with one agency sending a tightly scoped proposal, another sending a glossy deck with dramatic stock imagery, and a third essentially writing you a novella.

That is not a fair comparison. That is pitch roulette. A bit of clarity here saves a lot of pain later.

9. Say how you will benchmark agencies

You do not need a giant scoring matrix with weighted columns and colour coding (although fair play if that is your thing!), but it is genuinely helpful to tell agencies what you are prioritising.

Is it relevant sector experience? Technical capability? Strategic thinking? Cultural fit? Speed? Long-term support? Budget? A team that will challenge you instead of nodding at everything?

If agencies know how you are making your decision, they can focus on the things that actually matter to you instead of trying to cram every possible strength into one response.

That makes for better pitches and a much saner selection process on your side too.

10. Include any useful documentation or tools you already have

Got a prototype? A Figma file? A Google Doc? User research? An existing roadmap? A half-built product? A slightly chaotic concept deck with a few rogue AI bits still clinging on for dear life?

Send it!

Useful context does not need to be polished to be useful. In fact, some of the scrappiest docs are the ones that tell the clearest story.

Anything that helps an agency understand what has already been explored, what decisions have already been made, or what shape the thinking is in can save a lot of time and stop everyone reinventing the wheel.

And if something is sensitive, no stress. Get an NDA in place and carry on.

What matters is not whether the supporting materials look pretty. It is whether they help tell the truth.

What should not go in a brief?

A brief should be useful, not bloated. There are a few things that tend to make them worse rather than better.

The first is vague comparisons.

“Like Uber, but for X” is not enough on its own. What part of Uber? The booking flow? The marketplace model? The customer journey? The location tracking? The general vibe? If you are using another product as a reference point, explain what is actually relevant. Otherwise it’s just startup Mad Libs.

The second is giant feature lists masquerading as strategy.

A massive list of features can make a brief look detailed, but often it just tells us nobody has prioritised anything yet. We do not need every single idea you have had in the shower, in a Teams call, or at 2am in your Notes app. We need the core problem, the key needs, and the things that matter most right now.

The third is copying and pasting an AI-generated template and calling it done.

This is the big one!

AI can absolutely help you get started. It is useful for structure, useful for prompts, useful for getting past the blank page wobble. But if the brief has been generated in seconds and barely touched by the person behind the project, it usually shows.

The language gets smoother, but the meaning gets thinner. It sounds polished while neatly sidestepping all the questions that would actually help the project succeed. It is all skin, no skeleton.

Use AI, by all means. Just make sure you are still in the driver’s seat. The final brief should sound like someone understands the project, not just the prompt box.

For a bit of fun, take a look at our fully AI-generated 'Bad Brief' below. It contains 0 measurable goals, 0 user personas, 0 specific features, and exactly 1 vague market claim!

Bad example of an app brief for BriefMaster Pro, a brief-writing tool.

So, what does a good brief actually look like?

A good brief looks like somebody has thought properly. Not perfectly, properly!

It sounds like a real person explaining a real challenge with enough honesty, context, and clarity that the right agency can do something useful with it.

It is clear on the problem. Clear on the user. Clear on the constraints. Clear on what success looks like. And clear on where things are still uncertain.

It does not bluff its way through the gaps. It does not hide behind polished language. And it definitely does not confuse “professionally written” with “actually useful”.

Because the best briefs are not the ones that sound the smartest, they are the ones that start the best conversations!

Shout us a holla

If your brief is currently a mix of half-formed ideas, scattered notes, stakeholder opinions, and one suspiciously confident AI paragraph, you are not alone. That is exactly where a lot of projects start.

If you want help shaping it into something useful, shout us a holla. We love to chat!

We can help you pressure-test the thinking, spot the gaps, and turn the early chaos into a brief that gives your project a fighting chance.

Published on 13 April 2026, last updated on 13 April 2026