To turn a business idea into a project, define whose problem you are solving. Then choose one task that person needs to complete and test a small first version. The first step is to check the need and your ability to deliver the solution, rather than build every proposed feature.
Describe the customer’s problem
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.
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 |
Ask about past behaviour in interviews
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.
Complete one job in the first version
Illustrative idea: companies struggle to find a suitable workshop for an event. The first version does not need to be a large self-service marketplace. A request form, manual matching by the team and a shortlist sent to the customer can test the core service journey.
Record missing information and the human effort required to make a match. Ask why the customer accepted or rejected the options. If people cannot submit a request, review the interface. If requests arrive but suitable workshops cannot be found, investigate supply and the business model.
| First-version step | What it tests | A simple initial approach |
|---|---|---|
| Capture an event request | Required dates, subject and group details | Short form and clarification call |
| Find a suitable workshop | Whether supply can meet the request | Manual matching by the team |
| Send options | How the customer chooses | Clear shortlist and feedback |
| Complete the request | Whether operations can deliver | Follow-up list and service confirmation |
Write the project brief
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?
Choose the next step after first use
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.