From brief to focus areas
How to write a brief that produces useful focus area suggestions, and how to review and refine those suggestions into a solid spec.
The brief-to-focus-areas step is the most important in the Penling workflow. A well-written brief produces focus area suggestions that are close to final; a vague brief produces suggestions that need significant rework. This guide covers both.
Writing a brief that works
A brief should answer three questions in a few paragraphs:
What are you building? Be specific about the surface (which part of the product), the user (who benefits), and the behavior change (what they can do that they couldn't before).
Why does it matter? Describe the user need or business requirement. The AI uses this to understand priority and infer decisions you haven't made explicit.
What's out of scope? List at least one thing you're explicitly not doing. This is the most often skipped part, and the most important — it prevents the AI from suggesting focus areas for work you haven't decided to do yet.
Brief length
Three to eight sentences is the right range. Shorter than three and there's not enough signal. Longer than eight and you're probably doing work that belongs in the focus areas themselves.
What to leave out
Don't include implementation details in the brief — preferred tech stack, specific API names, data model choices. These belong in focus area notes, not the brief. The brief is about what and why, not how.
Reviewing AI-suggested focus areas
After submitting the brief, Penling surfaces a set of suggested focus areas. Work through them in order:
Check the split
Each focus area should be independently reviewable and testable. If two focus areas are so coupled that you can't review one without the other, consider merging them. If one focus area contains two clearly distinct slices of work, split it.
Check the results
Read the results of each focus area. Ask: could a developer look at this and know, without asking anyone, whether they've done it correctly? If the answer is no, the results need to be more specific.
Check the boundaries
Every focus area should have at least one boundary. If a suggested focus area has none, add one — even if it feels obvious. Obvious boundaries are the ones that cause the most scope creep when they're unwritten.
Handle AI clarifications
If Penling raised clarifications during extraction, answer them before finalising the focus areas. Unanswered clarifications mean the AI made assumptions — those assumptions are in the spec whether you want them there or not.
Ordering focus areas
Once you're happy with the content, think about ordering. Drag focus areas to reflect the sequence you expect to build them in. This isn't the plan — it's a hint to the plan generator about dependencies and criticality.
Foundation work (auth, data models, APIs) typically comes first. User-facing surfaces come after the systems they depend on. Nice-to-have refinements come last.