How to transfer knowledge — keep it actionable
At each step of service creation we are faced with information. Some of that will be useful in the later stages. How to pass it along? I claim that you need to keep the information actionable.
Easy way to keep enough richness in customer insight for example is to think that would an outsider of our project team know what to perform after finding this information. If the person should just shrug it off as meaningless, you have failed the handover as the communication sender.
It is easy to get lured thinking that the nuances are embedded in your bullet point for later uses, but they aren’t.
Information is lost by not acknowledging it is lost
I encountered a bullet point “Customer wants information from [the device]” in the wild. It was summarised there by the customer interviewer and reported as one of the results.
The problem is that it is not actionable. It is a summary and abstraction of the customer insight that was found in the customer interview. But it is not actionable. What information the customer wants? When the customer wants that information? For what purpose the customer wants that information?
As a researcher I observe phenomenas in the wild, and at this point I’m paying attention to this little bullet point detail in a much larger presentation. I finally see how information is lost in service creation projects. As a researcher I’m thrilled, but as project participant I’m horrified. Will we ever gain that knowledge back what was intended to be conveyed in that bullet point?
Solutions are varied.
You can keep the person who wrote that bullet point in the project team until end of the project.
You can keep contact with that person during later stages so they can clarify what they and the customers meant according to them.
You can add the actionable details to this information while you still remember them. Make it a user story or some other format.
You can teach the bullet point maker to write user stories instead of bullet points.
You can change the organisation or work so that less of the decisions are relying on somebody else’s bullet points.
Actionable information
Actionable information is something that tells us directly or gives us material to decide ourselves two following:
- Why is it important? And how important it is (presumably)?
- What can be done with this information?
Bullet point “Customer wants information from [the device]” turns into “While operating another device in the room the customer wants angle status information from [the device] to determine if the task is complete”
For example now the information tells us that the engineer who is able to program the interface for the device microcontroller, needs to open an API for the second engineer who can integrate this information to the another device screen, and all of this would make determining task completeness easier for the user, and the payer of this alteration needs to evaluate if it is important to work on — by balancing user easiness and development costs.
Make your information actionable!
