Most often in organisations we would want to create vision statements on certain capabilities that we want to achieve. At times this is in full display at coffee stations , common meeting points and in the stairways. At times these are simply in the form of certain xls sheets or mind maps tools which gets debated endlessly and post consensus are put down in ink on what gets on the plate first and what will be consumed later. All of this has umpteen rounds of discussion on what looks better and is lean and mean and is doable in a certain time scale. Most often what is seen of very high impact is what drives user experience lets say improved UI tools to solve the customer pain points in terms of customization / deployment or integration issues. We may have tweaked a certain algorithm deep down in the code which may improve database caching and save round trips end to end and improve performance. But this can at times go as a should have been done in the first place theory and what delights the customer is what he/she sees to use or touch etc. So it is beyond reason to debate what the customer likes and catches his attention. Most often have heard old timers whom I worked with saying customers were happy with character based terminals instead of browser / web enabled mechanism which improved tech quotient of the software but greatly increased the time taken to key in details to punch in a transaction detail on the screen. The customer in this case doesn’t care if you used jsp/ROR/Scala/Coffeescript/node.js or Ajax or html etc he is forever cribbing on missing his character based system. He was quite accostomed to inputting all of this without leaving his keyboard and now he needs a UI to distract him and has to leave the keyboard to do most of his tasks. You can justify saying we upgraded you to the latest technology but he would say a different story , you downgraded his precious user experience. This is beyond us when we are onset with different challenges to embrace the shiny new thing on the block at times driven internally, at times forced by a customer, at times marketing and sales driven. So in short we most often from time to time need to check what looks good on our roadmap or radar.

Build your product roadmap/radar 

Was reading an article on the same from Neal ( Thoughts works ) on how they build a technology radar . Could see that this can be used in many organisations not just as a technology radar and in fact as a product radar to paint your picture to your folks. Most often this exercise is tough and challenging as now if you as a team commit to doing something and is on the radar then it is for everyone to see and measure where you reached. It brings people to commit to items on the product stack and keep them motivated towards their committed items. Of course you would need other factors to keep people motivated and that would be another story. For now lets say it helps people to focus on the vision statement and keep them hooked to it. 

Lets say we could apply this radar to a product roadmap. If we were to consider our product to a banking software tool , since I have worked most time on this domain. Lets say we have different product divisions (Corebanking/CRM/Channels/Treasury) internally in the company that wants to track their progress and what looks good going ahead and what needs to be watched , what needs to be dropped. With our fascination for quadrants and the following radar mechanism is handy to view where you want to go and provides a pictorial representation behind all the discussions that went into making this chart happen.

There is a nice explanation on the whole process of making the radar on what the different arcs represent such as nice to haves, must haves , trial and error pieces for the period and on hold items. All there is a nice thing that if you see some items as not having moved up the discussion from nice to haves to must haves then they simply fade away. Can be re blipped  when needed back on the radar. There is a nice little tool https://github.com/bdargan/techradar for plotting your radar which uses a JSON format structure details which internally uses polar co-ordinates to plot the radar. On the process and the details of how to arrive at this radar in your organisation Neal’s article is a nice read. on the thought works approach. My personal experience has also been same in terms of the consensus approach finally the person closer to the technology or the domain guys to have a major say. This apart if it is a pressing need from product strategy or marketing then it overrules all.

Go ahead build your own radar and it would be nice to hang around places where people spend time most else it will simply become a vision statement without follow up.