for: corporate teams exploring a venture or startup partnership
allow: 60-90 minutes with the operational owner
leave with: a focused challenge brief with a baseline, access map and first decision
bring: recent workflow examples, available measures and the people who own the problem.
all examples and figures are fictional. this is a preparation tool, not an agreed engagement, procurement approval or legal document.
describe the actual problem
start with a recurring situation and its consequences before selecting a technology or commissioning a solution.
follow one recent occurrence
name the people involved, the trigger and the sequence of actions. ask what happened the last time, what workarounds were used and where the delay or failure arose. 'we need an ai platform' specifies a solution before establishing a problem. a useful brief lets another person understand the workflow without relying on internal shorthand.
worked example · illustrative
a fictional manufacturer notices that technicians repeatedly wait for a particular replacement part. the brief follows the last stoppage from fault report to repair, identifying stock checks, approval delays and the person authorised to order.
check: can you explain the situation without naming a preferred product or technology?
establish a baseline you can defend
define the measure, unit, period and source. separate an observed cost from an estimate and avoid adding overlapping losses. distinguish elapsed delay from actual staff time or lost output. when evidence is incomplete, record the gap and plan a short measurement exercise before projecting the value of a solution.
worked example · illustrative
the team records six relevant stoppages and 18 total hours of elapsed downtime over four weeks. it does not multiply those hours by every person's salary and also claim the full lost production value as if the costs were independent.
check: would finance and the operational owner calculate the baseline in the same way?
connect business value and wider impact
explain who benefits if the problem improves and how you would observe that change. cost, reliability, access, waste and working conditions may all matter, but need separate evidence. consider who could be disadvantaged by the proposed change. a credible partnership can state a worthwhile ambition without claiming outcomes before they are measured.
worked example · illustrative
fewer stoppages could improve delivery reliability. reduced emergency purchasing might also reduce waste, but this needs a separate measure. the team checks whether a new workflow would increase pressure on technicians or introduce unsafe shortcuts.
check: name one desired outcome and one unintended consequence to monitor.
make access and ownership real
a good problem becomes testable only when the right people can provide time, permission and a place to learn.
separate sponsor, user and decision maker
identify who champions the work, who experiences the problem, who controls the budget and who approves a live test. name an operational owner who can resolve day-to-day questions. ask how a successful test would enter normal procurement. enthusiasm from an innovation team is valuable, but may not carry the authority to change a production workflow.
worked example · illustrative
the innovation lead sponsors the conversation, technicians use the process, the plant manager owns downtime and procurement approves a supplier. the plant manager agrees to own the first decision, while each permission remains explicit.
check: who can authorise a test, and who could authorise continued adoption?
distinguish possible access from agreed access
list the people, facilities, systems and records a test needs. record who can permit access and what conditions apply. choose the minimum useful information and a suitable private channel for it. do not share customer, employee or commercially sensitive records simply because a potential partner asks to see a realistic example.
worked example · illustrative
a partner could interview two maintenance supervisors, subject to scheduling and permission. production-system access is not agreed. the initial discussion uses a de-identified workflow description while the relevant data and security owners consider a bounded test.
check: which access is confirmed, which is proposed and who owns each outstanding permission?
count the internal work
a pilot needs staff time as well as an external budget. identify the people needed for interviews, integration, training, measurement and review. establish whether they can actually participate during the proposed period. a project with funded software but no available operator may be unable to answer the question it was created to test.
worked example · illustrative
the manufacturer can fund an initial study, but its only systems specialist is committed to an upgrade. the team narrows the first step to workflow observation and baseline measurement rather than promising a live integration next month.
check: is the first milestone feasible with the people and time actually available?
choose the work the problem needs
a partnership, a purchase and a new venture solve different problems. keep the route open until the evidence supports it.
compare credible alternatives
consider changing an internal process, buying an existing product, working with a startup or exploring a new venture. compare what each could resolve and what it requires. building something new carries ongoing operating responsibilities. a solution that already works may be a better answer when the problem is local and established products can address it.
worked example · illustrative
the maintenance team first checks whether stock settings and supplier lead times explain the shortages. if a process change resolves the problem, a new software venture may add cost without creating enough additional value.
check: what is the simplest credible alternative, including doing nothing for now?
test whether the need extends beyond you
a corporate pain point can reveal a wider market, but one organisation's unusual process may not represent other buyers. ask whether others experience the same need, who would pay and what would need adapting. separate a useful internal project from a repeatable business, and separate local repeatability from evidence of international demand.
worked example · illustrative
other manufacturers also wait for parts, but one uses central purchasing and another outsources maintenance. the reusable opportunity may be narrower than the original brief. conversations with independent buyers test that possibility without assuming a global market.
check: which part of the solution would remain useful outside your own organisation?
define each partner's contribution
write what the corporate and prospective venture team could contribute: insight, customer access, technical work, time, budget or distribution. distinguish proposed contributions from confirmed commitments. identify dependencies on third parties. agree the scope of the next step before discussing broad ambitions or implying that a partnership includes an investment.
worked example · illustrative
the manufacturer proposes two supervisor interviews and a baseline dataset; a venture team proposes a workflow assessment. neither has promised a product build, customer introductions beyond the plant or investment capital.
check: does every proposed contribution have an owner, boundary and confirmation status?
write a decision-ready brief
the first brief should make it possible to choose a useful next step without creating an accidental open-ended project.
choose a bounded learning milestone
identify the uncertainty that changes the decision, then choose the smallest useful way to investigate it. specify the scope, time and cost limit. name the evidence that would justify further work, a change of approach or a stop. an inconclusive result should remain available if the test does not produce enough usable evidence.
worked example · illustrative
before building, the team maps ten recent part-related stoppages and interviews the relevant supervisors. the decision is whether the bottleneck lies in prediction, approval or supply. the output is a prioritised problem, not a product launch.
check: what decision will be possible at the end that cannot be made confidently today?
surface terms before delivery
list the agreements needed for the chosen next step, including scope, payment, access, responsibilities and treatment of existing and newly created intellectual property. involve the appropriate procurement, legal, data and security owners. the worksheet records issues to resolve; it does not grant rights, authorise access or replace agreed terms.
worked example · illustrative
the team flags that an existing scheduling method belongs to a third-party supplier. it asks the relevant owners to clarify what can be used before a partner begins development. the brief does not assume ownership simply because the method is used internally.
check: which unresolved permission or term could prevent the next step from starting?
prepare a shareable introduction
summarise the problem, baseline, operational owner, access and proposed first decision. keep sensitive supporting records private until the sharing process is agreed. say what is observed and what remains a hypothesis. lab2sky can then discuss whether the challenge fits its shared interests and what work might be useful; scope and availability are agreed individually.
worked example · illustrative
the introduction describes recurring part-related downtime and a proposed diagnostic exercise. it names the sponsoring role and confirmed interview access, while keeping supplier pricing and personnel details out of the initial message.
check: can someone unfamiliar with your organisation understand the challenge and respond to a specific next step?
your working pages
use the fillable pdf or copy these prompts into your own private notes. no answers are collected on this page.
your challenge and access map
write in plain language. use roles and private source references where personal or commercial details are unnecessary.
- problem and recent occurrence: who experienced it, what happened, what workaround was used and what was the consequence?
- baseline and intended outcome: measure, unit, period, source, uncertainty and one potential unintended consequence.
- sponsor, owner, users and buyer: who champions, operates, approves the test and decides whether adoption continues?
- access and capacity: people, data, site, systems and staff time; distinguish confirmed from proposed access.
your first partnership brief
use this page to prepare the first conversation, then refine it with the people responsible for delivery.
- alternatives and wider demand: process change, purchase, partnership or venture? what evidence suggests other buyers share the need?
- contributions and open terms: what could each party provide? identify permissions, payment, ownership and other unresolved matters.
- first milestone and decision rule: scope, time, budget, evidence, stop or change condition, and what would be inconclusive.
- shareable introduction and next action: summarise the challenge and requested conversation; name the next owner and review date.
further reading
original lab2sky teaching material and fictional examples. external reading is provided for context; links do not imply endorsement, affiliation or completed diligence. how we write our guides