Envisioning To Delivery - POC, Prototypes, Pilots and MVP

I took a deep breath before clicking on the “Join now” button of the MS Teams call. We were ready to present our proposal for a discovery project to a potential client.

Before today’s presentation, we had several calls with the client to agree on the deliverables, scope, and timelines of this engagement. The Product Owner had requested that we include a prototype as part of this discovery, and we made sure we agreed up front what that meant.

We took the first few minutes to introduce all parties. Several C-level executives were attending the call including the CEO. The Product Owner stressed that all the decision-making stakeholders were on the call so the “Go / No Go” decision should follow shortly.

The first slides covering the scope went smoothly with only a few questions being asked. Then, when we presented the timeline, we got a question that caught us completely off guard.

“Based on this timeline, I see that you will finish the discovery and the prototype in March. So, when will the users get trained and can start using the Prototype?” asked the CEO.

There was a noticeable pause… “What do you mean?” I asked. “Well, I presume the users need at least a basic training to start using the Prototype” said the CEO.

I could feel my heart starting to beat faster. I had enough experience to understand we were heading into a discussion that would not be smooth sailing.

“uhm…. Sir, we agreed that the prototype will not be accessible to all your users. The prototype will be a sandbox where we will only mimic functionalities to confirm requirements. We can provide access to some of your key users if you wish so, but we haven’t planned for any user training and deployment of the prototype."

The CEO insisted. “I thought we wanted the prototype to be a usable system that a subset of users could use to confirm everything before we expand it to a wider group of users?”

And there it was, clear confirmation the CEO was on a different train altogether.

“Ok, I think that there is a misunderstanding in what we all mean with prototype. What you are describing, we call it a Pilot.” I said.

A few exchanges between the Product Owner and the CEO confirmed the Product Owner and the CEO had a completely different understanding of what Prototype meant and were thus having very different expectations of what we were presenting.

The Product Owner then asked us to stop the presentation and apologized for the misunderstanding. We all agreed to have another call to define and revise the scope of the discovery if needed.

Let’s get specific

If, like in my experience above, you use the terms Proof of Concept, Prototype, Pilot or Minimum Viable Product (MVP) interchangeably then this article is for you. 

There is a (sometimes subtle) difference between those terms, they all have their place and use and it is very important for the success of any engagement that everyone you work with is on the same page. 

It is key to project success to apply a strategy for identifying and mitigating risks in the project lifecycle. Enterprise projects can be especially complex; Whether that complexity is driven by the scope and scale of applications being integrated, or the number of unique tasks, forms, scripts, rules and processes needed to support diverse departments. 

Each of the deliverables in the sequence below, along with the processes that assist in creating them (e.g. - Envisioning), should be thought of and focused as tools to navigate and discover the unknowns in the project and more fully inform (through iteration) final construction of the system. Appropriate fitting and execution on these deliverables will substantially decrease risk of system fit, security, scalability, and governance.

Let us look at the definition and fitting of these terms one by one below.

Proof of concept (POC)

A Proof of concept is an experiment of a specific approach or design to validate the feasibility of a requirement or idea. 
POC (proof of concept) is typically short in duration and is used to validate feasibility of an idea. A POC is generally "throw away" in that it does not result in production ready code. – Joel Lindstrom
Trial of specific approaches or methods in technology, such as integrations or plugin behaviors, that eliminates the risk of dependencies on functions that are otherwise not explicit out of the box features. – Ron Giblin
  • Validate that the Universal Resource Scheduling can be used to book course delivery to teachers based on the teacher’s availability, accreditations, skills, and location. 
  • Validate that an integration between Dynamics 365 and a legacy application can be done, including rollbacks, retries, timeouts and errors handling.
  • A company is interested in a new technology such as Power Virtual agents, so they quickly build out a functional chatbot around one of their business processes. 


