Mapping territories of investigation

When an epic is dropped in the backlog that's too broad, full of unknowns (in terms of value to the business, to the customer, and tech feasibility) it's gnarly to progress, as everyone see's something different.

Epic = 'Automated content curation - extract useful content from places that have lots of content'.

Starting questions:
1. Can we know what content needs to be found?
2. Can this be automatically found and curated?
3. Can we tag/index it for distribution?

Mapping the territory is a first attempt to plot the areas we need to navigate, and identify risks and dependencies.

Here we came up with a framework for a list of vendors and tech solutions that work in this space. We then tested these solutions in each area, to explore value.

Vincent's work flow

 Vincent's explanation of his work flow. Our first 30 minute conversation for me to gain understanding of his role and process. I'm looking for what he is unable to do with the current tools.

Vincent's explanation of his work flow. Our first 30 minute conversation for me to gain understanding of his role and process. I'm looking for what he is unable to do with the current tools.

It can be quite the task to get to the bottom of things, especially if new to the company (process, acronyms, tool names etc). Core questions are 'what are you trying to do', 'how do you do that', 'how can it be better' - identifying pains and gains along the way. Working on-site gives the luxury of future check-ins to refine the understanding. If it's complex and I can see them numerous times, I let people talk and build on it later, as too many questions can be disruptive and widen the scope of unknowns. I go away, map it, take it back and validate it, 2 or 3 times if need be. Better still, shadow them for a day.

Taming the ambiguity

Image from Visual Function by Paul Mijksenaar

Complex systems and cross-skilled people inevitably brings ambiguity to a project. What's the problem exactly? How are we doing this? I recall in-house product departments (100-200 people), with plenty of strong opinions on who to listen to and who to ignore (stakeholders, staff end users, back room silo'd departments). How can they decipher? Why are they editing inputs for me? I just want to listen to everyone at first. Negative or difficult opinions can be read between the lines, exposing anxieties and concerns. When the problem isn't clear, it's chaos. And then people want to see progress already. I find mental modelling sketches provide a powerful tool for plotting the territory and steering conversations. To frame and contextualise the cacophony of requirements, concerns, old habits, opinions. It's an interesting and challenging phase of a project - yet people respond well to a simple diagram, and of course it evolves. It's a very human space. Messy - as people often are.