Early deep-tech choices compound quickly. The first wedge shapes the product boundary; the product boundary shapes the architecture; the architecture shapes which customers, partners and deployment paths remain credible. The Wedge & Product Runway Sprint aligns those decisions before early traction hardens the wrong system.
Bounded engagement · no prior Diagnostic Sprint required.
The risk is not a lack of ideas. It is committing product, architecture and market effort before the company has decided which problem deserves to become the business. This Sprint is for teams that need to turn technical possibility into a credible first product and preserve enough runway for what may come next.
Technical breadth is creating multiple plausible products, use cases or customer stories, but the company needs one coherent wedge to organise the next decisions.
A design partner or early buyer is valuable, but its immediate requirements could pull the company into a customer-specific branch before the reusable core is clear.
Early implementation choices are becoming expensive to reverse, even though the product boundary and future portfolio are still being defined.
The company is telling a broader product or platform story than the current architecture, partner model or deployment path can credibly support.
These are not four independent workstreams. A credible wedge is only useful if the product can be built around it, the architecture preserves the right options and the first customer or partner path can validate the thesis without turning the company into a project business.
Which problem and customer context deserve to organise the company now?
Define the beachhead narrowly enough to focus product and evidence, but not so narrowly that the first deployment becomes the entire business.
What is the reusable product, and what must remain customer-specific?
Separate the repeatable core from implementation, integration or service layers before early customer requests become accidental product strategy.
Which choices must be made now, and which options must remain open?
Align system boundaries, interfaces and platform assumptions with the near-term roadmap without over-engineering for a future the market has not validated.
What must the first serious customer or partner actually validate?
Define the evidence, partner role and deployment path required to test the product thesis rather than simply prove that the technology can work once.
The engagement is designed to reduce ambiguity around the next product decisions. It does not replace product development, detailed engineering or full GTM execution.
The Wedge & Product Runway Sprint is built from transitions Jose Lopez has already lived as a founder, product leader and operator: deciding what should become reusable, shaping new product and platform directions around broad technical capability, and then seeing from the adoption side what happens when those early choices meet demanding customers.
Founded Simware to transform recurring defence and simulation patterns into a modular platform. The architecture was adopted by 50+ customers across Europe, the US and China.
Evidence behind the Sprint: reusable core · platform logic · architecture that can travel across customers
Co-founded TMRW and helped scale it to 150+ employees after €10M+ funding while shaping products and platform concepts across XR, simulation, AI, digital twins and industrial systems.
Evidence behind the Sprint: product thesis · category direction · architectural choices under compound complexity
As VP Customer Success during Threedy's post-Series-A growth phase, worked on repeatable enterprise delivery and adoption across complex industrial deployments for OEM and Tier-1 customers.
Evidence behind the Sprint: customer repeatability · deployment reality · product choices that survive scale
The common pattern: strong technology creates value only when product boundaries, architecture and the path to adoption are designed to reinforce each other.
Clarify the technical capability, constraints, existing evidence, likely alternatives and the customer contexts where the technology changes the economics or operating model enough to matter.
Compare plausible beachheads and decide which problem, customer and value hypothesis should organise the next product and market decisions.
Define the reusable core, customer-specific layer, roadmap logic and architecture choices required for the chosen wedge — including which decisions should deliberately remain open.
Translate the thesis into a first-customer, design-partner or partner path with explicit evidence and decision criteria for what comes next.
For defence, dual-use and other regulated markets, the first credible beachhead is not only a customer segment. Procurement, assurance, evidence, integration responsibility and partner position can determine whether a technically attractive product is deployable at all. In those cases, Trust, Assurance & Deployment Readiness is brought into the Sprint early enough to influence the product and architecture — not added after the first pilot stalls.
What must be demonstrable for an institutional buyer or prime to rely on the product beyond founder confidence and technical potential?
Which assurance, integration, governance or operational conditions shape what the product must be from the beginning?
Where should the venture own capability directly, and where does a prime, integrator or specialist partner strengthen the path to deployment?
If product, architecture, organisation, trust and market symptoms are interacting and the team does not know which one is actually limiting progress, use the Diagnostic Sprint instead.
See the Diagnostic Sprint →If the wedge and product thesis are already established and the need is specifically architecture, decision/delivery structure, trust/deployment readiness or partner/GTM design, start directly with a Focused Domain Sprint.
See Focused Domain Sprints →If the real question is why a successful pilot is not becoming repeatable operational deployment, the Pilot-to-Program Sprint is the more direct engagement.
See Pilot-to-Program →The team has enough clarity to execute the product and validation path internally.
The wedge is clear, but the next decision now requires focused work on architecture, decision/delivery structure, trust/deployment readiness or partner/GTM design.
Focused Domain Sprints →The product direction is clear, but repeated strategic or operating decisions justify ongoing Strategic Advisory or Embedded Scaling Leadership.
See engagement depth →A follow-on is not automatic. The next engagement exists only if a new decision is important enough to justify it.
If the technology is strong but the wedge, product boundary, architecture and first credible market path are still being decided, the Wedge & Product Runway Sprint is designed to make those choices coherent.