Define your B2B MVP around one complete customer task

Before deciding which features belong in your MVP, ask what you’re trying to learn.

Perhaps you know customers struggle with coordinating maintenance work, but you’re uncertain whether a shared digital handoff would improve the process.

Your first test might need to answer:

Can a maintenance coordinator prepare and share a work assignment that an external contractor can act on without repeated clarification?

That’s more useful than asking whether customers like a proposed maintenance platform.

It identifies a specific customer, task and uncertainty. It also gives the team a basis for deciding what the first version must support.

An MVP should help resolve a question that could change what you build next. If the problem itself is still uncertain, customer interviews or a simpler experiment may be more appropriate than building software.

Start with the customer’s work, not your planned features.

Follow one important task from the event that triggers it to the outcome the customer needs.

For each step, investigate:

• Starting point: What triggers the task, and who initiates it?
• Inputs: What information, permissions or resources are necessary?
• Actions: What must the customer actually do?
• Handoffs: Which other people or systems need to participate?
• Completion: How does the customer know the task is finished successfully?
• Exceptions: What can go wrong, and what must happen when it does?

The important distinction is between a small collection of capabilities and a complete experience.

A tool that creates maintenance assignments but cannot make them available to the contractor may demonstrate a feature. It might not support a meaningful test of the intended workflow.

Your first version doesn’t need to handle every customer situation. It does need enough of the selected situation to test the assumption you care about.

A practical way to define MVP scope is to put each proposed capability or requirement into one of four categories.

Scope category · The question to ask · Example

• Essential to the customer task: The question to ask: Would the customer be unable to complete the selected workflow without this?; Example: Create a maintenance assignment, provide required instructions and confirm receipt.
• Necessary to run a credible pilot: The question to ask: What is required for safe, reliable and understandable use?; Example: Appropriate access controls, essential error handling and support arrangements.
• Can be tested separately: The question to ask: Could we investigate this assumption without building it into the MVP?; Example: Whether customers need advanced reporting or automated scheduling recommendations.
• Can wait until later: The question to ask: Would this improve convenience or coverage without changing the main learning objective?; Example: Additional dashboards, customization and support for unrelated workflows.

These categories are not permanent feature priorities. They depend on what the current test needs to establish.

Manual work can sometimes support an early pilot. For example, the team might prepare an import manually instead of building a full integration.

But if automatic integration is the uncertainty being tested, replacing it with manual work would invalidate that particular test.

Security, privacy and other necessary safeguards cannot simply be postponed because the product is called an MVP. The pilot still needs to meet the requirements of its actual use.

Virtual Customer lets you investigate a proposed workflow with virtual customers representing specific roles, industries, geographic markets and company sizes.

Start with the person responsible for completing the task. Explore what information they need, what they consider essential and what would prevent them from using a simplified approach.

Then investigate relevant connected roles.

For a maintenance workflow, the coordinator might focus on preparing work assignments. A contractor might need clear instructions and access to supporting information. An IT stakeholder might raise questions about access, integration and data handling.

Keep the underlying company and market context consistent when comparing these perspectives.

Useful questions include:

• "What would you need to complete this task from beginning to end?"
• "Which parts could be handled manually during an initial pilot?"
• "What missing information would make the result unusable?"
• "Which requirements become important only when the solution is deployed more widely?"

Compare the simulated perspectives and use them to challenge your initial scope. These conversations can suggest dependencies and missing questions, but they cannot establish which requirements actual customers will accept.

Illustrative scenario, not an actual customer case or research result.

Imagine a software team developing a digital service for coordinating maintenance work between manufacturers and external contractors.

The team wants to explore whether a more structured handoff could reduce avoidable clarification and preparation work. Its initial product concept includes scheduling, document management, notifications, reporting, ERP integration and contractor performance analytics.

Instead of building a limited version of every module, the team focuses on one workflow:

A maintenance coordinator prepares a work assignment, shares the necessary information with a contractor and receives confirmation that the assignment can be acted on.

For an initial pilot at one industrial site, the proposed scope might look like this:

Include in the first test · Investigate separately or later

• Create one type of work assignment: Support every maintenance category
• Include required equipment and task information: Advanced document management
• Make the assignment accessible to the selected contractor: Full enterprise system integration
• Capture acknowledgment or requests for clarification: Automated scheduling and optimization
• Provide necessary access, reliability and support controls: Multi-site reporting and analytics

The team can use Virtual Customer to explore whether the proposed workflow is coherent from the coordinator’s and contractor’s perspectives.

It can then take the provisional scope into real customer research.

Perhaps the contractor needs information the coordinator doesn’t normally have. Perhaps confirmation alone is insufficient because another role must approve the work. Either finding could change what belongs in the first test.

The goal is not to protect the smallest possible scope. It’s to identify the smallest scope that can produce meaningful learning.

A pilot needs more than a working demonstration. It needs an agreed way to evaluate what happened.

Before building, define what you will observe and what could change your decision.

For the maintenance example, the team could investigate whether actual coordinators and contractors can complete the handoff, what information is missing, where they need help and whether the experience addresses a meaningful difficulty in their current process.

Distinguish three outcomes:

Continue: Real use provides credible evidence that the proposed workflow addresses the target problem.

Revise: Customers can complete the task, but important dependencies, workarounds or limitations require changes.

Reconsider: The problem proves less important than assumed, the workflow does not deliver useful value, or the proposed approach is inappropriate.

These are decision categories, not an automated score. The specific success criteria should be agreed before the pilot, and important findings should be verified with actual customer behavior and feedback.

Does an MVP have to be fully automated?

No. A controlled manual or assisted step can be appropriate when it helps test the intended customer outcome. Be transparent about what is manual, and don’t use an assisted pilot as proof that full automation works.

What if an enterprise customer requires integrations or extensive controls?

Separate what is required for the specific pilot from what is required for broader deployment. Some controls may be mandatory from the start. If an integration is essential to the customer’s task, it may need to be included or tested through another method.

Can Virtual Customer decide which features belong in the MVP?

No. Virtual Customer provides simulated perspectives that help your team explore requirements, dependencies and assumptions. The scope decision remains with your team and must be informed by real customer research and practical constraints.