Designers probably remember the headlines and edutech companies in the 2010s practically pleading us to learn to code. Fortunately that’s over, but it really does help us designers to at least get a feel for coding so we can work more smoothly and empathetically with our engineering teammates. As a designer, I still code a little myself both at work and as a hobby.
The same goes with our product management (PM) teammates. We should “get” them and the work they do just like we “get” coding and the work engineers do, as the three of our domains together comprise the engine of product development. We wouldn’t be doing our due diligence as good designers if we just wait for PMs to tell us what to do, do our work in a bubble, and then tell engineering what to do. If it’s important to be fairly educated about how our design may be engineered, the same should go for how it may be productized.
How do we define design and PM?
First, what is product management, broadly speaking? At Truss, our product managers “lead teams to align around a North Star, embrace constraints, ship to learn, and deliver client and user value early and often.” They may seek balance in making final decisions between what the business needs, what the production team can build, and what customers and users expect.
Here’s a list of core skill capacities that PMs at Truss have aligned on:
- Product strategy
- First principles thinking
- Systems thinking
- Communications & storytelling
- Consulting & managing change
- Data skills
- Agile methodologies
- Driving alignment towards value
I especially like “driving alignment towards value” as a pithy way of differentiating the two “PMs”:
- Project managers are more internally (on the product team) oriented: coordinating and unblocking complex parallelized work streams.
- Product managers are more externally oriented: aligning the product team’s work to the client, the market, whatever is a driver of eventual value.
But I digress…
Our roles, including product management, have these skill capacities, and the people who fill those roles bring shape to those capacities. Design and PM share a fair amount of these capacities such that a designer and PM may actually have a very similar shape.
At a contracting company like Truss, we all have to be generalists to help anywhere, and also have different specialties so Truss as a company can meet a contract’s unique needs, whether it be engineering, design, project management, client engagement, or specific industry expertise. So we use charts like these to share our shapes, not to fill them all up to the maximum, but to help cast people to the right contracts:
Below I’ve listed those PM skills again along with those of our Design & Research practice. You might notice some similarities!
|Product Management||Design & Research|
|Product strategy||Design Strategy|
|Systems thinking||Systems thinking|
|Communications & storytelling||Communications & storytelling|
|Consulting & managing change||Consulting & facilitation|
|First principles thinking||Research & Synthesis|
|Driving alignment towards value||Discovery & Framing|
|Data skills||Content Design & Information Architecture|
|Agile methodologies||Interaction Design|
|User Interface design|
Most of the PM and design skills are nominally similar, if not the same! Granted, our experience using them is often different, so I’m not saying a designer can just swap in for a PM without building some experience first. But it goes to show we already have overlap, and designers can even practice these skills by framing their design work as product work, in collaboration with the team’s PM.
Why might designers PM?
As I said before, we should be educated about and appropriately concerned with how the work we do is made into a product or service and shipped. “Designers should code,” to some extent, because it’s important to know some basics of how things are engineered, or else we’d ask for the moon and then be frustrated when we don’t get it.
Similarly, “Designers should PM”, to some extent, because if we simply wait for a product brief to be pitched over the fence, do our work completely in a vacuum, and then lob it back over the fence, the product will probably fall flat and seem out of touch. Junior designers are excused here as you’re just starting to learn the basics and build experience; this is more directed at mid/senior-level designers.
As designers, we shape the product so it’s worth using and continuing to use. We’re the ones designated to focus on and empathize with the people in the PM’s addressable market, so that a business plan isn’t just reliant on technical capacity and business forecasting. There was nobody empathizing with how someone might feel about combining mayo and Cadbury Creme Eggs, they just realized they could do it and it might make some money.
In the—forgive me, Heinz—more “serious” work of designing government services or potentially nefarious products, that means we need to know how our thing’s going to go from a file in Figma to a real product or service, i.e. “productized”. Socially good, responsible, sustainable design entails broader thinking about how we make decisions that affect people.
That goes for our teammates too. Helping each other get work done, especially when we have overlapping skills, can build a mutual understanding of how and why we make decisions. If done well, that can propagate even more of those socially good, responsible, sustainable decisions throughout the product development team, prompting a major culture change from below.
How might designers PM?
All of this is my own goal for building my PM skill capacities, not to cast this as sage advice from someone who’s done it already. But, they are all based on work from the awesome people in the Design & PM practices at Truss.
Lean more into our strategic side
Collaborate with product management to determine the best strategies for the project overall and how design fits that strategy. Educate the client/customer on how design might impact their business, market, and policy ecosystem. Create a persuasive vision that addresses the problem space, risks, and how to measure the effect of design to those ends. Finally, be able to articulate all of this to diverse audiences, like the broader design practice.
Read more theory
While it’s easy enough to practice design and coding in personal projects, it’s not so easy to practice business without, well, a business. But there’s always theory and learning from examples on topics like business strategy, project management, stakeholder engagement. Pluralsight, Stanford, and UC Berkeley all gave me some good fundamentals along with miscellaneous articles on more specific topics. I also like the app FWD, as it chunks content in a way I can glance at on the train or couch, letting me learn in smaller spans of time rather than longer reads on a laptop. This theoretical underpinning was also a good way to figure out if PM was even theoretically interesting to me (it is, but not all of it, so again: nobody should expect to max out all the skill capacities).
Shadow PM and sales discussions
This can be an easy one if your PM (or any PM with some time) minds inviting you to meetings just to follow a discussion or watch how a task is done. I’ve done this on many occasions, and I’ve followed Slack threads to the same end. At Truss, as we expand our overall sales capacity, we ask some ICs (including designers) to switch to the sales team for a 3 month term to help identify opportunities, ask questions of potential clients, and help write proposals with the technical expertise that only an IC can provide.
Use that trust over time to take on some tasks
The easiest way I’ve done this is to help take notes in meetings, and I’ve made some journey maps with the sales team to figure out how things work. From there, it’s just a matter of using that experience to build confidence and take on more than just notes. One PM recently told me I’m already doing much of a PM’s job fairly well. I turned up the heat slowly, rather than saying “Hey can I be a PM on this project?”, as being a (well, usually the only) PM on a project at Truss is asking for a ton of work and responsibility. That was only possible over multiple years of multiple projects, so it was an exercise in patience and knowing how to find and take opportunities.
Free up some mental space and time
As someone who came to design from engineering and research, I’ve freed up some mental space for the above by relying on design systems like USWDS and my fantastic fellow designers to cover visual and interaction design. As far as the design/PM overlap goes, visual and interaction design are pretty deep in the “just for designers” category. So offloading that workstream has afforded me more energy and attention to adjacent skills in product management.
How might we influence PM but stay designers?
Short answer: same as all the above, but less intensely.
Researchers are swimming in context. Pair that context with principles of design justice to contextualize your findings and suggest better strategic futures. I’m currently trying to integrate this with our design practice as part of our charter.
UX designers can work more closely with stakeholders (business and users alike) through inclusive co-design and participatory methods. I recommend Creative Reaction Labs’ workshops for both this and my previous point to learn more.
Visual designers can invest in storytelling. Volunteer to overhaul a dry business preso if you can convince them to also let you do (some of) the presenting, bringing your voice to a room normally without designers.
In business, just being in the right place at the right time is a pretty big deal compared to our usual design work. Finding more ways to get into rooms with people in power means you are more able to push for something you want to change. When I was doing field research for my master’s degree, I was working with an organization seeking more equitable land rights and home ownership in a historically under-invested (and threatened) neighborhood. My purely being a designer who can make a deck of data visualizations and being affiliated with a major university was enough to help them get into a room with state policy makers. I was just there to support and amplify, and we both succeeded.
That’s the kind of teamwork that designers and PMs can achieve by sharing our domains. We could even co-frame all design work as product work if we consider our design practice or organization as a product or service itself. If design work should be based on empathy and justice, on both a practice and IC level, so should product management. This work is my way of making that happen as much as it is to just find new ways of getting a job.