When it comes to creating a product, one of the principles I learned from a really old school tech guy is the Information model.
If there were a strict rule to apply to any business we would have taken arithmetically less time to sink into capitalism. So choosing which model to use in a given situation/project phase is either a sweet pleasure of an unknowing rookie. Or a sweet pleasure of an experienced product manager. This is because most of the time no exact method is applied. Due to the fact that The Work itself spontaneously organizes itself and its participants.
But in case you are one of the folks who believe in organized processes this text can help you.
In the below example a feature discussed is an Admin overview of stock products in an e-commerce platform. So the row, representing this feature, within the Information model would look like this.
The role of the Information model is to simply structure the data inputs and outputs from every functionality.
The place of the model is at the very beginning of the feature development. (before Backend, Mockups/Design, Frontend).
Why is this a good information model?
Developers are more prone to liking it because they don’t have to think a lot. And also they don’t have to ask additional questions compared when dealing with visual-first feature proposal.
Say a developer receives a mockup (below) as a feature proposal.
As an output, he/she needs to come up with an estimate and successfully plan the development work.
This person might come up with the following question:
- Do we display the exact data as drawn in the example or we need more details?
- Do we need paging or lazy loading or nothing?
- Which data is mandatory for input of a new product?
- What is the default listing of items?
The questions would have as consequence another feedback loop which would delay the beginning of implementation.
On the other hand, as the IM follows a bottom-up path of the actual feature existence (BE, FE, Design) the developers feel more prone to it, as, for the core beginning of the feature, Data is more important than Visual.
If the Client or Product person is thought to start the feature implementation with an Information model, consequent feedback loops could be used for visual alternations, while ground BE work is on its way. Given the person owning the feature has the right information it is also cheaper in time to write an IM feature summery compared to making several pages of a visual feature, which can ask more questions than providing answers to.
It’s best to use this model when crunching heavy Backend features down the roadmap from a Wishlist of Use Cases to actual functionalities. It also works well when the goal is to have lots of features covered by BE and their visual appearance is of secondary importance.
Of course with these tools/models, the value comes to actually using them not being smart about creating them. So, there you go…