KPI FOR DISCOVERING TOOLS: VANITY KPI OR PROBLEM SOLVING TOOL?

I am posting this stuff now because I dreamed with this, really… I just woke up with the idea and start to write quickly ‘cause it is a very important sh… perhaps a new KPI to understand issues caused by one of the upstream’s stages called DISCOVERING. 

It is not common to measure THE TOOL USED FOR DISCOVERINGS but it could really matters. Do you know what kind of tool your PMs, POs, BAs (or other pompous name you have in your company) are using? And most important: do you know in what kind of demand they mainly work? BUSTED! I could bet not, for both questions. How many times some XPTO tool was used to discover some types of issues?

Imagine a situation: your DEV teams are complaining about misunderstandings in what they must do and this is creating a lot of blockages, then when your talk to the upstreamers you face the reality that they are using simple tools (like only their own head) to discovering and storytelling the stuffs. And now you can question: what if they use a more robust or more complete tool as Lean Inception, Canvas MVP or some kind of a good tool for the storytelling? 

Imagine another situation: you just discovered that your upstream (I will use on this term now to facilitate) are using mostly Canvas MVP as a discovering tool, but you also realize that the work with a lot of issues (bugs, errors, etc) created by the application support teams – yes, we are talking about a mixed upstream because in the real world we do not have only the perfect and “fairytaled scenarios”, innit. Now you could question yourself: are they really using this tool like a bazooka to kill flies or are they lying? 

Did you get the idea?

There are a plenty of situations to show here and also a plenty of tools but the objective now is only to get the idea of it. Regardless of the scenario you can take a lot of information to better understanting the situation and defined what king of tools or trainings your upstream needs. Collecting this numbers you will be able to know the points of failure without look “to the names” and also create a plenty of cross-reference information to solve problems or issues in the very workflow. 

Remember kids: we can't fix what we can't measure!