Take me to the moon
What do you want done? Communicating that is the essence of any product managers’ job, but finding the right level of abstraction can be hard.
Having a human being set foot on the moon can probably be regarded as our most ambitious venture ever. It involved thousands of individuals and couldn’t have happened without a myriad of sub-projects and complex collaborations. It was initiated in a speech made 1961 by John F Kennedy, where he said the following:
“I believe that this nation should commit itself to achieving the goal, before this decade is out, of landing a man on the moon and returning him safely to the Earth.”
That’s got to be the most condensed specification ever. A brief in every sense of the word, it could almost have fitted into a tweet.
I thought of that this morning when I heard Ken Sandy talking about “the death of the specification”. Ken teaches product management at UC Berkeley and is a silicon valley thought leader when it comes to all things product. He’s also a great speaker and a charming guy, so it’s easy to pay attention to what’s on his mind. (It’s the second time now that I hear him and I really must get around to buying his latest book)
Ken says the spec is dead. Then he says it isn’t really dead, it just kind of smells funny. Then he comes full circle and basically says this: Look, we still need specifications but the old way of doing them doesn’t work anymore, if it ever did. They tend to be too long and too boring, so they get filed away and nobody really reads them. Also, they’re spoiling all the fun for the development team, because where’s the creativity in just simply executing on someone else’s blueprint for a solution?
So where does this leave us? Well, says Sandy, product managers need to make themselves comfortable in the problem space and focus on providing the team with context and with a clear idea of what success looks like. They must not fall for the temptation of being prescriptive ‘backlog managers’ but instead zoom out and always make sure that the right problem is solved. In Ken’s words, they need to:
“elevate the conversation to impact over specifics”.
I like the sound of that. I really do. The concept also isn’t new. I’ve personally been very influenced by going to courses with and reading books by Gojko Adzic, who in his turn claim that he invented nothing new but copied all from Eric Evans, the father of Domain Driven Design. This field, which can also be referred to as Behaviour Driven Development, seems to come close to the concepts that Ken Sandy promotes (and as with any good evangelist, he makes it feel fresh and interesting again).
So yes. In principle I do agree. But I’ve also got enough battle experience to know that it can be really really hard. In fact, I’ve spent the day pondering whether there even is such a thing as a sweet spot between the spec that is too specific and the one that is too abstract.
I mean, think about the moon-shot example. Sure Kennedy’s vision was both brief and exciting. A real “epic” in the parlance of Scrum. But in order for it to not just turn into hot air it had to be interpreted by a huge pyramid of managers.
It’s easy enough to imagine how the JFK-brief expanded through every layer of hierarchy until it must have been mind-numbingly detailed. It’s hard to see however, how the same thing wouldn’t happen today inside SpaceX, when Elon’s team is scrumming to execute on their bosses’ grand vision of putting humans on Mars. In short: isn’t it the nature of executing on really difficult problems, that parts of the process of getting there must be “boring”? The devil is, after all, in the details.
That’s not to say of course that there’s no need for visions, preferably embodied by great charismatic leaders. Perhaps the conversation that Ken and other product thinkers are helping us have here, isn’t so much about the changing nature of a specification, as it is about the changing nature of a product manager.
One more factor that risk destabilising the whole conversation is the trend towards products behaving more and more like services. To be clear, I don’t see this as a threat to product professionals per se. They might find themselves changing titles but their toolbox’s will be just as valid in a service-centric world.
So if I had a bone to pick with anyone (as the British put it), perhaps it would be about the semantics we’ve all come to take for granted when we’re talking about our community of practice. Because what unites us isn’t necessarily the fact that we’re all dying to work with products. Instead I think it’s about the drive to create something truly useful and about having the skills to bring teams together to make that happen. Sometimes that means you have to dive into the nitty-gritty details but just as importantly, some times you need to be able to zoom out and help people get the big picture:
“I don’t care how you do it, just get me to the moon damnit!”
This text is part of an ongoing series of thoughts provoked by the excellent Productbeats-seminar. Earlier posts include:
- “What I think about when I’m thinking about design” inspired by Guido Stompff’s meditation on the essence of the designerly way of problem solving.
- “Product people will get os out of the fix” inspired by Adrienne Tan’s thoughts on how and why challenging times often lead to renewed creativity.
- “Go figure” inspired by Thom Thavenius’ thoughts on what we can learn from how intelligence agencies turn information into insights through systematic (and creative) scenario planning.
- “Nobody said it was going to be easy” inspired by Roman Pichler’s thoughts on more and less successful conflict resolution styles when trying to mitigate the needs of product stakeholders.