How do we define everything a new venture has to deliver, and decide how to deliver it?

When an innovation concept starts turning into a potential new business venture, the team usually knows what it wants to build. The product is likely the part it has thought about most, and often the part the concept started from. What gets less attention is everything else a customer needs before that product is worth buying, and how each piece of it will actually be delivered.

In the core business, that gap rarely shows. Most of what surrounds the product already exists: the sales channels, the service organization, the integration partners, and the complementary products customers use with it. The product can stand in for the solution because the rest is already in place. A new venture may not have any of that. Teams often end up defining only the core product they deliver, and the pieces around it get assumed rather than designed.

Delivery goes the same way. Earlier in this series we described how a new venture inherits strategy choices from the core business, including being built in house. How each part of the solution gets delivered is usually decided by default too, using the capabilities and partners the company already has.

Both are strategy choices, and they shape the venture’s prospects more than most teams realize.

The product is not the whole solution

A whole solution is everything a customer needs to get the job done, across the whole journey: finding and evaluating the offering, buying it, setting it up, using it, getting help when something goes wrong, and eventually replacing it. The product the company makes is the core of it. Around it sits the extended product: onboarding, integration with what the customer already uses, service and support, the channel that sells and delivers it, and complementary products and services.

Much of the extended product comes from other parties in the venture’s value network: channel partners, integrators, service providers and makers of complementary products. That makes it easy to leave off the plan, because nobody on the team is building it. It is also where many ventures stall. The core product works, and customers still cannot adopt it, because part of the whole solution was assumed to exist and did not.

Start from the requirements, across the whole journey

A few posts ago we covered how to identify which requirements customers consider important and poorly served. Those requirements are the right starting point for defining the solution. For each element of the whole solution, the useful questions are which requirements it serves, how much it affects them, and what level of performance it has to reach for the offering to win.

Working that way does two things. It makes the extended product visible, because customer requirements run across the whole journey rather than stopping at the product’s features. And it scopes a first version: the elements that drive the requirements customers care most about have to be in it, and much of the rest can wait. Our Solution Definition launch post covers the two ways definitions go wrong, stopping at the core product or trying to win on every requirement.

Feasibility is a set of choices, not a yes or no

Once the elements are defined, each has to be delivered somehow. Technical teams are good at answering “can we build it?” Often the answer is yes, and that answer gets taken as the feasibility case. But feasibility in a new venture is not only whether the core product works. It is how every element of the whole solution will be delivered, and what each of those choices puts at risk.

The main paths trade off differently. Building in house is usually slower but gives the company control and exclusivity. Licensing is fast but constrains margin. Partnering is fast but leaves the element dependent on someone else’s priorities. Acquiring can be fast and exclusive, but it is expensive and hard to integrate. None of these is right or wrong. They are strategic choices with real trade-offs. What matters is how well the path fits the element and the risk tolerance and resource constraints the strategy has to operate within.

That fit depends mostly on how much the element matters. A commodity element built in house absorbs resources the differentiating elements need. A differentiating element held by a partner is a strategic dependency: supplier relationships change, exclusive access can be lost, and a complementor today can become a competitor tomorrow. Our Implementation Planning launch post and our definition of build vs. buy vs. partner go further into these choices.

Why the usual tools leave gaps

Most teams already have tools that touch this work. Each covers part of it.

Engineering and product development tools, such as requirements management and product lifecycle management systems, are built to specify what the company will make. They work at the level of detail development needs, and they seldom represent the parts of the solution that channel partners, integrators or suppliers will provide.

Project management tools plan the tasks and the timeline once a delivery approach has been chosen. They are not built to help choose it, or to weigh the risk each choice carries.

That leaves a fragmented patchwork of PowerPoint templates and Excel models: a build-or-buy matrix in one file, a partner slide in another, rebuilt for each project and disconnected from the customer requirements, the financial model and the assumptions the team is trying to test.

