Minimum Viable Product, Need for today, Necessity for tomorrow

Every one wants to launch it big, hugely big. A hype, A marketing base, plans and communications , blah blah blah.... in an attempt to make this big.. there is always a lot of bigger effort spent.. the bigger the effort the bigger the issues. Thus bigger your first version, bigger the problem. A while ago working with my current organization, I saw that the Team decided to build something new.. a shorter / mini version of a content management system, more robust , more architecturally strong, more envisioned. Perhaps the first version was a very very primary version.. a version that would just do the needful. There is no doubt that it was hugely successful. Bought by a major giant , having some real cool features, and scope to add new things in near future. All of this went by because of the simple and pragmatic approach was taken "Build what is atmost necessary".

We learnt, a bit late but we learnt it hard and well. We now start to work on a new feature addon to the system, A feature that would change life of the system and usage and sales and future. So I decided to ask this question to those selected few who are key and critical developers.... My question was

" What should we build? A Elephant or the sledge runner?"

The Team threw up all their ideas, brains and pros and cons.. in the end they concluded that the smaller they start and make it available the better they can make it for future. Experience backs it well. Define the minimum needs, instead of acting greedy and building everything in once. Avail the real-term feedback and then improvise. Define what is minimum instead of going with "Customers want this" because in the end customers dont know what they want.

Thats what Agile says, isnt it? Build in small phases , deploy regularly , get feedback and improvise?

Then came another question...

"How to define that Minimum of the Minimum Viable Product?"

A tricky question. I am sure this needs a better thought process than just a definition of X, Y and Z items. Its a iterative process that needs to be defined, Ask the question "Am I there yet? after every few days when you are defining the requirements."

I remember we did a documentary a couple of years ago... We started with a script that was conceptualised to be a city tour, it turned that we needed a proper theme to get attention of the audiences. We changed it. Then came the phase where decided cast of the documentary, we thought its too much, we changed. In iterations we went on and on to make a minimum script that would help us make a small piece that we could show others. As we progressed, we changed a lot of things based on the feedback that came out of the process. In the end it turned out that we were closer to make a commercial drama to make what it needed "Gather Audiences, and Get Applause". I know thats what they do with those Hollywood shows and movies.

A lot of times we make decisions driven by demands and not needs. MVP techniques you to help build a basic expectation first.

So when you plan for a feature, product ask your Product Owner on what is the MVP of the whole thing....

More on Minimum Viable Product here