A company may begin a business model project with a straightforward goal: increase revenue.
In most cases, achieving that goal requires generating more qualified leads. The company must reach enough prospective customers with a relevant problem, the means to buy, and a reason to act. Improving sales conversion matters too, but a stronger sales process cannot compensate indefinitely for too few suitable opportunities.
The question soon becomes broader than “How do we get more leads?” The answer may involve the customers the company targets, the problems it addresses, its value proposition, market visibility, sales channels or partner capacity. The company must also consider what it costs to acquire and serve additional customers. Growth that weakens profitability may do little to improve the value of the business.
The team cannot know all the changes it will recommend, which assumptions will survive testing or what implementation will require. But without agreed limits, it can consume considerable time and resources exploring options that management is unwilling to approve. The project needs clear responsibilities, initial resource commitments and a route for decisions beyond the project owner’s authority. It also needs room to learn.
In my forthcoming book, Building Successful Business Models, I use the Business Model Framework to help B2B software companies examine their existing business and identify improvements. I have also developed a separate project management tool: the Business Model Redesign Project Canvas. The project canvas records these starting conditions and supports their revision as the team learns.
Why the initial plan will change
The Business Model Framework helps a team examine how a company creates value for customers, delivers it and earns revenue. It also makes the relationships between choices visible. A decision about which customers to pursue, for instance, affects the message used to attract them, the channels needed to reach them, the sales effort required and the cost of serving them.
The team must also analyse the business model environment. Changes in markets, competition, technology, regulation and the wider economy can either create demand or make the company’s current approach less effective. A new reporting requirement might give many prospective customers an urgent reason to replace their software. A competitor’s new offering might instead weaken the company’s position, while economic pressure could delay customers’ investment decisions. These developments affect where qualified leads may come from, how quickly customers might act and what the company must offer to win them.
Suppose a software company sets out to double its flow of qualified leads. Management initially believes that more advertising will solve the problem. The investigation may reveal that an upcoming regulatory change creates a stronger opportunity in a particular customer segment than the company had recognised. It may also reveal that partners serving that segment lack capacity, or that the company’s product needs adapting before it can make a credible promise. The most useful next step might be customer research or a limited partner trial, rather than a larger advertising campaign.
Each finding changes the work ahead. The team may need to compare segments, interview customers, examine lost opportunities or test a new message. A successful lead generation test could create a need for additional sales and implementation capacity. An adverse change in the environment could require the team to revise its assumptions, redirect its efforts or reconsider the project’s objective.
The project’s activities, resources, timetable and risks therefore evolve with the analysis. In some cases, the evidence may show that the objective cannot be achieved within the agreed scope. Project management must respond without losing control of spending, responsibilities or decisions.
The Project Management Institute describes rolling wave planning as planning near-term work in detail and refining later work as more information becomes available. A business model project needs a practical way to apply that principle to commercial decisions.
Two kinds of information, two different jobs
The business analysis should record what the team is learning. It contains the current and proposed business models, evidence about the company’s environment, alternatives considered, assumptions, research questions, test designs and findings. If the team believes a regulatory change will increase qualified lead flow, the analysis explains why, how that belief will be tested and what evidence would challenge it.
Project management has a different job. It must establish what the team is allowed to examine, which work can proceed, who will do it, what capacity is available and who decides whether to invest further. If the team proposes customer interviews or a campaign, the project canvas should show the resources required, the approval status, any effect on the timetable and the decision that will follow.
Putting every research finding into the project canvas would make it hard to use. Leaving requests for money and staff time buried in analytical notes would be just as troublesome. The division is simple: manage the framework of the project in the project canvas; manage the substance of the investigation in the business model analysis. Links between them let decision-makers trace a proposed commitment back to the evidence behind it.
Establish the project canvas before the workshops
Agree on the project’s purpose, boundaries, responsibilities and initial resource commitments during preparation. Mark provisional entries and unresolved questions. Also agree on the conditions for closing the project and the handover and follow-up it will require. The workshops then have a clear starting point.
The project canvas has six sections:
1. Purpose
Ambition describes the broader change or improvement the project supports. Objective defines the measurable contribution this project must achieve, from what starting point and by when. Scope states what the project may examine or change, what is excluded and which restrictions apply.
Several projects may support the same ambition. Each has one objective, although achieving it may require several business model changes. Separate objectives require separate projects.
For example, the company’s ambition may be to double revenue in five years. One project could contribute by doubling qualified lead flow in the domestic market within twelve months, without major product changes. Agree on what counts as a qualified lead and establish how many the company currently generates over a defined period.
That starting point is the baseline. Without it, the team cannot judge the size of the improvement required or whether it has been achieved. If it is unknown, make measuring it an early task, with an owner and a deadline. Use the result to confirm or adjust the target before approving changes intended to achieve it.
More leads will only produce more revenue if conversion, revenue per customer and the capacity to serve additional customers support that result. Note these dependencies in the business model analysis. Another project could support the same ambition by entering a specified foreign market, with its own measurable objective and boundaries.
Make restrictions explicit before work begins. Define “no major product changes” clearly enough to guide the team. If the analysis shows that the current offering prevents the project from reaching its objective, report that dependency even though product changes are excluded. The project owner must then decide whether to widen the scope, revise the objective or stop.
2. Stakeholders and Commitments
Identify whose input, approval or adoption is essential, what commitments are needed and who will secure them. Keep this separate from the project team: customers, partners and operational colleagues may be essential without carrying out the project work. Attending a workshop does not establish a commitment to provide resources or adopt a change.
3. Team and Responsibilities
State who leads and carries out the project, who can approve decisions and where matters beyond their authority must go. Identify who owns implementation and who is responsible for the business outcomes. Keep individual research and testing assignments in the linked plans.
4. Budget and Capacity
Record the funding, staff time and capabilities required. Distinguish what is committed from what remains unsecured, and assign responsibility for securing outstanding resources. Include capacity for research, testing, implementation and follow-up alongside participants’ normal work.
5. Risks and Dependencies
Record what could prevent progress or the intended business improvement, the action required and who owns it. A partner trial may depend on product readiness or a partner’s capacity to participate. Keep the detailed environment analysis elsewhere and show its practical consequences for the project here.
6. Milestones and Decisions
For each milestone, state what must be achieved or decided, by when, what evidence or deliverable is required and who approves the next step. State what makes the deliverable ready to use. Before approving further work, check that the necessary resources and stakeholder commitments are secured.
A milestone could read: “Evaluate the pilot by 30 June. Review the evidence against the agreed criteria. The project owner decides whether to implement the change, revise it or stop.”
Plan milestones across five phases: Preparation; Workshops; Testing and Review; Implementation; and Handover and Follow-up. Findings may require a return to earlier work. By the end of the five workshop days, the team should have a documented, revised business model and an agreed test plan for project management to review. Keep detailed test assignments, measures and assessment criteria in that plan; put the review milestone on the project canvas.
Keep recommendations and commitments distinct
Workshop participants may recommend a partner-led lead generation trial. Their agreement does not commit the company to fund it. Project management reviews the recommendation, approves work within its authority or refers the decision to the appropriate decision-maker. Approval to test does not automatically authorise a full programme.
At each major decision point, update the project canvas to show which proposed activities and resource requests are awaiting a decision, approved, revised or rejected. Record the decision, its reasons and its effects on activities, timing, dependencies and resources. Obtain the appropriate approval for changes to the objective, scope, budget or timetable. If findings call the broader ambition into question, refer them to the company decision-makers responsible for it.
Use one shared online version as the current reference, with the project owner responsible for keeping it current and accessible. Retain dated versions so significant changes and their approvals remain traceable. Keep the project canvas brief and link it to the business model analysis, test plan, evidence, detailed budgets and decision records.
Control without pretending to know the answer
The team needs enough clarity and capacity to begin. Later commitments can follow the evidence.
A small test may attract many enquiries but few qualified leads. The team can revise its targeting before spending more. Another test may produce promising leads but reveal that the company cannot follow them up promptly. That finding affects both the proposed business model and the resources needed to pursue it.
Completing activities is not the same as achieving the objective. Launching a campaign does not prove that lead flow has doubled, and more leads do not by themselves establish that revenue or profitability has improved.
Before closing the project, confirm that the agreed closure conditions have been met, who accepts responsibility for the implemented changes and who will continue measuring their business effects. If results will emerge after closure, assign an owner and secure capacity for follow-up. Record separate handover and outcome-review milestones.
The Business Model Framework helps the team examine how changes within the company and its environment could support profitable growth. The project canvas keeps the purpose, responsibilities, commitments and decisions clear as that work develops. It gives the project room to learn while keeping management in control of what happens next.
