How should a small team plan InCubed's outline, pitch and full-proposal stages?

A small company should plan InCubed as a sequence of decisions rather than a single application deadline. The outline and pitch help determine whether the proposition should progress, change or stop. The full proposal then needs to reflect the feedback and the confirmed funding position.

The current guidance begins with an outline submitted through the indicated portal and a possible pitch. It identifies outcomes of proceed, stop or iteration. An optional revision can be required within two weeks; after successful assessment and national funding authorisation, the full proposal window is four to six weeks. ESA says the overall timeline is indicative and can take longer. InCubed application process The InCubed software eligibility review examines the commercial service rather than assuming a company must build a satellite.

The company's first preparation task is to ensure that the outline contains a coherent technical and commercial proposition. If the team cannot explain the customer, product, unresolved development question and expected outcome concisely, more pages are unlikely to resolve the underlying ambiguity.

Choose pitch participants around the questions they can answer. The technical owner should understand the proposed method and dependencies. The commercial owner should understand the market evidence and route to revenue. A finance contribution may be needed to explain costs and co-funding. A founder should not assume one person can improvise every part credibly.

Prepare a record of assumptions before the pitch. Distinguish facts supported by evidence from forecasts and decisions still open. This helps the team answer questions candidly and identify exactly which parts need revision afterwards.

Reserve capacity for the next stage before submitting. If the company is fully committed to customer delivery, a short revision window can become difficult to meet. The application plan should identify who can update the scope, budget and supporting documents when feedback arrives. The ESA OSIP review distinguishes an idea channel from the steps leading to a contract.

National funding authorisation should be tracked separately. An encouraging technical assessment is not the same event as confirmation that the relevant funding can proceed. The internal project record should show the status of each dependency and the owner responsible for resolving it.

The full proposal should incorporate the accepted direction rather than reproduce the outline at greater length. If feedback changes the target customer, work allocation or deliverable, update the entire document set consistently. A revised narrative with an unchanged budget can create contradictions.

Use an internal decision gate before the full proposal. Ask whether the revised work still fits the company's product strategy, available staff and financing position. Progressing in a programme is valuable only if the resulting activity remains deliverable and commercially relevant.

Do not assign a firm project start date to the sales forecast solely from the published process diagram. Review, clarification and contracting can affect timing. Customer commitments and recruitment plans should reflect that uncertainty.

What changes between the outline and the pitch

The outline is an economical way to expose the proposition to review before a small team commits to a complete delivery plan. ESA's published process specifies an outline through ORBIT, with InCubed selected in the relevant fields, followed by a pitch comprising a 15-minute presentation and 45 minutes of questions. The balance of that meeting matters: most of the scheduled time is available for examining the proposition, rather than hearing a longer version of the company introduction.

That structure favours a team able to discuss its assumptions directly. If a customer forecast relies on a distribution partner, somebody should understand the partner's actual role. If an important feature depends on an external dataset, somebody should understand the availability and commercial terms of that input. A polished presentation cannot substitute for those answers because the discussion can move beyond the prepared slides.

A useful way to organise the presentation is around the activity's central uncertainty. An established imagery supplier adapting its product for a new customer workflow has a different starting point from a startup still establishing whether its proposed service can be delivered. The development request should make that difference clear before reviewers encounter the budget. It helps explain why the chosen work is necessary and why the proposed team is appropriate.

An iteration can change the commercial proposition

ESA's process permits an iteration rather than a simple positive or negative decision. For a small business, this creates a short period in which the project may need genuine redesign. A request to narrow the customer segment can change the delivery interface, the size of the demonstration and the evidence required from prospective users. It is therefore more consequential than editing a few paragraphs for clarity.

InCubed's additional application information distinguishes derisking from product development. The distinction offers a useful explanation for some scope changes: a proposed full product-development activity may still contain an unresolved concept or market question. A more bounded initial activity can produce the evidence needed to justify the next investment. Conversely, an established product may warrant development work focused on commercial delivery rather than repeating early feasibility analysis.

Consider a hypothetical coastal-monitoring company whose outline proposes one service for insurers, port operators and public authorities. Those customers may use similar observations but purchase different outputs under different conditions. If feedback leads the company to concentrate on port operators, the revised work should follow that choice. User engagement, reporting intervals, integration and the commercial model all become more specific. Keeping the original broad market forecast while narrowing the technical work would leave the proposal internally inconsistent.

This is also why an iteration deserves an internal commercial decision. A narrower activity can be more deliverable and more useful, but it may no longer match the founder's immediate expansion plan. The relevant question is whether the revised project creates an asset the company wants to own and operate, not simply whether a revised document can be submitted on time.

Four to six weeks is a production window for a detailed agreement

The published full-proposal window follows successful assessment and national authorisation. By then, the company needs to turn an accepted direction into a coherent account of delivery. Technical scope, participating organisations, costs and the commercial case must describe the same activity. The practical burden is substantial because those elements often sit with different people or organisations.

Partner contributions are a common source of delay. A data supplier may need to define what access it will provide; an integration partner may need to estimate engineering work; a prospective user may need to confirm what involvement is realistic. Those inputs affect each other. A change in the available evaluation environment, for example, can alter both the work plan and the development evidence the company expects to obtain.

The small-team advantage is that decision-makers can resolve those trade-offs quickly. The corresponding weakness is that proposal production competes directly with customer delivery. Reserving named staff time for technical design and cost consolidation is therefore a commercial capacity decision. It prevents the full proposal from becoming an unfunded emergency project carried out around existing commitments.

The stages make most sense when each produces a more specific shared understanding: an assessable concept at outline, a tested set of assumptions at pitch and an internally consistent delivery proposition in the full proposal. That progression explains why the elapsed process cannot sensibly be reduced to a countdown from first contact to revenue.

The procedural windows are useful for planning, but they are not a guarantee of selection or contract signature. A well-managed application keeps the technical case, commercial case and financing dependencies aligned at each stage. That reduces rushed revisions and gives the company a clear basis for deciding how much additional effort to invest.