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.
“A minimum viable product is a product with just enough features to satisfy early customers and to provide feedback for future product development” – Wikipedia
Who Should Be Involved?
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.
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.
It’s not a case of saying NO to an idea, but more of a not now.
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.?
Common Data Service (CDS)
Timeline – 9 Months
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!
Validate Soon and Often
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.
“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.”