Imagine building a new recipe without getting feedback from your critics and key customers! Product development is much closer to building a new recipe than to mass producing McChickens. Its a continuous journey that requires constant course correction and one needs to know if he is on-track to building a great recipe[sync] and later, if he has arrived at his final recipe [convergence]of finger lickin’ good.
“Demo” is that revealing moment where you let your key customers and valued critics to taste your dish. Tasting a dish has no assumptions as you actually taste the food; it’s not a recipe or an abstract notion, it’s absolute. Same is true with an actual demo of a software.
‘A demo is a showcase of a working product. It brings the abstract to reality.’
Before this demo, all the participants (devs, PMs, designers & business) are imagining their own versions of what a product would feel like. Best way to remove these assumptions is to demo the complete experience. With the ability to experience the product; discussions between the team & stakeholders are much more objective & clear.
It is this revealed reality in a demo — in the form of a product/dashboard/KPI increment which enables anyone and everyone to give feedback. For example, in a demo of a new method of data visualization of Go-Jek’s supply side — everyone including the operations, customer support, marketing and leadership, can process the information together and understand its nuances. This enables them to instantly connect the new tool with multiple different applications in each of their domains. We receive meaningful feedback, see the potential for business impact and possible extent of its adoption. Since it’s a synchronous review, the demo participants are able to build on top of each-other’s feedback bringing both width and depth in the evaluation.
Our data engineering (DE) team at Go-Jek has used demos as a means to multiple ends. Usually data engineering teams have a very tech oriented roadmap and most if not all its customers are other tech teams. With demos we have been able to create far higher engagement with business and product organisation than it would have been otherwise possible. It is a unique platform which allows our data engineers to interact directly with customers, stakeholders and leadership, and ensures that there is a high sync among all with our roadmap. It’s the best way for us to get instant feedback and quickly teach our customers on how to use our tools, thereby inculcating a high level of accountability in the team. Regular demos also concretely show progress being made in the right direction. And finally, it gives us an opportunity to celebrate our solid results.
We have personally experienced the quality of interaction with our stakeholders significantly improve since we introduced regular demos. From questions on what are we contributing to the business, the discussion has moved on to how we can use the various DE tools to solve the key business needs. We strive to achieve a state where these demos are presented as options(not solutions) so as to initiate discussion and deliberation to solve our key business needs.
It is, however, appropriate to issue certain caveats here. If you pressurize yourself to showing progress every week then you may become myopic in your execution. These demos are best done when you have a completed piece of story and showing anything less for the sake of a demo doesn’t cut the mustard.
To summarize:
Do’s and Don’t of Demos
Why Demos
Finally going back to one of the 12 principles behind Agile Manifesto:
Working software is the primary measure of progress.
A demo is a silver bullet in an engineering and product team’s arsenal. Use it abundantly!
-----------------------------------------------------------------------------------------------------------------
This article was written by Prasun Jein and originally published here.