- All Hands on Tech - Your Reality Tech Newsletter
- Posts
- Just show me in the system
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