The Context-Driven Approach: Evolving as a Product Manager
Or, how to build confidence
I love community events and the opportunity to exchange war stories they provide. As I’ve no doubt mentioned in previous posts, I basically suffer from the opposite of the Dunning-Kruger effect; I’m all too aware of what I don’t know about product management, and I live in perpetual fear of making some kind of critical error or misjudgement that proves I basically have no idea what I’m doing.
Thankfully, 6 years in, that hasn’t happened yet. But there’s always a first time!
Anyways, community events (such as the Product Tank event I attended last week) provide a forum for sharing ideas, experiences, successes and failures, and I love to hear other peoples perspectives on how product work should be done in the various different contexts they’re working in. Last week, there were game developers, car manufacturers, fintech disrupters, early stage pre-VC startups, serial entrepreneurs and product managers of mature products (like me) sharing ideas in a lean coffee format. I already wrote about one of the questions I answered here:
Gandalf’s Wisdom in Product Management: Prioritizing with Purpose
One of the things about trying to write a weekly article is that the creation of the content needs to be prioritised against and above other stuff that might otherwise get in the way. Last week it was illness, blergh 🤧, which it was difficult to do too much about, but still, the principle holds. I’ve written a few pieces elsewhere and at other times ab…
One of the defining moments of the event for me though was talking to a peer about my lack of confidence in the PM space, and what, if anything, I could do about it. The advice given was very simple: move around a few different companies or products.
That sounded incredibly wise and obvious. Of course you can gain confidence from moving around a lot. In fact, that’s exactly what I did as a software tester and what gave me confidence that my craft could be applied successfully in a range of different contexts. I moved from contract to contract, and marketed myself as an expert because that’s what I brought to the table. Expertise in the identification and application of appropriate software testing techniques to the context into which I was engaged.
The trap into which I’ve fallen as a product manager is to remain somewhat static. Applying the same tools to the same product, in the same context over a long period of time. There’s been no variety; no change in context that’s required me to adapt or evolve my toolkit. Or very little at least.
Assuming that I stay in my current role for the foreseeable future, what can I do about that? What are some ways that I might switch things up a little, in order to gain the desired confidence that I really do have product management chops, and that they could conceivably be applied in whatever context I find myself?
There is or used to be a school of thought within the software testing field which embodied the notion of being “context driven”; it basically means that you should seek to apply appropriate techniques based on the context in which you find yourself. Sounds a lot like what I’m trying to accomplish, right? So, what would context driven product management look like?
For better or worse, I’ve tended to adhere to James Bach’s teachings in the software testing space, and it’s from his work that I’ve learned most of the principles I applied to a somewhat successful software testing career, over a period of about 10 years. It’s to his (and Cem Kaner’s) manifesto I’ll therefore point, here:
The value of any practice depends on its context.
There are good practices in context, but there are no best practices.
People, working together, are the most important part of any project’s context.
Projects unfold over time in ways that are often not predictable.
The product is a solution. If the problem isn’t solved, the product doesn’t work.
Good product management is a challenging intellectual process.
Only through judgment and skill, exercised cooperatively throughout the entire product lifecycle, are we able to do the right things at the right times to effectively deliver our products.
I’ve swapped out software testing references for product management ones instead. I don’t think any harm has been done to the overall premise. You can let me know in the comments if you disagree.
You might reasonably answer that the principles above don’t provide much of a steer as to what the techniques to be applied actually are (the right things to do) or when (at the right times). But that’s kind of the point; it’s a philosophy, a way of thinking. It’s not a toolkit, nor is it intended to be. Quoting from the article again (with modifications in bold):
My task is to do the best product management I can under the circumstances. The more techniques I know, the more options I have available when considering how to cope with a new situation.
That’s what this blog is all about. Me figuring out how to do the best product management I can, in whatever circumstances I find myself in, and exploring what I need to know or learn in order to accomplish that. I certainly don’t see this as a final solution to the question of me being the best version of whatever a good product manager looks like, that I can. It’s a step along the road though.
Going back to the question of confidence; as the modified principles above seem to state, doing good product management boils down to finding and learning about the techniques which can be applied, and the application of skill and judgement to best determine under which circumstances they should be applied.
In theory, so long as I’m learning the relevant techniques, and experimenting with their application (in a safe to fail environment), confidence should follow.
I’ll let you know how that goes!
