Sheshachalam Ratnala — Thanks for the note. I understand what you are referring to. Let me try to clarify the thought process a bit more, behind coming up with IoP and its differences with value proposition.
- As I see it and understand it — Value proposition is a promise/statement, meant more for the users using the product. In simple words, it makes it simple and clear so as to why should they use this product. Now IoP is more intrinsic to the product itself — as if say, its the product speaking about itself (and to itself). Let me take an quick example of an enterprise product in healthcare- call it “ResearchGenie”. The value proposition could be — “Helping Researchers find quick biomedical information to aid drug discovery process”. Compare it to IoP — where it could be different things/statements depending upon what the product is really trying to do and which might not be always known to the user. Imagine it to be a product’s thought process. So if the idea is to sell more licenses quickly (which is a case lot many times in enterprise) then IoP could be — “Promoting and prioritizing features that will excite the C level folks (or the decision makers on whether to buy the licenses).” I have seen lot of such products in enterprise that bite the dust in one’s laptops/computers, once the license is bought in. No updates, no proper release cycles, no feedback mechanisms. Why? Perhaps their intent was to make money more than actually solve problems. On the other hand, IoP could have also been — “At the initial stages, help researchers see that our system has lots of quality data”. See how it contrasts with the 2000ft high value proposition, and how its more intrinsic to the product and its current phase. It need not be a statement like Value Proposition, that is openly talked or relayed with the product — but something that the designers, developers and the stakeholders define, agree and relate to. To summarise, IoP is more a language of the product and is phase dependant. Its formed by the team that is nurturing the product. It can and should transform/evolve over time.
- Another aspect of IoP is its dual nature of validity. This is where I drew inspirations from Sufism and the internal-external interpretations of any activity. So if my IoP was — “At the initial stages, help researchers see that our system has lots of quality data”, then I should validate it from both aspects. The external aspect is the usability, experience, aesthetic aspect of the product where the user essentially ‘feels’ good and confident using the product. The internal aspect is more a question to the product itself, whether it really has the quality data that it is promising? Has the team done enough with all good intent to add quality data in the system, that its boasting/promising about? Once both these intents tend to positivity, it can be assumed that the intent is fulfilled.
Thanks for promoting a string of thoughts relating to this. A lot us while building products practice this in our own unsaid and informal ways. Something which is there in the head of the product teams - but the idea was to capture it with its emotional value intact, so that we do not loose sight of it in the product cycle!