What is missing is a single model that ties each element of the whole solution to the requirements it serves, and each delivery choice to the risk it carries, in the same place the financials, the assumptions, and the investment decision framing draw from.

There’s an app for that: how Growth Forge® Software addresses this

Growth Forge provides that model in two tools, with the first feeding the second.

Solution Definition is where the whole solution is defined. Elements are captured as a tree and typed as physical, operational, intellectual property, subsystem or capital. Each element is linked to the requirements it serves and rated for its impact on each, and the tool combines those ratings with each requirement’s opportunity to score how critical the element is. Target performance is set for each requirement. Analysis by customer journey phase, value creation and differentiation shows where the solution is thin and which elements carry the offering. AI Discovery Assistants can propose solution elements from the requirements, needs and strategy already in the project, for the team to review. The production and sales models are defined here too, and they are shared with Market Opportunity Sizing, so the revenue forecast starts from the solution rather than from a separate guess.

Implementation Planning takes those elements and records how each will be delivered: build, buy, partner and more. Its central analysis rates the execution risk of each choice against that element’s impact on how well the solution performs, so the choices that could do the most damage stand out before resources are committed. Around that frame, it shows whether internal effort is going to the elements that differentiate the offering while commodity elements are sourced, where a partner or supplier holds something central to the venture’s advantage, and how the chosen approaches are expected to perform against the targets set in Solution Definition. The highest-risk choices move into the Assumptions Manager as prioritized assumptions to test, and the risk picture feeds Strategy Evaluation.

Implementation Planning is deliberately not a detailed project plan. It works at the level of detail the current stage needs, and gives a detailed execution plan a structured starting point later.

The output is a whole solution defined from what customers need, with each delivery choice made explicitly and its risk visible, instead of a product description and an unstated assumption that the rest will be handled.

What no software can settle

A plan that builds some elements and sources others depends on functions the venture team does not typically control. Procurement, legal, engineering, manufacturing and corporate development each have processes and priorities set up for the core business. Procurement may be organized around cost and consolidating suppliers, legal around protecting the core’s intellectual property, engineering around building things itself, and corporate development around deals of a size the core business notices. None of that is wrong for the core. For a venture whose plan depends on a partnership, a license or a small acquisition, it creates friction on exactly the parts of the plan that are not built in house.

That friction is a company fit problem: the venture’s needs are out of line with the resources, processes and priorities of the organization that is supposed to support it. A later post in this series covers how to assess it. Resolving it is a leadership job: aligning those functions’ processes and incentives with what the venture needs, and deciding who has the authority to approve a delivery path the core business would not choose for itself. An outside perspective can help map where those functions’ processes conflict with the venture’s plan, and can raise it more freely, but the alignment has to be led from inside.

Putting it into practice

Before a new venture’s plan goes to review, a few steps make the whole solution and its delivery explicit. List the elements customers need across the whole journey, not only the product, and tie each to the requirements it serves. For each element, record how it will be delivered and what risk that choice carries relative to its impact. Flag the elements that depend on a partner, a supplier or a function outside the venture team’s control. These steps can be worked through with a framework, facilitated by an experienced consulting firm, or with purpose-built software such as Growth Forge, where Solution Definition and Implementation Planning provide the guidance and the analysis. Whether the team can build the product still matters. It is one part of feasibility, not all of it.

If the harder question is whether your organization can support a venture that builds some of what it needs and sources the rest, our Innovation Capability Assessment is a short scored read on where that stands.

These choices also set up the next step. What gets produced and how it is sold determine the revenue each sale brings in and how revenue arrives over time. Which elements are built, bought, licensed or supplied by partners determine what each unit costs and how much has to be spent before the first sale. Those are the inputs a business case needs, and one built before these choices are made describes a product, not the business around it.

Next in this series: building a business case for a business with no history yet.

BRI Associates helps companies grow by drawing on decades of practitioner experience in corporate innovation and new business development — practitioners, not pundits or academics — through direct consulting, training workshops, and Growth Forge® Software, built for the unique requirements of corporate innovation and growth organizations.