Just show me in the system

How to use Powerful Show in Tell for Requirements Engineering

I don’t know how many hours I have spent with video conferences that explained me on power point level how a potential application could look like (or not look like). What benefits I can get from using it and so forth. The same applies to theoretical ideas about benefits of using the cloud (or not).

Yet, almost 99% of my day consisted of exactly this format. Power Point, Teams Meeting, Phone Calls - to understand an abstract idea.

Some years ago I came across some pretty good product owners who showed me how abstract ideas can be communicated on another level:

These major topics were my Golden Take Aways:

  • Features and new functionality was always shown in the system - the more complex a feature was, the more time was spent on explaining what the goal of the feature was. I just want to be 100% clear: It was not a power point and I insisted on seeing it in the system

  • These Show & Tell sessions were used not only on application level, but also platform teams and sometimes I even asked it in the management team

  • To stimulate discussion, other similar features were shown e.g. from other systems / competitors etc. to open a dialogue about what might make most sense

  • Communication about features and functionality was exclusively done in meetings, workshops etc. Documents were only used to document the outcome but not to align & create commitment

  • Before we dived into new features, all items/features etc. from the previous cycle were shown and the impact it had based on simple data e.g. 20% more people clicked on the button than before.

  • In case you wonder - I used this approach on custom software, SAP and SaaS collectively :)

All this sounds easy but reality shows, to implement these ideas and bring everyone into this working mode requires resilience, a lot of convincing and most importantly: the willingness especially by management to dive into applications, features etc.

Let me know what your best practices are for successful requirements engineering.

Your,

Sophie