Move from a business idea to an actionable project brief. Define the customer problem, test assumptions, scope the first release and assign clear ownership.
A feature list does not automatically turn a business idea into a project. A workable project explains whose problem it addresses, what needs to be tested first, who will deliver the work and how completion will be recognised. That applies to a new digital service, a product, a website or a different way of bringing an offer to market. You do not need every answer at the start. You do need to expose the important unknowns and investigate them in a useful order. The framework below helps you do that before committing the idea to a technology stack or a large build.
1. Describe the job the customer is trying to complete
Saying you want to build a platform describes a possible solution, not why it should exist. Start with what the customer does today, where the difficulty occurs and what that difficulty costs them in practical terms. Then describe your proposed change. This also leaves room to consider whether a simpler service, better information or an operational change could solve the problem.
The GOV.UK discovery guidance recommends understanding the user problem and constraints before committing to delivery. That principle is useful for commercial work as well, without copying a public-service process wholesale. Your brief should explain a credible connection between the customer's need and the experience your business can provide.
2. Separate evidence from assumptions
The customer having a problem, being willing to change and being willing to pay are different propositions. Record the evidence behind each important assumption. A conversation, sales record, support request and internal guess should not appear equally certain. One piece of research does not establish a conclusion for the whole market.
Prioritise assumptions that could change whether the project should proceed. A colour preference may be testable, but whether customers will adopt a new way of working matters earlier. Include delivery capacity, data access, content production and technical dependencies. Evidence of customer interest does not by itself prove that the proposed experience can be delivered reliably.
| Assumption | Question | First learning method |
|---|---|---|
| Problem | Does this difficulty occur in practice? | Interview about a recent experience |
| Behaviour | What does the customer do about it now? | Observe the existing workflow |
| Offer | Does the proposed scope make sense? | Discuss a concrete offer or prototype |
| Delivery | Can we provide the experience? | Run a limited operational trial |
| Technology | Can the critical connection work? | Test the narrow technical dependency |
3. Ask about actual behaviour rather than general enthusiasm
Would you use this app is easy to answer positively without much commitment. Ask when the person last encountered the problem, how they addressed it, who helped and where they abandoned the attempt. Where appropriate, ask to see the current document or workflow. That detail gives you more useful design information than a broad expression of interest in the idea.
Do not assume every participant has the same need. The person approving a purchase may be different from the person using the service. Narrow the initial audience with those differences in mind. Preserve the customer's language and observed behaviour in the research notes, rather than rewriting feedback to match the team's preferred solution.
4. Scope the first release around a completed job
A useful first release lets a customer complete something meaningful from beginning to end. Building registration alone may not do that. Consider how the request arrives, how the team handles it and how the outcome reaches the customer. Some back-office work can initially be manual if the capacity, ownership and limitations are explicit.
Imagine a hypothetical service connecting specialist workshop providers with corporate event enquiries. A first version might use a focused request form, manual matching and proposal tracking instead of a full marketplace. This could help the team learn about demand quality and delivery complexity. It is an illustrative scope, not a validated business model or a claimed customer success.
5. Write a brief that supports delivery decisions
Include the target customer, problem, proposed experience, first-release scope, exclusions, dependencies and acceptance criteria. Replace a vague request for a modern website with the tasks customers must be able to complete. Brand ambition and visual direction matter too, but they should accompany functional delivery conditions rather than substitute for them.
Connect strategy, brand, content, design, development, marketing and project management on one delivery plan. Specify who decides, who supplies information and who checks acceptance. A task may involve several contributors, but it still needs clear ownership. Agree how new requests will be assessed for their effect on scope and timing before they arrive.
- Goal: Which customer problem does the first release address?
- Scope: What complete customer task will it support?
- Boundary: What is deliberately outside this release?
- Dependency: Which information, access or third party is required?
- Acceptance: Which scenarios must work before delivery is complete?
6. Plan the launch as a learning point
After initial use, examine more than visitor volume. Can customers finish the job? Where do they need assistance? Can the team continue providing the service? Compare the observations with the original assumptions. Limited demand could reflect the audience, the clarity of the offer or a lack of relevant reach, so avoid treating one observation as a complete diagnosis.
Before funding the next release, record what has been learned and what remains uncertain. Narrowing the scope or changing the approach can be a sound decision. Project planning should place effort and resources in an order supported by customer evidence, rather than expand an idea automatically because work has already begun.