A prototype is a sandbox environment where we mimic functionalities to help gather and validate requirements from a User Interface or business process perspective.
A prototype is an early but not final representation of the User Interface, with elements in place needed to perform a system transaction or part of a process. – Ron Giblin
Prototypes validate how a problem will be solved. It is bigger than a POC but is not deployed in production. – Joel Lindstrom.
  • Forms and Business Process Flow layout to validate technician activities to service a job, including the sequence of data inputs and a checklist of tasks to be performed.
  • After the POC, Acme corporation prototyped chatbot to a small group of users to get feedback.
  • A Power Apps Portals with sample forms, lists and pages to consolidate Portals requirements.


Pilots are small initial deployments of a solution - while they may not be the full and final solution, they should be feature complete for the functionality included and will be used in production in a limited rollout. Lessons learned from a pilot are incorporated to f.e. make a full enterprise rollout smoother. – Joel Lindstrom 

A pilot is a production environment of Dynamics 365 or the Power Platform used in real-world conditions by a small group of users or area of an organization. The purpose of the pilot is to allow the organization to determine if the current configuration is the appropriate solution and gives personnel and users hands-on experience. This reduces the risk of an unsuccessful wider launch and adoption later. – Ron Giblin
  • A Field Service solution deployed in production and used by 30 users in a specific region. Following this initial pilot, the system will be fine-tuned before a deployment to additional regions.
  • A Sales solution deployed in production and used by 5 key users for a period of time, before being rolled out to the remaining sales users.
  • After the Prototype, a pilot of the chatbot was deployed for helpdesk users in the South office. 

Minimum Viable Product

A minimum viable product is a version of the solution that delivers key customer identified features that are aligned and sequenced for delivery according to the roadmap of features identified in Envisioning. – Ron Giblin

MVP is the Minimum viable product - all deployments should have MVP, including prototypes and Pilots so that we avoid scope creep and ensure that the end result is usable. - Joel Lindstrom 

  • For a Customer Service solution, the MVP is the case creation and update including a simplified Business Process Flow for the case lifecycle. Future releases include an improved Business Process Flow, Case relationships, SLA and knowledge management.   
  • The MVP for the chatbot pilot included the ability to reset passwords and open a helpdesk ticket for desktop issues. Future releases include additional ability like requesting automatic software install on users machines.
To me, MVP refers to the scope of the solution, whereas pilot refers to the scope of the deployment. – Simon Douglas

Summary Table

The below diagram and table illustrate how POC, Prototype, Pilot and MVP relate to each other and what is the usual sequence of delivery. However, each of those are optional and you can pick and choose the ones to use during your Dynamics 365 and Power Platform project delivery. 

Ultimately, following the below sequence is the optimal approach to reduce risks of unknowns through your project delivery.

A word about project risk and ALM management 
While this short article addresses deliverable taxonomy, terminology and definitions to assist sales and project teams in setting expectations and communication, it should be noted that covering all aspects of project risk in detail, is a project discipline on its own. 

A full risk management plan will have accompanying risk registers, categories, processes, budget, WBS, roles and responsibilities, and reporting structures. Each project possesses unique risk that need identification and the creation of mitigation plans that sometimes become the basis of on-going ALM and Operations management; As an example there are sometime non - technical risks, such as geo-political elements or events that emerge that can effect supply chains and may require data residency changes for compliance.
In ERP implementations risks and their total elimination are almost impossible. You design and work around your risks and your project charter should have a solid plan to deal with them OR you have already failed. The primary objective of risk management is to minimize impacts of the project unknowns rather than eliminate them completely. This way when you advance through your project stages and your project unknowns are converted to knowns their negative impact on project delivery drop. Your risks still may or may not be there! - Reza Alirezaei


Proof of concept





Validate feasibility of an idea

Gather and validate Requirements

Validate solution at low risk by reducing number of users

Functioning solution with enough valuable features to be usable by users

Project Unknowns and delivery risk





Requires training and UAT





Accessible by users in PROD





Authors and contributors