OK bear with me while I say “I’m going to start blogging again” and proceed to deliver you a rambly post about treasure hunters and product management. No editor to stop me! This has not been proofread.
In my personal mythology, I think it’s very auspicious to see treasure hunters on the beach. I’m inspired by their tenacity and hope, and how they discover carefully and respond rapidly with feedback loops throughout.
They have found actual treasures like ancient gold coins that most people have never touched, never mind being the first person to see that special item for tens or hundreds of years. And they don’t give up! They work well away from other treasure hunters, but they go together to toil, commiserate, or celebrate. It’s serious work, but they have good humour about it.
Scanning then digging
At the start, they broadly pan the detector around, slowly stepping and swiping just above the sand. Observant and focused, but deliberate. They pay attention to even the slightest hint and check and compare.
But when they get a solid lead the pace picks up. They start to dig. They get down on their knees, and they start to dig a little, listen a little. Dig a little, listen a little.
There’s NO POINT in digging further until you get some feedback. Are we going in the right direction?
I’m inspired by their alertness and grit. I think that I aspire to be like that. Acting, but getting feedback, keeping moving. Picking up the pace when it’s needed, but never forgoing discovery, feedback, and rest.
Scanning: Discovery and evolutions
Is this a parable about service design and product management? Yes.
I’ve been working in consulting for small to mid-sized digital agencies in training, marketing, user research, and market research. One thing they invariably have trouble “selling” is discovery, research, analysis, workshops, user interviews, community building, etc. They are paid to BUILD SOFTWARE.
I think the correlation of that within a wider organisation is to measure output on numbers of commits, or *gasp* lines of code. (I know someone out there has probably done it.) What about the work to analyse the potential impact of a technology decision? What about experimental and discovery work? What about ongoing learning, discussions, code review, and mentoring?
My colleague Matthew Wilson came up with a riff off Apple’s “Swift Evolution” Process. This process produces a document that proposes a change. Over time the evolutions have a tidy history of major decisions. It prompts you to review prior proposals, which helps you understand “why” things are the way they are. This is the technology and delivery side of the scanning process.
Usually, this research and decision-making is done by engineering leads, but in my last team, junior developers jumped at the chance to try their hand at researching, spikes, and experimentation using this method.
It also walks through socialising an idea as well as analytical steps to take. It’s also learning and development in practice for the developers. So it’s a truly social and situated form of deep learning.
Overall, this work is deeply satisfying and builds confidence and a shared understanding. But it doesn’t show up in lines of code. In fact, if you work this way, you can actually build LESS and make it more sustainable, flexible, and scalable.
How exactly do you measure building less? (genuine questions!!)
The burden of your assumptions
The alternative to scanning and discovery sounds ridiculous, but we do it all the time.
However could treasure hunters get it right if they set out in the morning, picked a spot and just started digging? It doesn’t make sense. We wouldn’t expect them to know everything. They could make a guess based on the tide, recent weather, and rumours.
Like the treasure hunter, we can’t set a course from the start. Instead, take a wider view, and observe.
I’ve seen backlogs and task lists with years worth of work in them. Based on all the grandiose ideas we have now, with the knowledge we have now, limited by the context in which we’re in now.
Later it’s going to feel like a drag. It’s boring. It’s an old dusty idea. If it’s a good one, it just makes you feel bad you didn’t start there sooner.
It’s like an “I TOLD YOU SO” to your future selves.
Learn by going where you have to go
Have we learned nothing from Covid? Could someone have set a course pre-pandemic and stuck to it? No.
Your master list of all your features will become what I call “idea debt” you have to pay down.
Jessica Abel related idea debt to the sunk-cost fallacy.
What happens when you carry Idea Debt for too long, and your life moves on, is that your idea hangs on like an albatross. You can’t move on to new, exciting, more mature work, because you promised yourself you’d finish this thing.
Jessica Abel https://jessicaabel.com/idea-debt/
Working this way, to an old crusty idea log, you never feel like you have room for discovery or play. It’s just a plod of delivering on ideas that may not even make sense anymore.
So the alternative is to learn by going. Don’t overplan or think. Start small. Do less. With greater impact.
I learn by going where I have to go.
The Waking BY THEODORE ROETHKE
nearlythere 