Getting your minimum viable product (MVP) right is one of the critical things when bringing a product to market as an ISV building on the Microsoft Power Platform. This post is based on what I have learned so far from in my own experience, speaking with various ISVs and from the reading I have done in this area.

Before getting into IT, I worked for a company in New Zealand that was a supplier to the medical industry. The owner of the business was a mechanical engineer. We imported and supplied technology from overseas to hospitals and laboratories. The engineer decided that we were going to manufacture our own laminar airflow cabinets and sell them in the local market. He would complete a design for a cabinet, which we would then build and sell. Then he would redesign all over again, and we would build and sell another one. The more we did this, the more our costs increased, and it became impossible to recover those costs.

Our competitors had built a product and manufactured many cabinets, which enabled them to sell the same product repeatedly without engineering it from scratch each time — meaning that in a short time they were gaining a return on their investment.

I have seen similar approaches in the software industry, where companies build a product for the market and then rebuild it again many times. They burn a massive amount of dev cycles, repeating the process repeatedly without realising a return on their investment.

The idea of building an MVP is to research and decide what are the minimum number of features that a product should have to make it usable, and able to provide benefits to the customer.

“A minimum viable product is a product with just enough features to satisfy early customers and to provide feedback for future product development” – Wikipedia

If you want to do some more research on this, read The Lean Startup by Eric Ries.

The person with the vision for the product, of course, will be a core pillar on selecting the MVP team. They will have an idea of the problem they want to solve and the solution they see. However often they don't know what needs to be cut from the MVP to get it into the market to be tested with real customers sooner rather than later. Therefore, you need others who can help this person see what needs to be cut as well as what does not need to be rebuilt repeatedly before market validation.

There will always be ways to improve what you have, but that should come once you are selling it in market and getting lots of regular feedback. You need someone on the team that has a deep understanding of the Power Platform.

Many in our industry come from a Dynamics 365 background and think that is all that is needed. But the earth is no longer flat people, and you need to update your thinking. Dynamics 365 apps are only apps running on the Power Platform, and dependencies on Dynamics 365 should be avoided if possible, in the design of your ISV product.

Another thing to consider: do you have someone on the team that understands Microsoft licensing and product direction? Who do you need in the team? I was involved in a project where one of the decisions at this point was to either get a team of developers and architects or use a single Architect/Developer.

It was decided to go with a single Architect/Developer. When I look at the most successful ISVs in our ecosystem, they have followed this model. The old saying applies too many cooks spoil the broth.

So that everyone is clear about what is needed, you need to design wireframes of how the product should look with features and functionality of the design.

In my experience, MocFlow is an excellent tool for this. It allows the model to be shared with all the stakeholders and the validation process can start. It will also allow you to assess what should be in the MVP and what should be put on a backlog for future iterations of the product you are building.

It's not a case of saying NO to an idea, but more of a not now.

The Architecture of the product is fundamental and should be decided by more than one-person’s view of what is needed.

For example, Microsoft has released the PowerApp Component Framework (PCF), but it has been in beta or development for a long time. Should you use PCF or the old way of doing it using web resources?

You need to consider how your solutions will be deployed technically, how will you manage licenses for your product? How will you scale your solution with Azure services, etc.?

As mentioned above, you will want to start with CDS at the core of the Power Platform and not Dynamics 365. You should look at Microsoft Accelerators and Common Data Model to see how they should make up part of your solution so that your product stays interoperable as much as possible.

You should use Dynamics 365 if your product NEEDS to take a dependency on a Dynamics 365 app, but you should ask yourself, can you “create the functionality yourself” in CDS, where you have 100% control over it.

In my experience you should set yourself a ship date of 9 months or less. With a great Architect/Developer on your team this should be doable. If not, I would ask is your MVP too big?  Can it be reduced with a heavy focus on the word MINIMUM!

You will want to set up a regular validation session to see where the MVP is at and the time to complete from its current build status.  That way there are no surprises. In Agile methodology you would look at the velocity and burn time to assess how things are progressing and how this affects your ship date.

The sooner you can get ten customers using the product, the better.  Regular feedback can be used to iterate your product to what the market needs.

I like this quote from the creator of Basecamp – Jason Fried

“Most of your great ideas won’t seem all that great once you get some perspective. And if they truly are that fantastic, you can always do them later. Lots of things get better as they get shorter; Directors cut good scenes to make a great movie. Musicians drop good tracks to make a great album. Writers eliminate good pages to make a great book.”