Role, Parameters, Functionality Prompt Stack
Give the model a role, operating parameters, and sequenced functionality
- Difficulty
- Easy
- Time to result
- ~days to results
- Steps
- 5
- Confidence
- 96%
This prompt stack supplies three distinct layers of direction. First, assign the model a role that matches the judgment required, such as an elite CTO experienced in lightweight tools for non-technical users. Second, define operating parameters, including simplicity, best-in-class user experience, and short time to value. Third, describe the required functionality as an ordered flow rather than an unordered feature list. The model is then asked to convert the conversation into a functional specification and sequential build plan. Each layer serves a different purpose: the role establishes perspective, the parameters define quality, and the functionality anchors concrete behavior. Together they make an improvised spoken request more actionable without requiring the user to write a formal technical document unaided.
Origin
Extracted from Marketing Against The Grain during Kieran Flanagan's live prompt for a creator-hub specification.
Core principles
- 01Use a role to establish the model's operating perspective
- 02Define quality parameters instead of relying on generic excellence
- 03Describe functionality as a sequence of user-visible outcomes
- 04Make simplicity and time to value explicit constraints
How to run it
- 1
Assign the operating role
Tell the model what kind of expert judgment the task requires. Choose a role whose responsibilities match the desired decisions.
Pro tip Describe relevant strengths, not just a prestigious job title.
Watch out A role cannot compensate for missing facts or requirements.
- 2
Define the user and outcome
Explain who will use the result and what they must be able to accomplish. This gives the role a concrete design target.
Pro tip Include the user's technical ability and expected time to value.
Watch out Avoid describing only the builder's needs while ignoring the end user.
- 3
Set quality parameters
Specify the qualities that should govern trade-offs, such as simplicity, usability, speed, or best-practice UX.
Pro tip Use parameters that can be observed in the finished output.
Watch out Generic adjectives like amazing or world-class provide little operational guidance.
- 4
Sequence the functionality
Describe what happens from the user's first input through the final result. Keep dependencies in their real operating order.
Pro tip Phrase each function as an input, transformation, and output.
Watch out An unordered feature dump can lead to an incoherent workflow.
- 5
Request a buildable specification
Ask the model to turn the agreed flow into sequential phases or parts that can be built and tested independently.
Pro tip Require assumptions and external dependencies to be surfaced.
Watch out Do not assume the first specification is technically compatible with the target platform.
In the wild
Kieran assigned Claude the role of an elite CTO, specified lightweight tools for non-technical users, required simplicity and short time to value, and then narrated the creator hub's functionality from domain entry through creator discovery.
→ Claude produced a phased functional specification rather than an undirected product concept.
A founder assigns the model a support-operations role, states that novice agents need answers in under a minute, defines clarity and auditability as parameters, and sequences ticket intake, classification, retrieval, drafting, and escalation.
→ The resulting specification reflects both operational needs and the intended user experience.
Common mistakes
Using a decorative persona
A role adds little when it is unrelated to the decisions the model must make or lacks relevant operating characteristics.
Leaving quality undefined
Without concrete parameters, the model may optimize for feature volume instead of simplicity or speed.
Listing features without a flow
Features that are not placed in dependency order are harder to convert into coherent phases and interfaces.
Is it for you?
Best for
Non-technical builders translating a product concept into a functional specification or implementation prompt.
Not ideal for
Tasks where the model needs objective source evidence more than a particular expert persona.
From the transcript
“Claude you are going to act as my CTO for this tool we want to build.”
“So you're an elite level CTO you know how to build lightweight tools for non-technical users and make them incredibly simplistic to use using best…”
“Claude, can you start by turning this conversation into a functional spec that we can get aligned on and break it into step-by-step parts that…”
From the episode
Claude Broke. Perplexity Built the App Anyway