{"id":24,"date":"2012-06-11T09:45:10","date_gmt":"2012-06-11T07:45:10","guid":{"rendered":"http:\/\/www.matvoz.com\/?p=24"},"modified":"2013-03-18T20:53:54","modified_gmt":"2013-03-18T19:53:54","slug":"where-to-draw-the-line-in-adding-functionalities-to-the-product","status":"publish","type":"post","link":"https:\/\/www.matvoz.com\/blog\/2012\/06\/where-to-draw-the-line-in-adding-functionalities-to-the-product\/","title":{"rendered":"Where to draw the line in adding functionalities to the product"},"content":{"rendered":"

tl;dr
\nUse the wooden bucket water method (the diagram is at the bottom)<\/p><\/blockquote>\n

The problem<\/h2>\n

I come across this issue all the time. Even though specifications about what the product needs and what are the necessary \u201cingredients\u201d usually exist, there comes a point in the middle of the project each and every time, when somebody involved in the project finds a functionality that could be better than previously discussed and specified.
\nThe main concern is always about the future users. Every project has to be as easy to use and as useful as possible. But at what price? What do you do, when you\u2019ve already done better than projected but can still find some functionalities that would make life easier for the user?<\/p>\n

The example<\/h2>\n

One good example is my company’s last product that we are building at the moment. I can only show you the landing page for it Knowledge Management System \u2013 KMSadmin<\/a>, but I must say that I am really proud of it. Its purpose is to help institutions, e.g. Universities, to manage their know-how more effectively.
\nBut it is impossible to make a perfect product because of its sheer size. There will always be yet another functionality that could help the users. Just recently we\u2019ve finished polishing the connection between researchers and their projects. According to the specifications we\u2019ve done it far better, but we still found some improvements on how a user could find the right researcher for a new project by knowing his previous projects. Do we implement these or not?<\/p>\n

The solution<\/h2>\n

The first filter to define how much work will be put into the project is of course money. If nobody wants to use the product, there is no sense in upgrading existing features. The same goes for the fixed amount of money that you get for a product. It is possible to try a different approach, but if you run out of time\/money, it doesn’t matter anymore.
\nSo now we\u2019ve figured out we have the motivation and somehow limited amount of money\/time to continue improving. I like to imagine the project as a wooden bucket filled with water.<\/p>\n

\"Wooden<\/a><\/p>\n

The water are users and wooden staves (wooden boards that make the bucket) are the functionalities. Each stave has the height proportional to the quality of the functionality. So the water level in the bucket is only as high as the lowest stave or user happiness is only as high as the least useful frequently used functionality. The trick is to find the lowest stave and make it higher until you run out of time, money and\/or motivation.
\nHow to find it? Usually you or other developers will already have an idea where the low points in the product are, but when you need a proof, ask other stakeholders and actual users. It is also wise to implement tools for later analysis or to prepare metrics that will help you acknowledge the actual usefulness of the product.<\/p>\n

The diagram for the wooden bucket water method (yes, I just made that name up):<\/p>\n

\"\"<\/p>\n","protected":false},"excerpt":{"rendered":"

tl;dr Use the wooden bucket water method (the diagram is at the bottom) The problem I come across this issue all the time. Even though specifications about what the product needs and what are the necessary \u201cingredients\u201d usually exist, there comes a point in the middle of the project each and every time, when somebody […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-24","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/www.matvoz.com\/blog\/wp-json\/wp\/v2\/posts\/24","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.matvoz.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.matvoz.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.matvoz.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.matvoz.com\/blog\/wp-json\/wp\/v2\/comments?post=24"}],"version-history":[{"count":5,"href":"https:\/\/www.matvoz.com\/blog\/wp-json\/wp\/v2\/posts\/24\/revisions"}],"predecessor-version":[{"id":46,"href":"https:\/\/www.matvoz.com\/blog\/wp-json\/wp\/v2\/posts\/24\/revisions\/46"}],"wp:attachment":[{"href":"https:\/\/www.matvoz.com\/blog\/wp-json\/wp\/v2\/media?parent=24"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.matvoz.com\/blog\/wp-json\/wp\/v2\/categories?post=24"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.matvoz.com\/blog\/wp-json\/wp\/v2\/tags?post=24"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}