Connecting the Digital Dots
by designing learning experiences for digital product management teams
In the fall of 2014, I was hired as a Corporate Training Designer for the Enterprise team at General Assembly — specifically focused on developing our digital product management (DPM) offering for Fortune 500 clients.
Since then, I’ve designed digital product management education for more than 10 product teams in various industries at various stages of maturity. I’ve worked with brilliant subject matter expert instructors, interviewed countless digital and non-digital product managers and their stakeholders, and read articles, books, and the musings of many experts that I haven’t yet had the pleasure to meet.
If this time has taught me anything, it’s that success as a DPM is highly contextual and as soon as you think you’ve figured it out, you learn about a nuance you hadn’t even considered yet. Time has also taught me that a solid DPM organization plays a critical role in digital transformation, perhaps the MOST critical role, and that well-designed learning experiences can accelerate the turning of the proverbial battleship.
This post is an exercise for me in laying out some of the broad problems that the organizations that I work with are facing and how I’ve come to think about approaching these problems. It should go without saying that this list is not exhaustive and I’ll probably run into something I’ve never encountered when I go back to work on Monday — but that’s what makes this work so challenging and awesome, right?
Three common challenges:
- Leaders struggle to define and communicate what a DPM does and the value DPMs provide as it relates to their unique organizational context.
- Teams crave clarity and alignment around what they should be doing to bring ideas and products to market.
- Individuals need to overcome the inherent struggles of working in complex, highly matrixed and regulated environments (with very-little-to-no positional authority).
DPMs “live in the grey”
A few years ago, I left my work in a learning operations role at F500 company to work at a mid-sized organization somewhere between “start up” and “end up”. It was a messy role that changed direction just about every day and I had little to no control over anything. The leader of my function used to say that I needed to “get comfortable living in the grey.” That experience is what prepared me for the real startup world and is the foundation of the empathy I feel for DPMs.
Because these DPMs operate in environments of high ambiguity, I have come to believe that the foundation that they need is the product management mindset, not a complicated framework of processes. They need the ability to identify assumptions and test them quickly, the confidence to do what needs to be done (whether strategic or tactical), and the smarts to recognize when not to move ahead with an idea.
With every one of the teams I work with, the DPMs crave clarity and alignment. They love processes! They love frameworks! They love tools! They love org charts! They want it to be as black and white as possible… and that’s really hard if not nearly impossible.
There is no consistent definition of digital product management
If you’re in this line of work, you’ve seen the venn diagram from Martin Eriksson over at Mind the Product. For me, one of the challenges with this model is that those overlaps are pretty big and extremely vague. There’s a ton of variation that can exist in the “you are here” part of the diagram, not to mention the other overlapping bits.
Short story: the question about what a DPM does is not easily solved with only this picture in mind. But, when I started viewing this diagram as a starting point and used it to diagnose the contextual nature of the team I was helping, it become more useful to me than any competency model would have been.
In addition, when adding on the additional layer of the Product Management triangle, the grey became a little more defined. Imagine a version of this triangle INSIDE of the ‘you are here’ section of Eriksson’s venn diagram:
A few months ago, I had a conversation with Laura Klein about her blog post, “Who does what on product teams?” and aside from being a delightful conversation, it greatly informed some key beliefs that I’ve brought into my work.
Caveat: these insights relate specifically to DPM organizations inside of large enterprises who are not digital-first while Laura’s article is more relevant for small or mid-size companies that are more likely to be digital-first.
The scope and responsibilities of a DPM role is largely informed by three things:
- The history of the team on which they work: For example, if the organization started their .com site as part of the marketing function, these DPMS probably have a role that is less technically focused and more brand and community-oriented. This would skew the balance of the venn towards the Business/UX side vs. the tech side.
- The type of product on which they work: Much like a doctor has specialties, the same depth of knowledge or skills may not be required for all digital products. For example, if you are a product manager for an API, it’s highly likely that you will need a deeper level of technical expertise than say, the person in the .com example above.
- The type of development process they use: In much of my recent work, the question about Product Manager vs. Product Owner has been a point of contention. As if transitioning from waterfall processes to Agile isn’t hard enough, it has created another nuance to what these DPMs are responsible for and an entirely new set of ceremonies in which they may or may not participate. For example, one of my clients chooses an APO from a roster of people who have their hands in the product’s management — possibly the DPM but likely someone else — and that person may only be the APO for a particular sprint or program increment. This means that at some points you are involved in the development of the product, and at other points you have no involvement at all.
You are not the “mini CEO”
If you’re familiar with the Eriksson diagram, you’ve probably also heard something about the product manager being the “mini CEO”, having authority and ownership over the strategic direction of products. Well sorry folks, I’m gonna have to side with writer Ale Carlos here and say, “not so much.”
As he so eloquently puts it:
At it’s best, this statement transmits in an extremely simplistic manner this very ambiguous and amorphous role and at worst it sets incorrect expectations to people who have never done the role and/or attracts the wrong people.
At the beginning of the article he attributes the line in part to General Assembly and he’s correct. In our campus courses, “You are the CEO of your product” is one of the foundational ideas. Without getting into a ton of detail, I’ll purport that in a startup or a smaller company, this is more likely to be true, especially for the entrepreneur who is managing their own product.
However, I need to point out that it is not a mindset that we espouse in our work with Enterprise clients. DPMs in big companies are certainly not the CEO of the product, in fact, they usually don’t even manage a P&L. These organizations usually have non-digital product managers aligned to the lines of business, and it is they who are responsible for strategy and direction of products. One of the biggest obstacles DPMs must overcome is that their non-digital counterparts view the digital aspect as only one small piece of the overall experience. They’re also likely to have competing goals that are measured by contradictory KPIs and have no authority to change it.
There isn’t one framework to rule them all.
The variations I described above are just a piece of what has made it so difficult to create a standardized framework around successful digital product managers: No model is universal because it all depends.
And because it all depends, a large part of my work is creating a custom framework for each individual client and then designing unique experiences to support it. There are just too many variables to do it right, unless like Pragmatic Marketing, you’re going to drop into an organization and train every single role and give them all forms and processes to follow. For my clients, that’s just not feasible and it’s too culturally volatile.
As my friend Matt LeMay wrote,
The traditional “profile” of a PM is often frustratingly narrow. We owe it to ourselves and our organizations to invite new perspectives into this role, to look beyond superficial subject matter knowledge, and to think critically about the core skills that make a great product manager.
DPMs don’t need to be told what to do, they need to be taught how to think creatively and solve problems. They need to internalize the mantra of “Outcomes over Outputs” and align their work to the organization’s strategic vision. Once that new mindset is embedded, it can be supported by consistent knowledge, skills, and tools.
By bringing people together, in a room and breathing the same air, we can generate the dialogue and context necessary for figuring out specifically how the DPM role can add unique value for an organization.